✍️ 필사 모드: 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/Tokyo"
  grouping: "cluster"
  probability: 1.0
  exceptions:
    - account: "prod-critical"
      region: "ap-northeast-1"
      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-1:123456789:alarm:HighErrorRate"
    }
  ],
  "roleArn": "arn:aws:iam::123456789:role/FISRole"
}

# 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障害シミュレーション
experiment_template:
  description: "AZ-a障害シミュレーション"
  targets:
    azSubnets:
      resourceType: "aws:ec2:subnet"
      resourceTags:
        AvailabilityZone: "ap-northeast-1a"
      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)
   - 仮説の検証/反証
   - 発見された脆弱性の文書化
   - 改善作業チケットの作成

実験前チェックリスト：
[ ] 仮説が明確に定義されているか？
[ ] 定常状態メトリクスが収集されているか？
[ ] 爆発半径が適切に制限されているか？
[ ] 中断条件が設定されているか？
[ ] ロールバック手順が文書化されているか？
[ ] 関連チームに事前通知したか？
[ ] モニタリングダッシュボードが準備されているか？
[ ] オンコールエンジニアが待機しているか？

実験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] リトライ時に別インスタンスにルーティングする

ゲームデイ計画テンプレート：

1. 目的
   - 決済システムのAZ障害レジリエンス検証
   - インシデント対応プロセスの訓練
   - 新メンバーのオンボーディング

2. スケジュール
   - 日程：2025年4月14日（月）
   - 時間：14:00 ～ 17:00 JST
   - 場所：大会議室 + Zoom

3. 参加者
   - ゲームマスター：SREリード（シナリオ注入担当）
   - インシデントコマンダー：バックエンドリード
   - 対応チーム：バックエンド3名、フロントエンド1名、DBA 1名
   - オブザーバー：CTO、PM

4. シナリオ（参加者には非公開）
   シナリオ1：payment-service Pod 50%終了
   シナリオ2：データベース読み取りレプリカ接続断
   シナリオ3：外部決済API応答5秒遅延

5. 成功基準
   - 検出時間 < 5分
   - 緩和時間 < 15分
   - 顧客への影響ゼロ

6. 安全装置
   - キルスイッチ：ゲームマスターが即座にすべての実験を中断可能
   - ステージング環境で実行（プロダクションではない）
   - 実際の顧客トラフィックへの影響なし

役割定義：

ゲームマスター (Game Master)
- シナリオ設計と障害注入
- 実験中断の決定権
- ヒント提供（必要時）
- 時間管理

インシデントコマンダー (Incident Commander)
- 対応チームの調整
- 意思決定
- コミュニケーション管理
- エスカレーション判断

対応チーム (Responders)
- 問題の診断と解決
- ランブック参照と実行
- リアルタイムの状態報告

オブザーバー (Observers)
- 対応プロセスの記録
- プロセス改善点のメモ
- 介入しないこと（重要！）

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  総合振り返り（レトロスペクティブ）

目標：チームのカオスエンジニアリング能力構築

活動：
1. カオスツールのインストール（Chaos MeshまたはLitmus）
2. 簡単な実験の実行
   - 開発環境でのPod Kill
   - ネットワーク遅延注入
3. 実験設計方法の教育
4. 最初の実験レポート作成

成功指標：
- チーム全員が実験を1回以上実行
- 実験設計プロセスの文書化完了

目標：実戦に近い環境での体系的実験

活動：
1. ステージングにカオスツールをデプロイ
2. コアサービスを対象とした体系的実験
3. 最初のゲームデイの実行
4. CI/CDパイプラインへの基本実験統合

成功指標：
- 週1回以上の定期実験実行
- ゲームデイ1回完了
- 発見された脆弱性3件以上の改善

目標：プロダクションでの安全な実験開始

活動：
1. プロダクションカオス実験の安全装置構築
2. 小規模プロダクション実験
   - 全トラフィックの1%に対して単一Pod Kill
   - 非クリティカルサービスへのネットワーク遅延
3. オブザーバビリティダッシュボードの強化

成功指標：
- プロダクション実験5回以上安全に完了
- 顧客への影響ゼロ
- 自動中断メカニズム1回以上検証

目標：カオスエンジニアリングを日常的な実践として定着

活動：
1. 自動化された定期的実験実行
2. 新サービスデプロイ時の必須カオステスト
3. 四半期ごとの大規模ゲームデイ
4. AZ/リージョンレベルの障害シミュレーション
5. カオス文化の全社展開

成功指標：
- 月10回以上の自動実験実行
- 四半期ゲームデイの定例化
- MTTR（平均復旧時間）50%削減
- 障害関連インシデント30%削減

Chaos Kong プロセス：

1. 準備段階
   - トラフィックルーティングの確認
   - 代替リージョンのキャパシティ確認
   - モニタリング強化
   - 関連チームへの事前通知

2. 実行段階
   - US-East-1の全トラフィックをUS-West-2へ転送
   - DNSベースのグローバルロードバランシングを活用
   - 転送過程でのリアルタイムメトリクス監視

3. 観察項目
   - トラフィック転送完了時間
   - 代替リージョンのオートスケーリング応答時間
   - ユーザー体験への影響
   - データの一貫性

4. 復旧段階
   - トラフィックを元のリージョンに復元
   - データ同期の確認
   - 全体結果の分析

Level 0：カオスなし
- 障害時の手動対応
- 「うちのシステムは大丈夫」という希望

Level 1：基本カオス
- Chaos Monkeyによるインスタンス終了
- 個別サービスのレジリエンス確認

Level 2：体系的カオス
- 多様な障害タイプの実験
- 定期的なゲームデイの実行
- 結果に基づく改善

Level 3：高度なカオス
- AZ障害シミュレーション
- CI/CD統合
- 自動化された実験

Level 4：カオス文化
- リージョン退避訓練（Chaos Kong）
- 全チームがカオス実験を実施
- レジリエンスがアーキテクチャ意思決定の核心基準

Amazon GameDay の原則：

1. "Everything fails, all the time" - Werner Vogels
   - 障害を通常の運用の一部として扱う

2. 段階的な複雑度の増加
   - 単一サービス → サービスチェーン → システム全体

3. 非難のない文化
   - 障害対応の失敗を学習機会に変える

4. 文書化
   - すべてのGameDay結果を詳細に記録

5. 繰り返し
   - 同じシナリオを繰り返して改善を検証

# 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: Verify System Recovery
        run: |
          ./scripts/verify-steady-state.sh

主要メトリクス（Golden Signals）：

1. レイテンシ (Latency)
   - p50、p90、p99レスポンスタイム
   - サービス間呼び出しレイテンシ

2. トラフィック (Traffic)
   - 秒間リクエスト数（RPS）
   - トラフィック分布

3. エラー (Errors)
   - HTTP 5xx率
   - アプリケーションエラー率
   - タイムアウト率

4. 飽和度 (Saturation)
   - CPU使用率
   - メモリ使用率
   - ネットワーク帯域幅
   - ディスクI/O

# 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: "直ちに実験を中断して状態を確認してください"

SREとChaos Engineeringの関係：

SREの目標：信頼性が高くスケーラブルなシステムの運用
     |
     +-- SLO/SLI/SLA定義 → カオス実験の成功基準
     |
     +-- Error Budget → カオス実験実行の可否を決定
     |
     +-- インシデント管理 → ゲームデイシナリオのソース
     |
     +-- ポストモーテム → 新しいカオス実験のアイデア
     |
     +-- Toil削減 → カオス実験の自動化