Chaos Engineering 완전 가이드 2025: 복원력 테스트, Chaos Monkey, Litmus, 게임 데이

정상 상태 예시:
- API 응답 시간 p99 < 200ms
- 에러율 < 0.1%
- 주문 처리 성공률 > 99.9%
- 데이터베이스 복제 지연 < 1초

폭발 반경 제어 전략:
1. 소규모 시작: 단일 인스턴스 → 인스턴스 그룹 → AZ → 리전
2. 시간 제한: 실험 지속 시간 설정 (예: 5분)
3. 자동 중단: 핵심 메트릭 임계값 초과 시 실험 즉시 중단
4. 트래픽 제한: 전체 트래픽의 1%에만 실험 적용
5. 롤백 계획: 실험 전 롤백 절차 확인

Simian Army 구성원:
┌─────────────────────┬──────────────────────────────────────┐
│ 이름                │ 역할                                 │
├─────────────────────┼──────────────────────────────────────┤
│ Chaos Monkey        │ 무작위 인스턴스 종료                 │
│ Latency Monkey      │ 네트워크 지연 주입                   │
│ Conformity Monkey   │ 모범 사례 미준수 인스턴스 탐지       │
│ Doctor Monkey       │ 비정상 인스턴스 건강 검사            │
│ Janitor Monkey      │ 미사용 리소스 정리                   │
│ Security Monkey     │ 보안 취약점 탐지                     │
│ Chaos Gorilla       │ 전체 AZ 장애 시뮬레이션              │
│ Chaos Kong          │ 전체 리전 장애 시뮬레이션            │
└─────────────────────┴──────────────────────────────────────┘

# Chaos Monkey 설정 (Spinnaker 통합)
chaos_monkey:
  enabled: true
  leashed: false
  schedule:
    frequency: "weekday"
    start_hour: 10
    end_hour: 16
    timezone: "Asia/Seoul"
  grouping: "cluster"
  probability: 1.0
  exceptions:
    - account: "prod-critical"
      region: "ap-northeast-2"
      stack: "payment"

# Litmus Chaos 설치
apiVersion: v1
kind: Namespace
metadata:
  name: litmus
---
# LitmusChaos Operator 배포
apiVersion: apps/v1
kind: Deployment
metadata:
  name: chaos-operator-ce
  namespace: litmus
spec:
  replicas: 1
  selector:
    matchLabels:
      name: chaos-operator
  template:
    metadata:
      labels:
        name: chaos-operator
    spec:
      serviceAccountName: litmus
      containers:
        - name: chaos-operator
          image: litmuschaos/chaos-operator:3.0.0
          env:
            - name: CHAOS_RUNNER_IMAGE
              value: "litmuschaos/chaos-runner:3.0.0"
            - name: WATCH_NAMESPACE
              value: ""

# Pod Delete 실험 정의
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosExperiment
metadata:
  name: pod-delete
  namespace: litmus
spec:
  definition:
    scope: Namespaced
    permissions:
      - apiGroups: [""]
        resources: ["pods"]
        verbs: ["delete", "list", "get"]
    image: "litmuschaos/go-runner:3.0.0"
    args:
      - -c
      - ./experiments -name pod-delete
    command:
      - /bin/bash
    env:
      - name: TOTAL_CHAOS_DURATION
        value: "30"
      - name: CHAOS_INTERVAL
        value: "10"
      - name: FORCE
        value: "false"

# Chaos Mesh 설치 (Helm)
# helm repo add chaos-mesh https://charts.chaos-mesh.org
# helm install chaos-mesh chaos-mesh/chaos-mesh -n chaos-mesh --create-namespace

# 네트워크 지연 실험
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-delay-example
  namespace: default
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - default
    labelSelectors:
      app: my-service
  delay:
    latency: "200ms"
    jitter: "50ms"
    correlation: "50"
  duration: "5m"
  scheduler:
    cron: "@every 1h"

{
  "description": "EC2 인스턴스 종료 실험",
  "targets": {
    "myInstances": {
      "resourceType": "aws:ec2:instance",
      "resourceTags": {
        "Environment": "staging",
        "ChaosReady": "true"
      },
      "selectionMode": "COUNT(1)"
    }
  },
  "actions": {
    "stopInstances": {
      "actionId": "aws:ec2:stop-instances",
      "parameters": {},
      "targets": {
        "Instances": "myInstances"
      }
    }
  },
  "stopConditions": [
    {
      "source": "aws:cloudwatch:alarm",
      "value": "arn:aws:cloudwatch:ap-northeast-2:123456789:alarm:HighErrorRate"
    }
  ],
  "roleArn": "arn:aws:iam::123456789:role/FISRole"
}

