ディザスタリカバリのパターン：クラウドアーキテクトのための実践ガイド

あらゆるシステムは、いずれかの時点で停止します。停電のような単純な事象でデータホールがダウンすることもあります。不適切なアップデートによってデータベースが破損することもあります。地域全体が障害に見舞われることもあれば、誰かが重要な情報を誤って削除してしまうこともあります。ディザスタリカバリ（DR）とは、こうした事象が発生した際に「何をどう行うか」を事前に計画することです。アプリケーションを再び稼働させるための手順を定めることであり、また、復旧に要するデータの損失量と所要時間についても明確にすることです。本稿では、実際の障害から回復するためのさまざまな手法を検討します。意思決定の際に考慮される2つのキーメトリクス（RPO／RTO）について解説し、データの複製・保護方法についても述べます。さらに、障害発生時に機能する計画立案のベストプラクティスについても考察します。

1. DR戦略を定義する2つの数値
   何かを決める前に、必ず2つの数値を設定する必要があります。

復旧時点目標（Recovery Point Objective：RPO） とは、許容できる最大のデータ損失量を「時間」で表した指標です。たとえば、RPOが5分であれば、復旧プロセスによって、障害発生時から遅くとも5分以内の状態までシステムを戻す必要があります。これは、データをいかにしてコピーし、安全な場所に保存するかという点に直結します。

復旧時間目標（Recovery Time Objective：RTO） とは、サービス停止を許容できる最大時間であり、復旧作業が完了してサービスが再開するまでの所要時間を示します。これは、インフラストラクチャとデータをいかに迅速に復旧させるかという点に焦点を当てています。

この2つの数値は、必ずしも連動して変化するわけではありません。たとえば、毎日1回バックアップを取得している場合、RPOは24時間になります。そのバックアップからデータを復元するのに6時間がかかるなら、RTOは6時間です。一方、データを常時複製している場合は、理論上のRPOはほぼゼロになります。ただし、待機システムを起動し、トラフィックを切り替えるために1時間かかる場合、RTOは1時間となります。

これらの数値はすべて、「事業影響分析（Business Impact Analysis：BIA）」に基づいて導出されます。各ワークロードごとに、1時間の停止や1時間分のデータ損失が事業に与えるコストを評価し、そのコストを支払ってでも達成したい目標値（RPO／RTO）を設定します。異なるワークロードには異なる保護レベルが必要であるため、それぞれ個別に分析を行う必要があります。たとえば、決済台帳と社内Wikiでは、求められる可用性レベルは明らかに異なります。もう一点留意すべきは、ゼロダウンタイム・ゼロデータロスに近づけるほど、コストが急激に増加することです。復旧目標を半分に短縮しても、コストが半分になることはありません。

図1（作成予定）：RPOとRTOのタイムライン。障害発生時刻、RPOに対応するデータ復旧可能時点、およびRTOに対応するサービス完全復旧時刻を示します。

1. コストと復旧速度のトレードオフ：安価・遅速から高価・即時まで

DRパターンは、連続するスペクトラム上に位置付けられます。一端には「ストレージ中心・復旧遅延型」があり、他端には「常時稼働・即時復旧型」があります。実務上は、以下の4つのDRパターンでほぼすべてを網羅できます。実際のシステムでは、各レイヤー（例：アプリケーション層、データ層など）ごとに異なるパターンを組み合わせて運用することが一般的です。

• レストア（Restore）：定期的にデータを安全なストレージ場所へコピーするパターンです。障害発生時には、インフラストラクチャを新規構築し、バックアップからデータを復元します。
  　RPOはバックアップ間隔（例：1日1回 → RPO＝24時間）であり、RTOは約1時間です。主にストレージコストのみが発生するため、最も低コストな選択肢です。
  　ツール類、レポート生成、開発／テスト環境などに適しています。
  　よくあるミスは、復旧プロセスの実施テストを怠ることです。テストを行わなければ、バックアップは「推測」に過ぎず、信頼できる安全網にはなりません。

• パイロットライト（Pilot Light）：復旧用リージョンに、最小限のコア（特にデータ層）を常時稼働させ、レプリケーションにより最新状態を維持します。アプリケーション層およびコンピューティング層は、必要になるまでシャットダウンされたままです。
  　RPOは数分、RTOは数十分〜1時間程度です。コストは低〜中程度です。
  　夜間バックアップだけでは不十分だが、サーバー群の起動待ちを許容できるワークロードに適しています。

1. データ複製：RPOが決まる鍵となる要素

RPOは、主にデータを復旧先に届ける方法によって決まります。これには、以下の3つのアプローチがあります。

