Chaos Engineering 완전 해부 — Netflix Simian Army, LitmusChaos/Chaos Mesh, AWS FIS, Game Day

들어가며 — "프로덕션 서버를 일부러 죽인다고요?"

Chaos Engineering을 처음 듣는 사람은 보통 이렇게 반응한다.

"장애가 나도 문제인데, 왜 일부러 만듭니까?"

답: 장애는 어차피 일어난다. 통제된 환경에서 먼저 겪는 게 덜 아프다. 2010년 Netflix가 AWS로 이전하며 이 역설적 진리를 깨달았고, 세상에 Chaos Monkey를 풀어놓았다.

이 글에서는:

왜 Netflix가 서버를 죽이기 시작했나 — 탄생 배경
Chaos Engineering 4원칙 — 공식 principles
Simian Army — Chaos Monkey부터 Chaos Kong까지
LitmusChaos / Chaos Mesh — Kubernetes 카오스 툴링
AWS Fault Injection Simulator
Game Day 설계와 실행
관측성과 카오스의 결합
비난 없는 포스트모템 — 조직 문화의 기둥
카오스 실험 실제 레시피 10개
성숙도 모델 — 우리 조직은 어디에?

이전 글 CDN과 엣지 컴퓨팅 완전 해부에서 전 세계에 배포된 인프라를 봤다. 이렇게 복잡한 시스템이 정상 동작한다는 건 어떻게 증명하나? 답은 부숴서 증명하는 것이다.

1. 탄생 배경 — 2010년 Netflix의 선택

문제: 모놀리스에서 클라우드로

Netflix는 2008년 데이터센터 장애로 3일간 DVD 배송 시스템 다운. 결정: "우리는 이걸 자체 DC로 해결 못 함. 클라우드로 간다." AWS로 이전하면서 깨달음:

클라우드는 개별 인스턴스 신뢰도가 낮음 (싸구려 VM)
네트워크는 언제든 단절 (AZ, 리전 간)
의존 서비스는 항상 실패 중

해법 둘 중 하나:

완벽한 코드를 만든다 (불가능)
실패를 전제로 설계한다 (현실적)

Chaos Monkey 탄생 (2010)

Netflix 엔지니어가 만든 간단한 도구: AWS에서 무작위로 EC2 인스턴스 종료. 처음엔 내부 반발 심함. "미쳤다." 하지만 엔지니어들이 자신의 서비스가 한 인스턴스 죽어도 살아남게 설계하기 시작. 영향:

재시작에도 살아남는 아키텍처
배포 시 점진 교체 정상화
장애가 뉴스거리가 아닌 일상

2012년 Chaos Monkey 오픈소스화. Chaos Engineering이라는 이름이 세상에 등장.

2. Chaos Engineering의 4가지 원칙

Netflix, Google SRE 등이 공식화한 principlesofchaos.org 선언:

1. "Steady State"를 정의하라

시스템이 정상일 때의 측정 가능한 지표가 있어야 한다. 예:

초당 요청 수
P99 지연
에러 비율
비즈니스 지표 (결제 성공률)

"정상"이 모호하면 카오스 실험이 성공인지 실패인지 모른다. 비즈니스 지표가 특히 강력 — Netflix의 "초당 재생 시작 횟수(SPS)"가 대표적.

2. 실세계 이벤트를 다양화하라

실제로 일어날 수 있는 사건을 주입:

인스턴스 다운
네트워크 지연/단절
DNS 실패
의존 서비스 timeout
리전 장애
디스크 full
시계 왜곡

"코드 버그"보단 환경 이벤트에 집중.

3. 프로덕션에서 실험하라

"스테이징에서만 하면 안 되나?" 스테이징은 프로덕션이 아니다:

트래픽 패턴 다름
데이터 크기 다름
서드파티 의존 다름

점진적으로 프로덕션에 도입. 10% 트래픽부터. 그러나 궁극적으론 프로덕션에서.

4. 자동화하고 지속하라

한 번 테스트하고 끝이면 의미 없다. 지속적 실험만이 회귀를 잡는다. CI/CD처럼 카오스도 파이프라인.

3. Simian Army — Netflix의 전체 구성

Chaos Monkey는 시작일 뿐. Netflix는 Simian Army로 확장:

Chaos Monkey (2010)

무작위 EC2 인스턴스 종료
업무 시간 내만 실행 (엔지니어가 대응 가능할 때)

Latency Monkey (2012)

서비스 간 통신에 지연 주입
외부 API가 느릴 때의 대응 검증

Conformity Monkey

"우리 표준"에 맞지 않는 인스턴스 찾아 종료
구식 AMI, 잘못된 태그 등

Doctor Monkey

