ディザスタリカバリのアーキテクチャ図：RPO、RTO と 4 つの戦略

高可用性は、サーバーやアベイラビリティーゾーンが落ちてもシステムを動かし続けます。ディザスタリカバリが扱うのは、もっと大きな障害です。リージョン全体の停止、破損したデータベース、削除されたアカウント、ランサムウェア。こうした事態への計画は起きる前に用意しておく必要があり、どれだけのデータを失い、どれだけ止まるかはアーキテクチャで決まります。

この記事では、あらゆる DR 設計の出発点となる 2 つの数値を定義し、4 つの標準的な戦略をそのコストとともに見ていき、2 つのリージョンにまたがるウォームスタンバイ構成を図にします。

RPO と RTO

• 目標復旧時点（RPO）： どれだけのデータを失っても許容できるかを、時間で表したものです。RPO が 5 分なら、直近 5 分間の書き込みを失っても許容できるという意味です。
• 目標復旧時間（RTO）： サービスが復旧するまで、どれだけ止まっていてよいかです。

どちらもエンジニアリングではなくビジネスから決まり、どちらにもお金がかかります。データ損失ゼロ、停止時間ゼロに近づくたびに、インフラと運用の手間は何倍にも増えます。1 時間の停止がいくらの損失になるか、どのデータが作り直せないかを確認し、その数値を満たす最も安い設計を選びましょう。1 つのシステムでも部分ごとに目標は違うのが普通です。決済は数分が必要かもしれませんが、レポート用のデータウェアハウスは 1 日で構いません。

4 つの戦略

AWS のディザスタリカバリのホワイトペーパー は、DR をコストと復旧の速さの順に 4 つの戦略に分けています。同じ考え方は、どのクラウドでも自社のデータセンターでも通用します。

バックアップと復元 は、バックアップとインフラのコードからすべてを作り直します。復元がテスト済みで、インフラをコードから再作成できるなら、多くの社内システムにはこれで十分です。

パイロットライト はデータを生かしたまま（データベースやバケットを複製）、コンピューティングは停止またはゼロにしておきます。復旧とは、サービスを起動してスケールさせることです。

ウォームスタンバイ は、小さいながらも動いているコピーを常に稼働させます。縮小したキャパシティですぐにトラフィックを処理でき、フェイルオーバー中にスケールアウトします。常に動いているので、テストもしやすい構成です。

アクティブ/アクティブ は、両方のサイトから常にユーザーにサービスを提供します。フェイルオーバーはほぼルーティングの変更だけで済みますが、2 つのリージョンでの書き込みには競合の処理か単一ライターの設計が必要になり、コストは本番環境 2 つ分です。

1 つのシステムでの選び方：例

1 時間に 2,000 件の注文を受けるオンラインストアが、決済について RPO 5 分、RTO 30 分を求めているとします。バックアップと復元では RPO を満たせません。夜間のスナップショットでは 1 日分の注文を失う可能性があり、スタックの再構築には何時間もかかります。パイロットライトはデータベースの複製で RPO を満たせますが、別のリージョンでサービス、キャッシュ、検索インデックスを起動して温めるには、初めて試すときにはたいてい 30 分以上かかります。ウォームスタンバイなら両方を満たせます。レプリカの遅れは数秒で、縮小版のサービスはすでに動いているので、フェイルオーバーは昇格、スケールアウト、DNS の切り替えだけです。アクティブ/アクティブなら RTO をさらに縮められますが、コストは 2 倍になり、このストアが解決する必要のない書き込みの競合も生まれます。答えは、決済にはウォームスタンバイ、レポート用のデータウェアハウスにはバックアップと復元です。

それでもバックアップは必要

複製はミスもコピーします。誰かがテーブルを削除したり、ランサムウェアがデータを暗号化したりすれば、レプリカも数秒で同じ状態になります。複製では手の届かないポイントインタイムのバックアップを保持しましょう。

• 数日から数週間保持するスナップショットとトランザクションログ。
• 認証情報の異なる別アカウントに置いたコピー。1 つのアカウントが侵害されても両方は削除されないようにします。
• プラットフォームが対応していれば、変更不可またはロックされたバックアップ。
• 定期的な復元テスト。誰も復元したことのないバックアップは、バックアップではなく願望です。

フェイルオーバーの手順

手順を書き出し、短く保ちます。

