セクション 03 · タスク 1.3 · SAP-C02-026

AWS Elastic Disaster RecoveryによるDR設計

AWS Elastic Disaster Recovery / 継続的レプリケーション / 復旧サイト / フェイルオーバー / フェイルバック

このページのゴール

既存サーバーワークロードに対して、継続レプリケーションから復旧インスタンス起動、トラフィックフェイルオーバー、プライマリへのフェイルバックまでの責任を分離し、AWS Elastic Disaster Recoveryを採用すべき要件を判断できることをゴールにします。

復旧要件
        ↓
既存サーバーを大幅に再設計せず保護したい？
        ↓
継続的レプリケーション
        ↓
復旧サイトを事前設計
        ↓
訓練 / 復旧
        ↓
復旧インスタンス起動
        ↓
フェイルオーバー（トラフィック切替）
        ↓
フェイルバック

特に、復旧とフェイルオーバーは同じ処理ではありません。AWS DRSが担当する復旧と、DRアーキテクチャ全体で別途設計するトラフィック管理を区別します。

1. AWS DRSは既存サーバーワークロードをAWSへ復旧するマネージド DRサービス

AWS Elastic Disaster Recovery（AWS DRS）は、オンプレミスやクラウド上の既存サーバーワークロードをAWSへ継続レプリケーションし、災害時にAmazon EC2復旧インスタンスとして起動できるマネージドサービスです。

平常時はステージング領域で安価なストレージと最小限のコンピューティングを利用し、復旧時に必要なEC2を起動するため、完全本番コンピューティングを常時待機させる構成より稼働コストを抑えやすくなります。

特に、既存VMや物理サーバーを大幅にクラウドネイティブへ再設計せず、短いRPOと分単位の復旧を狙いたい要件で有力な候補になります。

2. DRSはアプリケーションを別アーキテクチャへ作り直すサービスではない

送信元サーバーにはAWS Replication Agentを導入し、ディスクブロックの変更をAWSへ継続的に複製します。

既存サーバー
   ↓
ブロックレベルレプリケーション
   ↓
AWS ステージング領域
   ↓
復旧時にEC2へ変換・起動

つまりDRSの中心は、既存サーバー / OS / ディスク構成を保護してAWS上へ復旧することです。アプリケーションをマイクロサービスへ分割したり、データベースをマネージドサービスへ自動変換したりするモダナイゼーションサービスではありません。

3. AWS DRSの全体構造

送信元環境
┌────────────────────┐
│ 送信元サーバー      │
│ AWS レプリケーション    │
│ エージェント              │
└─────────┬──────────┘
          │ 継続的ブロックレプリケーション
          ▼
AWS 復旧リージョン

ステージング領域サブネット
┌────────────────────┐
│ レプリケーションサーバー │
│ レプリケート済みEBS     │
└─────────┬──────────┘
          │ 訓練 / 復旧
          ▼
運用上のサブネット
┌────────────────────┐
│ 復旧インスタンス  │
│ Amazon EC2         │
└────────────────────┘

レプリケーション用のステージング領域と、アプリケーションを実際に動かす復旧環境は同じ責任ではありません。ステージング領域は継続レプリケーションを維持するための領域で、復旧インスタンスは起動設定に基づいて運用サブネットへ起動します。

4. 継続的レプリケーションは変更ブロックを継続的に転送する

AWS Replication Agentは初回にボリュームをブロックレベルで読み取り、その後は送信元ボリュームへの書き込みを捕捉して変更ブロックをレプリケーションサーバーへ継続的に送ります。

初期同期
ボリューム全体を同期
        ↓
継続的データ保護
        ↓
変更ブロックだけを継続転送

これは日次スナップショットのような定期バックアップとは異なり、送信元の変更へ継続的に追随することで小さいRPOを狙う設計です。

5. 継続的レプリケーションでもRPOは自動保証されない

「継続的」という名称だけでRPOを判断しません。送信元の書き込み率に対してネットワークやレプリケーション側のスループットが不足すると、滞留とレプリケーション遅延が増加します。

