実際にリハーサルするマルチリージョンDR
東京プライマリ、大阪スタンバイ、Terraformモジュールは1セット:何をレプリケーションし、何をリハーサルするか。テストされていないフェイルオーバー計画が能力ではなく図である理由。
ディザスタリカバリは、アーキテクチャの中で最も「無駄になってほしい」と願う部分であり、最も「願い」を信用してはいけない部分です。私がリードしたエンタープライズ向けサーバーレスプラットフォーム——AWS LambdaとSQSパイプライン、Aurora PostgreSQL、契約に明記された厳格な復旧目標——では、東京をプライマリ、大阪をスタンバイとして運用しました。以下は、それを図ではなく現実にしたもの:レプリケーション、コード、リハーサルについての判断です。
モジュール1セット、リージョン2つ
土台となる選択:大阪は2つ目のプロジェクトではない。2つ目の変数ファイルである。
すべてのインフラはTerraformモジュール(約24個、約10環境にまたがる)に住み、両リージョンは同じモジュールを異なる入力で適用します。標準的なプラクティスに聞こえますが——そのとおりです——これが強制する規律こそが実質的なDR機能です:
- 構造的にドリフトしない。 スタンバイがプライマリから静かに乖離することはできません。乖離するためのスタンバイ専用コードが存在しないからです。セキュリティグループの変更はモジュールに入り、次のapplyで両リージョンが受け取ります。
- DRリージョンは常に再構築可能。 最も怖いDR態勢は、2年前に手作業で組まれたスタンバイです。私たちのものは壊して再適用できました。つまりレシピが完全であることを知っていた——誰かのコンソール操作履歴の中にしか存在しないものはない、ということです。
- コスト管理が正直になる。 リージョンレベルの入力により、スタンバイは構造的同一性を保ちながら軽く走れます(小さいインスタンス、少ないレプリカ)。トレードオフは忘れられたサイジング判断の中に暗黙で沈むのではなく、変数ファイルの中で明示されます。
何を、どの速さでレプリケーションするか
すべての状態が同じ復旧待遇に値するわけではありません。状態を3層に仕分けました:
| 層 | 対象 | 機構 | 許容損失 |
|---|---|---|---|
| 1 | リレーショナルデータ(記録としての注文) | Auroraのクロスリージョンレプリケーション | 秒単位の遅延 |
| 2 | オブジェクト(アップロードファイル、生成物) | S3クロスリージョンレプリケーション | 分単位、非同期 |
| 3 | 導出可能な状態(キャッシュ、キューの滞留) | レプリケーションしない——再構築する | 再構築時間 |
議論になるのは層3です。キューの中身をリージョン間でレプリケーションするのは複雑で、ほとんどの場合割に合いません。SQSの滞留は「処理中の仕事」であり、パイプラインのステージはすでに冪等でした(そうでなければなりません——at-least-once配送がそれを要求します)。フェイルオーバー時には上流システムが再送するか、オペレーターが再トリガーし、重複は冪等性が吸収します。誰かが不要なキューレプリケーションに四半期を燃やさないよう、これはポリシーとして文書化しました。
一方コンピュートはサーバーレスの配当です:Lambda関数とAPI定義はただのコードと設定であり、共有モジュールのおかげで両リージョンに存在します。パッチを当て続けるべきウォームなサーバー群はありません。
ランブックこそがプロダクト
フェイルオーバーのランブックは番号付きの文書で、その順序が荷重を支えていました:
- 宣言 — 指名された役割がフェイルオーバー開始を決断する。ここでの曖昧さは、どんな技術的ステップよりも高くつきます。
- 受付停止 — プライマリ側で新規の仕事を受けるのをやめ、状態の動きを止める。
- 昇格 — 大阪のAuroraスタンバイが書き込み可能になる。
- 切り替え — DNS/ルーティングがトラフィックを大阪スタックへ向ける。
- ドレインと突合 — 中断されたパイプラインの仕事を再トリガーする。重なりは冪等性が処理する。
- 検証 — スクリプト化されたスモークシーケンス。雰囲気の確認ではなく。
リハーサルからの教訓2つ:
- リハーサルは文書を能力に変換する。 最初のウォークスルーで、緊急時には誰も持っていないアクセス権を前提にした手順と、所要時間が全員の予想を裏切った昇格ステップが見つかりました。どれも図には現れません。すべてストップウォッチには現れます。
- リハーサルを目標値と突き合わせて計測する。 RTOとRPOは契約上の数字でした。リハーサルがその中に収まるか、収まらないならアーキテクチャが差し戻される——このフィードバックループこそ、数字を持つことの意味の全部です。
地味な周辺部
DRレビューはデータベースに執着し、リージョンを実際に使える場所にする退屈な依存物を飛ばしがちです:4層のVPCレイアウト、ネットワークファイアウォールのルール、IAM、KMSキー、監視、アラーム——これらすべてが「悪い日」の前から大阪に存在しなければなりません。いくつかは人を驚かせる形でリージョンスコープであり、だからこそ全部モジュールの中にあるのです。監査スタックも同様です:プライマリリージョンが落ちているとき、証拠の痕跡(CloudTrail、VPC Flow Logs、その上のAthenaテーブル)まで一緒に落ちていてはなりません。
これから始めるチームに渡すなら:DRを、オーナーと予算とテスト周期を持つプロダクト機能として扱うこと。技術——Auroraレプリケーション、S3 CRR、Terraformの対称性——は踏み固められた道です。能力と図を分けるのは、誰かがそれをリハーサルし、時間を計り、ストップウォッチが見つけたものを直したという事実です。