LabHub

블로그

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

2026-04-15 · 20 분 읽기 · #chaos-engineering#sre#reliability#netflix#kubernetes#observability#game-day

한국어English日本語

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

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

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

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

이 글에서는:

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

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

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

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

해법 둘 중 하나:

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

Chaos Monkey 탄생 (2010)

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

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

2. Chaos Engineering의 4가지 원칙

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

1. "Steady State"를 정의하라

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

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

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

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

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

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

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

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

4. 자동화하고 지속하라

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

3. Simian Army — Netflix의 전체 구성

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

Chaos Monkey (2010)

Latency Monkey (2012)

Conformity Monkey

Doctor Monkey

Janitor Monkey

Security Monkey

Chaos Gorilla (2011)

Chaos Kong (2013)

FIT (Failure Injection Testing)

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

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

LitmusChaos (CNCF Graduated 2024)

특징:

실험 예:

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):

Chaos Mesh (CNCF Incubating)

특징:

실험 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"

비교

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

선택 팁:

5. AWS Fault Injection Simulator (FIS)

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

주요 기능

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

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

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

Azure Chaos Studio / GCP 실험

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

왜 Game Day인가

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

Game Day 설계 템플릿

1. 목표 설정

2. 참여자 선정

3. 시나리오 작성

4. 실행

5. 복기 (가장 중요)

실전 팁

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

Chaos without Observability = Guessing

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

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

"Canary + Chaos" 패턴

자동 중단 (Auto-Abort)

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

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

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

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

왜 "비난 없는"인가

개인을 비난하면:

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

포스트모템 템플릿

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

5 Whys 예시

문제: 결제가 15분간 실패

  1. 왜? → 결제 서비스가 응답 없음
  2. 왜? → DB 커넥션 풀 고갈
  3. 왜? → 쿼리 하나가 인덱스 없이 스캔 중
  4. 왜? → 최근 배포에서 쿼리 추가, 인덱스 빼먹음
  5. 왜? → 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

Level 3 — Production Chaos

Level 4 — Continuous Chaos

Level 5 — Engineering Culture

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가지

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

다음 글 예고 — Feature Flag와 Progressive Delivery

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

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

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

원문 보기: https://www.youngju.dev/blog/culture/2026-04-15-chaos-engineering-netflix-simian-army-litmus-chaos-mesh-fis-game-day-principles-deep-dive-guide-2025

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다