フェイルオーバー手順
マルチリージョン構成とバックアップが準備できたら、実際の切り替え手順を整理します。DR のフェイルオーバーは Blue-Green デプロイと似ていますが、計画外で実行される点が異なります。
Blue-Green デプロイとの違い
| Blue-Green デプロイ | DR フェイルオーバー | |
|---|---|---|
| タイミング | 計画的（リリース時） | 計画外（障害時） |
| 精神状態 | 落ち着いている | パニックになりやすい |
| 準備時間 | 数時間〜数日 | なし（即座に判断） |
| ロールバック | 容易（旧環境が残っている） | 困難（Primary が壊れている可能性） |
| データ同期 | レプリケーション稼働中 | レプリケーションが切れている可能性 |
だからこそ手順を事前に整理し、定期的に訓練しておく必要がある。
そもそも操作できるのか
DR が必要な状況では、操作する側も被災している可能性がある。手順書があっても実行できなければ意味がない。
人の問題
リージョン障害 = その地域のインフラ全体が影響を受ける可能性
オペレーターが同じ地域にいる場合:
├── 地震・台風 → オペレーター自身が被災
├── 停電 → 自宅のネットワークも使えない
└── 深夜の障害 → そもそも気づかない
対策:
├── オンコール体制を複数リージョン / 拠点で組む
│ → 東京が被災しても大阪のメンバーが対応
├── リモートワーク前提 → 複数の通信手段（携帯回線 + 自宅回線）
└── 自動フェイルオーバーを最大限活用
→ 人の介入なしで復旧できる範囲を広げる
ツールの問題
DR 操作に使うツールが Primary リージョンに依存していないか？
確認すべき項目:
□ クラウドの管理コンソール → 通常はグローバルサービス（OK）
□ CI/CD パイプライン → どのリージョンで動いている？
□ 踏み台サーバー / VPN → Primary リージョンだけに置いていないか？
□ チャットツール（Slack 等） → SaaS なら通常 OK
□ ページングツール（PagerDuty 等） → SaaS なら通常 OK
□ IaC の state ファイル → S3 + DynamoDB がどのリージョンにある？
□ シークレット（DB パスワード等） → Primary リージョンだけに保存していないか？
対策:
├── CI/CD はマルチリージョン or SaaS（GitHub Actions 等）
├── 踏み台 / VPN は DR リージョンにも配置
├── シークレットは DR リージョンにレプリケーション
└── IaC の state は別リージョンにバックアップ
自動化で人の介入を減らす
理想:
┌──────────────────────────────────────────────┐
│ 人が何もしなくても復旧する範囲を最大化する │
│ │
│ 自動: │
│ ・DNS ヘルスチェック → 自動切替 │
│ ・DB フェイルオーバー → 自動昇格 │
│ ・アプリ → オートスケーリングで自動起動 │
│ │
│ 手動（人が必要）: │
│ ・フェイルオーバーの「判断」（自動が不適切な場合）│
│ ・フェイルバック（Primary に戻す） │
│ ・ステークホルダーへの報告 │
└──────────────────────────────────────────────┘
→ 深夜に地震が来ても、DNS + DB + アプリが自動復旧
→ 朝出社したら DR リージョンで動いている状態が理想
フェイルオーバーの判断
いつフェイルオーバーするか
自動フェイルオーバー（DNS ヘルスチェック）:
・全エンドポイントが応答なし → 自動で DR リージョンに切替
→ 明確なダウンは自動で対応
手動判断が必要:
・一部 AZ のみ障害（全体ではない）
・性能劣化だがダウンではない
・クラウドプロバイダーが「復旧中」と発表
判断基準:
┌──────────────────────────────────────────────────┐
│ │
│ 「30分以内に復旧の見込みがあるか？」 │
│ │
│ YES → Primary の復旧を待つ │
│ （ただし30分後に再判断） │
│ │
│ NO or 不明 → DR フェイルオーバーを開始 │
│ │
└──────────────────────────────────────────────────┘
フェイルオーバーのリスク
フェイルオーバーにもリスクがある:
・レプリカラグ分のデータ損失（通常数秒、障害時は増大の可能性）
・DR 環境が本番と完全に同一でない可能性
・DR 環境の容量が不足している可能性（Pilot Light の場合）
・フェイルバック（Primary に戻す）が難しい
→ 「フェイルオーバーしない方がリスクが高い」と判断した場合に実行
フェイルオーバー手順
Step 1: 状況確認（5分）
□ Primary リージョンの状態を確認
・クラウドプロバイダーのステータスページ
・ヘルスチェックの状態
・DB のステータス
□ DR リージョンの状態を確認
・DB レプリカのステータスとラグ
・アプリの状態（稼働中 or 停止中）
□ IC が Sev 1 を宣言、DR フェイルオーバーを決定
Step 2: DB の昇格（5〜15分）
DR リージョンの DB を Writer に昇格:
Global Database の場合:
・Secondary クラスタを Primary に昇格
・旧 Primary との接続を切断
・数分で完了
スタンドアロンレプリカの場合:
・レプリカを昇格
・接続先エンドポイントをアプリに設定
確認:
□ 昇格が完了したか
□ Writer として書き込み可能か
□ 最後のレプリカラグを記録（データ損失量の推定）
□ 昇格後の最終書き込みタイムスタンプを確認
（SELECT max(created_at) FROM 主要テーブル でデータの鮮度を検証）
Step 3: アプリの起動 / スケールアウト（5〜15分）
Pilot Light の場合:
・DR リージョンのアプリを起動
・起動完了を待機
・ヘルスチェックが通ることを確認
Warm Standby の場合:
・DR リージョンのアプリをスケールアウト（1台 → 4台等）
・全台のヘルスチェックが通ることを確認
Active-Active の場合:
・既に稼働中。追加作業なし
Step 4: DNS 切り替え（数秒〜数分）
DNS のルーティングを DR リージョンに変更:
・重み付き: Primary 100 → 0, DR 0 → 100
・フェイルオーバー: ヘルスチェック連動で自動（既に切り替わっている可能性）
確認:
□ DNS の伝搬を確認（dig コマンド等）
□ DR リージョンにトラフィックが来ているか
□ ユーザーがアクセスできるか
注意:
DNS の TTL によっては、切り替えが反映されるまで数分〜数十分かかる
→ TTL は事前に短く設定しておく（60秒推奨）
Step 5: 動作確認（10分）
□ ログインフロー手動テスト
□ トークン発行確認
□ 主要テナントの動作確認
□ エラー率の監視
□ レイテンシの確認（DR リージョンの方が遅い可能性）
Step 6: 報告
□ 「DR フェイルオーバー完了」をステークホルダーに報告
□ データ損失の推定値を報告（レプリカラグ分）
□ フェイルバック（Primary に戻す）の計画を策定
フェイルバック（Primary に戻す）
Primary リージョンが復旧したら、元に戻す作業が必要。フェイルオーバーより難しい。
なぜ難しいか:
フェイルオーバー後:
DR リージョンが Primary になっている
→ DR に新しいデータが書き込まれている
→ 旧 Primary にはそのデータがない
フェイルバックするには:
① DR → 旧 Primary にデータを同期
② 旧 Primary が追いついたことを確認
③ DNS を旧 Primary に戻す
→ 実質的に「逆方向の DR フェイルオーバー」
推奨:
・急いで戻す必要はない
・DR リージョンで安定稼働を確認
・計画的なメンテナンスウィンドウでフェイルバック
・Blue-Green デプロイと同じ手順で切り替え
まとめ
DR フェイルオーバーの原則:
1. 判断基準を事前に決めておく（30分ルール）
2. 手順を事前にドキュメント化しておく（この文書）
3. パニックにならない → 手順に従う
4. フェイルバックは急がない → 安定してから計画的に
5. 定期的に訓練する → Game Day
次のステップ
- DR テスト（Game Day）: 本当に復旧できるか定期的に検証