비정상 인스턴스 (CPU 100%, 응답 없음) 발견 후 조치

Janitor Monkey

사용 안 되는 리소스 (orphan EBS, 미사용 IP) 정리
비용 관리 겸용

Security Monkey

잘못된 IAM/보안 그룹 설정 자동 탐지

Chaos Gorilla (2011)

AZ 하나 전체를 시뮬레이션 장애
훨씬 큰 영향, 훨씬 큰 배움

Chaos Kong (2013)

AWS 리전 하나 전체를 다운
Netflix는 리전 장애에도 견딜 수 있게 설계. 2016년 실제 AWS 리전 장애 때도 서비스 유지

FIT (Failure Injection Testing)

특정 서비스, 특정 사용자, 특정 요청에만 장애 주입
세분화된 카오스

대부분은 오픈소스로 공개됐지만, 많은 것들이 후계 도구들로 대체됐다.

4. Kubernetes 시대의 카오스 — LitmusChaos vs Chaos Mesh

LitmusChaos (CNCF Graduated 2024)

특징:

CNCF 졸업 프로젝트 (인큐베이션 → 졸업)
Kubernetes 네이티브 (CRD 기반)
ChaosHub — 수십 개의 사전 제작 실험
GitOps 친화적

실험 예:

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: pod-delete-chaos
spec:
  appinfo:
    appns: default
    applabel: app=nginx
  experiments:
  - name: pod-delete
    spec:
      components:
        env:
        - name: TOTAL_CHAOS_DURATION
          value: "30"
        - name: CHAOS_INTERVAL
          value: "10"

실험 유형 (ChaosHub):

Pod delete, container kill
Network loss/latency/corruption
CPU/memory/IO stress
Node drain, cordon
AWS/Azure/GCP 리소스 조작

Chaos Mesh (CNCF Incubating)

특징:

PingCAP(TiDB 회사)가 만듦
훌륭한 UI 대시보드
Scheduling 강력 — cron 기반 반복 실험
워크플로우 지원 — 여러 실험을 단계별로

실험 YAML 예:

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: delay-example
spec:
  action: delay
  mode: one
  selector:
    namespaces:
    - default
    labelSelectors:
      app: nginx
  delay:
    latency: "100ms"
    correlation: "25"
    jitter: "10ms"
  duration: "5m"

비교

측면	LitmusChaos	Chaos Mesh
성숙도	CNCF Graduated	CNCF Incubating
UI	좋음	우수
실험 수	ChaosHub 50+	내장 30+
GitOps	강함	중간
스케줄링	기본 cron	고급 워크플로우
학습 곡선	중간	낮음

선택 팁:

온보딩 빨리 하고 싶다 → Chaos Mesh
엔터프라이즈 정책과 GitOps 통합 → LitmusChaos

5. AWS Fault Injection Simulator (FIS)

AWS 공식 카오스 서비스 (2021 GA).

주요 기능

EC2 인스턴스 stop/terminate
EBS volume detach
네트워크 혼란 (latency, packet loss)
RDS 페일오버 트리거
사용자 정의 CloudWatch 알람으로 자동 중지
IAM 기반 안전장치

전체 리전 셧다운 실험 (조심)

FIS Template
  ├── Action: aws:network:disrupt-connectivity
  ├── Target: us-east-1의 특정 서브넷
  ├── Stop Condition: CloudWatch 알람 '비즈니스 지표 이하'
  └── IAM Role: 제한된 권한

Netflix의 Chaos Kong을 AWS가 공식 제공하는 셈.

Azure Chaos Studio / GCP 실험

Azure Chaos Studio — 2021년 출시, Kubernetes/AKS 통합
GCP: 공식 제품 없음, Chaos Mesh 권장

6. Game Day — 조직적 재난 훈련

왜 Game Day인가

자동화된 카오스가 '기술 검증'이라면, Game Day는 '조직 검증'. 다음을 테스트:

누가 대응하나? (온콜 로테이션)
어떤 Runbook이 실제로 쓸만한가?
Slack/PagerDuty 알림이 제대로 오나?
커뮤니케이션이 지연되는 지점은?
에스컬레이션 체인이 작동하나?

Game Day 설계 템플릿

1. 목표 설정

예: "us-east-1 리전 셧다운 시 15분 이내에 us-west-2로 복구"

2. 참여자 선정

SRE, 백엔드, DBA, 프론트엔드, PM
사전 일정 공유 (재난 모의 날짜)

3. 시나리오 작성

"오전 10:00에 RDS 프라이머리 페일오버"
"오전 10:05에 쓰기 트래픽 10% 증가"
"오전 10:10에 캐시 노드 절반 재시작"

4. 실행