RPOへ影響する要素	影響
送信元書き込み率	変更量が多いほど転送量が増える
ネットワーク帯域幅	不足すると滞留が増える
レプリケーションサーバー	処理能力がレプリケーション速度へ影響する
ステージング EBS パフォーマンス	書き込み性能が不足すると遅延の要因になる

したがって、レプリケーション状態や遅延を監視し、要件のRPOを満たせることを確認します。

6. 復旧ポイントはブロックレベルのクラッシュ整合性状態

AWS DRSはブロックレベルレプリケーションを基盤とするため、復旧ポイントはディスクへ書き込まれた状態を基準にしたクラッシュ整合性な復旧です。

アプリケーションメモリ上にだけ残っていてディスクへ書き込まれていないデータまで、トランザクション単位で論理的に同期する仕組みではありません。

継続的ブロックレプリケーション
≠
アプリケーショントランザクションレプリケーション

アプリケーション固有の整合性要件がある場合は、そのアプリケーション側の設計も合わせて評価します。

7. ステージング領域と復旧サイトを分けて設計する

ステージング領域サブネットにはレプリケーションサーバーとレプリケート済みデータを配置します。一方、復旧サイトでは実際に本番ワークロードを動かすためのVPC / サブネット / セキュリティグループ / IAM / 接続性 / キャパシティを準備します。

ステージング領域
→ レプリケーションの責任

復旧サイト
→ アプリケーション実行の責任

「データがレプリケーションできている」だけでは復旧アーキテクチャは完成していません。

8. 起動設定が復旧インスタンスの形を決める

送信元サーバーごとにDRS起動設定とEC2起動テンプレートが作成され、訓練 / 復旧インスタンスをどのように起動するかを決めます。

例えば、復旧サブネット、セキュリティグループ、インスタンスタイプ、IAM インスタンスプロファイルなどが復旧結果へ直接影響します。

レプリケーション正常
        ↓
しかし
復旧サブネットが誤り
セキュリティグループが不足
インスタンスタイプが不適切
        ↓
アプリケーション復旧失敗

復旧サイトのネットワークとコンピューティング設定まで事前に設計します。

復旧モードとしてOptimalとFastを選択できます。Optimalはデフォルトで、復旧インスタンス起動前にドライバー注入、ブート設定、ファイルシステムの変更などの完全変換を実行します。送信元サーバーのAWS互換性に確信がない場合やクロスプラットフォームシナリオではOptimalを基本にします。

Fastは変換プロセスを省略し、レプリケート済みスナップショットから直接復旧インスタンスを起動して復旧時間を短縮します。AWS間DRなど、送信元サーバーがAWS互換ドライバー / 設定をすでに持つシナリオが主な候補です。Fast復旧モードにはAWS Replication Agent 6.42.20以降が必要です。

9. 復旧訓練は「レプリケーションできる」から「復旧できる」へ検証を進める

AWS DRSの復旧訓練は送信元サーバーと継続レプリケーションを止めず、実復旧と同じ起動設定とポイントインタイムデータを使って訓練インスタンスを起動します。

これにより、EC2がブートするだけでなく、ネットワーク接続性、アプリケーションプロセス、HTTP/HTTPS応答、依存サーバーとの通信まで確認できます。

レプリケーション状態が正常でもアプリケーションが利用できるとは限らないため、定期訓練で実際の復旧準備状態とRTOを検証します。

10. 複数サーバーの復旧では依存関係順序を設計する

業務システムがデータベース、ディレクトリサービス、アプリケーションサーバー、バッチサーバーなど複数サーバーで構成される場合、すべてを同時に起動すればよいとは限りません。

データベース / ディレクトリサービス
        ↓ 準備完了を待つ
アプリケーションサーバー
        ↓ 準備完了を待つ
バッチ / フロントエンド

現在のAWS DRSには復旧計画があり、相互依存する送信元サーバーをグループ化し、定義した順序と手順間の待機時間で訓練 / 復旧できます。

サーバー単体の復旧ではなく、アプリケーション全体として依存関係を満たす順番までRTO設計に含めます。