# Gremlin 에이전트 설치 (Kubernetes)
helm repo add gremlin https://helm.gremlin.com
helm install gremlin gremlin/gremlin \
  --set gremlin.secret.managed=true \
  --set gremlin.secret.type=secret \
  --set gremlin.secret.teamID=YOUR_TEAM_ID \
  --set gremlin.secret.clusterID=my-cluster \
  --set gremlin.secret.teamSecret=YOUR_SECRET

# Chaos Mesh: 네트워크 파티션
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-partition
  namespace: default
spec:
  action: partition
  mode: all
  selector:
    namespaces:
      - default
    labelSelectors:
      app: order-service
  direction: both
  target:
    selector:
      namespaces:
        - default
      labelSelectors:
        app: payment-service
    mode: all
  duration: "2m"

# Chaos Mesh: 패킷 손실
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: packet-loss
  namespace: default
spec:
  action: loss
  mode: all
  selector:
    labelSelectors:
      app: api-gateway
  loss:
    loss: "25"
    correlation: "50"
  duration: "3m"

# Chaos Mesh: 대역폭 제한
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: bandwidth-limit
  namespace: default
spec:
  action: bandwidth
  mode: all
  selector:
    labelSelectors:
      app: file-service
  bandwidth:
    rate: "1mbps"
    limit: 20971520
    buffer: 10000
  duration: "5m"

# Chaos Mesh: CPU 스트레스
apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
  name: cpu-stress
  namespace: default
spec:
  mode: one
  selector:
    labelSelectors:
      app: compute-service
  stressors:
    cpu:
      workers: 4
      load: 80
  duration: "5m"

# Chaos Mesh: 메모리 스트레스
apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
  name: memory-stress
  namespace: default
spec:
  mode: one
  selector:
    labelSelectors:
      app: cache-service
  stressors:
    memory:
      workers: 2
      size: "512MB"
  duration: "3m"

# Chaos Mesh: Pod Kill
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-example
  namespace: default
spec:
  action: pod-kill
  mode: fixed
  value: "2"
  selector:
    namespaces:
      - default
    labelSelectors:
      app: web-frontend
  gracePeriod: 0
  duration: "1m"

# Chaos Mesh: 컨테이너 Kill
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: container-kill
  namespace: default
spec:
  action: container-kill
  mode: one
  selector:
    labelSelectors:
      app: multi-container-app
  containerNames:
    - sidecar-proxy
  duration: "30s"

# Litmus: 노드 드레인 실험
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: node-drain-engine
  namespace: litmus
spec:
  engineState: active
  chaosServiceAccount: litmus-admin
  experiments:
    - name: node-drain
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "60"
            - name: TARGET_NODE
              value: "worker-node-02"
            - name: APP_NAMESPACE
              value: "default"
            - name: APP_LABEL
              value: "app=critical-service"

# AWS FIS: AZ 장애 시뮬레이션
# 특정 AZ의 모든 서브넷에 대해 네트워크 차단
experiment_template:
  description: "AZ-a failure simulation"
  targets:
    azSubnets:
      resourceType: "aws:ec2:subnet"
      resourceTags:
        AvailabilityZone: "ap-northeast-2a"
      selectionMode: "ALL"
  actions:
    disruptConnectivity:
      actionId: "aws:network:disrupt-connectivity"
      parameters:
        scope: "all"
      targets:
        Subnets: "azSubnets"
      duration: "PT10M"
  stopConditions:
    - source: "aws:cloudwatch:alarm"
      value: "arn:aws:cloudwatch:region:account:alarm:CriticalErrorRate"

# Chaos Mesh: DNS 장애
apiVersion: chaos-mesh.org/v1alpha1
kind: DNSChaos
metadata:
  name: dns-failure
  namespace: default
spec:
  action: error
  mode: all
  selector:
    labelSelectors:
      app: external-api-client
  patterns:
    - "external-api.example.com"
  duration: "2m"

카오스 실험 설계 프레임워크:

1. 가설 수립 (Hypothesis)
   "결제 서비스 Pod 1개가 종료되더라도,
    주문 성공률은 99.9% 이상을 유지할 것이다"

2. 정상 상태 정의 (Steady State)
   - 주문 성공률: 99.95%
   - API 응답 시간 p99: 180ms
   - 에러율: 0.05%

3. 실험 변수 (Variables)
   - 독립 변수: Pod 1개 강제 종료
   - 종속 변수: 주문 성공률, 응답 시간, 에러율

4. 폭발 반경 (Blast Radius)
   - 대상: payment-service의 3개 Pod 중 1개
   - 영향 범위: 결제 관련 요청의 약 33%

5. 중단 조건 (Abort Conditions)
   - 주문 성공률 < 99.0%
   - API 응답 시간 p99 > 1000ms
   - 동시 에러 수 > 100/min

6. 실행 및 관찰 (Execute and Observe)
   - 실험 시작 전 5분간 기준선 수집
   - 실험 실행 (2분)
   - 실험 종료 후 5분간 복구 관찰

7. 분석 및 개선 (Analyze and Improve)
   - 가설 검증/반증
   - 발견된 취약점 문서화
   - 개선 작업 티켓 생성

실험 전 체크리스트:
[ ] 가설이 명확하게 정의되어 있는가?
[ ] 정상 상태 메트릭이 수집되고 있는가?
[ ] 폭발 반경이 적절하게 제한되어 있는가?
[ ] 중단 조건이 설정되어 있는가?
[ ] 롤백 절차가 문서화되어 있는가?
[ ] 관련 팀에 사전 통보했는가?
[ ] 모니터링 대시보드가 준비되어 있는가?
[ ] On-Call 엔지니어가 대기 중인가?

실험 중 체크리스트:
[ ] 메트릭을 실시간으로 모니터링하고 있는가?
[ ] 중단 조건을 지속적으로 확인하고 있는가?
[ ] 예상치 못한 부작용이 없는가?

실험 후 체크리스트:
[ ] 시스템이 정상 상태로 복구되었는가?
[ ] 실험 결과가 기록되었는가?
[ ] 발견된 문제에 대한 액션 아이템이 생성되었는가?
[ ] 결과를 팀에 공유했는가?

실험 ID: CE-2025-042
날짜: 2025-04-14
실험자: SRE 팀 (홍길동)

가설: payment-service의 Pod 1개가 종료되어도
      주문 성공률 99.9% 이상 유지

정상 상태 기준선:
- 주문 성공률: 99.97%
- p99 응답 시간: 165ms
- 에러율: 0.03%

실험 결과:
- 주문 성공률: 99.12% (가설 반증!)
- p99 응답 시간: 892ms
- 에러율: 0.88%
- 복구 시간: 45초

발견 사항:
1. Kubernetes readiness probe 간격이 30초로 설정되어 있어
   트래픽이 종료 중인 Pod로 계속 전달됨
2. Circuit breaker 타임아웃이 너무 길게 설정 (10초)
3. 재시도 로직이 같은 Pod로 재시도함

개선 액션:
- [HIGH] readiness probe 간격을 5초로 단축
- [HIGH] Circuit breaker 타임아웃을 2초로 조정
- [MED] 재시도 시 다른 인스턴스로 라우팅하도록 수정

Game Day 계획 템플릿:

1. 목적
   - 결제 시스템의 AZ 장애 복원력 검증
   - 인시던트 대응 프로세스 훈련
   - 새로운 팀원 온보딩

2. 일정
   - 날짜: 2025년 4월 14일 (월)
   - 시간: 14:00 ~ 17:00 KST
   - 장소: 대회의실 + Zoom

3. 참가자
   - 게임 마스터: SRE 리드 (시나리오 주입 담당)
   - 인시던트 커맨더: 백엔드 리드
   - 대응팀: 백엔드 3명, 프론트엔드 1명, DBA 1명
   - 관찰자: CTO, PM

4. 시나리오 (참가자에게는 비공개)
   시나리오 1: payment-service Pod 50% 종료
   시나리오 2: 데이터베이스 읽기 복제본 연결 끊김
   시나리오 3: 외부 PG사 API 응답 5초 지연

5. 성공 기준
   - 탐지 시간 < 5분
   - 완화 시간 < 15분
   - 고객 영향 없음