관찰자와 실행자 분리
진행 시 실시간 기록 (타임라인, Slack 스크립트)

5. 복기 (가장 중요)

무엇이 잘 됐나
무엇이 놀라웠나
어떤 Runbook을 갱신해야 하나
어떤 자동화가 필요한가

실전 팁

첫 Game Day는 고위험 피하기 — 평일 오후, 트래픽 낮은 시간
Chat Channel을 열어둔다 — 모든 결정이 로그에 남도록
Time-boxing — "1시간 해보고 복구 안 되면 중단"
Blast Radius 제어 — 전체의 1~5%만 먼저

7. 관측성과 카오스의 결합

Chaos without Observability = Guessing

카오스 실험 중 무엇을 봐야 하는가?

스테디 상태 지표 (steady state)
의존 서비스의 에러 전파
캐스케이드 실패 징후

관측성 3기둥 (이전 글 OpenTelemetry 완전 해부 참고):

메트릭 — 지속적 수치 모니터링
로그 — 이상 이벤트
Trace — 장애가 어느 서비스로 전파됐나

"Canary + Chaos" 패턴

배포 후 10% 트래픽 카나리
동시에 카나리 인스턴스에만 카오스 주입
정상 페일 라인에 잘 대응하는지 검증
통과하면 전체 배포

자동 중단 (Auto-Abort)

카오스 실행 중 비즈니스 지표 이하로 떨어지면 자동 중단. 예:

stopConditions:
- source: cloudwatch
  alarm: checkout-success-rate-below-95

실수로 큰 장애 만드는 것 방지.

8. 비난 없는 포스트모템 — 카오스 문화의 기둥

왜 "비난 없는"인가

개인을 비난하면:

사람들이 장애 숨김
학습 멈춤
심리적 안전 파괴

"누가 잘못했나"가 아닌 **"어떻게 시스템이 실패를 허용했나"**에 집중.

포스트모템 템플릿

영향 — 몇 명에게 얼마나? 금전적 영향?
타임라인 — 분 단위 사건 기록
근본 원인 — "왜?"를 5번
잘 된 점 — 탐지 속도, 팀워크 등
안 된 점 — 알림 누락, Runbook 부족 등
액션 아이템 — 담당자 + 마감일 명확히

5 Whys 예시

문제: 결제가 15분간 실패

왜? → 결제 서비스가 응답 없음
왜? → DB 커넥션 풀 고갈
왜? → 쿼리 하나가 인덱스 없이 스캔 중
왜? → 최근 배포에서 쿼리 추가, 인덱스 빼먹음
왜? → PR 리뷰 체크리스트에 "인덱스 확인" 없음

→ 액션: PR 템플릿에 인덱스 확인 체크박스 추가.

근본 원인이 "개발자 실수"가 아닌 **"프로세스 누락"**으로 귀결.

"Just Culture"

단, 비난 없음 ≠ 책임 없음. 고의적 무시, 지속적 부주의엔 조치. John Allspaw (Etsy)의 "Just Culture" 프레임워크 참조 권장.

9. 실전 카오스 레시피 10개

레시피 1: Pod 무작위 삭제

# ChaosMesh
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
spec:
  action: pod-kill
  mode: random-max-percent
  value: "25"
  selector:
    namespaces: [production]
    labelSelectors: { tier: backend }
  scheduler:
    cron: "0 */6 * * *"  # 6시간마다

검증: readinessProbe 설정, graceful termination, PodDisruptionBudget.

레시피 2: CPU 스트레스

검증: HPA가 스케일 아웃하나? Throttling 대응은?

레시피 3: 네트워크 지연

networkChaos:
  action: delay
  delay: { latency: "500ms" }

검증: 타임아웃 설정, 서킷 브레이커 작동.

레시피 4: DNS 실패

대부분 장애의 절반이 DNS (이전 글 참고).

검증: DNS 캐시 정책, 복구 후 재연결.

레시피 5: Disk Full

dd if=/dev/zero of=/tmp/fill bs=1M count=10000

검증: 로그 로테이션, 디스크 알람.

레시피 6: 의존 서비스 5xx 응답

Envoy의 fault injection 필터:

fault:
  abort:
    percentage: 50
    httpStatus: 503

검증: 재시도 정책, 폴백 구현.

레시피 7: DB 페일오버

검증: 연결 풀 재연결, 클라이언트 측 retry.

레시피 8: Region/AZ 셧다운

AWS FIS로 서브넷 네트워크 단절.

검증: 멀티-AZ 배포, 자동 페일오버.

레시피 9: Clock Skew

NTP 동기화 끊고 시간 조작.

검증: JWT 검증, 이벤트 타임스탬프, TLS 인증서.

