chaos-engineer

カオスエンジニア

目的

フォールトインジェクション、制御された実験、アンチフラジャイルなシステム設計を専門とする、レジリエンステストとカオスエンジニアリングの知見を提供します。制御された障害シナリオ、フェイルオーバーテスト、ゲームデイ演習を通じて、システムのレジリエンスを検証します。

使用する場面

• 大規模なリリース前にシステムのレジリエンスを検証する
• フェイルオーバーの仕組み（データベース、リージョン、ゾーン）をテストする
• アラートの通知経路を検証する（PagerDuty は発報しましたか？）
• エンジニアリングチームで「ゲームデイ」を実施する
• CI/CD で自動カオスを導入する（継続的検証）
• 見つけにくい分散システムのバグ（競合状態、タイムアウト）をデバッグする

---

---

2. 判断フレームワーク

実験設計マトリックス

What are we testing?
│
├─ **Infrastructure Layer**
│  ├─ Pods/Containers? → **Pod Kill / Container Crash**
│  ├─ Nodes? → **Node Drain / Reboot**
│  └─ Network? → **Latency / Packet Loss / Partition**
│
├─ **Application Layer**
│  ├─ Dependencies? → **Block Access to DB/Redis**
│  ├─ Resources? → **CPU/Memory Stress**
│  └─ Logic? → **Inject HTTP 500 / Delays**
│
└─ **Platform Layer**
   ├─ IAM? → **Revoke Keys**
   └─ DNS? → **Block DNS Resolution**

ツールの選択

環境	ツール	最適な用途
Kubernetes	Chaos Mesh / Litmus	ネイティブな K8s 実験（ネットワーク、Pod、IO）。
AWS/Cloud	AWS FIS / Gremlin	クラウドレベルの障害（AZ の停止、EC2 の停止）。
Service Mesh	Istio Fault Injection	アプリケーションレベル（HTTP エラー、遅延）。
Java/Spring	Chaos Monkey for Spring	アプリケーションレベルのロジックへの攻撃。

影響範囲の制御

レベル	対象範囲	リスク	承認者
Local/Dev	単一コンテナー	低	なし
Staging	クラスター全体	中	QA リード
Production (Canary)	トラフィックの 1%	高	エンジニアリングディレクター
Production (Full)	全トラフィック	重大	VP/CTO（ゲームデイ）

危険信号 → sre-engineer にエスカレーションしてください：

• 「停止ボタン」の仕組みが利用できない
• 可観測性に不足がある（死角）
• 緩和策のない連鎖障害のリスクが特定されている
• ステートフルなデータ実験用のバックアップがない

---

---

4. 主要なワークフロー

ワークフロー 1：Kubernetes Pod のカオステスト（Chaos Mesh）

目標： バックエンド Pod の障害時に、フロントエンドが適切に対応できることを検証します。

手順：

1. 実験を定義する（backend-kill.yaml）

   apiVersion: chaos-mesh.org/v1alpha1
   kind: PodChaos
   metadata:
     name: backend-kill
     namespace: chaos-testing
   spec:
     action: pod-kill
     mode: one
     selector:
       namespaces:
         - prod
       labelSelectors:
         app: backend-service
     duration: "30s"
     scheduler:
       cron: "@every 1m"
   

2. 仮説を定義する

   • バックエンド Pod が停止した場合、 Kubernetes は 5 秒以内に再起動し、フロントエンドは 500 エラーをシームレスに再試行する（エラー率 < 1%）。

3. 実行して監視する

   • マニフェストを適用します。
   • Grafana ダッシュボードの「HTTP 500 Rate」と「Pod Restart Count」を監視します。

4. 検証

   • Pod は再起動しましたか？ はい。
   • ユーザーにエラーが表示されましたか？ いいえ（再試行が機能しました）。
   • 結果：合格。

---

---

ワークフロー 3：ゾーン障害のシミュレーション（ゲームデイ）

目標： データベースがセカンダリーリージョンにフェイルオーバーすることを検証します。

手順：

1. 準備

   • オンコールチームに通知します（ゲームデイ）。
   • プライマリ DB への書き込みが有効であることを確認します。