• 同期レプリケーション（Synchronous Replication）：書き込み操作は、プライマリ側とレプリカ側の両方に正常に書き込まれて初めて「完了」とみなされます。このため、承認済みのデータは一切失われず、実質的なRPOはゼロとなります。ただし、両方のロケーションへの通信が必要なため、処理が遅くなる傾向があります。そのため、同一リージョン内や隣接するアベイラビリティゾーン間など、地理的に近い環境での利用が推奨されます。大陸を跨ぐような遠距離間では、実用的ではありません。

• 非同期レプリケーション（Asynchronous Replication）：書き込み操作は、プライマリ側でのみ完了すれば「完了」とみなされ、その後、データをレプリカ側に遅れて送信します。通信待機が不要なため高速であり、地理的に離れたリージョン間でも有効です。しかし、レプリカへの反映に遅延が生じるため、その遅延時間自体がRPOとなります。つまり、プライマリ側が突然消失した場合、その遅延分だけのデータが失われるリスクがあります。

• スナップショット＋ログ配信（Snapshots and Log Shipping）：上記2つのアプローチの中間に位置する手法です。ある時点におけるデータのスナップショットを取得し、その後の変更をログとしてレプリカ側へ送信します。これにより、任意の時点までデータを復元できます。多くのバックアップ／レストアシステムやパイロットライト構成で採用されています。

レイヤー設計の良い例としては、高い可用性を確保するために、同一リージョン内の異なるアベイラビリティゾーン間で同期レプリケーションを活用し、ディザスタリカバリのためにリージョン間で非同期レプリケーションを活用するという方法です。これにより、単一ゾーンの障害にも耐え、さらにリージョン全体の障害にも備えることができます。Alibaba Cloudでは、ECSディスクのスナップショットやカスタムイメージ、リージョン間レプリケーション対応のオブジェクトストレージ（OSS）、マネージドデータベースのクロスリージョンレプリケーションなどの機能を通じて、こうした設計が実現可能です。

Alibaba Cloudの「Cloud Backups」ドキュメントでは、リージョン間ディザスタリカバリにおいて、多くのシステムが2段階のレプリケーションを採用していると説明されています。第1段階は初期のフルデータ複製、第2段階はその後の変更データをリアルタイム（または準リアルタイム）で継続的に複製するプロセスです。

図3（作成予定）：同一リージョン内でのゼロデータロス同期レプリケーション（左）と、リージョン間での非同期レプリケーション（右）を比較。後者のデータロスは、レプリケーション遅延（replication lag）によって制限されます。

1. フェイルオーバーとフェイルバック

優れたDR計画は、「移動」だけでなく「帰還」も想定しなければなりません。障害発生時には、トラフィックを代替システムへ切り替え、バックアップシステムを稼働させる必要があります。この際、以下の3点を検討する必要があります。

• 検出（Detection）：システムが完全にダウンしているのか、あるいは一時的なパフォーマンス低下にすぎないのかを正確に判断する必要があります。単一地点からの監視ではなく、複数の場所から監視することで信頼性を高めます。
• 昇格（Promotion）：バックアップシステムを「本番システム」として昇格させるプロセスです。緊急時の人的ミスを防ぐため、自動化が強く推奨されます。
• リダイレクト（Redirection）：ユーザーを新しいシステムへ誘導する仕組みです。DNSによる切り替えも可能ですが、TTLの制約から遅延が生じることがあります。より高速な切り替えには、専用のロードバランサー（例：Alibaba Cloud SLB）を活用します。

ここで注意すべきは、「スプリットブレイン（Split-brain）」と呼ばれる状態です。これは、両方のシステムが「自分こそが本番」と認識し、同時に更新を受け入れてしまうことで、矛盾した2つの状態が発生し、深刻なデータ不整合を招く危険性がある状況です。これを回避するには、どちらが本番かを一意に決定する仕組み（例：クォーラム方式、または片方のシステムを更新不可状態にするロック機構）が必要です。

最後に、しばしば見落とされがちなのが**フェイルバック（Failback）**です。これは、元のシステムが復旧した後に、再度本番として切り替えるプロセスです。フェイルオーバー中にバックアップシステムで発生したデータ変更を元のシステムへ同期し、その上で安全に切り替える必要があります。このフェイルバックの練習は、フェイルオーバーと同様に重要です。多くのチームが、実際に緊急時にフェイルバックを試みるまで問題に気づかないため、事前の訓練が不可欠です。フェイルオーバーとフェイルバックの両方において、検出・昇格・リダイレクトの3要素を設計・検証する必要があります。

免責事項：本記事は教育目的で作成された中立的な技術解説です。Alibaba Cloudの特定サービスへの言及は、あくまで本稿で紹介するDRパターンが、クラウド上の基本的な管理リソース（cloud primitives）とどのように対応するかを具体的に示すための事実例であり、サービスの推奨や保証を意味するものではありません。記載されているサービス機能および数値は、執筆時点での公式ドキュメントに基づくものであり、今後変更される可能性があります。最新情報については、Alibaba Cloudの公式ドキュメントをご確認ください。