6. 안전 장치
   - 킬 스위치: 게임 마스터가 즉시 모든 실험 중단 가능
   - 프로덕션 아닌 스테이징 환경에서 실행
   - 실제 고객 트래픽에 영향 없음

역할 정의:

게임 마스터 (Game Master)
- 시나리오 설계 및 장애 주입
- 실험 중단 결정권
- 힌트 제공 (필요시)
- 시간 관리

인시던트 커맨더 (Incident Commander)
- 대응팀 조율
- 의사결정
- 커뮤니케이션 관리
- 에스컬레이션 판단

대응팀 (Responders)
- 문제 진단 및 해결
- 런북 참조 및 실행
- 실시간 상태 보고

관찰자 (Observers)
- 대응 과정 기록
- 프로세스 개선점 메모
- 개입하지 않음 (중요!)

서기 (Scribe)
- 타임라인 기록
- 주요 의사결정 기록
- 발견 사항 정리

14:00 - 14:15  킥오프 브리핑
               - 규칙 설명
               - 안전 장치 확인
               - 도구 접근 확인

14:15 - 14:20  시나리오 1 주입 (게임 마스터)
14:20 - 14:50  대응팀 탐지 및 대응
14:50 - 15:00  시나리오 1 리뷰

15:00 - 15:10  휴식

15:10 - 15:15  시나리오 2 주입
15:15 - 15:45  대응팀 탐지 및 대응
15:45 - 15:55  시나리오 2 리뷰

15:55 - 16:00  시나리오 3 주입
16:00 - 16:30  대응팀 탐지 및 대응
16:30 - 16:40  시나리오 3 리뷰

16:40 - 17:00  종합 회고 (Retrospective)
               - 잘한 점
               - 개선할 점
               - 액션 아이템 도출

회고 질문 목록:

탐지 (Detection)
- 어떤 알림이 가장 먼저 발생했는가?
- 해당 알림을 보고 문제를 정확히 파악할 수 있었는가?
- 놓친 알림이 있었는가?
- 탐지 시간을 줄일 수 있는 방법은?

대응 (Response)
- 런북이 도움이 되었는가?
- 커뮤니케이션 채널은 효과적이었는가?
- 역할 분담은 명확했는가?
- 에스컬레이션이 필요했는가?

복구 (Recovery)
- 복구에 걸린 시간은 적절했는가?
- 자동 복구 메커니즘이 작동했는가?
- 수동 개입이 필요한 부분은?

시스템 (System)
- 예상대로 동작하지 않은 부분은?
- 개선이 필요한 모니터링은?
- 자동화가 필요한 작업은?

목표: 팀의 카오스 엔지니어링 역량 구축

활동:
1. 카오스 도구 설치 (Chaos Mesh 또는 Litmus)
2. 간단한 실험 실행
   - 개발 환경에서 Pod Kill
   - 네트워크 지연 주입
3. 실험 설계 방법 교육
4. 첫 번째 실험 보고서 작성

성공 지표:
- 팀원 전원이 실험 1회 이상 실행
- 실험 설계 프로세스 문서화 완료

목표: 실전에 가까운 환경에서 체계적 실험

활동:
1. 스테이징에 카오스 도구 배포
2. 핵심 서비스 대상 체계적 실험
   - 서비스 간 통신 장애
   - 데이터베이스 연결 풀 고갈
   - 캐시 전면 장애
3. 첫 번째 Game Day 실행
4. CI/CD 파이프라인에 기본 실험 통합

성공 지표:
- 주 1회 이상 정기 실험 실행
- Game Day 1회 완료
- 발견된 취약점 3건 이상 개선

목표: 프로덕션에서 안전하게 실험 시작

활동:
1. 프로덕션 카오스 실험 안전 장치 구축
   - 자동 중단 조건 설정
   - 킬 스위치 구현
   - 실험 영향 범위 제한
2. 소규모 프로덕션 실험
   - 전체 트래픽의 1%에 대해 단일 Pod Kill
   - 비핵심 서비스에 네트워크 지연
3. 관찰 가능성 대시보드 강화

성공 지표:
- 프로덕션 실험 5회 이상 안전하게 완료
- 고객 영향 제로
- 자동 중단 메커니즘 1회 이상 검증

목표: 카오스 엔지니어링을 일상적 실천으로 정착

