AWS の DR 戦略の選択肢 - Pilot Light から Multi-Site まで段階的に設計する災害復旧
Pilot Light、Warm Standby、Multi-Site Active/Active の各 DR 戦略と Elastic Disaster Recovery を中心に、AWS が提供する災害復旧の選択肢の幅広さと柔軟性を解説します。
DR 戦略はコストと復旧速度のトレードオフである
災害復旧 (Disaster Recovery) の設計は、RTO (Recovery Time Objective: 復旧目標時間) と RPO (Recovery Point Objective: 復旧目標地点) という 2 つの指標を軸に行います。RTO が短いほど、障害発生からサービス復旧までの時間が短くなります。RPO が短いほど、障害発生時に失われるデータの量が少なくなります。しかし、RTO と RPO を短縮するほど、DR 環境の維持コストは増大します。AWS は Backup & Restore、Pilot Light、Warm Standby、Multi-Site Active/Active という 4 段階の DR 戦略を定義しており、ビジネス要件に応じた最適なコストと復旧速度のバランスを選択できます。この段階的なアプローチは AWS Well-Architected Framework の信頼性の柱に組み込まれており、体系的な DR 設計のガイダンスが提供されています。
4 段階の DR 戦略
Backup & Restore は最もコストの低い戦略です。データのバックアップを別リージョンの S3 に保存し、障害発生時にバックアップからリソースを再構築します。RTO は数時間から数十時間、RPO はバックアップ頻度に依存します。コストはバックアップストレージのみで済みますが、復旧に時間がかかります。Pilot Light は、DR リージョンにデータベースのレプリカなど最小限のコアコンポーネントだけを常時稼働させる戦略です。障害発生時に、停止していたアプリケーションサーバーやロードバランサーを起動します。RTO は数十分から数時間、RPO はレプリケーションの遅延に依存します。Warm Standby は、DR リージョンに本番環境の縮小版を常時稼働させる戦略です。障害発生時にスケールアップして本番トラフィックを処理します。RTO は数分から数十分です。Multi-Site Active/Active は、複数リージョンで同時にトラフィックを処理する戦略です。RTO と RPO はほぼゼロに近づきますが、コストは最も高くなります。
Elastic Disaster Recovery による DR の簡素化
AWS Elastic Disaster Recovery (DRS) は、オンプレミスや他クラウドのサーバーを AWS にレプリケーションし、障害時に迅速にフェイルオーバーするマネージドサービスです。DRS はソースサーバーにエージェントをインストールし、ブロックレベルの継続的レプリケーションを行います。データは圧縮・暗号化されて AWS に転送され、低コストのステージングエリアに保存されます。障害発生時には、ステージングエリアのデータから EC2 インスタンスを数分で起動し、本番トラフィックを切り替えます。DRS の特徴は、レプリケーション中のコストが非常に低い点です。ステージングエリアは低コストの EBS ボリュームを使用し、本番スペックの EC2 インスタンスはフェイルオーバー時にのみ起動されます。これにより、Warm Standby に近い RTO を、Pilot Light に近いコストで実現できます。定期的な DR ドリル (復旧訓練) もコンソールから簡単に実行でき、本番環境に影響を与えずに復旧手順を検証できます。
AWS のリージョン間レプリケーション機能
AWS の主要サービスは、リージョン間のデータレプリケーション機能をネイティブに提供しています。S3 のクロスリージョンレプリケーション (CRR) は、オブジェクトを別リージョンの S3 バケットに自動複製します。RDS のクロスリージョンリードレプリカは、データベースの読み取り専用コピーを別リージョンに維持し、障害時にプライマリに昇格できます。Aurora Global Database は、最大 5 つのセカンダリリージョンにデータをレプリケーションし、1 秒未満のレプリケーション遅延と 1 分未満のフェイルオーバーを実現します。DynamoDB Global Tables は、複数リージョンでアクティブ-アクティブのテーブルレプリケーションを提供し、各リージョンで読み書きが可能です。EBS スナップショットのクロスリージョンコピー、EFS のクロスリージョンレプリケーション、Secrets Manager のマルチリージョンシークレットなど、データ層の DR に必要な機能が各サービスに組み込まれています。これらのネイティブ機能を組み合わせることで、サードパーティツールに依存せずに DR アーキテクチャを構築できます。
Route 53 と Global Accelerator による DR のトラフィック制御
DR 戦略の実効性は、障害検知とトラフィック切り替えの速度に大きく依存します。Route 53 はヘルスチェック機能により、エンドポイントの障害を自動検知し、DNS フェイルオーバーを実行します。フェイルオーバールーティングポリシーを設定することで、プライマリリージョンの障害時に DR リージョンへ自動的にトラフィックを切り替えられます。ただし、DNS ベースのフェイルオーバーは TTL の影響を受けるため、切り替えに数十秒から数分のラグが生じる場合があります。Global Accelerator は AWS のグローバルネットワークを活用した静的 IP ベースのトラフィックルーティングを提供します。DNS の TTL に依存しないため、エンドポイントの障害検知後、数十秒以内にトラフィックを別リージョンに切り替えられます。Multi-Site Active/Active 戦略では、Global Accelerator のトラフィックダイヤル機能により、各リージョンへのトラフィック配分を動的に制御できます。障害時には障害リージョンのトラフィックダイヤルを 0% に設定し、即座にトラフィックを健全なリージョンに集中させることが可能です。
DR 設計の実践的な考慮事項
DR 戦略の選択は、ビジネスインパクト分析 (BIA) に基づいて行います。各ワークロードの RTO と RPO を定義し、それに見合った DR 戦略とコストを経営層と合意することが重要です。すべてのワークロードに Multi-Site Active/Active を適用する必要はなく、ワークロードの重要度に応じて戦略を使い分けるのが現実的です。DR 環境の維持だけでなく、定期的な DR ドリルの実施が不可欠です。復旧手順が文書化されていても、実際に訓練しなければ障害時に機能しません。AWS Resilience Hub は、ワークロードの耐障害性を評価し、RTO と RPO の目標に対する準拠状況を可視化するサービスです。DR の設計パターンを体系的に学ぶには関連書籍 (Amazon) も参考になります。
まとめ
AWS は Backup & Restore、Pilot Light、Warm Standby、Multi-Site Active/Active という 4 段階の DR 戦略を体系的に定義し、ビジネス要件に応じた最適なコストと復旧速度のバランスを選択できます。Elastic Disaster Recovery は Warm Standby に近い RTO を低コストで実現するマネージドサービスであり、DR の導入障壁を大幅に下げています。S3 CRR、Aurora Global Database、DynamoDB Global Tables など、主要サービスのネイティブなクロスリージョンレプリケーション機能が充実しており、サードパーティツールに依存しない DR アーキテクチャを構築できます。Route 53 と Global Accelerator によるトラフィック制御の柔軟性も、DR の実効性を高める重要な要素です。DR 戦略の選択肢の幅広さと各戦略を支えるサービスの成熟度において、AWS は他のクラウドプロバイダーをリードしています。