ゲームデイ

ゲームデイとは

ゲームデイ (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 回 (自動化)

実践的な知識は関連書籍でも得られる。