활동:
1. 자동화된 주기적 실험 실행
2. 새로운 서비스 배포 시 필수 카오스 테스트
3. 분기별 대규모 Game Day
4. AZ/리전 수준 장애 시뮬레이션
5. 카오스 문화 확산 (전사 교육)

성공 지표:
- 월 10회 이상 자동 실험 실행
- 분기별 Game Day 정례화
- MTTR(평균 복구 시간) 50% 감소
- 장애 관련 인시던트 30% 감소

Chaos Kong 프로세스:

1. 준비 단계
   - 트래픽 라우팅 확인
   - 대체 리전 용량 확인
   - 모니터링 강화
   - 관련 팀 사전 통보

2. 실행 단계
   - US-East-1 리전의 모든 트래픽을 US-West-2로 전환
   - DNS 기반 글로벌 로드 밸런싱 활용
   - 전환 과정에서 메트릭 실시간 모니터링

3. 관찰 항목
   - 트래픽 전환 완료 시간
   - 대체 리전의 오토스케일링 응답 시간
   - 사용자 경험 영향 (재생 품질, 시작 시간)
   - 데이터 일관성

4. 복구 단계
   - 트래픽을 원래 리전으로 복원
   - 데이터 동기화 확인
   - 전체 결과 분석

Level 0: 카오스 없음
- 장애 시 수동 대응
- "우리 시스템은 잘 작동한다"는 희망

Level 1: 기본 카오스
- Chaos Monkey로 인스턴스 종료
- 개별 서비스 복원력 확인

Level 2: 체계적 카오스
- 다양한 장애 유형 실험
- Game Day 정기 실행
- 결과 기반 개선

Level 3: 고급 카오스
- AZ 장애 시뮬레이션
- CI/CD 통합
- 자동화된 실험

Level 4: 카오스 문화
- 리전 대피 훈련 (Chaos Kong)
- 모든 팀이 카오스 실험 수행
- 복원력이 아키텍처 의사결정의 핵심 기준

Amazon GameDay 원칙:

1. "Everything fails, all the time" - Werner Vogels
   - 장애를 정상적인 운영의 일부로 간주

2. 점진적 복잡도 증가
   - 단일 서비스 → 서비스 체인 → 전체 시스템

3. 비난 없는 문화
   - 장애 대응 실패를 학습 기회로 전환

4. 문서화
   - 모든 GameDay 결과를 상세히 기록

5. 반복
   - 같은 시나리오를 반복하여 개선 검증

{
  "description": "Multi-AZ resilience test",
  "targets": {
    "ec2Instances": {
      "resourceType": "aws:ec2:instance",
      "resourceTags": {
        "chaos-ready": "true"
      },
      "filters": [
        {
          "path": "Placement.AvailabilityZone",
          "values": ["ap-northeast-2a"]
        }
      ],
      "selectionMode": "ALL"
    },
    "rdsInstances": {
      "resourceType": "aws:rds:db",
      "resourceTags": {
        "chaos-ready": "true"
      },
      "selectionMode": "ALL"
    }
  },
  "actions": {
    "stopEC2": {
      "actionId": "aws:ec2:stop-instances",
      "targets": {
        "Instances": "ec2Instances"
      },
      "startAfter": []
    },
    "failoverRDS": {
      "actionId": "aws:rds:failover-db-cluster",
      "targets": {
        "Clusters": "rdsInstances"
      },
      "startAfter": ["stopEC2"]
    }
  },
  "stopConditions": [
    {
      "source": "aws:cloudwatch:alarm",
      "value": "arn:aws:cloudwatch:region:account:alarm:HighErrorRate"
    }
  ]
}

# GitHub Actions: 카오스 테스트 통합
name: Chaos Testing Pipeline

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 2 * * 1-5'  # 평일 새벽 2시

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Staging
        run: kubectl apply -f k8s/staging/

  chaos-test:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - name: Install Litmus
        run: |
          kubectl apply -f https://litmuschaos.github.io/litmus/3.0.0/litmus-3.0.0.yaml

      - name: Run Pod Delete Experiment
        run: |
          kubectl apply -f chaos/experiments/pod-delete.yaml
          sleep 120
          kubectl get chaosresult pod-delete-result -o jsonpath='{.status.experimentStatus.verdict}'

      - name: Run Network Delay Experiment
        run: |
          kubectl apply -f chaos/experiments/network-delay.yaml
          sleep 180
          kubectl get chaosresult network-delay-result -o jsonpath='{.status.experimentStatus.verdict}'

      - name: Verify System Recovery
        run: |
          ./scripts/verify-steady-state.sh

      - name: Collect Results
        if: always()
        run: |
          kubectl get chaosresults -o yaml > chaos-results.yaml

      - name: Upload Results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: chaos-results
          path: chaos-results.yaml