11. 起動後アクションで復旧後の処理と検証を自動化できる

復旧インスタンスを起動した後に必要な作業もRTOへ影響します。AWS DRSの起動後アクションでは、AWS Systems Managerを利用して定型処理や検証を自動化できます。

例えば、プロセス状態、ディスク / ボリューム完全性、ネットワーク接続性、HTTP/HTTPS応答などを確認できます。カスタム SSM ドキュメントを利用した処理も構成できます。

復旧インスタンス起動
        ↓
起動後アクション
        ↓
処理 / ディスク / ネットワーク / HTTP確認
        ↓
アプリケーション準備完了
        ↓
フェイルオーバー判断

復旧インスタンスが稼働になったことと、ビジネスアプリケーションが準備完了であることを分けて考えます。

12. 復旧は復旧インスタンスをAWSへ起動する処理

現在のAWS DRSでは、復旧はレプリケート済みデータを使用して復旧インスタンスをAWSへ起動する処理です。

レプリケート済みデータ
        ↓
復旧ジョブ
        ↓
EC2 復旧インスタンス
        ↓
アプリケーション検証

復旧インスタンス起動前の処理は復旧モードで異なります。OptimalではAWS上でブートできるよう完全変換を実行し、Fastでは変換を省略してレプリケート済みスナップショットから直接起動します。

13. フェイルオーバーはDRS外部のトラフィック管理

復旧インスタンスを起動しただけではユーザートラフィックは切り替わりません。

AWS DRS
→ 復旧インスタンスを起動

トラフィック 管理
→ 本番トラフィックを復旧サイトへ切替

現在のAWS DRSでは、本番トラフィックを復旧インスタンスへリダイレクトするフェイルオーバーはDRSの外部で行います。Amazon Route 53などのDNS / トラフィック管理や組織独自の仕組みを利用します。

したがって「DRSで復旧したから自動でユーザーが復旧サイトへ接続する」とは判断しません。

14. ポイントインタイム復旧で破損前へ戻せる

最新状態が常に正しい復旧ポイントとは限りません。

10:00 正常
10:05 データ破損
10:10 災害検知

破損がレプリケーション済みなら、最新状態から起動すると破損状態も再現されます。AWS DRSでは保持されている以前のポイントインタイムを選び、破損前の状態から復旧できます。

継続的レプリケーションは最新状態へ追随する責任、ポイントインタイム復旧は過去の正常状態へ戻す責任です。

15. フェイルバックでは復旧サイトの最新データをプライマリへ戻す

復旧サイトで本番を継続すると、その期間に新しいトランザクションや更新データが発生します。プライマリが復旧したからといって、そのままトラフィックを戻すと最新データを失う可能性があります。

復旧サイトで業務継続
        ↓
最新データをプライマリへレプリケーション
        ↓
プライマリを同期
        ↓
検証
        ↓
トラフィックをプライマリへ戻す

AWS DRSは復旧インスタンスから送信元インフラストラクチャへのデータレプリケーションを支援します。オンプレミスフェイルバックとAWS内フェイルバックでは使用する仕組みが異なりますが、アーキテクチャ判断は「最新データを戻してから切り戻す」です。

16. DRSを選ぶ決定打

要件	判断
既存サーバーを大幅に再設計せずAWSへ復旧したい	AWS DRSが有力
継続ブロックレプリケーションで短いRPOを狙いたい	AWS DRSが有力
復旧用完全コンピューティングを常時維持したくない	AWS DRSが有力
数時間〜数日単位でバックアップから再構築可能	バックアップと復元も比較
復旧リージョンが平常時からトラフィックを処理する必要がある	ウォームスタンバイ等を比較
通常時から複数リージョンをアクティブにする	マルチサイトアクティブ/アクティブを比較

決定打は、既存サーバーワークロード + 継続的ブロックレプリケーション + オンデマンド復旧コンピューティングです。

17. AWS DRSとパイロットライトは同義ではない

