Skip to content
Published on

Chaos Engineering 完全解剖 — Netflix Simian Army、LitmusChaos/Chaos Mesh、AWS FIS、Game Day

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに — 「本番サーバーをわざと殺すの?」

Chaos Engineering を初めて聞く人はこう反応する。

「障害だけでも困るのに、なぜわざと起こすのか?」

答え: 障害はどうせ起きる。統制された環境で先に経験するほうが痛みが少ない。 2010 年、Netflix は AWS 移行でこの逆説的な真理を悟り、世界に Chaos Monkey を解き放った。

本稿では:

  • なぜ Netflix はサーバーを殺し始めたのか — 誕生背景
  • Chaos Engineering の 4 原則
  • Simian Army — Chaos Monkey から Chaos Kong まで
  • LitmusChaos / Chaos Mesh — Kubernetes のカオスツール
  • AWS Fault Injection Simulator
  • Game Day の設計と実行
  • Observability とカオスの結合
  • Blameless Postmortem — 文化の柱
  • 実戦レシピ 10 個
  • 成熟度モデル

1. 誕生背景 — 2010 年 Netflix の選択

問題: モノリスからクラウドへ

Netflix は 2008 年の DC 障害で DVD 配送が 3 日停止。結論: 「自社 DC では無理、クラウドへ」。AWS 移行で気づいたこと:

  • 個別インスタンスの信頼性は低い (コモディティ VM)
  • ネットワークは常に分断しうる (AZ/リージョン間)
  • 依存サービスは常にどこかで失敗している

選択肢:

  1. 完璧なコードを書く (不可能)
  2. 失敗を前提に設計する (現実的)

Chaos Monkey の誕生 (2010)

シンプルなツール: AWS でランダムに EC2 を終了。内部反発は激しかった。「正気じゃない」。しかしエンジニアが自サービスを 1 インスタンス死んでも生き残る よう設計し始めた。結果:

  • 再起動に耐えるアーキテクチャ
  • ローリング更新の常態化
  • 障害がニュースではなく日常に

2012 年 OSS 化。Chaos Engineering という名称が世に出る。

2. 4 つの原則

principlesofchaos.org が公式化:

1. Steady State Hypothesis を定義せよ

健全時の測定可能な指標 が必要:

  • 秒間リクエスト数
  • P99 レイテンシ
  • エラー率
  • ビジネス指標 (決済成功率)

Netflix の「Starts Per Second (SPS)」が有名。

2. 実世界イベントを多様化せよ

現実に起きる事象を注入:

  • インスタンスダウン
  • ネットワーク遅延/分断
  • DNS 失敗
  • 依存サービスのタイムアウト
  • リージョン障害
  • ディスク満杯
  • 時計のずれ

コードバグより 環境イベント に集中。

3. 本番で実験せよ

Staging は本番ではない。トラフィックパターン、データ量、サードパーティ依存がすべて異なる。段階的に — 10 % から。しかし最終的には本番で。

4. 自動化し、継続せよ

一度きりでは意味がない。CI/CD のように カオスもパイプライン に。

3. Simian Army — Netflix の全体構成

Chaos Monkey (2010)

ランダム EC2 終了。業務時間内のみ。

Latency Monkey (2012)

サービス間通信に遅延を注入。

Conformity Monkey

標準外インスタンスを終了 (旧 AMI、誤ったタグなど)。

Doctor Monkey

異常インスタンス (CPU 100 %、無応答) を検知・対処。

Janitor Monkey

未使用リソース (孤立 EBS、未使用 IP) を整理。

Security Monkey

誤った IAM/セキュリティグループを自動検知。

Chaos Gorilla (2011)

AZ 1 つ全体 をダウンさせる。

Chaos Kong (2013)

AWS リージョン 1 つ全体 をダウン。2016 年の実障害でも Netflix は耐えた。

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"

実験種別: Pod delete、container kill、network loss/latency/corruption、CPU/memory/IO stress、node drain、AWS/Azure/GCP 操作。

Chaos Mesh (CNCF Incubating)

  • PingCAP (TiDB 社) 製
  • 優れた UI ダッシュボード
  • 強力な スケジューリング (cron ベース反復)
  • ワークフロー 対応
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高度なワークフロー
学習曲線中低

選択ガイド:

  • すぐ始めたい → 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 リリース、AKS 連携
  • GCP: 公式製品なし、Chaos Mesh 推奨

6. Game Day — 組織的災害訓練

なぜ Game Day か

自動カオスが「技術検証」なら、Game Day は「組織検証」。検証対象:

  • 誰が対応するか (on-call rotation)
  • 実用的な Runbook はどれか
  • Slack/PagerDuty 通知は機能するか
  • コミュニケーションの遅延箇所
  • エスカレーションは機能するか