# Argo Rollouts + Chaos 통합
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-service
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause:
            duration: 5m
        # 카나리에 카오스 실험 실행
        - analysis:
            templates:
              - templateName: chaos-analysis
            args:
              - name: service-name
                value: my-service
        - setWeight: 50
        - pause:
            duration: 10m
        - setWeight: 100
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: chaos-analysis
spec:
  metrics:
    - name: success-rate-during-chaos
      interval: 30s
      successCondition: result[0] >= 99.5
      provider:
        prometheus:
          address: http://prometheus:9090
          query: |
            sum(rate(http_requests_total{status="200",service="my-service"}[5m]))
            /
            sum(rate(http_requests_total{service="my-service"}[5m]))
            * 100

핵심 메트릭 (Golden Signals):

1. 레이턴시 (Latency)
   - p50, p90, p99 응답 시간
   - 서비스 간 호출 레이턴시

2. 트래픽 (Traffic)
   - 초당 요청 수 (RPS)
   - 트래픽 분포

3. 에러 (Errors)
   - HTTP 5xx 비율
   - 어플리케이션 에러율
   - 타임아웃 비율

4. 포화도 (Saturation)
   - CPU 사용률
   - 메모리 사용률
   - 네트워크 대역폭
   - 디스크 I/O

{
  "dashboard": {
    "title": "Chaos Engineering Dashboard",
    "panels": [
      {
        "title": "Request Success Rate",
        "type": "gauge",
        "targets": [
          {
            "expr": "sum(rate(http_requests_total{status=~\"2..\"}[5m])) / sum(rate(http_requests_total[5m])) * 100"
          }
        ],
        "thresholds": {
          "steps": [
            { "color": "red", "value": 0 },
            { "color": "yellow", "value": 99 },
            { "color": "green", "value": 99.9 }
          ]
        }
      },
      {
        "title": "P99 Latency",
        "type": "timeseries",
        "targets": [
          {
            "expr": "histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))"
          }
        ]
      },
      {
        "title": "Error Rate",
        "type": "timeseries",
        "targets": [
          {
            "expr": "sum(rate(http_requests_total{status=~\"5..\"}[5m])) / sum(rate(http_requests_total[5m])) * 100"
          }
        ]
      },
      {
        "title": "Active Chaos Experiments",
        "type": "stat",
        "targets": [
          {
            "expr": "count(chaos_experiment_status{phase=\"Running\"})"
          }
        ]
      }
    ]
  }
}

# Prometheus AlertManager 규칙
groups:
  - name: chaos-safety-alerts
    rules:
      - alert: ChaosExperimentHighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[2m]))
          /
          sum(rate(http_requests_total[2m]))
          > 0.05
        for: 1m
        labels:
          severity: critical
          team: sre
        annotations:
          summary: "카오스 실험 중 에러율 5% 초과"
          description: "즉시 실험을 중단하고 상태를 확인하세요"

      - alert: ChaosExperimentHighLatency
        expr: |
          histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[2m]))
          > 2.0
        for: 1m
        labels:
          severity: warning
          team: sre
        annotations:
          summary: "카오스 실험 중 P99 레이턴시 2초 초과"

SRE와 Chaos Engineering의 관계:

SRE 목표: 안정적이고 확장 가능한 시스템 운영
     │
     ├── SLO/SLI/SLA 정의 → 카오스 실험의 성공 기준
     │
     ├── Error Budget → 카오스 실험 실행 여부 결정
     │   (예산이 충분할 때만 공격적 실험 가능)
     │
     ├── 인시던트 관리 → Game Day 시나리오 소스
     │   (과거 장애를 재현하여 개선 검증)
     │
     ├── 포스트모템 → 새로운 카오스 실험 아이디어
     │   (장애 분석에서 발견된 취약점 실험)
     │
     └── Toil 제거 → 카오스 실험 자동화
         (반복적인 수동 실험을 자동화)