AWS Elastic Disaster Recoveryとは？コストを抑えつつ災害対策を実現するソリューション

1.DR対策を取り巻く背景と課題

システムの停止がビジネスに与える影響は、年々大きくなっています。

業務システムや顧客向けサービスのほとんどがITに依存し、障害や災害による停止は単に一時的な不便にとどまらず、売上の損失や信用の低下といったリスクにもつながりかねません。

そのためDR対策は、事業継続計画を支える重要な要素として位置づけている企業も多いのではないでしょうか。

一方で、DR対策は「重要であることは分かっているが、十分に実装できていない」領域でもあります。DR構成によってはインフラにかかるコストが高くなったり、データレプリケーションやフェイルオーバー手順の設計や運用に担当者の負荷が大きくなるといった課題もあります。

さらに、DR環境は「いざという時」に正しく動作することが求められますが、定期的な復旧テストを実施することも容易ではありません。テストのために本番環境へ影響が出るリスクや、手順の煩雑さから、DR構成が実際には検証されないままで運用されているケースも少なくありません。

クラウドの普及により、インフラ構築の柔軟性は高まりましたが、DRに関する課題は解消されたわけではありません。バックアップは取得しているものの、復旧にどれだけ時間がかかるのか、どこまでのデータを復元できるのかが明確になっていない場合、それは十分なDR対策とは言えないでしょう。

NTT東日本では、AWSなどクラウドに関するお役立ち情報をメールマガジンにて発信していますので、ぜひこちらからご登録ください。

2. AWS Elastic Disaster Recoveryとは

2-1. 概要

AWS Elastic Disaster Recoveryは、システム障害や災害発生時に迅速かつ確実にシステムを復旧することを目的としたAWSのマネージドサービスです。オンプレミス環境や他クラウドで動作するサーバーや、AWS上で稼働する EC2 インスタンスを対象に、継続的なデータレプリケーションを行い、障害発生時にはAWS上で復旧環境を立ち上げることができます。

AWS Elastic Disaster Recoveryでは、平常時はデータレプリケーション用の最小限のリソースのみを使用し、必要なタイミングで復旧環境を構築するというアプローチを採用しています。

これにより、DR対策に伴うコストや運用負荷を抑えつつ、実用的な復旧体制を実現することができます。

2-2. AWSでのDRパターンとAWS Elastic Disaster Recovery

AWSでのDR対策としては主に以下の4パターンとなります。

• マルチサイト（非常に短いRPO、非常に短いRTO）：本番環境と同等のシステムを複数拠点で常時稼働させるDR構成で、可用性は非常に高い一方で、インフラコストや運用負荷が最も大きくなります。
• ウォームスタンバイ（数秒間のRPO、数分間のRTO）：本番環境を縮小した形で待機系環境を常時稼働させる構成で、障害発生時にはリソースをスケールさせて復旧します。可用性とコストのバランスを取ったDR手法です。
• パイロットライト（数分間のRPO、数十分間のRTO）：データベースなどの最小限の中核コンポーネントのみを待機させ、障害時にアプリケーション層を起動して復旧する構成です。平常時のコストを抑えられる一方、復旧には一定の時間がかかります。
• バックアップリストア（数時間でのRPO、24時間以下でのRTO）：バックアップデータをもとにシステムを再構築する最もシンプルなDR手法で、コストは低いものの、復旧時間（RTO）が長くなりやすく、迅速な復旧には不向きです。

REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する - AWS Well-Architected フレームワーク

これら手法のうち、特にマルチサイトやウォームスタンバイといった構成では、障害発生時の復旧時間を短縮できる一方で、平常時からインフラのコストが発生し続けるという課題があります。

一方で、AWS Elastic Disaster Recoveryは、ウォームスタンバイ構成と同等のRPO/RTOを目指しつつ、パイロットライト構成のように平常時のコストを抑えることを可能にするサービスです。

これにより、DR対策を「現実的に維持できるコスト」で実現することが可能になります。

NTT東日本では、AWSなどクラウドに関するお役立ち情報をメールマガジンにて発信していますので、ぜひこちらからご登録ください。

3. AWS Elastic Disaster Recoveryの機能とメリット

AWS Elastic Disaster Recoveryの機能、メリットとそれによって解決できる課題を解説します。

3-1. 継続的なブロックレベルレプリケーション

AWS Elastic Disaster Recoveryは、ブロックレベルでの継続的なデータレプリケーションを提供します。DR対象となるサーバーには、専用のエージェント（AWS Replication Agent）を導入し、ディスクの変更内容をほぼリアルタイムにレプリケーションします。

アプリケーションやデータベースごとに個別のレプリケーション設計を行うことなく、OSレベルで統一的にレプリケーションすることができ、システム構成が複雑な環境でもDR設計をシンプルに保つことが可能です。

3-2. 復旧の容易さとDRテストの実施

DR対策においては「誰でも確実に復旧できる」ことも重要です。

AWS Elastic Disaster Recoveryは、復旧プロセスがサービスとして提供されており、事前に定義した設定に基づいて復旧用のEC2インスタンスを起動することができます。

