カオスエンジニアリング
本番環境で意図的に障害を注入し、システムの耐障害性を検証する実践手法
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) がある
- ロールバック手順が確立されている
- チームが障害対応に慣れている
詳しくは関連書籍を参照。