移行とハイブリッド

AWS Elastic Disaster Recovery で構築する災害復旧 - 継続的レプリケーションと復旧テスト

継続的レプリケーションでオンプレミスサーバーを AWS に複製し、復旧ドリルで手順を検証する。フェイルバックまでの一連の流れを紹介します。

約 3 分で読めます

Elastic Disaster Recovery の概要

Elastic Disaster Recovery (DRS) はオンプレミスや他クラウドのサーバーを AWS に継続的にレプリケーションし、災害時に迅速に復旧するサービスです。ソースサーバーに AWS Replication Agent をインストールすると、ブロックレベルの変更が TCP 1500 番ポート経由で継続的に AWS のステージングエリアにレプリケーションされます。初回は全ディスクのフルシンクが実行され、以降は変更ブロックのみが差分転送されるため、ネットワーク帯域の消費を抑えつつ RPO を秒単位に維持できます。エージェントは Windows Server 2012 R2 以降と主要な Linux ディストリビューション (Amazon Linux、RHEL、CentOS、Ubuntu、SUSE、Debian) に対応しています。レプリケーション先のステージングエリアには低コストの EBS ボリューム (gp3 または st1) が使用され、ソースディスクのデータが圧縮なしで保持されます。

復旧ドリルとフェイルオーバー

復旧ドリルはレプリケーションデータから EC2 インスタンスを起動し、アプリケーションの動作を検証するテストです。本番のレプリケーションに影響を与えずに実行でき、RTO の実測値を取得できます。ドリルではポイントインタイムスナップショットから特定時刻の状態を復元でき、データ破損が発生した場合に破損前の時点を指定して起動することも可能です。DRS はスナップショットを過去数日間保持するため、ランサムウェア攻撃からの復旧にも対応します。フェイルオーバーはドリルと同じ手順で EC2 インスタンスを起動し、DNS を切り替えて本番トラフィックを AWS に向けます。DRS コンソールから複数サーバーを一括でフェイルオーバーする Recovery Plan 機能を使えば、起動順序と待機時間を定義して依存関係のあるサーバー群を正しい順番で復旧できます。フェイルバックは AWS から元のオンプレミス環境にデータを戻す操作で、専用の Failback Client を元サイトで起動し、DRS がレプリケーションの逆方向を管理します。

ネットワーク設計と復旧自動化

DRS のレプリケーションサーバーはステージングサブネットに配置され、ソースサーバーからのデータを受信します。復旧時に起動するインスタンスは別のサブネット (復旧サブネット) に配置し、本番環境のネットワーク設定を事前に定義します。起動テンプレートでインスタンスタイプ、セキュリティグループ、サブネット、 IAM ロールを設定し、復旧時の手動作業を最小化します。ポストローンチアクションで、インスタンス起動後にスクリプトを自動実行し、 DNS の切り替えやアプリケーションの設定変更を自動化します。ステージングサブネットからインターネットへのアウトバウンド通信は不要で、VPN や Direct Connect 経由のプライベート接続でレプリケーションを完結できます。ソースサーバーの Private IP を復旧インスタンスに維持することも可能で、IP アドレス依存のアプリケーション設定をそのまま引き継げます。 DRP 設計のベストプラクティスを把握するうえで関連書籍 (Amazon)が参考になります。

DRS の料金と制限の注意点

DRS の料金はレプリケーションサーバーの EC2 インスタンスと EBS ボリュームで構成されます。レプリケーションサーバーは t3.small 程度の小さいインスタンスで動作し、ソースサーバー 1 台あたりの月額コストは比較的低く抑えられます。復旧ドリルやフェイルオーバー時に起動するインスタンスは、実行時間分のみ課金されます。EBS スナップショットのストレージ料金がデータ量に応じて発生します。注意すべき制限として、1 つの AWS アカウントあたりのソースサーバー数に上限が設定されており、大規模環境ではサービスクォータの引き上げリクエストが必要です。レプリケーション帯域は最大 10 Gbps/サーバーに制限されるため、書き込みが極端に多いデータベースサーバーでは初回同期の完了時間を見積もる必要があります。Cross-Region レプリケーションにはリージョン間のデータ転送料金も発生するため、大容量サーバーでは月額コストを事前に試算することが重要です。

他の DR 方式との比較

AWS には DRS 以外にも DR を実現する方法があります。AWS Backup はスナップショットベースの定期バックアップで、RPO は最短 1 時間程度ですが設定が簡素でコストが低いのが特長です。CloudEndure Disaster Recovery は DRS の前身サービスで、DRS への移行が推奨されています。パイロットライト方式は最小構成のインフラを常時稼働させ災害時にスケールアップする手法で、RDS や Route 53 のフェイルオーバーと組み合わせます。ウォームスタンバイは本番に近い構成を縮小版で常時稼働させる手法で、RTO は短いがコストは DRS より高くなります。DRS の強みは継続的レプリケーションによる秒単位の RPO と、常時フルサイズのスタンバイ環境が不要な点にあります。逆にデータベース層のみの DR (例: RDS Multi-Region Read Replica + Route 53 フェイルオーバー) で十分な場合は、DRS を導入するよりシンプルに実現できます。

設計のベストプラクティスと落とし穴