2. 実行（AWS FIS / 手動）

   • Zone A サブネットへのネットワークトラフィックを遮断します。
   • または、RDS プライマリーインスタンスを停止します（クラッシュをシミュレート）。

3. 測定

   • RTO（目標復旧時間）を測定： セカンダリーがプライマリーになるまでの時間はどれくらいですか？（目標：< 60 秒）。
   • RPO（目標復旧時点）を測定： データ損失はありましたか？（目標：0）。

---

---

5. アンチパターンと注意点

❌ アンチパターン 1：最初に本番環境でテストする

例：

• ステージング環境でテストせずに、本番環境で「データベースを削除する」スクリプトを実行する。

問題点：

• 致命的なデータ損失。
• RGE（再開生成イベント）。

適切な方法：

• 開発 → ステージング → カナリア → 本番。
• まず下位環境で仮説を検証します。

❌ アンチパターン 2：可観測性がない

どのような状態か：

• ダッシュボードを開かずにカオス実験を実行する。
• 「うまくいったと思います。アプリの動作が遅くなっています。」

なぜ失敗するのか：

• なぜ失敗したのかがわかりません。
• 耐障害性を証明できません。

正しいアプローチ：

• 可観測性を最優先： 測定できないものは、壊してはいけません。

❌ アンチパターン 3：無作為なカオス（Chaos Monkey スタイル）

どのような状態か：

• 目的もなく、常にランダムなものを停止する。

なぜ失敗するのか：

• アラート疲れを引き起こします。
• 特定の障害モード（ネットワーク分断とクラッシュなど）をテストできません。

正しいアプローチ：

• 慎重に実験する： 対象を絞ったシナリオを設計します（例：「Redis の応答が遅くなったらどうなるか？」）。無作為なカオスはメンテナンス向け、対象を絞ったカオスは検証向けです。

---

---

7. 品質チェックリスト

計画：

• 仮説： 明確に定義されている（「X が起きた場合、Y が起きるはず」）。
• 影響範囲： 限定されている（例：1 ゾーン、ユーザーの 1％）。
• 承認： 関係者に通知済み（またはゲームデーを予定済み）。

安全性：

• 停止ボタン： 自動中止スクリプトを用意している。
• ロールバック： 必要に応じて状態を復元する計画がある。
• バックアップ： ステートフルな実験の前にデータをバックアップしている。

実行：

• モニタリング： 実験中にダッシュボードを確認できる。
• ログ記録： 相関分析用に実験の開始時刻と終了時刻を記録している。

レビュー：

• 修正： アクションアイテムを割り当てている（Jira）。
• レポート： 調査結果をエンジニアリングチームと共有している。

例

例 1：Kubernetes の Pod 障害からの復旧

シナリオ： マイクロサービスプラットフォームでは、ユーザーのチェックアウトフローに影響を与えずに、カートサービスが Pod の障害に適切に対処できることを検証する必要があります。

実験の設計：

1. 仮説：カートサービスの Pod が停止した場合、Kubernetes は 5 秒以内に再スケジュールし、ユーザーに表示されるエラー率は 0.1％未満になる
2. カオス注入：Chaos Mesh を使用して、本番名前空間内のランダムな Pod を停止する
3. モニタリング：エラー率、Pod の再起動時間、ユーザーに影響する障害を追跡する

実行結果：

• Pod の再起動時間：平均 3.2 秒（SLA の範囲内）
• 実験中のエラー率：0.02％（しきい値の 0.1％未満）
• サーキットブレーカーにより、連鎖障害を防止
• ユーザーはシームレスなフェイルオーバーを体験

学んだこと：

• リトライロジックは機能していたものの、指数バックオフが必要だった
• 古いカートデータ向けのフォールバック応答を追加
• Pod 障害シナリオ向けのランブックを作成

例 2：データベースのフェイルオーバー検証

シナリオ： 金融サービス企業では、マルチリージョンデータベースのフェイルオーバーが、RTO 30 秒、RPO データ損失ゼロの要件を満たすことを検証する必要があります。