DRSはステージング領域で最小限のコンピューティングを維持し、復旧時にEC2を起動するため、コストと復旧運用の観点ではパイロットライトに近い特徴があります。

しかしパイロットライトはDRアーキテクチャパターン、AWS DRSはレプリケーションと復旧を実装するマネージドサービスです。

パイロットライト
→ アーキテクチャパターン

AWS DRS
→ マネージドサービス

パターンとサービスを同一視しません。

18. RTO / RPOは環境条件を含めて評価する

AWS DRSは短い復旧目標を狙えるサービスですが、実際のRTO / RPOは環境によって決まります。

指標	主な影響要素
RPO	書き込み率 / ネットワーク / レプリケーション遅延 / ステージングパフォーマンス
RTO	復旧ジョブ / ボリューム準備 / EC2 ブート / アプリケーション起動 / 検証 / トラフィック切替

代表値を暗記するのではなく、実際の訓練結果と監視で要件を満たすか確認します。

19. 代表シナリオ

企業はオンプレミス VMware上で20台のLinux サーバーから構成される業務システムを運用しています。

アプリケーションを大幅に再設計しない
データ損失を小さくしたい
DR用20台を常時稼働させるコストは避ける
災害時はAWS上で復旧
DB → アプリ → バッチの順序依存あり
復旧後はオンプレミスへ戻す

この要件なら、サーバーを継続ブロックレプリケーションするAWS DRSが有力です。復旧計画で依存サーバーを順序制御し、起動設定 / 起動後アクション / 訓練で復旧サイトを検証します。災害時は復旧インスタンスを起動し、検証後にトラフィックをフェイルオーバーします。プライマリ復旧後は最新データを戻してフェイルバックします。

20. 混同ポイント

混同	正しい考え方
DRS = バックアップサービス	継続的ブロックレプリケーションとサーバー復旧が中心
ステージング領域 = 復旧サイト	レプリケーション用領域とアプリケーション実行環境は別責任
レプリケーション正常 = アプリケーション復旧可能	訓練と検証で確認する
復旧 = フェイルオーバー	復旧はEC2起動、フェイルオーバーはトラフィック切替
DRSがトラフィックを自動切替	フェイルオーバーはDRS外部で設計する
継続的レプリケーションならRPO保証	遅延 / 帯域幅 / 書き込み率を確認する
最新状態だけから復旧	以前のポイントインタイムも選択可能
プライマリ復旧後すぐトラフィックを戻す	復旧サイトの最新データを同期してからフェイルバック
DRS = パイロットライト	DRSはサービス、パイロットライトはパターン

21. SAP-C02判断フロー

既存サーバーワークロード？
        ↓ はい
大幅な再設計を避けたい？
        ↓ はい
短いRPOが必要？
        ↓ はい
AWS DRSを候補
        ↓
継続的レプリケーション
        ↓
復旧サイト / 起動設定
        ↓
依存関係がある？
→ 復旧計画
        ↓
復旧訓練 + 検証
        ↓
災害
        ↓
復旧インスタンス起動
        ↓
フェイルオーバーは別途トラフィック切替
        ↓
プライマリ復旧
        ↓
逆方向レプリケーション / フェイルバック

22. まとめ

AWS Elastic Disaster Recoveryは、既存サーバーワークロードを大幅に再設計せず、継続的ブロックレプリケーションとオンデマンド復旧コンピューティングでAWSへ復旧するためのマネージドサービスです。

AWS DRS
→ 継続的レプリケーション
→ ステージング領域
→ 復旧サイト / 起動設定
→ 復旧モード（Optimal / Fast）
→ 訓練 / 復旧計画 / 検証
→ 復旧インスタンス
→ フェイルバック用データレプリケーション支援

トラフィック 管理
→ フェイルオーバー
→ ユーザートラフィックの切り替え

サービスを選ぶだけでなく、復旧サイト、依存関係順序、検証、トラフィックフェイルオーバー、フェイルバックまで責任を分けて設計します。

23. 主要AWS公式資料

理解確認

このページの内容を16問で確認します。

理解確認16問へ →