マルチリージョン/DR構成の設計 — どこまで地理冗長するかの判断

マルチリージョン/DR構成は「念のため二拠点」という発想では機能しません。RTO・RPOの定義から始まり、スタンバイ方式の選定、データ整合性の保証、フェイルオーバー検証の設計まで、それぞれに判断の分岐があります。過剰な地理冗長が運用の複雑さを跳ね上げる境界も見極める必要があります。本記事では、構築担当者が直面する設計判断の構造を整理し、「どこまで冗長化するか」の判断軸を示します。

「念のため二拠点」でDRが絵に描いた餅になる構造

RTO/RPOを定義しないまま設計に入る落とし穴

DR構成を検討する際、「とりあえず別リージョンにも同じ構成を立てる」という進め方をするプロジェクトは少なくありません。しかしこのアプローチでは、肝心の「どのくらいの時間でサービスを復旧させるか（RTO）」と「どの時点のデータまで失っても許容されるか（RPO）」が曖昧なまま実装が進みます。RTO・RPOが未定義のままだと、何を達成すれば「DRが機能する」と言えるのかが決まらず、フェイルオーバーのテストをしても成功基準が存在しない状態になります。ある現場では、RTOを48時間として合意すべき業務要件があったにもかかわらず、エンジニアの判断で「2時間以内の復旧」を前提とした設計を進め、後から要件のすり合わせをやり直した事例があります。設計に入る前に、業務側と合意した文書としてRTO・RPOを残しておくことが、後工程の手戻りを防ぐ最初の判断です。

フェイルオーバー手順が文書化されているだけで検証されていない問題

DR構成で最も多く聞かれる失敗パターンが、「手順書はあるが実際に動かしたことがない」という状態です。ドキュメントが整備されていても、実際の切替操作は環境依存の問題を多数含みます。DNSのTTL設定、データベースのプライマリ切替タイミング、アプリケーションの接続先変更——これらが連動して動くことを、本番相当の環境で検証しない限り、手順書の信頼性は担保されません。現場では「年に1回の訓練を計画していたが3年間実施できていない」という話をよく聞きます。DR構成は構築して終わりではなく、定期的な検証サイクルを設計の中に組み込む必要があります。検証コストを設計フェーズで見積もっていないと、運用フェーズで形骸化するのは避けられません。

バックアップとDRを混同した構成設計

DR構成の議論でよくある混乱が、「バックアップがある＝DRができている」という誤解です。バックアップはデータの保護を目的とし、RPOに直接関係します。一方、DRはサービス継続性を確保するための仕組みであり、RTOを達成するためのインフラ構成全体を指します。バックアップからのリストアだけでは、サーバーの起動・設定の復元・ネットワークの再構成といった工程が別途必要であり、それらが完了するまでの時間がRTOに加算されます。両者を同一視したまま設計すると、「バックアップは取っているのでDR対応済み」という判断になり、実際の障害時に復旧時間が想定を大幅に超えるケースが生じます。DRはデータを守るだけでなく、「サービスをいつまでに再開できるか」という問いに答える設計であることを、構成の起点として明確にしておく必要があります。

単一リージョンで妥協してよい／してはいけない業務の違い

停止許容時間と業務インパクトで線引きする

マルチリージョン構成は、すべてのシステムに必要なわけではありません。判断の軸は「停止が発生したとき、業務にどれだけの損失が生じるか」と「その損失が許容されるまでの時間」の2点です。この2軸が明確になれば、単一リージョンで十分かどうかの判断は自ずと定まります。社内の管理システムや分析バッチなど、停止の影響が限定的な場合は、RTOが24〜72時間程度でも許容されるケースがあります。この場合、コールドスタンバイ構成やスナップショットからの復旧で対応できます。一方、決済・予約・在庫管理など、数分の停止が直接的な売上損失や契約違反につながるシステムは、単一リージョンのリスクが許容できません。業務側と「許容できる停止時間」を数値で合意する工程を省かないことが、この線引きの前提です。

単一リージョンで対応できる業務の特徴

停止許容時間が長く、業務インパクトが限定的なシステムは単一リージョンの構成でも十分なことが多いです。バッチ処理・社内ツール・開発や検証環境・アーカイブシステムなどが該当します。これらは、AZ（アベイラビリティゾーン）間の冗長化とスナップショットバックアップを組み合わせることで、必要な可用性を確保できる場合が多いです。同一リージョン内のマルチAZ構成でも、物理的なデータセンター分離によって単一障害点は排除されます。リージョン全体に影響する広域障害は稀であり、すべてのシステムにマルチリージョン構成を適用するのは過剰投資になる可能性があります。コストと複雑さを意図的に絞ることも、設計判断のひとつです。