これにより、障害発生時に複雑な手順書を参照しながら手作業でDR環境を構築する必要がなくなりオペレーションミスのリスクを低減できるほか、RTOの短縮にも寄与することができます。

また、実際の障害を想定したDRテストを本番環境へ影響を与えることなく実施できる点もメリットです。

DRテストを定期的に実施することで、設定の不備や想定外の挙動を事前に把握することができ、「使われないまま形骸化したDR環境」になることを防ぐことができます。

3-3. 幅広い対応環境への対応

AWS Elastic Disaster Recoveryは、特定のプラットフォームに依存しないDRを実現することができます。AWS上のEC2インスタンスのみならず、オンプレミスや他クラウド上のサーバーまで、幅広い環境をDR対象として統一的に扱うことが可能です。

これにより、既存のAWS環境におけるDR対策だけではなく、オンプレミス環境におけるDR対策としても利用することも可能です。

3-4. 平常時コストを抑える設計

AWS Elastic Disaster Recoveryは、平常時のコストを抑えることができます。平常時に稼働するのは、データレプリケーションに必要な最小限のEC2インスタンスと付随するストレージのみであり、本番と同等の待機系環境を常時起動しておく必要はありません。

そのため、マルチサイトやウォームスタンバイといった構成にくらべてDRにかかるコストを大幅に削減することができます。

NTT東日本では、AWSなどクラウドに関するお役立ち情報をメールマガジンにて発信していますので、ぜひこちらからご登録ください。

4. AWS Elastic Disaster Recoveryの注意点や制約

AWS Elastic Disaster Recoveryは、DR対策を現実的なコストと運用負荷で実現できる選択肢として魅力的です。しかし、すべてのシステムに無条件で導入できるわけではありません。

本章では、導入を検討する際に事前に把握しておきたい注意点や制約について整理します。

4-1. 対応OSに関する注意点

AWS Elastic Disaster Recoveryは、DR対象となるサーバーデータのレプリケーションにAWS Replication Agent（以下エージェント）を使用します。このエージェントが対応しているOSやバージョンは事前に確認する必要があります。

また、OSやバージョンが対応していても、エージェントのインストールにあたって別途対応が必要な場合もありますので注意が必要です。

なお以下のコラムでは、AWS Replication Agentインストール時にハマったポイントと対処方法を紹介しております。合わせて参考にしていただければ幸いです。

AWS Replication Agentインストール時にハマったポイントと対処方法

対応OSやバージョンは以下にまとめられていますので、合わせて参考にしてください。

Windows：Windows operating systems supported by Elastic Disaster Recovery - AWS Elastic Disaster Recovery

Linux：AWS DRS supported Linux operating systems - AWS Elastic Disaster Recovery

4-2. ネットワーク設計に関する注意点

DR対象となるサーバーはデータレプリケーションのために必要なEC2インスタンス（レプリケーションサーバー）やAWS Elastic Disaster Recoveryサービスと通信できる必要があります。特にオンプレミス環境や他クラウドからデータレプリケーションを行う際はAWS上のネットワークとの接続を確立しておく必要があります。

また、復旧後のネットワーク設計についても検討や準備が必要で、復旧環境で起動したEC2インスタンスが既存のシステムや外部サービス等と正しく通信できるよう、VPCやサブネット、セキュリティグループなどを事前に定義しておく必要があります。

ネットワーク設計を曖昧にしたまま導入を進めると「インスタンスは起動したがサービスとして利用できない」といった事態になりかねません。

4-3. アプリケーションの仕様やライセンスに関する注意点

AWS Elastic Disaster Recoveryを使用してDR時に起動するリカバリインスタンスは、DR対象となるサーバーのコピー（複製）となります。アプリケーションの仕様やライセンスなどによっては、起動した復旧用のEC2インスタンス上でアプリケーションを起動できないといった問題も発生する可能性があり、例えば弊社でクラウドリソースの監視に使用している、株式会社はてな社のMackerelというサービスでは以下のコラムのような問題が発生します。

インスタンス複製時にMackerelの監視を継続する方法～AMIからの復元やAWS Elastic Disaster Recovery利用時の注意点～

そのため、事前の仕様やライセンスなどを確認やテストが重要になります。

NTT東日本では、AWSなどクラウドに関するお役立ち情報をメールマガジンにて発信していますので、ぜひこちらからご登録ください。

5. AWS Elastic Disaster Recoveryについてのまとめ

AWS Elastic Disaster Recoveryは、平常時のリソースを最小限に抑えながら、障害発生時には迅速な復旧を実現することができるサービスです。継続的なブロックレベルのレプリケーションや復旧プロセスの自動化により、従来のDR手法と比べコストと運用負荷を抑えたDR対策が可能になります。

NTT東日本では、AWSの導入・運用をサポートするサービスを提供しています。サービスや事例をご紹介していますので、AWSによるサービス展開を検討している方は、ぜひお問い合わせください！

• Amazon Web Services（AWS）およびその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
• その他、本コラムに記載されてる会社名、サービス名、商品名は、各社の商標または登録商標です。