레시피 10: Traffic Surge

부하 테스트 도구(k6, Locust)로 예상 3배 트래픽.

검증: Rate limiting, HPA, CDN hit ratio.

10. 카오스 성숙도 모델

Level 1 — Chaos-curious

관심 있지만 도구 안 씀
장애 대응은 사후 대응 중심
포스트모템은 비난 섞임

Level 2 — Staging Chaos

스테이징에서 가끔 실험
Runbook 존재
온콜 로테이션 있음

Level 3 — Production Chaos

프로덕션에서 통제된 실험
비즈니스 지표 steady state 정의됨
Game Day 분기별

Level 4 — Continuous Chaos

CI/CD에 통합된 카오스 테스트
Blast radius 자동 확장
자동 중단 + 관측성 결합

Level 5 — Engineering Culture

모든 PR이 "이 변경의 카오스 시나리오는?"을 고려
비난 없는 포스트모템이 자연스러움
조직이 "실패는 학습 기회"로 인식

Netflix, Google, Amazon이 Level 5. 대부분 회사가 Level 1~2. 목표는 차근차근 올라가기.

11. 카오스가 드러내는 아키텍처 안티패턴

안티패턴 1: Hidden Dependency

"그 서비스가 죽을 수 있나?" → "안 죽어요." 실험하면 죽는다. 그러면 드러나는 의존성.

안티패턴 2: Cascading Failures

서비스 A가 B에 의존, B가 다운되면 A가 retry 폭발 → C까지 다운. 카오스로 발견.

안티패턴 3: Single Point of Failure

DB 프라이머리 하나, Load Balancer 하나, DNS 하나. 카오스로 실제 SPOF 탐지.

안티패턴 4: Inadequate Timeouts

타임아웃 30초 = 클라이언트 대기 30초. 카오스로 "사용자 경험"에 얼마나 아픈지 보여줌.

안티패턴 5: Incomplete Retries

재시도는 있는데 backoff 없음 → 부하 증폭. 카오스로 발견.

12. 금융·의료·정부 등 엄격 규제 환경

"우리는 규제가 엄격해서 프로덕션 카오스 못 함."

접근 1: Regulatory Sandboxing

많은 규제(GDPR, PCI-DSS, HIPAA)가 프로덕션 미러 환경에서의 테스트를 허용. 실데이터 마스킹 후 카오스 적용.

접근 2: 최소 Blast Radius

0.1%부터. 특정 내부 사용자 트래픽에만. 감사 로그 철저히.

접근 3: Game Day만 프로덕션에서

연 1~2회 공식 훈련. 사전 승인 얻고 후속 보고.

접근 4: 실제 장애를 카오스처럼 기록

매 장애마다 구조화된 학습. 이미 카오스 중인 셈.

13. 실전 체크리스트 12가지

Steady State 먼저 정의 — 비즈니스 지표 기반
Staging부터 시작 — 그다음 프로덕션 10%
Blast Radius 명시 — 영향 범위 투명화
자동 중단 조건 항상 설정 — "이 지표 이하면 중단"
관측성 먼저 — 측정 없으면 실험 무의미
Runbook과 함께 — 카오스는 Runbook의 테스트
PDB / preStop hooks — Kubernetes 기본 안전장치
온콜이 알고 있어야 — 모의 실험을 진짜 알람으로 착각하면 낭비
결과 문서화 — 블로그, 내부 위키
비난 없는 포스트모템 문화 — 프로세스부터 정착
Game Day 정기화 — 분기 1회 이상
경영진 후원 — 카오스는 투자가 필요한 문화 변화

다음 글 예고 — Feature Flag와 Progressive Delivery

"카오스"가 프로덕션에서 장애를 탐색한다면, Feature Flag는 프로덕션에서 신기능을 탐색한다. 다음 글에서는:

Feature Flag의 역사 — Facebook "Dark Launch"에서 LaunchDarkly까지
플래그 타입 분류 — release, experiment, ops, permission
Progressive Delivery — Canary → Rolling → Blue/Green
A/B Testing과 플래그의 차이
Trunk-based Development — 브랜치 지옥 끝내는 법
플래그 부채 관리 (오래된 플래그의 문제)
Unleash, LaunchDarkly, GrowthBook, Flagsmith 비교
Open Feature 표준화 움직임
실전 롤아웃 전략 (사용자 버킷, 지리적, 시간대)

Feature Flag는 이제 "혁신적 도구"가 아닌 현대 배포의 기본기. 다음 글에서 전모를 보자.

"배포와 릴리스를 분리하라. 코드는 이미 거기에 있지만, 기능은 아직 켜지지 않았다 — 이것이 현대 소프트웨어의 기본 태도다."