単一リージョンでは対応できない業務の特徴

法令・契約でRTOやデータ保持要件が定められているシステム、外部ユーザーに影響する決済・サービス提供系のシステム、リージョン全体の障害を想定しなければならないシステムは、地理的冗長化が必要です。クラウドプロバイダーのリージョン障害は年数回の頻度で発生しており、復旧手段が単一リージョン内に閉じているとサービスの全停止を避けられません。また、複数拠点のユーザーを抱えるグローバルサービスでは、レイテンシの観点からもマルチリージョン配置が選択肢に上がります。その場合はDRとしてのマルチリージョンではなく、アクティブ-アクティブ構成という設計パターンになり、設計の複雑さが段違いに増す点に注意が必要です。DRと性能分散を混在させると、障害時の挙動が予測しにくくなります。

比較表：ホット／ウォーム／コールドスタンバイの選定判断

3方式の特性とトレードオフ

スタンバイ方式の選定は、RTO・RPO要件とコスト・運用負荷のバランスで決まります。3方式の特性を正確に理解しておくことが、過不足のない設計の前提です。

方式	RTO目安	RPO目安	コスト水準	主な用途
ホットスタンバイ	数分〜数十分	ほぼゼロ〜数秒	高（本番の1〜2倍）	金融・決済・基幹SaaS
ウォームスタンバイ	数十分〜数時間	数分〜数十分	中（本番の30〜60%）	業務系・ECサイト・社内基幹
パイロットライト	15〜60分程度	数分以内	低〜中（データ層のみ常時稼働）	コスト重視・データ保護優先
コールドスタンバイ	数時間〜数日	数時間	低（ストレージコストのみ）	管理・分析・アーカイブ

ウォームスタンバイが最も選択の難しい方式である理由

ホットとコールドの中間に位置するウォームスタンバイは、コスト・RTO・運用負荷のバランスが取れているように見えますが、設計が最も難しい方式でもあります。「縮退構成でどこまで動かすか」「同期の頻度をどう設定するか」「フェイルオーバー時にどこまで自動化するか」という判断が全て曖昧になりやすいためです。現場でよく見られる失敗として、DR環境のスペックが本番の10分の1以下になっており、フェイルオーバー後に性能問題が発生するケースがあります。縮退構成は「停止よりはマシ」という最低限の稼働を保証するものであり、本番同等の性能を期待する設計にはならない点を明確にしておく必要があります。「ウォームにしたから大丈夫」という認識がある限り、いざという時の齟齬は埋まりません。

パイロットライトという中間の設計パターン

クラウド環境ではパイロットライトと呼ばれる方式もよく選ばれます。コアとなるデータ層（データベース）は常時稼働・同期した状態を保ちつつ、アプリケーションサーバー層はスナップショットやマシンイメージから起動する構成です。復旧時間はサーバー起動時間に依存し、15〜60分程度が目安となります。コールドスタンバイよりもRTOを短縮しながら、コンピューティングコストを抑えたい場合に有効な選択肢です。ただし、アプリケーション層の自動起動と設定の自動適用が確実に動くことを、定期的なテストで担保し続ける必要があります。テストをやめた時点から、復旧手順の信頼性は静かに低下していきます。

データ複製の遅延と整合性をどう設計するか

同期複製と非同期複製の選択基準

データ複製の方式は、RPO要件と距離（レイテンシ）によって選択が分かれます。同期複製はプライマリへの書き込みが完了するタイミングでセカンダリへの書き込みも完了する方式であり、データロストをゼロにできる反面、リージョン間のラウンドトリップレイテンシが書き込みパフォーマンスに直接影響します。リージョン間の距離が数十〜数百ミリ秒に達する場合、トランザクション性能の低下が無視できなくなります。非同期複製はプライマリへの書き込みを先に確定させ、セカンダリへの転送を後から行う方式です。パフォーマンスへの影響は小さいですが、レプリケーション遅延の分だけデータロストのリスクが残ります。この遅延がRPO要件を常に満たしているかを継続的にモニタリングする仕組みが必要です。

