メインコンテンツまでスキップ

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)から。
問題が見つかるはず。それを修正してから実地テストへ。

関連ドキュメント