Chaos Engineering 입문 — 장애 주입으로 시스템 복원력 검증

“장애는 언제든 발생한다. 문제는 실제 장애가 났을 때 처음 알아채느냐, 아니면 이미 검증해뒀느냐다.” Chaos Engineering은 통제된 환경에서 장애를 먼저 경험해 시스템의 약점을 찾아냅니다.

Chaos Engineering의 5단계

1. 정상 상태(Steady State) 정의
   → "시스템이 정상일 때 어떤 지표 값을 보이는가?"
   → 예: 에러율 < 0.1%, p95 < 200ms, 결제 성공률 > 99.9%

2. 가설 수립
   → "Pod 1개가 죽어도 정상 상태가 유지될 것이다"

3. 변수 주입 (실험)
   → Pod 강제 종료, 네트워크 지연 주입, 디스크 가득 채우기

4. 결과 관찰
   → 정상 상태가 유지되는가? SLO가 깨지는가?

5. 개선 후 재실험
   → 취약점 발견 → 수정 → 같은 실험 반복

Chaos Monkey 계열 도구

Chaos Mesh (Kubernetes)

쿠버네티스 네이티브 카오스 엔지니어링 플랫폼입니다.

# 설치
helm repo add chaos-mesh https://charts.chaos-mesh.org
helm install chaos-mesh chaos-mesh/chaos-mesh --namespace chaos-mesh --create-namespace

# Pod 장애 주입: 특정 Pod를 무작위로 종료
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-failure-test
  namespace: production
spec:
  action: pod-failure       # pod-kill, container-kill 도 가능
  mode: random-max-percent
  value: "30"               # 최대 30%의 Pod에 장애 주입
  duration: "5m"
  selector:
    namespaces:
      - production
    labelSelectors:
      app: payment-service

# 네트워크 지연 주입: 결제 API에 200ms 지연 추가
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-delay-test
spec:
  action: delay
  mode: all
  selector:
    labelSelectors:
      app: payment-service
  delay:
    latency: "200ms"
    correlation: "25"       # 25% 확률로 추가 지연 변동
    jitter: "50ms"
  duration: "10m"
  direction: to             # 인바운드 트래픽에만 적용

# 디스크 I/O 부하: 스토리지 성능 저하 시뮬레이션
apiVersion: chaos-mesh.org/v1alpha1
kind: IOChaos
metadata:
  name: io-latency-test
spec:
  action: latency
  mode: all
  selector:
    labelSelectors:
      app: mysql
  volumePath: /var/lib/mysql
  delay: "100ms"
  percent: 50               # 50%의 I/O 요청에 지연 적용
  duration: "5m"

Litmus Chaos

# CPU 부하 주입
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: cpu-stress-test
spec:
  engineState: active
  appinfo:
    appns: production
    applabel: app=api-server
  experiments:
    - name: pod-cpu-hog
      spec:
        components:
          env:
            - name: CPU_CORES
              value: "2"          # 2 CPU 코어 독점
            - name: TOTAL_CHAOS_DURATION
              value: "300"        # 5분

검증 시나리오 예시

1. Pod 재시작 내성 검증

# kubectl로 직접 장애 주입 (도구 없이)
kubectl delete pod -l app=payment-service --field-selector spec.nodeName=node-1

# 확인 사항:
# - 서비스 에러율이 SLO 이내인가?
# - 새 Pod가 목표 시간(예: 30초) 내에 Ready 상태가 되는가?
# - 요청이 살아있는 Pod로 자동 라우팅되는가?

2. 외부 API 타임아웃 처리

# toxiproxy로 특정 외부 서비스에 지연/단절 주입
docker run --rm -p 8474:8474 -p 8080:8080 ghcr.io/shopify/toxiproxy

# toxiproxy-cli로 프록시 설정
toxiproxy-cli create payment-gateway -l 0.0.0.0:8080 -u payment.external.com:443
toxiproxy-cli toxic add payment-gateway -t latency -a latency=3000  # 3초 지연

# 확인 사항:
# - Circuit Breaker가 열리는가?
# - Fallback 응답이 반환되는가?
# - 타임아웃 후 정상 복구되는가?

3. DB 커넥션 고갈 시뮬레이션

-- 커넥션 고갈 시뮬레이션: 커넥션을 5분간 점유
SELECT pg_sleep(300);   -- 여러 세션에서 동시에 실행

-- 확인 사항:
-- - 앱이 "Connection pool timeout" 에러를 적절히 반환하는가?
-- - Circuit Breaker / Retry 로직이 동작하는가?
-- - 커넥션 복구 후 서비스가 자동 정상화되는가?

GameDay: 팀 단위 카오스 훈련

GameDay는 전체 팀이 참여하는 계획된 카오스 실험입니다.

GameDay 진행 순서:

1. 사전 준비 (1주 전)
   - 실험 시나리오 정의 및 공유
   - 롤백 절차 문서화
   - 모니터링 대시보드 준비

2. 당일 진행 (2~4시간)
   - 참가자: 개발, 운영, QA, 제품팀
   - 실험 실시 → 탐지 시간 측정 → 대응 연습

3. 결과 분석
   - 탐지까지 걸린 시간 (MTTD)
   - 복구까지 걸린 시간 (MTTR)
   - 발견된 취약점 목록

4. 개선 사항 티켓화 → 다음 GameDay에서 재검증

다음 단계

이 가이드를 내 서비스에 직접 적용해 보세요.

TestForge 무료 스캔 시작 →