DRS を導入する際のベストプラクティスとして、まず復旧ドリルを月次で定期実行し、復旧手順とアプリケーションの動作確認を習慣化します。ポストローンチアクションに依存するスクリプトはバージョン管理し、変更のたびにドリルで検証します。落とし穴として多いのは、ソースサーバーの OS パッチによりエージェントが停止するケースです。レプリケーション遅延が閾値を超えた際に CloudWatch アラームで検知する仕組みを構築してください。また、ソースサーバーが Active Directory ドメインに参加している場合、復旧インスタンスがドメインに再参加できるよう DNS 設定とドメインコントローラーへの疎通をあらかじめ確認する必要があります。Recovery Plan を使う場合はサーバー間の依存関係 (DB → App → Web の起動順序) をドキュメント化し、起動グループと待機時間を正しく定義します。フェイルバック時はソースサイトのネットワーク復旧を先に確認し、Failback Client が AWS のステージングサーバーに接続できることを検証してから開始します。

まとめ

Elastic Disaster Recovery は継続的レプリケーションで RPO を秒単位に短縮し、数分での復旧を実現する DR サービスです。起動テンプレートと Recovery Plan で復旧インスタンスの設定と起動順序を事前定義し、ポストローンチアクションで DNS 切り替えを自動化します。定期的な復旧ドリルで RTO/RPO 目標の達成を検証し、ポイントインタイムリカバリでランサムウェア対策にも活用できます。バックアップベースの方式に比べ RPO が圧倒的に短く、常時稼働スタンバイと比較してコストを大幅に削減できる、バランスの取れた DR ソリューションです。

関連するサービス

AWS Elastic Disaster Recoveryオンプレミスや他クラウドのサーバーを AWS に継続的にレプリケーションし、災害復旧を提供するサービスAmazon EC2クラウド上で仮想サーバーを提供するコンピュートサービスAmazon EBSEC2 インスタンスに接続して使うブロックストレージサービス

関連する記事

AWS Backup による一元バックアップ管理 - バックアッププランとクロスリージョン保護EC2・RDS・DynamoDB など複数サービスのバックアップを統一ポリシーで一元管理する。Vault Lock による WORM 保護と復元テストの自動化を紹介します。Amazon EBS のボリューム設計と運用 - gp3 ・ io2 の選定基準とスナップショット戦略gp3・io2 のボリュームタイプ選定基準を明確にし、IOPS・スループットの設計指針とスナップショットによるバックアップ戦略を実践的に紹介します。Amazon EBS の暗号化とスナップショット共有 - クロスアカウント・クロスリージョンの設計デフォルト暗号化の有効化からスナップショットのクロスアカウント共有、クロスリージョンコピーによる DR 設計までを一貫して紹介します。

同じテーマの記事

データベース移行サービス - AWS DMS で実現する安全かつ効率的なデータベース移行AWS Database Migration Service (DMS) を活用したデータベース移行の手法を解説します。RDS との統合による同種・異種データベース間の移行と、継続的レプリケーションによるダウンタイム最小化の実践方法を紹介します。AWS DataSync で高速化するデータ転送 - オンプレミスから S3 ・ EFS への移行オンプレミスから S3・EFS への高速データ転送を自動化する。エージェントのデプロイ、タスクスケジューリング、転送データの整合性検証を紹介します。メインフレーム移行 - AWS Mainframe Modernization でレガシーシステムをクラウド化するAWS Mainframe Modernization を使ったメインフレームのクラウド移行を解説。リプラットフォーム (Micro Focus) とリファクタリング (Blu Age) の 2 パターンと移行戦略を紹介します。AWS Mainframe Modernization でメインフレームを AWS に移行 - リプラットフォームとリファクタMainframe Modernization によるメインフレームアプリケーションの移行パターン、Blu Age と Micro Focus の使い分けを解説します。メインフレーム刷新を加速する - AWS Transform でレガシー COBOL を数か月でモダナイズAWS Transform for mainframe によるメインフレームモダナイゼーションを解説。COBOL コードの自動分析、Java への変換、段階的な移行戦略を紹介します。AWS MGN による大規模移行の計画と実行 - ウェーブ設計とカットオーバー自動化数百台規模のサーバー移行をウェーブ設計で計画し、カットオーバーの自動化スクリプトと移行後の最適化手法を紹介します。AWS Application Migration Service (MGN) によるリフト&シフト移行の実践エージェントのインストールからカットオーバーまでのリフト&シフト移行手順を実践的に紹介。設計上の注意点とネットワーク構成も解説します。移行の一元管理 - AWS Migration Hub でクラウド移行の進捗を可視化するAWS Migration Hub を使ったクラウド移行の一元管理を解説。移行進捗の可視化、Application Discovery Service との統合、移行戦略の選択支援を紹介します。

内容が近い記事・サービス

AWS Elastic Disaster Recoveryオンプレミスや他クラウドのサーバーを AWS に継続的にレプリケーションし、数分でフェイルオーバーする DR サービスAWS の DR 戦略の選択肢 - Pilot Light から Multi-Site まで段階的に設計する災害復旧Pilot Light、Warm Standby、Multi-Site Active/Active の各 DR 戦略と Elastic Disaster Recovery を中心に、AWS が提供する災害復旧の選択肢の幅広さと柔軟性を解説します。AWS Application Migration Serviceオンプレミスや他クラウドのサーバーを AWS にリフト & シフトで移行するサービスで、継続的レプリケーションによりカットオーバー時のダウンタイムを最小化するAWS Application Migration Service (MGN) によるリフト&シフト移行の実践エージェントのインストールからカットオーバーまでのリフト&シフト移行手順を実践的に紹介。設計上の注意点とネットワーク構成も解説します。