DR設計の実務ポイント
事業優先度から逆算するRTO/RPOと復旧層の選択
DRは「全部最強」は成り立ちません。まず業務を3段階に分け、数値を置きます。たとえばA:売上直結（RTO 15分／RPO 0〜5分）、B:基幹サブシステム（RTO 1時間／RPO 15分）、C:内部向け（RTO 24時間／RPO 4時間）。この数字がDR層の選び方を決めます。
- Active-Active：A向け。多拠点で常時稼働。コンフリクト管理とコストが重いが、RTO/RPOを最小化。
- Warm Standby：B向け。待機系に最小限を常駐、データは継続同期。切替で水平展開。
- Pilot Light：C向け。メタデータとテンプレートのみ保持、障害時に復元。
- Backup & Restore：長期保管のみ。RTO/RPOは大きくなる前提で採用。
意思決定のコツは「単価×停止影響×頻度」で粗い経済性を出すこと。AにActive-Activeを当てる根拠が見えると、CはPilot Lightで十分と割り切れます。逆にBをWarm Standbyにするなら、切替時間（スケールアウト＋DNS反映＋人手承認）を合算してRTO内に収まるかを秒単位で試算します。
データとネットワークの設計要点（レプリケーション／名前解決／権限）
データ同期の選択肢
ブロック複製（ストレージ同期）は運用が簡単ですが、リージョン間の遅延とスプリットブレイン対策が要件です。DB論理レプリケーションはRPOを制御しやすい一方、スキーマ差異やラグ監視が肝になります。スナップショット＋ジャーナル追従はPilot Lightに最適。書き込みは「単一書き込みリージョン＋読み取り分散」が安全で、障害時のみ昇格。双方向書き込みが必要なら、ID採番と業務衝突解決（最終書き込み勝ちではなく業務ルール勝ち）を先に定義します。
切替経路の制御
DNSはTTLを日頃から60秒以下に設定、ヘルスチェック連動の自動切替でも「過検知→振り子」を防ぐため投票多数決（例：3監視の2/3一致）を設けます。Anycast/VRRP/BGPでのIPフェイルオーバーは高速ですが、ネットワーク権限と運用負荷が跳ね上がるためA領域に限定。アプリ側はタイムアウトとリトライを層別に設計し、切替中は「縮退モード」（例：ポイント照会OFF、在庫は最終確定のみ）をフラグで即時反映できるようにします。
権限と秘密情報はDRの落とし穴です。IAMロール／サービスアカウントは両拠点で同一ポリシーをコード化、鍵はKMS等でラップして複製、監査ログも二重化。時刻同期ずれは認証失敗を招くため、NTP監視をSLO対象に含めます。
運用を回すRunbook／監視／演習
Runbookの粒度と保守
Runbookは「誰が・どこで・何を・期待結果・所要時間・ロールバック」を1手順1画面で完結。CLIはコピペ不可を前提にスクリプト化し、IaCに寄せます。週次で差分レビュー、四半期で演習の知見を反映。説明文はChatGPTやClaudeで簡潔化し、Copilotでスクリプトの危険オプションをLint、変更履歴の要約はGeminiで振り返るなど、執筆・校正の摩擦を減らします。
監視とSLO、演習の頻度
- 検知SLO：障害から5分以内に宣言。根拠はL7ヘルス＋合意指標（メッセージキュー遅延、エラー率）、DBレプリカラグ（秒）。
- 切替SLO：宣言から10分以内に縮退モードで復旧、完全復旧は30分以内。
- 演習：90日に1回のGameDay、年1回は就業時間外で全社シナリオ。メトリクスは「意思決定までの時間」「人手作業の回数」「ロールバック有無」。
演習は段階的に。最初は読み合わせ、次にサンドボックスでのハンズオン、最後に本番での限定的フェイルオーバー。毎回、失敗学をRunbookに即時反映します。
身近な企業活用例：従業員120名小売ECの失敗と改善
セール当日に単一リージョンのDB障害が発生し、RTO目標4時間に対し実績12時間。原因はDNS TTLが1日、権限未複製、バックアップ復元手順が属人化でした。
見直しでは、受注・決済（A）をWarm Standbyから準Activeへ。読み取りレプリカを常時稼働させ、昇格スクリプトを自動化。アプリは縮退モードを追加（ポイント一時停止、在庫は最終確定のみ）。DNS TTLは60秒、ヘルスチェックは複数系統＋多数決。権限はIaCで両拠点同期、鍵はラップ複製。Runbookは手順ごとの期待結果とタイムスタンプ欄を設け、演習は月次ミニゲームデーで5分の検知宣言訓練を実施。説明や手順の誤読チェックにChatGPTとClaude、IaC修正の雛形生成にCopilot、演習ログの要約にGeminiを活用しました。
結果、RTO実測は28分、RPOは4分以内に改善。追加コストは月間+18%でしたが、セール1回停止での逸失利益見積り（約1,200万円）を下回り、経営判断が明確になりました。監視ではレプリカラグ閾値の早期アラートと、切替判定時の「人の最終確認」をワークフロー化し、夜間も迷いが減少。以降は障害時も顧客影響を最小限に抑えられています。
DRは設計図だけでは動きません。数値で優先度を決め、データ・経路・権限を地味にそろえ、Runbookと監視で日常に落とす。これが実装と運用の接点であり、サーバ監視運用事業の現場では、この接点を滑らかに保つことが継続的な可用性につながります。
