カオスエンジニアリング

本番環境で意図的に障害を注入し、システムの耐障害性を検証する実践手法

SRE耐障害性

カオスエンジニアリングとは

カオスエンジニアリングは、本番環境で意図的に障害を注入し、システムの耐障害性を検証する実践手法である。Netflix が 2010 年代に体系化し、「Principles of Chaos Engineering」として原則を公開した。詳細は「Chaos Monkey」「ゲームデイ」を参照。

原則

カオスエンジニアリングでは、まず「エラー率 < 1%」のような定常状態の仮説を立てる。AZ 障害、ネットワーク遅延、ディスク障害など実世界のイベントを模擬し、ステージングではなく本番環境で実験する。実験は 1 回限りではなく自動化して継続的に実行し、影響範囲 (爆発半径) を最小化する。

実験の進め方

1. 仮説: 「AZ-a が停止しても、エラー率は 1% 未満を維持する」
2. 実験設計: AZ-a のインスタンスを停止
3. 停止条件: エラー率 > 5% で自動停止
4. 実行: AWS FIS で障害を注入
5. 観察: CloudWatch でメトリクスを監視
6. 分析: 仮説が正しかったか検証
7. 改善: 問題があれば修正し、再実験

サーバーレスでの実験

実験 方法
Lambda スロットリング Reserved Concurrency を 0 に
DynamoDB スロットリング プロビジョンドモードで容量を制限
外部 API 障害 Lambda Layer でエラーを注入
レイテンシ注入 Lambda Layer で sleep を追加

成熟度モデル

レベル 内容
1. 手動テスト ゲームデイで手動実験
2. 自動化 FIS で定期実行
3. 継続的 CI/CD パイプラインに組み込み
4. 自律的 自動修復の検証を含む

前提条件

カオスエンジニアリングを始める前に:

  • オブザーバビリティ (ログ、メトリクス、トレース) が整備されている
  • 自動復旧の仕組み (Auto Scaling, Multi-AZ) がある
  • ロールバック手順が確立されている
  • チームが障害対応に慣れている

詳しくは関連書籍を参照。

関連用語