設計テンプレート

  1. 目標設定 — 例: 「us-east-1 停止時に 15 分以内に us-west-2 へ復旧」
  2. 参加者 — SRE、Backend、DBA、Frontend、PM
  3. シナリオ — 「10:00 RDS プライマリ フェイルオーバー、10:05 書き込み +10 %、10:10 キャッシュ半分再起動」
  4. 実行 — 観察者と実行者を分離、タイムライン実況
  5. 振り返り — うまくいった点、驚いた点、更新すべき Runbook、必要な自動化

実戦 Tips

  • 初回は低リスクで — 平日午後、トラフィック低い時間帯
  • チャットチャンネルを常時オープン
  • Time-boxing — 1 時間で復旧しなければ中止
  • Blast Radius 制御 — 全体の 1〜5 %

7. Observability とカオスの結合

Chaos without Observability = Guessing

実験中に見るもの:

  • Steady State 指標
  • 依存サービスへのエラー伝播
  • Cascading Failure の兆候

観測性 3 本柱 — Metrics / Logs / Traces。

Canary + Chaos パターン

  • 10 % カナリアにデプロイ
  • カナリアのみにカオス注入
  • 正しくフェイルするかを検証
  • 合格 → 全体展開

Auto-Abort

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

8. Blameless Postmortem — カオス文化の柱

なぜ「非難なし」か

個人を非難すると:

  • 障害が隠蔽される
  • 学習が止まる
  • 心理的安全性が崩れる

「誰が悪いか」ではなく 「システムがなぜ失敗を許したか」 に集中。

テンプレート

  1. 影響 — ユーザー数、時間、金銭的影響
  2. タイムライン — 分単位
  3. 根本原因 — Five Whys
  4. よかった点 — 検知速度、チームワーク
  5. 悪かった点 — 通知漏れ、Runbook 不備
  6. アクションアイテム — 担当者と期限

Five Whys 例

問題: 決済が 15 分失敗

  1. なぜ? → 決済サービスが無応答
  2. なぜ? → DB コネクションプール枯渇
  3. なぜ? → インデックスなしのクエリ
  4. なぜ? → 直近のデプロイで追加したがインデックス漏れ
  5. なぜ? → PR レビュー チェックリストに「インデックス確認」がない

→ アクション: PR テンプレートに追加。根本原因は「開発者のミス」ではなく 「プロセスの欠落」 に帰結。

Just Culture

Blameless ≠ 無責任。故意の無視・繰り返しの不注意には処置。John Allspaw (Etsy) の Just Culture フレームワーク参照推奨。

9. 実戦カオスレシピ 10 個

1. Pod ランダム削除

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 * * *"

検証: readinessProbe、graceful termination、PodDisruptionBudget。

2. CPU ストレス

検証: HPA のスケールアウト、Throttling 対応。

3. ネットワーク遅延

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

検証: タイムアウト、サーキットブレーカー。

4. 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 ヒット率。

10. カオス成熟度モデル

Level 1 — Chaos-curious

興味はあるがツール未導入。事後対応中心。非難ありのポストモーテム。

Level 2 — Staging Chaos

Staging で散発的に実験。Runbook 存在。On-call ローテーション。

Level 3 — Production Chaos

本番で統制された実験。ビジネス指標の Steady State。四半期 Game Day。

Level 4 — Continuous Chaos

CI/CD 統合。Blast Radius 自動拡大。自動中止 + Observability。

Level 5 — Engineering Culture

すべての PR が「このカオスシナリオは?」を考慮。Blameless が自然。失敗は学習機会。

Netflix、Google、Amazon は Level 5。多くは 1〜2。段階的に登ろう。

11. カオスが暴くアンチパターン

  1. Hidden Dependency — 「あのサービス死なないよ」→ 実験で死ぬ
  2. Cascading Failures — A→B 依存、B 落ち → A リトライ爆発 → C 巻き込み
  3. Single Point of Failure — 単一 DB、LB、DNS
  4. Inadequate Timeouts — 30 秒待ちの UX 苦痛
  5. Incomplete Retries — バックオフなしの再試行で負荷増幅

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. Stop Condition 必須
  5. Observability 先行
  6. Runbook と連携
  7. PDB / preStop hooks
  8. On-call に事前告知
  9. 結果のドキュメント化
  10. Blameless Postmortem 文化
  11. Game Day 定期化 (四半期)
  12. 経営層のスポンサーシップ

次回予告 — 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
  • OpenFeature 標準化
  • 実戦ロールアウト戦略

「デプロイとリリースを分離せよ。コードはすでにそこにある、機能はまだオンになっていない — これが現代ソフトウェアの基本姿勢だ。」

Discuss on Twitter • View on GitHub