AWS 上でのディザスタリカバリ (DR) 構成 4 パターン
2020-07-07AWS 認定ソリューションアーキテクト - プロフェッショナルの勉強をしている中でディザスタリカバリ (DR) に関する話が出てきたので、今回は AWS 上での DR 構成 4 パターンについて簡単にまとめてみます。
目次
ディザスタリカバリ (DR) とは
ディザスタリカバリ (disaster recovery - DR) とは、直訳すると 災害からの復旧 という意味です。 AWS では「Design for Failure」という設計原則があり、 公式ドキュメントにも次のように記載されています。
自然災害から機械的障害、人的ミスまで多岐にわたる原因により、こうした小さな障害が起こります。物理インフラストラクチャが長期間使用できない場合に備えて、稼働を継続できるようにするための予防的なクラウド災害復旧戦略が必要です。
DR 対策 4 パターン
この DR 対策には RTO 1 、 RPO 2 という要件とコストとのバランスを考慮して、どのような構成にするかを検討します。今回はその構成の例として 4 パターンについてまとめてみます。
バックアップ & リストア
定期的にシステムのバックアップを作成し、障害発生時にはバックアップからシステムを復旧する方法です。 AWS では、バックアップデータをリージョン A にある S3 に保存し、バックアップデータをリージョン B の S3 (DR 用) にレプリケートしておきます。構成イメージとしては次のようになります。
バックアップは日次や月次などのタイミングで取得することになるため、 RPO は 最終バックアップ保存時点まで となります。また、障害発生時にはバックアップデータから復元 (リストア) をするため、 RTO は 長く なります。一方で、 DR 対策のために用意するのは S3 へのバックアップだけのため、コストは 低く なります。
まとめ
- 適当なタイミングでバックアップを取得し、別リージョンにバックアップデータをレプリケート
- 障害発生時にはバックアップからリストア
- RPO は最終バックアップ時点まで
- RTO は長い
- コストは低い
パイロットライト
DR 用にスペックの低い DB を起動しておいて、通常時はデータの同期のみを行います。障害発生時には、 DR 用のリージョンでアプリケーションを起動し、 DB のスペックを上げて対応します。そして元のリージョンの復旧作業を行います。構成イメージは次のようになります。
データについては適宜 別リージョンの DB に同期するため、 RPO は 最終データ同期時点まで となります。障害発生時には DR 用のリージョンでのアプリケーション起動、 DB のスケールアップを実施する必要があるため、 RTO は やや長く なります。DR 対策のために用意するのはスペックの低い DB のみとなるため、コストは やや低く なります。
まとめ
- 別リージョンに低スペックの DB を立て、適宜データ同期
- 障害発生時には DR 用リージョンでアプリケーションを起動、 DB をスケールアップ
- RPO は最終データ同期時点まで
- RTO はやや長い
- コストはやや低い
ウォームスタンバイ
DR 用のリージョンで、スペックのみ低い同構成でシステムを常時起動しておきます。障害発生時にはアプリケーションおよび DB のスケールアップ、 Route 53 で DNS を切り替えて対応します。そして元のリージョンの復旧作業を行います。構成イメージは次のとおりです。
データについてはパイロットライトと同様になので RPO は 最終データ同期時点まで となります。障害発生時には、 DB のスケールアップとアプリケーションのスケールアップ、 DNS の切り替えをする必要があります。ただし、新たにアプリケーションを起動するわけではないので RTO は やや短く なります。一方で、低スペックとは言え同構成のシステムを別リージョンに用意する必要があるためコストは やや高く なります。
まとめ
- 低スペックで同構成のシステムを別リージョンに用意
- 障害発生時には DB とアプリケーションのスケールアップ、 DNS 切り替えを実施
- RPO は最終データ同期時点まで
- RTO はやや短い
- コストはやや高い
マルチサイト (ホットスタンバイ)
DR 用として同スペック、同構成のシステムを常時起動しておきます。障害発生時には Route 53 で DNS の切り替えのみを実施して対応します。
データについてはパイロットラン、ウォームスタンバイと同様なので RPO は 最終データ同期時点まで となります。障害発生時には DNS の切り替えのみで対応できるので、 RTO は 短く なります。しかし、別リージョンに全く同じシステム (スペック、構成) を常時起動しておく必要があるため、コストは 高く なります。
まとめ
- 同スペック、同構成のシステムを別リージョンに用意
- 障害発生時には DNS の切り替えのみ実施
- RPO は最終データ同期時点まで
- RTO は短い
- コストは高い
まとめ
AWS 上での DR 構成 4 パターンについてまとめてみました。
RTO、RPO とコストの兼ね合いについては DR 対策を講じる対象のシステムの性質や重要性によって議論が必要になるので、実際に DR 対策をする場合にはそのあたりの数値をしっかりと決めて置く必要がありそうです。
試験対策としては、各パターンのメリット・デメリット、長所・短所を理解して問題文からどのパターンが最適なのかを判断できるようにしておきたいと思います。
参考
comments powered by Disqus