Amazon Web Services ブログ
事業継続性が求められる基幹システムの DR 戦略
こんにちは。ソリューションアーキテクトの平井です。
本記事では、基幹システムに AWS を検討されている方に、事業特性として重視される可用性を実現するための AWS 構成パターンと、その前提となる AWS グローバルインフラストラクチャの基本的なポイントをご紹介します。
はじめに
事業の中核となる業務には事業継続性が求められます。卸売業を例にあげると、必要な時に、必要な場所へ商品を届けるために、常に商品の在庫を切らさないことが求められます。生活や健康に欠かせない商品では、地震や台風、津波などの自然災害が発生した場合においても物流網を途切らせないために、全国に配備された物流センターの間での相互補完や、物流センター自体の自家発電装置の設置、免震構造の採用といった対策が取られています。
表：卸売業における災害対策の例
| 分類 | 対策の例 |
|---|---|
| 物流センター間 | ・商品供給体制の補完 |
| 物流センター | ・非常用自家発電装置の設置 ・免震構造の採用 |
このような卸売業を支える基幹システムは、物流網を途切らせないために稼働し続けることが求められます。サーバの冗長化に加えて、自然災害対策としてのデータセンターの冗長化が取られています。
様々な理由（※）から AWS のクラウドを検討されますが、基幹系システムにおいては、上記にあげた要件を実現する構成が求められます。要件に基づいて構成を検討する必要性は、卸売業に限りません。
※：AWS のクラウドを選ばれたお客様の理由については、AWS の クラウドが選ばれる 10 の理由 でまとめています。
AWS グローバルインフラストラクチャ
構成パターンについて議論する前に、前提となる AWS グローバルインフラストラクチャについて紹介します。ここで押さえておくべきポイントは、リージョンとアベイラビリティーゾーンです。AWS グローバルインフラストラクチャの詳しい内容や最新の情報については、グローバルインフラストラクチャ でまとめています。
AWS におけるリージョンはデータセンターが集積されている世界中の物理的ロケーションです。2022年3月時点では全世界で26リージョン展開されており、国内では東京と大阪リージョンが利用できます。リージョンは、アベイラビリティーゾーン（AZ）と呼ばれる1つ以上のデータセンターで構成されていて、データセンターは冗長的な電力源やネットワークを備えています。各 AZ は、数kmから100km以内に配置されていて、AZ 間は高スループットかつ低レイテンシーの冗長化、暗号化されたネットワークで結ばれています。
AZ 間で冗長構成とることによって、可用性の高いシステムを簡単に構築できます。システム起因の問題だけでなく、停電、落雷、竜巻、地震などの問題からより安全に隔離され保護されます。
DR 戦略検討時に確認すべきこと
いきなり構成パターンを検討するのではなく、まず以下について整理します。
- システムとして対策すべき災害や障害と AWS グローバルインフラストラクチャにおける影響範囲
- システムとして対策すべき範囲における復旧の要件と復旧シナリオ
システムとして対策すべき災害と AWS グローバルインフラストラクチャにおける影響範囲
停電や洪水、地震といった災害のうち、システムとして何を対象とするか整理します。その上で、対象とする災害や障害の AWS グローバルインフラストラクチャにおける影響範囲を明らかにします。例えば、落雷による停電であれば、個別の電力源が用意されているAZが影響範囲と考えられます。可用性を実現する構成の方向性としては、同じリージョンの中の異なる AZ でどう構成を組むかがポイントとなります。一方で、例えば関東一帯が影響範囲となるような災害の場合は、複数の AZ 、つまりリージョンが影響範囲になるので、異なるリージョンとの間でどう構成を組むかがポイントなります。大阪リージョンが候補となりますが、影響範囲が関東一帯ではなく国内の大部分といった場合も対象とする場合、国外のリージョン（例えばシンガポールや、アメリカのオハイオなど）が候補となります。
| 想定する災害（例） | 影響範囲 | 対策の方向性 |
|---|---|---|
| 落雷による停電 | AZ | 異なるAZとの間でどう構成を組むか |
| 関東一帯が影響を受ける災害 | リージョン | 大阪リージョンを含む別リージョンとの間でどう構成を組むか |
| 日本国内の大部分が影響を受ける災害 | リージョン | 国外のリージョン（例：シンガポール）との間でどう構成を組むか |
AWS グローバルインフラストラクチャで説明した通り、システムを AZ 間で冗長構成をとる、いわゆるマルチ AZ 構成によって、データベースといったシステム構成要素の障害に対する可用性だけでなく、AZ 単位の障害を引き起こす自然災害にも有効であるといえます。
システムとして対策すべき範囲における復旧の要件と復旧シナリオ
可用性を考慮した構成検討には要件の明確化が必須ですが、復旧の要件として以下の2つを整理します。
- どの時点までデータを戻す必要があるか（RPO：Recovery Point Objective、目標復旧時点）
- システムの復旧にどれぐらい時間をかけられるか（RTO：Recovery Time Objective、目標復旧時間）
要件を実現するための構成、つまり復旧シナリオは、RPO 、RTO によって変わりますが、一般的な復旧シナリオと、その考え方としては以下の4パターンに分類できます。平常時は単一のメインサイト（単一のリージョン）で基幹システムとしてサービスを提供するアクティブ/パッシブと、複数のサイトでリクエストを受け付けてサービスを提供するアクティブ/アクティブに大別されます。
システムとして対策すべき範囲に対して、復旧シナリオを検討していきます。冒頭例に挙げた卸売業の基幹系システムでは、地震や台風、津波などの自然災害が発生した場合においても、物流網を途切らせないためにシステムとしても動作し続けることが求められます。したがって、マルチ AZ 構成による可用性の確保を土台として、リージョン単位の影響範囲となる災害からの復旧シナリオを整理するのが良いです。
可用性を実現するためのAWS構成パターン
システムの前提として、アプリケーションサーバとデータベース（DB）から構成される Web システムとします。まず、マルチ AZ 構成について説明してから、リージョンに跨った復旧シナリオを実現する構成について、アクティブ/パッシブのバックアップリストア、パイロットライト、ウォームスタンバイに焦点をあてます。
補足：ホットスタンバイについても選択肢となりますが、期待される要件と、リアルタイムに反映するための同期レプリケーションがアプリケーションのレイテンシーに及ぼす影響も考慮して検討してください。
マルチ AZ 構成
下図は、マルチ AZ 構成のイメージ図です。異なる AZ に配置されたアプリケーションサーバ（Web/AP）に対して、ロードバランサーを介して接続します。データベース（DB）も異なる AZ にまたがって配置し、データレプリケーションによって、マスターが動作する AZ が利用不能になった場合にも、システムとしてサービスを提供することができます。DB について、マネージドリレーショナルデータベースサービスであるAmazon Relational Database Service（Amazon RDS）を利用すると、マルチ AZ の構成やバックアップの取得を簡単に実現することができます。
また、アプリケーションとしての障害（例：リリース不備によるデータ更新誤り）に対する復旧手段として、バックアップも取得します。AWS Backup を使用することで、バックアップの一元化と自動化が可能です。
マルチリージョン構成：バックアップ・リストア
マルチリージョン構成のバックアップ・リストアですが、バックアップに利用するAmazon Simple Storage Service（Amazon S3）の機能を利用することで、DR サイトとなる別リージョンにバックアップをコピーできます。Web/AP サーバはインスタンスのイメージや画像や動画などのコンテンツを、DB サーバはスナップショットをバックアップとして取得します。バックアップの取得頻度は、RPO に基づき決定します。
リージョン利用不能時、DR サイトとなる別リージョンのバックアップをリストアし、エンドユーザからのアクセスは DNS レコードを本番サイトから DR サイトで切り替えることでシステムを復旧します。AWS CloudFormation により DR サイトでセットアップする環境を事前にテンプレート化しておくと、RTO を短くして復旧作業のミスを防ぐことができます。
マルチリージョン構成：パイロットライト
パイロットライトは、平常時はコアサービスとして、障害時にその他のサービスを起動する復旧シナリオです。コアサービスについて、DB のみ常時運用するケースがあげられます。
DR サイトとなる別リージョンへの DB のデータコピー方法ですが、Amazon RDS の場合はクロスリージョンリードレプリカを利用することができます（利用可能なデータベースエンジンはこちらをご確認ください）。その他、データベースマネジメントシステムや、Amazon Database Migration Service などによるレプリケーションを利用できます。
リージョン利用不能時、DR サイトではリードレプリカをソース DB に昇格させます。その他の手順についてはバックアップ・リストアと変わりませんが、DB のリストアが不要になるため、短い所要時間（RTO）が期待できます。また、レプリケーションによりデータを常時コピーしているため、より少ないデータの消失（RPO）も期待できます。
マルチリージョン構成：ウォームスタンバイ
ウォームスタンバイは、規模を縮小してはいるものの平常時からメインサイトと同等機能を持ち、障害時に必要なリソースに拡張する復旧シナリオです。平常時の構成として、アプリケーションサーバは1台、DB はデータレプリケーションに必要な最小リソースが考えられます。
リージョン利用不能時は、必要なリソースに拡張する以外の、パイロットライトで実施するアプリケーションサーバや DB に対する接続の設定や Amazon Machine Image(AMI) からのアプリケーションサーバの作成といった作業は不要となります。これにより、より短い復旧時間（RTO）が期待できます。
まとめ
本記事では、可用性の高いシステムを AWS で実現するための構成例を、前提となる AWS クラウドの特徴を紹介した上で説明しました。より詳しい災害対策の設計方法については、AWS でのディザスタリカバリ (DR) アーキテクチャと題したブログシリーズで説明しています。パート1はこちらです。また、オンプレミス環境のシステムと専用ネットワーク接続である AWS Direct Connect を介して連携したい場合は、AWS Direct Connect の回復性に関する推奨事項 が参考になります。
実際に構築されるシステムが災害発生時においても可用性の要件を満たして機能するためには、定期的なテストによる切り替えの訓練を行い、運用プロセスを含む継続的な改善活動が重要です。また、本記事では可用性に焦点を当てましたが、事業を機会損失なく、安全に、経済合理性を満たして運営していくためには、システムに対して可用性以外にも性能やセキュリティ、コスト最適化、サステナビリティといった要素が求められるはずです。
AWS では、AWS のソリューションアーキテクトとお客さまが長年にわたり数多くの経験から作り上げたクラウド最適化を検討するためのベストプラクティスを、AWS Well-Architected としてまとめています。AWS Well-Architected フレームワークを利用することで、皆様のシステムを AWS のベストプラクティスに照らし合わせ、一貫した基準でアーキテクチャを評価し改善領域を見つけることが可能です。戦略的な将来のアーキテクチャの検討に是非ご活用ください。