DR テスト（Game Day）

DR の手順書を作っても、実際に動かさなければ本番で使えるかわからない。Game Day は、本番環境（またはそれに近い環境）で意図的に障害を発生させ、復旧手順を検証するイベントです。

---

なぜ Game Day が必要か

DR 手順書があるのに Game Day が必要な理由:

  ❌ 手順書の通りに動かない
     → 「スナップショットから復元」と書いてあるが、
       実際にはパラメータグループの設定が必要だった

  ❌ 復元に想定以上の時間がかかる
     → RTO 30分のつもりが、DB 復元だけで2時間かかった

  ❌ 手順書に書いていない依存関係がある
     → DB は復元できたが、キャッシュのウォームアップに時間がかかり
       切り替え直後にレイテンシが跳ね上がった

  ❌ 担当者が手順を実行できない
     → 権限がない、ツールの使い方を知らない

  → 実際にやってみないとわからない問題が必ずある

---

Game Day の種類

種類	対象	リスク	頻度
テーブルトップ演習	手順の読み合わせ、役割確認	なし	月次
DR リージョン復元テスト	DR リージョンで DB 復元 + アプリ起動	低（本番影響なし）	四半期
フェイルオーバーテスト	実際に DR リージョンに切り替え	中（切り替え時に一時停止）	半年〜年次
カオスエンジニアリング	本番で意図的に障害を注入	高	成熟したチームのみ

---

テーブルトップ演習（最初のステップ）

実際のインフラを触らずに、手順書を読み合わせて問題を見つける。

進め方（1時間）:

  1. シナリオを提示（10分）
     「Primary リージョンの DB が応答しなくなりました。
      クラウドプロバイダーは復旧見込み不明と発表しています。」

  2. 手順に沿って「何をするか」を口頭で実行（30分）
     ・IC「Sev 1 を宣言します」
     ・調査担当「DB のステータスを確認します」
     ・IC「30分以内の復旧見込みなし。DR フェイルオーバーを開始」
     ・復旧担当「手順 Step 2: DB の昇格を実行します」
     ・... 手順の各ステップを口頭で確認

  3. 問題点の洗い出し（20分）
     ・「Step 2 で必要な権限を持っていない人がいた」
     ・「Step 4 の DNS 切り替えの具体的なコマンドがない」
     ・「フェイルバックの手順が曖昧」
     → 手順書を更新

---

DR リージョン復元テスト

DR リージョンで実際に DB を復元し、アプリを起動する。本番には影響しない。

手順:

  1. 最新のバックアップ / スナップショットを確認
  2. DR リージョンで DB を復元
  3. DR リージョンでアプリを起動
  4. 動作確認（ヘルスチェック、ログイン、トークン発行）
  5. 復元にかかった時間を記録
  6. RTO を満たしているか評価
  7. DR 環境をクリーンアップ

計測すべき指標:
  □ DB 復元時間: __分
  □ アプリ起動時間: __分
  □ 動作確認完了: __分
  □ 合計（= 実測 RTO）: __分
  □ 目標 RTO: __分
  □ 達成: YES / NO

---

フェイルオーバーテスト

実際に DR リージョンにトラフィックを切り替える。最もリアルだが、リスクもある。

事前準備:
  □ 低トラフィック時間帯に実施
  □ テナントへの事前通知（計画メンテナンスとして）
  □ ロールバック（フェイルバック）手順の確認
  □ 全チームメンバーの待機確認

実施:
  1. Primary リージョンの DB レプリケーションを確認（ラグ = 0）
  2. DNS を DR リージョンに切り替え
  3. Primary の DB を意図的に停止（or アプリを停止）
  4. DR リージョンでの動作確認
  5. 一定時間（30分〜1時間）DR リージョンで運用
  6. フェイルバック実施（Primary に戻す）

計測すべき指標:
  □ フェイルオーバー完了時間: __分
  □ エラー率（切り替え中）: __%
  □ ユーザー影響時間: __分
  □ フェイルバック完了時間: __分

---

Game Day のアンチパターン

❌ 「やったことにする」
   → テーブルトップだけで「DR テスト完了」にする
   → 実際にインフラを触らないと見つからない問題がある

❌ 本番でぶっつけ本番
   → 最初から本番フェイルオーバーテストをやる
   → まずテーブルトップ → 復元テスト → フェイルオーバーテスト の順で

❌ 問題が見つかっても修正しない
   → Game Day で見つかった問題を放置
   → 次の Game Day で同じ問題が見つかる → 時間の無駄

❌ 1回やって終わり
   → インフラは変わる、チームも変わる
   → 定期的に実施しないと手順が陳腐化する

---

Game Day の結果レポート

# Game Day レポート: YYYY-MM-DD

## 概要
- 種類: DR リージョン復元テスト
- 日時: YYYY-MM-DD HH:MM - HH:MM
- 参加者: {名前}

## 実施内容
- シナリオ: Primary リージョンの DB 障害

## 計測結果
| 指標 | 目標 | 実測 | 達成 |
|------|------|------|------|
| DB 復元時間 | 30分 | 25分 | ✅ |
| アプリ起動時間 | 10分 | 8分 | ✅ |
| 動作確認 | 5分 | 15分 | ❌ |
| 合計 RTO | 45分 | 48分 | ❌ |

## 発見された問題
1. 動作確認に使うテストスクリプトが DR リージョンの URL に対応していなかった
2. DB パラメータグループが DR リージョンで異なっていた

## アクションアイテム
- [ ] テストスクリプトの URL を環境変数化 → 担当: {名前} → 期限: YYYY-MM-DD
- [ ] DB パラメータグループを IaC で統一 → 担当: {名前} → 期限: YYYY-MM-DD

---

段階的な導入

1ヶ月目: テーブルトップ演習
  → 手順書の読み合わせ、問題点の洗い出し
  → コスト: 0（人件費のみ）

3ヶ月目: DR リージョン復元テスト
  → 実際に DB を復元してアプリを起動
  → コスト: DR 環境の一時稼働分

6ヶ月目: フェイルオーバーテスト
  → 実際にトラフィックを切り替え
  → コスト: DR 環境のフル稼働分 + メンテナンスウィンドウ

以降: 四半期ごとに復元テスト、年次でフェイルオーバーテスト

クラウドの利点: クラウド環境では DR テスト用の環境を一時的に起動し、テスト終了後に削除できます。使った時間分だけの課金で済むため、オンプレミス（常時 DR サイトを維持する必要がある）に比べてテストのコストが大幅に低くなります。

---

まとめ

Game Day の価値:

  1. 手順書の問題を「本番前に」発見できる
  2. 実測 RTO で目標を達成できるか検証できる
  3. チームが DR 手順に習熟できる
  4. 「DR は準備してある」と自信を持って言える

始め方:
  まずはテーブルトップ演習（1時間、コスト0）から。
  問題が見つかるはず。それを修正してから実地テストへ。

---

関連ドキュメント

• RPO/RTO と DR 戦略: 復旧目標の設計
• フェイルオーバー手順: 切り替えの具体手順
• 障害対応 - ポストモーテム: Game Day の結果も同じフォーマットで記録
• カオスエンジニアリング: より高度な障害注入テスト