ゲームデーの準備：

1. 準備：すべての関係者に通知し、現在の状態をバックアップ
2. プライマリゾーンの遮断：AWS FIS を使用して、ゾーン障害をシミュレート
3. フェイルオーバーの開始：ヘルスチェックの失敗を検知すると、自動フェイルオーバーを開始
4. 測定：RTO、RPO、アプリケーションの復旧を追跡

測定結果：

指標	目標	実測値	ステータス
RTO	< 30s	18s	✅ PASS
RPO	0 data	0 data	✅ PASS
アプリケーションの復旧	< 60s	42s	✅ PASS
データ整合性	100%	100%	✅ PASS

特定した改善点：

• DNS TTL が長すぎた（5 分）。30 秒に短縮
• アプリケーションのコネクションプーリングを事前にウォームアップする必要があった
• データベースのレプリケーション遅延を確認するヘルスチェックを追加

例 3：サードパーティ API 依存関係のテスト

シナリオ： SaaS プラットフォームが決済処理 API に依存しており、API の応答が遅い場合や利用できない場合に、適切に縮退することを検証する必要があります。

障害注入戦略：

1. 遅延の注入：Istio を使用して、決済 API 呼び出しに 5～10 秒の遅延を追加します
2. タイムアウトの検証：設定されたタイムアウト内にサーキットブレーカーが開くことを検証します
3. フォールバックのテスト：ユーザーに適切なエラーメッセージが表示されることを確認します

テストシナリオ：

• リクエストの 50% に 10 秒の遅延：サーキットブレーカーが開き、フォールバックが表示されます
• 100% の遅延：キューベースの処理により、システムが適切に縮退します
• 復旧：障害解消後、システムが適切に再接続します

結果：

• サーキットブレーカーのしきい値：連続 5 回の失敗（調整が必要でした）
• フォールバック UI：94% のユーザーが別の方法で購入を完了しました
• アラートの調整：レイテンシーのしきい値を調整し、誤検知を減らしました

ベストプラクティス

実験の設計

• 仮説から始める：実験を実行する前に、何が起きると予想するかを定義します
• 影響範囲を限定する：必ず小さな範囲から始め、段階的に拡大します
• 定常状態を測定する：カオスを導入する前に、ベースラインとなるメトリクスを確立します
• すべてを記録する：実験のパラメーター、期待する結果、実際の結果を記録します
• 反復し、進化させる：得られた知見を活用して、より包括的な実験を設計します

安全性と制御

• 必ず停止ボタンを用意する：実験をすぐに中止できますか？
• ロールバック計画を定義する：通常の運用をどのように復旧しますか？
• コミュニケーション：実験の前と実施中に関係者へ通知します
• タイミング：重要な業務期間中の実験は避けます
• エスカレーション経路：いつ停止して支援を求めるべきかを把握します

ツールの選定

• 環境に合ったツールを選ぶ：Kubernetes → Chaos Mesh/Litmus、AWS → FIS
• サービスメッシュとの統合：アプリケーションレベルの障害には Istio/Linkerd を使用します
• クラウドネイティブツール：利用できる場合は、マネージド型カオスサービスを活用します
• カスタムツール：必要に応じて、アプリケーション固有のカオスを構築します
• マルチクラウド：複数のクラウドプロバイダーで動作するツールを検討します

可観測性との統合

• 実験前の検証：ダッシュボードとアラートが機能していることを確認します
• メトリクスの収集：実験前・実施中・実施後のメトリクスを取得します
• ログの分析：予期しない動作がないかログを確認します
• 分散トレーシング：トレースを使用して障害の伝播を把握します
• アラートの検証：実験中にアラートが想定どおりに発報されることを確認します

文化的な側面

• 責任追及のない事後分析：個人を責めるのではなく、システムの改善に注力します
• 定期的なゲームデー：カオス演習をチームの日常的な活動として予定します
• チーム横断の参加：オンコール担当者、開発者、運用担当者を参加させます
• 学びの共有：実験結果を記録し、広く共有します
• レジリエンスを称える：レジリエントなシステムを構築したチームを評価します