ゲームデイ
本番環境で意図的に障害を発生させ、チームの対応力とシステムの耐障害性を検証する訓練
SRE耐障害性
ゲームデイとは
ゲームデイ (Game Day) は、本番環境で意図的に障害を発生させ、チームの対応力とシステムの耐障害性を検証する訓練である。AWS が推奨するプラクティスで、「障害は起きるもの」という前提で準備する。
なぜ必要か
| 問題 | ゲームデイで検証 |
|---|---|
| フェイルオーバーが動くか不明 | RDS のフェイルオーバーを実行 |
| アラートが正しく発火するか | 障害を起こしてアラートを確認 |
| ランブックが最新か | 手順通りに復旧できるか検証 |
| チームが障害対応できるか | 実践的な訓練 |
ゲームデイの進め方
1. 計画
- シナリオを定義 (例: AZ 障害、DB フェイルオーバー)
- 影響範囲を限定 (本番の一部 or ステージング)
- ロールバック手順を準備
- 関係者に事前通知
2. 実行
- 障害を注入
- チームが検知・対応
- タイムラインを記録
3. 振り返り
- 検知までの時間
- 復旧までの時間
- 改善点の洗い出し
- アクションアイテムの作成
シナリオの例
| シナリオ | 注入方法 | 検証項目 |
|---|---|---|
| AZ 障害 | サブネットのルートテーブルを変更 | Multi-AZ フェイルオーバー |
| DB フェイルオーバー | aws rds reboot-db-instance --force-failover |
復旧時間、アプリの挙動 |
| Lambda スロットリング | Reserved Concurrency を 0 に | アラート、フォールバック |
| 外部 API 障害 | DNS を変更して接続不能に | サーキットブレーカー |
| DynamoDB スロットリング | 大量書き込みで WCU を超過 | リトライ、アラート |
FIS は AWS のカオスエンジニアリングサービスで、安全に障害を注入できる。停止条件 (Stop Condition) を設定し、影響が大きすぎる場合は自動停止する。
ゲームデイの頻度
| チームの成熟度 | 頻度 |
|---|---|
| 初期 | 四半期に 1 回 |
| 成長期 | 月 1 回 |
| 成熟期 | 週 1 回 (自動化) |
実践的な知識は関連書籍でも得られる。