災害復旧のためのクロスリージョンフェイルオーバー設計
クロスリージョンフェイルオーバー ワークロードをプライマリリージョンからセカンダリリージョンに自動的に転送することで、大規模な障害発生時の事業継続性を確保します。このアプローチは、ハリケーンや地域的な停電などの大規模な障害に最適です。ただし、他の災害復旧手法と比較して、コストが高く、非常に複雑になります。.
考慮すべき重要なポイント:
- 信頼性: 自動フェイルオーバーとデータ レプリケーションにより、地域的な停止に対する強力な保護を提供します。.
- 費用: インフラストラクチャの重複とデータ転送料金により高価になります。.
- 複雑: DNS ルーティングやフェイルバック プロセスなどの高度な設定が必要です。.
- 目標復旧時間 (RTO): 設定によって異なります:
- アクティブ/アクティブ: ほぼゼロの RTO。.
- ウォームスタンバイ: 分。.
- コールドスタンバイ: 時間。.
その他のオプションとしては アクティブ-アクティブ冗長性 （高い信頼性、最高のコスト）と アクティブ・パッシブ冗長性 （より手頃な価格で、回復に時間がかかります）。適切な戦略の選択は、ビジネスのダウンタイム許容度と予算によって異なります。.
| 冗長オプション | 信頼性 | 料金 | 料金 |
|---|---|---|---|
| クロスリージョンフェイルオーバー | 高（地域的な停電） | 高い | 分-時間 |
| アクティブ-アクティブ | 最高（グローバルトラフィック共有） | 非常に高い | 秒 |
| 能動態-受動態 | 中程度（スタンバイ設定） | 適度 | 分-時間 |
適切な方法を選択するには、システムの重要度に応じて、信頼性、コスト、復旧速度のバランスを取る必要があります。定期的なテストと自動化は成功に不可欠です。.
災害復旧の冗長性オプションの比較：コスト、RTO、信頼性
クロスリージョンアプリケーションフェイルオーバーを構成する方法
適切な設定には、適切なものを選択する必要があることが多い データセンター 遅延を最小限に抑え、冗長性を確保するために場所を分割します。.
sbb-itb-59e1987
1. クロスリージョンフェイルオーバー
クロスリージョンフェイルオーバー は、本番環境のワークロードをプライマリリージョンから遠隔地にあるセカンダリリージョンに移行することを目的とした災害復旧アプローチです。マルチAZ戦略は約60マイル（約96キロメートル）以内のローカルデータセンターの障害に対応しますが、クロスリージョンフェイルオーバーは、地震、洪水、地域的な停電など、はるかに大規模な災害に対処するために役立ちます。この構成は、数百マイル、あるいは数千マイル（約100キロメートル）も離れた場所に分散したインフラストラクチャに依存しています。以下では、その信頼性、コストに関する考慮事項、運用上の課題、そしてそれが目標復旧時間（RTO）にどのように影響するかについて詳しく説明します。.
信頼性
クロスリージョンフェイルオーバーにより、 地理的孤立, 地域的な停電にも堅牢なソリューションを提供します。例えば、ハリケーンによって地域全体で停電が発生した場合、セカンダリリージョンがシームレスに業務を引き継ぎます。自動監視システムがパフォーマンスの問題を検知し、フェイルオーバーをトリガーします。また、継続的なブロックレベルのレプリケーションにより、データが損なわれることなく維持され、インフラストラクチャと重要な情報の両方が保護されます。.
AWS Well-Architected Frameworkでは、適切なフェイルオーバーの実践を省略すると、 "「高」リスクレベル ワークロードの回復力を確保するために、定期的な復旧訓練は、災害復旧計画が必要な時に確実に機能するための鍵となります。これらの訓練により、計画は理論的なものから実証済みのものへと進化し、サービスの継続と収益損失の回避に不可欠です。.
コストに関する考慮事項
クロスリージョンフェイルオーバーは、マルチAZソリューションに比べて高額です。その理由は？ 保管と運用コストが2倍になる 遠隔地間でミラーリングされたデータベースとアプリケーションを維持することで、データ転送コストを削減できます。さらに、リージョン間のレプリケーションにかかるデータ転送料金は急速に増加し、そのコストは関係するリージョンによって大きく異なります。.
従業員2,000人以上の大規模組織の場合、社内ソリューションを使用した災害復旧費用は、 年間$675,000～$1,750,000. ほぼゼロのRTOを目指す場合、これらのコストはさらに上昇することを覚悟してください。最小限のRPO要件を満たすためのリアルタイムレプリケーションは、さらに費用を増加させます。これらのコストを管理するため、多くの企業は環境全体ではなく、最も重要なアプリケーションのみをレプリケーションすることを選択します。.
運用の複雑さ
リージョン間のフェイルオーバーの設定はスイッチを切り替えるほど簡単ではありません。 高度なオーケストレーション. グローバルDNSルーティング、非同期データレプリケーション、そして遠隔地間の自動フェイルオーバープロセスを処理する必要があります。プライマリ環境とセカンダリ環境間の一貫性と再現性を維持するには、Infrastructure as Code（IaC）の使用が不可欠です。.
フェイルバック（復旧後にプライマリリージョンにオペレーションを戻すこと）のプロセスはさらに困難です。データ損失を防ぐためのデータの再同期、DNS経由のトラフィックのリダイレクト、そして新たにアクティブ化されたインスタンスのセキュリティを確保するための逆レプリケーションの管理などが含まれます。このレベルの複雑さを円滑に実行するには、熟練したチームと詳細なドキュメントが必要です。.
目標復旧時間 (RTO)
RTO は、選択したフェイルオーバー モデルに大きく依存します。. アクティブ/アクティブ構成 両方のリージョンで同時にトラフィックを処理できるため、RTO がほぼゼロになります。. ウォームスタンバイ セカンダリリージョンで最小限のサービスを実行する構成では、RTOは数分単位で実現できます。一方、, コールドスタンバイ 障害発生後にのみリソースが起動されるアプローチでは、RTO は数時間単位になります。.
99.999%の可用性を必要とするシステムの場合、RTOは通常、 秒, 一方、99.9%の可用性を備えた重要度の低いシステムは、数時間単位のダウンタイムを許容できます。自動化されたランブックとIaCツールは、フェイルオーバー時の人為的ミスのリスクを軽減し、厳しいRTO目標の達成を支援します。特に、1分のダウンタイムが収益と顧客の信頼の喪失につながる場合はなおさらです。.
2. アクティブ-アクティブ冗長性
アクティブ-アクティブ冗長性 アプリケーションが2つ以上のリージョンで同時に実行され、ライブトラフィックがすべてのリージョンに分散されることを保証します。セカンダリリージョンがアイドル状態または最小限のアクティブ状態を維持するアクティブ/パッシブ構成とは異なり、アクティブ/アクティブ構成では、すべてのリージョンが実際のユーザーリクエストを処理します。これにより、すべてのリージョンが常に稼働しているため、コールドスタートの問題が解消されます。この構成が、深刻なリージョン障害発生時でも信頼性をどのように向上させるかを見てみましょう。.
信頼性
アクティブ・アクティブ構成では、 最高レベルの信頼性 災害復旧戦略の中でも、 Amazon Route 53 アプリケーションリカバリコントローラー 複数のリージョンの健全性を継続的に監視し、障害が発生したインフラストラクチャからトラフィックを自動的にリダイレクトします。この設定は、サービスレベル目標が1.50を超えるミッションクリティカルなワークロード（Tier 0）に最適です。 99.99%. 数秒のダウンタイムでも収益の損失や顧客の信頼の低下につながる可能性がある企業にとって、このレベルの信頼性は不可欠です。.
"「自動化は英雄に勝る：自動フェイルオーバープロセスは、障害発生時に手動で修正する人に依存するよりもはるかに優れています。」 – アレックス・ブルックス、AWSソリューションアーキテクト
コスト効率
アクティブ・アクティブ冗長性は 最も高価な 災害復旧オプション。これは、複数のリージョンで24時間365日、フルコンピューティングとストレージ容量を利用料として支払うことになるためです。リージョン間の継続的なデータレプリケーションや、Amazon EBSボリュームやスナップショットなどのリソースに対する時間単位の課金によって、コストはさらに増加します。しかし、ダウンタイムが収益に直接影響する企業では、これらの費用は十分に価値があるとみなされることが多いです。重要度の低いシステムでは、アクティブ/パッシブ構成のウォームスタンバイの方が経済的な選択肢となる場合があります。.
実装の複雑さ
アクティブ-アクティブ冗長性の設定は、標準的なフェイルオーバーモデルよりも複雑です。同期キャッシュ（例：, エラスティキャッシュ）、高度なトラフィック ルーティング、およびリージョン間でのデータの一貫性の維持を実現します。.
データの整合性は大きな課題です。同期レプリケーションは精度を保証しますが、書き込みレイテンシが増加し、通常は単一リージョンに限定されます。非同期レプリケーションはリージョン間のリカバリをサポートしますが、遅延が発生し、データが古くなる可能性があります。こうした複雑さを管理するために、Infrastructure as Code (IaC) はリージョン間でネットワークトポロジとセキュリティ構成を複製できます。自動化ツールとランブックは、障害発生時のデータベースの昇格とトラフィックルーティングを処理します。 Amazon クラウドウォッチ メトリックを集約して、フェイルオーバーをいつ実行するかを決定します。.
目標復旧時間 (RTO)
アクティブ・アクティブ冗長性により、 RTOは秒単位で測定されます, 多くの場合、ダウンタイムはほぼゼロです。すべてのリージョンで既にライブトラフィックが処理されているため、フェイルオーバーはリソースの起動やデータベースの昇格を待つのではなく、トラフィックの重みを調整するだけで済みます。 AWS グローバルアクセラレーター バックエンドのエンドポイントに障害が発生した場合でも一定のままの静的 IP アドレスを使用するため、DNS ベースのフェイルオーバー方法に比べてトラフィックのシフトが高速になります。.
| 寸法 | アクティブ-アクティブ冗長性 | アクティブ/パッシブ（ウォームスタンバイ） |
|---|---|---|
| 信頼性 | 最高; すべての地域でトラフィックがアクティブ | 高; フェイルオーバーの成功が必要 |
| コスト効率 | 最も高価。全地域でリソースが充実 | コスト効率が向上し、セカンダリリージョンが縮小されました |
| 複雑 | 高; グローバルなデータ同期が必要 | 中程度; 自動フェイルオーバー スクリプトが必要 |
| 料金 | ほぼゼロ。交通は瞬時に移行 | 数分から数時間。スケーリング/プロモーションによって異なります。 |
この表は、アクティブ/アクティブ構成とアクティブ/パッシブ構成の主な違いを強調し、トレードオフについてのより明確な視点を提供します。.
3. アクティブ・パッシブ冗長性
アクティブ・パッシブ冗長性 プライマリリージョンがすべてのライブトラフィックを処理し、セカンダリリージョンがスタンバイ状態を維持し、必要に応じて引き継ぐディザスタリカバリ構成です。このアプローチは、アクティブ/アクティブ構成よりも予算に優しい代替手段となりますが、特にフェイルオーバー速度においてトレードオフがあります。アクティブ/アクティブ構成とは異なり、セカンダリリージョンは障害が発生するまでリクエストを処理しません。アクティブ/パッシブ構成には、主に2つの種類があります。 パイロットライト, これにより、データベースなどの必須リソースのみが稼働し、 ウォームスタンバイ, これにより、軽量でありながら運用可能なバージョンのワークロードがセカンダリ リージョンに維持されます。.
信頼性
アクティブ・パッシブ構成は、 継続的なデータ複製 信頼性を確保するため、プライマリリージョンはセカンダリリージョンに定期的にデータを同期します。このデータは暗号化によって保護され、フェイルオーバーはDNSの変更によってトリガーされます。DNSの変更は、多くの場合、CloudWatchなどのツールによって監視および自動化されています。.
しかし、課題もあります。最大の懸念は 複製遅延, リージョン間でデータ更新が完全に同期されていない可能性があります。一部のオーケストレーションツールは、フェイルオーバーを開始する前に遅延を自動的にチェックしないため、データ損失を回避するために手動による介入が必要になる場合があります。フェイルオーバー後、システムは新たにアクティブになったリージョンを保護するために「逆レプリケーション」を実行する必要がありますが、これは自動ではありません。さらに、ネットワーク帯域幅が不十分な場合、継続的なレプリケーションが失敗し、データが保護されない可能性があります。.
コスト効率
アクティブ/パッシブ冗長構成は、コストとパフォーマンスのバランスが取れています。アクティブ/アクティブ構成よりも手頃な価格ですが、単純なバックアップとリストア方式よりも高価です。コストは構成の種類によって異なります。
- パイロットライト コンピューティング リソースはステージングされたまま非アクティブなまま、データベースなどの重要なリソースのみを実行することでコストを低く抑えます。.
- ウォームスタンバイ ワークロードの縮小バージョンをセカンダリ リージョンで実行し続けるため、コストが高くなります。.
その他の継続的な費用には、リージョン間のデータ転送料金、Amazon EBSストレージ料金、災害復旧サービスの時間単位の費用などがあります。コストを最適化するには、パッシブリージョンでAWS LambdaやAmazon API Gatewayなどのサーバーレステクノロジーを使用することで、アイドル状態のコンピューティングリソースに対する課金を回避できます。ネットワークに関しては、VPCピアリングはTransit Gatewayよりもシンプルで手頃な価格のオプションです。.
実装の複雑さ
アクティブ・パッシブ冗長性を設定するには 中程度の努力. DNSリダイレクト、自動フェイルオーバーメカニズム、そしてプライマリリージョンへのオペレーション復帰のための明確なプロセスを設定する必要があります。AWS CloudFormationやHashiCorp Terraformなどのツールは、リージョン間でリソース設定の一貫性を確保することで、導入を簡素化します。すべてが期待どおりに機能していることを確認し、チームにプロセスをトレーニングするために、定期的なフェイルオーバー演習が不可欠です。.
フェイルバックプロセスは、さらに複雑なプロセスとなります。プライマリリージョンに戻るには、リカバリリージョンからデータをコピーし直す必要があり、時間がかかる場合があります。これには、古くなったプライマリデータベースの削除と新しいレプリカの作成が含まれることがよくあります。重要なデータをステージングリージョンとリカバリリージョンで別々のAWSアカウントに分割することでセキュリティを強化すると、運用上のオーバーヘッドが増加し、リカバリ作業がさらに複雑になる可能性があります。これらの要因は最終的にリカバリ時間に影響を与えます。これについては次に詳しく説明します。.
目標復旧時間 (RTO)
アクティブ/パッシブ設定の RTO は、選択した戦略によって異なります。
- バックアップと復元: 回復には通常 24 時間ほどかかります。.
- パイロットライト: リカバリ中にコンピューティング リソースをプロビジョニングおよび拡張する必要があるため、RTO は数十分で達成されます。.
- ウォームスタンバイ: インスタンスはすでに実行されており、スケーリングのみが必要なため、多くの場合数分以内に高速なリカバリが実現します。.
AWS Elastic Disaster Recovery は、Pilot Light のコスト削減とウォームスタンバイの高速な復旧時間を組み合わせた便利なツールです。.
自動化は、手作業を削減することでRTOを短縮する上で重要な役割を果たします。例えば、DNS TTL設定とRoute 53ルーティングの更新は、ユーザーがリカバリリージョンにリダイレクトされる速度を決定します。さらに、データプレーンAPIを使用することで、リージョン障害発生時のフェイルオーバーの信頼性を向上させ、よりスムーズな移行を実現できます。.
メリットとデメリット
冗長化手法にはそれぞれ、コスト、複雑さ、復旧速度のバランスを取るためのトレードオフが存在します。これらの手法を比較してみましょう。
クロスリージョンフェイルオーバー 地域的な障害発生時でも業務の継続が求められる高優先度ワークロードにとって、これは確かな選択肢です。RTO（目標復旧時間）が明確に設定された自動フェイルオーバーをサポートしています。しかし、この利便性にはコストがかかります。データ転送と同期には多大なコストがかかり、フェイルバックプロセスは逆レプリケーションや手動クリーンアップなど、複雑な作業を伴う場合があります。Amazon Web ServicesのJohn Formento氏は次のように指摘しています。
"「マルチリージョンアーキテクチャが正しく構築されていない場合、ワークロードの全体的な可用性が低下する可能性があります。」"
アクティブ-アクティブ冗長性 ほぼゼロRTOで超高速リカバリを実現し、ユーザーには地理的に最も近い場所からサービスを提供します。この構成は、最高レベルのパフォーマンスを求めるグローバルユーザーに最適です。その一方で、複数のリージョンで完全に稼働するアプリケーションスタックを維持するにはコストがかかります。データ同期も課題となる可能性があり、設計が不適切なシステムは意図せず全体的な可用性を低下させる可能性があります。.
アクティブ・パッシブ冗長性 ウォームスタンバイやパイロットライト構成を利用することでコストを削減できる、より予算に優しいオプションです。アイドル状態のコンピューティングリソースに料金を支払う必要がないため、お財布にも優しいです。さらに、フェイルオーバー演習でプライマリ環境が中断されることはありません。ただし、その代償として、アクティブ/アクティブ構成に比べてRTOが高くなります。復旧は、パッシブリソースの拡張性とDNSトラフィックのリダイレクト速度に依存します。さらに、フェイルオーバー中にデータ損失につながる可能性のあるレプリケーション遅延などの問題を回避するために、データレプリケーションの管理が不可欠です。.
| 冗長化方式 | 主な利点 | 主な欠点 |
|---|---|---|
| クロスリージョンフェイルオーバー | 自動リカバリ、定義されたRTO、ビジネス継続性の確保 | 高いデータ転送コスト、複雑なフェイルバックプロセス、レプリケーションの遅延によるデータ損失のリスク |
| アクティブ-アクティブ | ほぼゼロのRTO、グローバルパフォーマンスの向上、最高の可用性 | 高価、データ同期が難しい、構成を誤ると可用性が低下する可能性がある |
| 能動態-受動態 | コスト効率が高く、訓練はプライマリシステムに影響を与えず、コールドバックアップよりも高速です | アクティブ/アクティブよりもRTOが高く、データ損失を防ぐために慎重なレプリケーション管理が必要 |
この分析では、災害復旧計画に最適な冗長化戦略を決定する際に考慮すべき重要な点を取り上げています。それぞれの方法には長所と短所があり、最適な選択はお客様の具体的なニーズと優先順位に大きく左右されます。.
結論
適切な冗長化方法を選択するには、ビジネスニーズとシステムの重要性を理解することが重要です。 ミッションクリティカルなシステム（Tier 0）, 数秒のダウンタイムさえも許容できない状況では、, アクティブ-アクティブ冗長性 最適な方法です。これらのシステムでは、多くの場合、99.999%以上のサービスレベル目標（SLO）と、実質的にゼロの復旧時間目標（RTO）が求められます。.
のために 中程度に重要なシステム（Tier 1）, 短時間の中断が許容できる場合、 アクティブパッシブウォームスタンバイ セットアップは、コストと迅速な復旧のバランスをしっかりと保ちます。この方法は、過剰なコストをかけずに信頼性の高いパフォーマンスを必要とする顧客向けアプリケーションに特に効果的です。ただし、災害復旧計画が最も必要な時に確実に機能するためには、定期的なテストが不可欠です。.
となると 運用システム（Tier 2）, 数時間という長いRTOが許容される場合、, アクティブパッシブコールドスタンバイ コスト効率の高い選択肢を提供します。同様に、, 管理ワークロード（Tier 3） 多くの場合、バックアップと復元の手法に依存しており、復旧時間は数時間から数日に及ぶことがあります。これらの階層化された戦略は、堅牢な災害復旧計画の基盤となります。.
これらの戦略をシームレスに機能させるには、ワークロードの重要度に合わせて冗長化方法を調整する必要があります。マネージドサービスは、冗長化とレプリケーションのタスクを自動化することで、このプロセスを簡素化できます。フェイルオーバーメカニズムの自動化は、ダウンタイム削減の重要なステップです。Microsoft Azure Well-Architected Frameworkでは、次のようにアドバイスされています。
"ワークロードの冗長性を高めるとコストも増加します。冗長性の追加を慎重に検討し、アーキテクチャを定期的に見直してコスト管理を確実に行ってください。"
まず、ワークロードを階層に分類し、それぞれに明確なRTO（目標復旧時間）とRPO（復旧時点目標）を設定します。最も効果的なアプローチは必ずしも最も高価なものではなく、保護と持続可能性のバランスが取れたアプローチです。.
運用の回復力を高めるには、 Serverion. マルチリージョン ホスティングにより、地域的な混乱が発生した場合でも中断のない運用が保証され、重要なシステムを常に稼働させることができます。.
よくある質問
災害復旧のためにリージョン間フェイルオーバーを設定する場合、どのようなコストを考慮する必要がありますか?
リージョン間フェイルオーバーの設定には、慎重に検討する必要があるさまざまなコストがかかります。大きな費用は、 コンピューティングリソース セカンダリリージョンで。ウォームスタンバイまたはホットスタンバイ構成を選択した場合、追加のインスタンスの実行、ストレージ、ライセンス要件によりコストが高くなります。一方、コールドスタンバイ構成は、インスタンスを継続的に実行することなく、主に複製されたデータを維持するため、一般的に経済的です。.
考慮すべきもう一つの大きなコストは データ複製ストレージ, は、各リージョンで個別に請求されます。ストレージ料金の低いリージョンを選択すると、これらのコストを抑えることができます。さらに、, 地域間データ転送料金 進行中のデータレプリケーションとフェイルオーバーイベント中に発生するトラフィックに適用されます。大規模なデータセットを扱う場合、これらの料金は急速に上昇する可能性があります。.
また、考慮する必要があるのは 管理およびライセンスコスト 災害復旧ツール、監視システム、そして依存しているサードパーティサービスなど、あらゆる費用を負担する必要があります。多くの組織は、費用を効果的に管理するために、階層型アプローチを採用しています。例えば、重要なサービスのみをウォームスタンバイ状態に維持し、費用対効果の高いストレージソリューションを使用し、復旧目標に基づいて帯域幅の使用を慎重に計画するといった対策が考えられます。.
インスタンス料金 (例: $0.10/時間)、ストレージ料金 (例: $0.023/GB/月)、データ転送コスト (例: $0.02/GB) などのコスト要素に特定の値を割り当てることで、企業は信頼性と手頃な価格のバランスが取れたフェイルオーバー戦略を作成できます。.
リージョン間フェイルオーバーは、リージョン停止時のデータの信頼性をどのように向上させるのでしょうか?
クロスリージョンフェイルオーバーにより、 セカンダリリージョンでの同期バックアップ. プライマリリージョンが障害によりオフラインになった場合、トラフィックはセカンダリリージョンにシームレスにリダイレクトされます。つまり、ユーザーは中断することなく最新のデータにアクセスし続けることができます。.
この方法は災害復旧計画において重要な役割を果たし、企業が 高可用性 地域的な障害発生時のダウンタイムを削減します。遠隔地間でデータを複製することで、企業は業務を保護し、どのような状況下でもユーザーに一貫したエクスペリエンスを提供できます。.
アクティブ/アクティブとアクティブ/パッシブの冗長設定のどちらを選択する場合に考慮すべきことは何ですか?
どちらかを選択する場合 アクティブ-アクティブ そして 能動態-受動態 冗長性を設定する場合は、コスト、パフォーマンス要件、運用の複雑さなどの要素を比較検討することが重要です。.
アン アクティブパッシブ設定 一般的に予算に優しいです。プライマリサーバーとスタンバイサーバーを使用するため、導入と保守が簡単です。一方、 アクティブ-アクティブ構成 インフラストラクチャが倍増し、管理にさらに多くの労力が必要になるため、費用が高くなります。.
パフォーマンスのニーズとダウンタイムの許容度も重要な考慮事項です。. アクティブ/アクティブ設定 安定したパフォーマンスが必須となる高トラフィック環境で真価を発揮します。トラフィックを全ノードに分散することで、フェイルオーバーによる遅延を排除します。しかし、小規模なアプリケーションや中程度の要求のシステムでは、 アクティブパッシブ設定 多くの場合、これで十分であり、扱いやすくなります。.
最後に、チームの能力と許容できるダウンタイムについて考えます。. アクティブ・アクティブシステム 高度な管理と同期が求められ、より熟練した人材が必要になる場合があります。, アクティブパッシブ設定 よりシンプルで、リソースが限られているチームや、短時間のフェイルオーバー期間に対応できるチームに適しています。どちらのオプションも、特定のニーズに合わせてコスト、パフォーマンス、可用性のバランスを調整できます。.