レプリケーション遅延のモニタリング設計

非同期複製を採用した場合、レプリケーション遅延がRPO閾値を超えていないかをアラートで監視する設計が不可欠です。特に書き込みピーク時には遅延が急増するケースがあります。平常時は数秒以内で追従しているものが、大量バッチ処理の実行中に数分以上遅延するケースは珍しくありません。閾値アラートだけでなく、「どのくらいの遅延が発生しているか」を時系列で記録し、RPO達成の可否を事後に検証できるデータを残すことも設計の一部です。障害発生時に「その時点のレプリケーション遅延が何秒だったか」を把握できない構成では、RPOの達成判定ができません。遅延の記録は、DR設計の実効性を証明するための重要な証跡になります。

整合性モデルと分散トランザクションのトレードオフ

複数リージョンにデータを分散させる場合、結果整合性（Eventual Consistency）と強整合性（Strong Consistency）の選択が設計判断の核心になります。強整合性を保とうとすると同期複製が必要になり、リージョン間レイテンシの影響を受けます。結果整合性を選択すると書き込みパフォーマンスは改善されますが、読み取り側で古いデータを参照する可能性を設計上許容する必要があります。アクティブ-アクティブ構成での分散トランザクションは、コンフリクト解決ロジックが必要になり、設計の複雑さが大幅に増します。設計フェーズでアプリケーションがどの整合性モデルを前提としているかを明確にしないまま複製設計を進めると、後から根本的な変更が必要になるリスクが高くなります。この判断はアーキテクチャの根幹に関わるため、手を動かす前に確定させる必要があります。

切替（フェイルオーバー）と切戻しをどう検証するか

フェイルオーバーテストの設計思想

フェイルオーバーが形骸化しないためには、定期的な実機テストが不可欠です。検証方法として代表的なのは、本番と同等のステージング環境での切替演習と、本番環境でのカオスエンジニアリング的な障害注入の2方向があります。ステージング環境のみでのテストは「本番と環境差異がある」という問題を常に抱えますが、本番環境への障害注入はリスクコントロールが難しいです。現場では、ステージング環境での年2回以上の切替演習を基本とし、フェイルオーバー所要時間・RTO達成可否・手順の抜け漏れを記録するアプローチが現実的な落としどころとして選ばれることが多いです。演習結果を次の設計改善サイクルに反映させる仕組みまで含めて「DR設計」と捉えることが、機能するDR構成の条件です。

切戻し（フェイルバック）設計の重要性

フェイルオーバー後の切戻し設計を見落とすプロジェクトは多くあります。障害が解消した後、DR環境から元の本番環境に戻る際にも、データの逆同期・アプリケーションの向き先変更・DNSの切戻しなど、複数の工程が連動します。切戻しを設計していないと、DR環境を本番として長期間運用し続けることになり、構成管理が複雑化します。フェイルバックの設計では、「DR稼働中に発生したデータ更新をどうやって元のリージョンに戻すか」が最大の課題です。DR環境に書き込まれたデータを、元のプライマリ環境に整合性を保って反映させる手順を、フェイルオーバーの設計と同時に検証しておく必要があります。切戻しの設計なき切替設計は、半分しか完成していません。

自動フェイルオーバーと手動フェイルオーバーの判断軸

自動フェイルオーバーは切替の速さという点で優れますが、誤検知による不要な切替リスクがあります。ネットワークの一時的な遅延や監視エージェントの誤動作を「障害」と判断してフェイルオーバーが起動すると、逆にサービス断が発生するケースがあります。自動化の度合いは、「切替失敗のコスト」と「切替遅延のコスト」のどちらが大きいかで判断します。RTO要件が5分以下であれば自動フェイルオーバーの設計を検討せざるを得ませんが、30分以上の猶予があれば手動を基本としつつ、最初のヘルスチェックアラートを自動化するアプローチが安全な落としどころとなります。自動化の範囲を広げるほど、誤動作シナリオへの対処設計も同時に必要になります。

地理冗長しすぎてコスト・複雑さが跳ねる境界

マルチリージョン化で増えるコスト構造