1. 判断する。 誰が、どのシグナルで災害を宣言できるのかを決めます。リージョン全体の自動フェイルオーバーはリスクが高いため、多くのチームは検知を自動化し、判断は人に残しています。
2. データベースのレプリカを昇格する。 スタンバイリージョンのレプリカをプライマリにします。
3. コンピューティングをスケールアウトする。 スタンバイリージョンをフルキャパシティにします。
4. トラフィックを移す。 DNS フェイルオーバーのレコードか、グローバルロードバランサーの重みを切り替えます。DNS の TTL や、キャッシュするクライアントも考慮します。
5. 確認する。 合成監視で確認してから告知します。
6. 戻り方を計画する。 フェイルバックは 2 回目の移行であり、同じだけの注意が必要です。

アーキテクチャ図

図の読み方は次のとおりです。

• 上： ユーザーは DNS フェイルオーバーのルーティングに到達します。現在はすべてのトラフィックをプライマリリージョンに送っており、破線のエッジはフェイルオーバー後のトラフィックの行き先を示しています。
• 左、プライマリリージョン： ロードバランサー、6 つのアプリインスタンス、オブジェクトストレージ、プライマリデータベースです。
• 右、スタンバイリージョン： 同じ形を小さな規模で再現しています。2 つのアプリインスタンス、非同期レプリケーションで更新されるレプリカデータベース、複製されたオブジェクトです。破線のエッジは、フェイルオーバー後にだけトラフィックが流れる経路を示しています。
• 下： 日次のスナップショットは別アカウントのバックアップ保管庫に送られます。これが、複製では防げない破損や削除からの保護になります。
• Markdown ブロック には、この設計が満たすべき目標を書いています。

テスト

DR の計画は細部でつまずきます。スタンバイリージョンで期限切れの証明書、ハードコードされたエンドポイント、足りないシークレット、1 日もある DNS の TTL。直す方法は、実際にフェイルオーバーしてみることだけです。訓練を予定に組み込み、1 つのサービスから始めて、実際の RTO を目標と比べて測りましょう。ウォームスタンバイならこれを安く行えます。これはパイロットライトに対する大きな利点の 1 つです。

DR の図に描くべきこと

• 両方のサイト： それぞれで何がどの規模で動いているかを描きます。
• レプリケーションの経路とモード： 同期か非同期かで RPO が決まるからです。
• トラフィックの切り替え： 自動かどうかも示します。
• 影響範囲の外にあるバックアップ： アカウントの境界も含めて描きます。
• 目標： 設計のすぐ横に書きます。

マルチリージョンのネットワークについては AWS マルチリージョンのアーキテクチャ図 を参照してください。レプリケーションの遅延とフェイルオーバーは データベースレプリケーションの図 で、インシデントの宣言と対応そのものは インシデント対応のフローチャート で詳しく扱っています。

Archboard で作る

1. Google または GitHub でサインインし、図を作成します。
2. クラウドパックから、プライマリ用とスタンバイ用に リージョン フレームを 2 つ追加します。
3. それぞれの中に、クラウドロードバランサー、アプリ用の コンピューティング ノード、オブジェクトストレージ ノード、マネージドデータベース を追加します。インスタンス数はラベルに書きます。
4. リージョンの上に C4 モデルパックの 人物 とネットワークパックの DNS ノードを、下にバックアップ保管庫用の オブジェクトストレージ ノードをもう 1 つ追加します。
5. リージョン間のレプリケーションを描き、フェイルオーバー時だけ使う経路を破線にして、RPO と RTO を書いた基本パックの Markdown ブロックを追加します。

この例で使うダイアグラムノードは 14 個で、Free プランの範囲に収まります。

よくある質問

RPO と RTO の違いは何ですか？ RPO は、障害の前の時間で測った、失ってもよいデータの量です。RTO は、障害の後にサービスが復旧するまでにかかる時間です。

高可用性とディザスタリカバリは同じものですか？ いいえ。高可用性は、コンポーネントやゾーンの障害を自動的かつ継続的に処理します。ディザスタリカバリは、リージョンの停止やデータの破損といったより大きな事態を、多くの場合は意図的なフェイルオーバーによって扱います。

別のリージョンに複製していても、バックアップは必要ですか？ はい。複製は削除や破損もほぼ即座にコピーします。別アカウントのバックアップがそれを防ぎます。

どのディザスタリカバリ戦略を選ぶべきですか？ そのシステムについてビジネスが必要とする RPO と RTO を満たす中で、最も安いものです。ウォームスタンバイは手頃でテストしやすいため、よく選ばれる中間の選択肢です。

ディザスタリカバリはどのくらいの頻度でテストすべきですか？ ランブックが正しい状態を保てる頻度で行います。重要なシステムではたいてい四半期ごとに、そして大きなアーキテクチャ変更のたびに行います。

無料で始める — 1 シート、クレジットカード不要。