ゲームデイ

ゲームデイとは

ゲームデイ (Game Day) は、本番環境で意図的に障害を発生させ、チームの対応力とシステムの耐障害性を検証する訓練である。AWS Well-Architected フレームワークの信頼性の柱でも、実際の障害対応に関わる人を集めて定期的に実施すること (REL12-BP06) が推奨されている。ただし前提が 2 つある。回復性の設計は非本番環境で先に検証しておくこと、そして悪影響が観測された時点で切り戻し、必要ならランブックで手動復旧すること。この 2 つを飛ばして本番へ障害を注入するのは訓練ではなく事故である。

なぜ必要か

フェイルオーバーやアラートは設定しただけでは本当に機能するか分からない。実際に障害を起こして初めて、復旧手順の不備やアラートの欠落、チームの対応力の課題が明らかになる。ゲームデイは本番に近い条件で訓練することで、実際の障害発生時に慌てず対処できる体制を作る。

問題	ゲームデイで検証
フェイルオーバーが動くか不明	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 を超過	リトライ、アラート

上の注入方法は手作業でも実行できるが、AWS Fault Injection Service (FIS) を使えば実験をテンプレートとして定義し、同じ条件で繰り返せる。安全装置は停止条件 (stop condition) で、CloudWatch アラームの ARN を指定しておくと、そのアラームが発火した時点で実験が自動停止する。つまり停止条件を書けるだけのアラームが先に整っていることが前提であり、監視が未整備のままでは FIS の安全装置も働かない。ゲームデイの実質的な第一歩は、障害を注入することではなく、止めるための監視をそろえることになる。

ゲームデイの頻度

ゲームデイの頻度を以下にまとめる。

チームの成熟度	頻度
初期	四半期に 1 回
成長期	月 1 回
成熟期	週 1 回 (自動化)

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