リージョンを追加するとコストが増加するのは当然ですが、見落とされがちなのは「データ転送コスト」と「運用工数」です。リージョン間のデータ転送は多くのクラウドプロバイダーで課金対象となり、レプリケーション量が多いほど転送コストが積み上がります。加えて、DR環境の維持管理・パッチ適用・設定変更の同期という運用作業が、本番環境と並行して発生します。ウォームスタンバイ以上の構成では、実質的に2つの環境を同時に運用する体制が必要です。10台規模のシステムをウォームスタンバイ構成でマルチリージョン化した場合、運用工数が1.5〜2倍になるというのが現場での経験則として語られることが多く、この工数増加を運用体制の設計に織り込まないと、DR環境のメンテナンスが後手に回ります。手が届かないDR環境は、いざという時に動きません。

過剰冗長が生む複雑さのリスク

「より多くの冗長化は常に良い」という思い込みが設計を複雑にします。アクティブ-アクティブ構成で3リージョン以上を束ねると、障害発生時の影響判断・切り離しロジック・データコンフリクトの解決・ルーティングの制御が複雑化します。設計を担当したエンジニアが異動した後、引き継ぎドキュメントだけでは全体を把握できないシステムになりやすいです。「複雑さ」はそれ自体がリスクです。障害対応中に「DR環境の状態が把握できない」「どこで何が動いているか分からない」という状況は、障害の長期化を招きます。地理冗長の設計は「必要なRTO・RPOを達成できる最もシンプルな構成」を基準にすることが、長期的な運用安定につながります。

3リージョン構成が正当化される条件

3リージョン以上の構成が正当化されるのは、2リージョン構成でもカバーできないリスクシナリオが明確に存在する場合だけです。地政学的リスクや国ごとのデータ主権規制への対応、複数地域のユーザーへの低レイテンシ提供、大規模な自然災害シナリオへの対応などが該当します。これらの要件が業務要件として明文化されていない場合は、2リージョン構成で十分なケースが大半です。要件の根拠なく「より多くを」という判断は、運用コストと複雑さだけを積み上げる結果になります。「なぜ3リージョンが必要か」を設計根拠として説明できない構成は、見直しの対象とすることが適切です。

DR構成設計チェックフレーム

設計フェーズで合意する判断項目

DR構成の設計を進める前に、以下の判断項目を業務側と合意しておくことが、実装フェーズでの手戻りを防ぎます。チェック欄がひとつでも空欄のまま設計に入ると、後から要件が差し込まれるリスクが高まります。

1. RTO・RPOの業務合意：停止許容時間とデータロスト許容量を、業務担当者と合意した文書として残す。エンジニアの想定だけで進めない。
2. 障害スコープの定義：AZ障害・リージョン障害・クラウドプロバイダー全体障害のどれまでをDR対象とするかを決定する。対象外のシナリオも明記する。
3. スタンバイ方式の選定：RTO・RPO・コスト・運用体制の4軸で方式を選定する。比較根拠を設計ドキュメントに残す。
4. データ複製方式の決定：同期・非同期・パイロットライトから選択し、RPO要件との整合性を確認する。レプリケーション遅延のモニタリング設計も同時に決める。
5. フェイルオーバー自動化の範囲：自動と手動の境界を決定し、自動化する場合は誤検知時の影響を評価する。自動化の条件（閾値・判定ロジック）を明文化する。
6. 切戻し手順の設計：フェイルオーバーと同時に切戻し手順も設計する。DR稼働中のデータ更新の扱いを明確にする。
7. 検証サイクルの計画：年何回・どの環境で・何を成功基準として検証するかを設計に含める。検証を「任意」にしない。
8. 運用体制と工数の見積もり：DR環境の維持管理に必要な工数を明示し、運用体制に織り込む。担当者が決まっていない項目を残さない。

業務インパクト別の推奨構成マトリクス

業務インパクト	停止許容時間	推奨構成	最低限の検証頻度
高（売上・契約に直結）	数分以内	ホットスタンバイ／アクティブ-アクティブ	四半期に1回以上
高〜中	数時間以内	ウォームスタンバイ／パイロットライト	半年に1回以上
中〜低	数日以内	コールドスタンバイ／バックアップ復旧	年1回
低（社内ツール・開発環境）	数日〜週単位	単一リージョン＋スナップショット	任意（年1回推奨）

DR設計の核心は、「どれだけ冗長化するか」ではなく「どこまでの障害に、どの速さで、どのコストで対応するか」を先に決めることにあります。RTO・RPOを起点に方式を選定し、データ複製と検証サイクルを設計に組み込む——この順序を守ることが、機能するDR構成を実現する最短ルートです。手を動かすのはその後です。