クラウド内での災害対策オプション

AWS 内で利用できる災害対策戦略は、コストが低くて複雑さが少ないバックアップ作成から、複数のアクティブなリージョンを使用したより複雑な戦略まで、4 つのアプローチに大別できます。災害対策戦略を定期的にテストして、必要なときに自信を持って実行できるようにすることが重要です。

図 6 - 災害対策戦略

高可用性の Well-Architected ワークロードに対する災害イベントが、1 つの物理データセンターの中断や喪失に伴うものである場合、災害対策として必要なのはバックアップと復元のアプローチのみである場合があります。災害の定義が、物理データセンターの中断や喪失を超えてリージョンの災害にまで及ぶ場合、または定義を必要とする規制要件の適用対象である場合は、パイロットライト、ウォームスタンバイ、またはマルチサイト アクティブ/アクティブを検討する必要があります。

バックアップと復元

バックアップと復元は、データの損失や破損を軽減するために適したアプローチです。このアプローチは、他の AWS リージョンにデータをレプリケートしてリージョンの災害を軽減したり、1 つのアベイラビリティーゾーンにデプロイしたワークロードの冗長性の欠如を軽減したりするためにも使用できます。データに加えて、インフラストラクチャ、設定、アプリケーションコードを復旧先のリージョンに再デプロイする必要があります。インフラストラクチャをエラーなく迅速に再デプロイするには、AWS CloudFormation や AWS Cloud Development Kit (AWS CDK) などのサービスを通じて常に Infrastructure as Code (IaC) を使用してデプロイする必要があります。IaC を使用しないと、復旧先のリージョンにワークロードを復元することが複雑になり、復旧時間が長くなって RTO を超えるおそれがあります。ユーザーデータに加えて、Amazon EC2 インスタンスの作成に使用する Amazon マシンイメージ (AMI) など、コードと設定も必ずバックアップしてください。AWS CodePipeline を使用すると、アプリケーションコードと設定の再デプロイを自動化できます。

図 7 - バックアップと復元のアーキテクチャ

AWS のサービス

ワークロードのデータに対しては、バックアップ戦略を定期的または継続的に実行する必要があります。バックアップを実行する頻度によって、達成できる復旧時点が決まります (RPO を満たすように調整する必要があります)。バックアップは、バックアップを作成した時点に復元する方法も提供する必要があります。ポイントインタイムリカバリによるバックアップは、以下のサービスとリソースを通じて利用できます。

Amazon Simple Storage Service (Amazon S3) では、Amazon S3 クロスリージョンレプリケーション (CRR) を使用して、オブジェクトを継続的に DR 用リージョンの S3 バケットに非同期的にコピーするとともに、保存したオブジェクトのバージョニングを提供して復元ポイントを選択できます。データの継続的レプリケーションには、データのバックアップ時間が最短 (ゼロに近い) という利点がありますが、データの破損や悪意のある攻撃 (不正なデータ削除など) などの災害イベントから保護できない場合があります。ポイントインタイムバックアップもできません。継続的レプリケーションについては、「パイロットライト向けの AWS のサービス」セクションで説明しています。

AWS Backup は、以下のサービスとリソースに対して AWS のバックアップ機能を設定、スケジュール、モニタリングするための一元化された場所を提供します。

AWS Backup は、リージョン間でのバックアップのコピー (災害対策リージョンへのコピーなど) をサポートしています。

Amazon S3 データの追加の災害対策戦略として、S3 オブジェクトのバージョニングを有効にします。オブジェクトのバージョニングは、削除や変更のアクションの前に元のバージョンを保持することで、アクションの結果から S3 内のデータを保護します。オブジェクトのバージョニングは、人為的なミスに伴う災害への有効な軽減策となります。S3 レプリケーションを使用してデータを DR 用リージョンにバックアップしている場合、デフォルトでは、レプリケート元バケットでオブジェクトが削除されると、Amazon S3 はレプリケート元バケットにのみ削除マーカーを追加します。このアプローチは、DR 用リージョンのデータをレプリケート元リージョンでの悪意のある削除から保護します。

データに加えて、ワークロードの再デプロイと目標復旧時間 (RTO) の達成に必要な設定とインフラストラクチャもバックアップする必要があります。AWS CloudFormation では、Infrastructure as Code (IaC) を提供し、ユーザーがワークロード内のすべての AWS リソースを定義して、複数の AWS アカウントや AWS リージョンに確実にデプロイおよび再デプロイできるようにします。ワークロードで使用する Amazon EC2 インスタンスを Amazon マシンイメージ (AMI) としてバックアップできます。AMI は、インスタンスのルートボリュームと、インスタンスにアタッチされたその他の EBS ボリュームのスナップショットから作成します。この AMI を使用して、復元したバージョンの EC2 インスタンスを起動できます。AMI のコピーはリージョン内またはリージョン間で行うことができます。または、AWS Backup を使用して、バックアップをアカウント間でコピーしたり、他の AWS リージョンにコピーしたりできます。クロスアカウントバックアップ機能は、内部関係者による脅威やアカウントの侵害などの災害イベントからの保護に役立ちます。AWS Backup は、EC2 バックアップに他の機能も追加します。インスタンスの個々の EBS ボリュームに加えて、AWS Backup は、インスタンスタイプ、設定済みの仮想プライベートクラウド (VPC)、セキュリティグループ、IAM ロール、モニタリング設定、タグなどのメタデータも保存および追跡します。ただし、この追加メタデータは、EC2 バックアップを同じ AWS リージョンに復元する場合にのみ使用します。

災害対策用リージョンにバックアップとして保存したデータは、フェイルオーバー時に復元する必要があります。AWS Backup には復元機能がありますが、現在、スケジュールされた復元や自動復元は利用できません。AWS SDK を使用して AWS Backup の API を呼び出すと、DR 用リージョンへの自動復元を実装できます。これを定期的に繰り返すジョブとして設定したり、バックアップが完了するたびに復元をトリガーしたりできます。次の図は、Amazon Simple Notification Service (Amazon SNS) と AWS Lambda を使用した自動復元の例を示しています。

図 8 - バックアップの復元とテスト

パイロットライト

パイロットライトアプローチでは、あるリージョンから別のリージョンにデータをレプリケートし、コアワークロードインフラストラクチャのコピーをプロビジョニングします。データベースやオブジェクトストレージなど、データのレプリケーションとバックアップをサポートするために必要なリソースは常に稼働しています。アプリケーションサーバーなどの他の要素は、アプリケーションコードや設定とともにロードされますが、オフに切り替えられ、テスト時または災害対策フェイルオーバーの起動時にのみ使用されます。バックアップと復元のアプローチとは異なり、コアインフラストラクチャは常に利用可能であり、アプリケーションサーバーをオンに切り替えてスケールアウトすることで、フルスケールの本番環境を迅速にプロビジョニングできます。

図 9 - パイロットライトのアーキテクチャ

パイロットライトアプローチでは、アクティブなリソースを最小限に抑えて災害対策の継続的なコストを最小化します。コアインフラストラクチャの要件がすべて揃っているため、災害発生時の復旧は簡素化されます。この復旧オプションでは、デプロイ方法を変更する必要があります。各リージョンに対してコアインフラストラクチャの変更を行い、ワークロード (設定、コード) の変更を各リージョンに同時にデプロイする必要があります。このステップを簡素化するには、デプロイを自動化し、Infrastructure as Code (IaC) を使用して複数のアカウントやリージョンにインフラストラクチャをデプロイします (インフラストラクチャ全体をプライマリリージョンにデプロイし、スケールダウン/オフに切り替えたインフラストラクチャを DR 用リージョンにデプロイします)。最高レベルのリソースとセキュリティの分離を実現するために、リージョンごとに異なるアカウントを使用することをお勧めします (認証情報の侵害が災害対策計画の一部である場合も)。

このアプローチでは、データ災害も軽減する必要があります。継続的なデータレプリケーションは、いくつかの種類の災害からユーザーを保護しますが、保存データのバージョニングやポイントインタイムリカバリのオプションも戦略に含めていない限り、データの破損や破壊からユーザーを保護することはできません。レプリケートしたデータを災害リージョンでバックアップして、同じリージョンにポイントインタイムバックアップを作成できます。

AWS のサービス

「バックアップと復元」セクションで説明した AWS のサービスを使用してポイントインタイムバックアップを作成することに加えて、パイロットライト戦略では次のサービスも検討してください。

パイロットライトでは、DR 用リージョン内のライブデータベースやデータストアへの継続的なデータレプリケーションが、RPO を低く抑えるための最善のアプローチです (前述のポイントインタイムバックアップに加えて使用する場合)。AWS では、以下のサービスとリソースを使用して、データをクロスリージョンで継続して非同期的にレプリケートできます。

継続的レプリケーションでは、データのバージョンを DR 用リージョンでほぼ即座に利用できます。実際のレプリケーション時間は、S3 オブジェクト用の S3 レプリケーション時間制御 (S3 RTC) や、Amazon Aurora Global Database の管理機能などのサービス機能を使用してモニタリングできます。

フェイルオーバーして災害対策用リージョンから読み取り/書き込みワークロードを実行する場合は、RDS リードレプリカをプライマリインスタンスに昇格させる必要があります。Aurora 以外の DB インスタンスの昇格は、完了するまでに数分かかり、昇格プロセスの一部として再起動が必要です。クロスリージョンレプリケーション (CRR) と RDS によるフェイルオーバーでは、Amazon Aurora Global Database を使用するといくつかの利点があります。グローバルデータベースは、専用のインフラストラクチャを使用し、アプリケーションでデータベースを全面的に利用できるようにします。また、セカンダリリージョンへのレプリケーションに伴うレイテンシーは、一般的に 1 秒未満 (AWS リージョン内では 100 ミリ秒未満) です。Amazon Aurora Global Database を使用すると、プライマリリージョンでパフォーマンスの低下や停止が発生し、リージョン全体が停止した場合でも、1 分以内にセカンダリリージョンの 1 つを昇格させて読み取り/書き込みの責任を引き継ぐことができます。昇格は自動化することが可能であり、再起動は不要です。

DR 用リージョンには、コアワークロードインフラストラクチャのスケールダウンしたバージョン (リソースの数が少ないか、サイズが小さい) をデプロイする必要があります。AWS CloudFormation を使用すると、インフラストラクチャを定義し、これを AWS アカウントや AWS リージョン全体に一貫してデプロイできます。AWS CloudFormation では、事前定義された擬似パラメータを使用して、デプロイ先の AWS アカウントや AWS リージョンを特定します。したがって、CloudFormation テンプレートに条件ロジックを実装して、スケールダウンしたバージョンのインフラストラクチャのみを RD 用リージョンにデプロイできます。EC2 インスタンスのデプロイでは、Amazon マシンイメージ (AMI) がハードウェア設定やインストール済みソフトウェアなどの情報を提供します。必要な AMI を作成する Image Builder パイプラインを実装し、これらをプライマリリージョンとバックアップリージョンの両方にコピーできます。これにより、これらのゴールデン AMI は、災害発生時にワークロードを新しいリージョンに再デプロイまたはスケールアウトするための万全の備えを提供します。Amazon EC2 インスタンスは、スケールダウンした設定 (プライマリリージョンよりも少ないインスタンス数) でデプロイされます。休止状態を使用すると、EC2 インスタンスを停止状態にできます。この場合、EC2 の費用は発生せず、使用したストレージに対してのみ支払います。EC2 インスタンスを起動するには、AWS コマンドラインインターフェイス (CLI) または AWS SDK を使用してスクリプトを作成できます。インフラストラクチャをスケールアウトして本番トラフィックをサポートするには、「ウォームスタンバイ」セクションの「AWS Auto Scaling」を参照してください。

パイロットライトなどのアクティブ/スタンバイ設定では、すべてのトラフィックの送信先は最初にプライマリリージョンであり、プライマリリージョンが使用できなくなると、送信先が災害対策用リージョンに切り替わります。AWS のサービスの使用を検討する場合、2 つのトラフィック管理オプションがあります。最初のオプションは、Amazon Route 53 を使用することです。Amazon Route 53 を使用すると、1 つ以上の AWS リージョンにある複数の IP エンドポイントを 1 つの Route 53 ドメイン名に関連付けることができます。次に、そのドメイン名の下にある適切なエンドポイントにトラフィックをルーティングできます。Amazon Route 53 ヘルスチェックは、これらのエンドポイントをモニタリングします。これらのヘルスチェックを使用すると、トラフィックが正常なエンドポイントに確実に送信されるように DNS フェイルオーバーを設定できます。

2番目のオプションは、AWS Global Accelerator を使用することです。AnyCast IP を使用すると、1 つ以上の AWS リージョンにある複数のエンドポイントを同じ静的 IP アドレスに関連付けることができます。AWS Global Accelerator は、そのアドレスに関連付けられた適切なエンドポイントにトラフィックをルーティングします。Global Accelerator ヘルスチェックは、エンドポイントをモニタリングします。AWS Global Accelerator は、これらのヘルスチェックを使用して、アプリケーションの正常性を自動的にチェックし、ユーザートラフィックを正常なアプリケーションエンドポイントにのみルーティングします。Global Accelerator は、広範な AWS エッジネットワークを利用して、できるだけ早く AWS ネットワークバックボーンにトラフィックを送信するため、アプリケーションエンドポイントへのレイテンシーが短縮されます。また、Global Accelerator は DNS システム (Route 53 など) で発生する可能性のあるキャッシュの問題も回避します。

CloudEndure Disaster Recovery

CloudEndure Disaster Recovery は、AWS Marketplace から利用でき、基盤となるサーバーのブロックレベルレプリケーションを使用して、サーバーがホストするアプリケーションとサーバーがホストするデータベースを任意のソースから AWS に継続的にレプリケートします。CloudEndure Disaster Recovery により、AWS クラウドをオンプレミスのワークロードとその環境の災害対策用リージョンとして使用できます。また、AWS がホストするワークロードが EC2 (RDS ではない) でホストされているアプリケーションとデータベースのみで構成されている場合、これらのワークロードの災害対策にも使用できます。CloudEndure Disaster Recovery はパイロットライト戦略を使用し、ステージングエリアとして使用されている Amazon Virtual Private Cloud (Amazon VPC) に、データのコピーとオフに切り替えたリソースのコピーを保持します。フェイルオーバーイベントがトリガーされると、ステージングされたリソースを使用して、復旧場所として使用されているターゲット Amazon VPC にフル容量のデプロイが自動的に作成されます。

図 10 - CloudEndure Disaster Recovery アーキテクチャ

ウォームスタンバイ

ウォームスタンバイアプローチでは、本番環境のスケールダウンしたバージョンではあるが、完全な機能を備えたコピーを別のリージョンに確保します。このアプローチは、パイロットライトの拡張であり、別のリージョンでワークロードが常に稼動しているため、復旧までの時間が短縮されます。また、このアプローチでは、より簡単にテストを実行したり、継続的なテストを実装したりできるため、災害から復旧する能力に自信を深めることができます。

図 11 - ウォームスタンバイアーキテクチャ

注意: パイロットライトとウォームスタンバイの違いは理解しにくいかもしれません。どちらの場合も、プライマリリージョンのアセットが DR 用リージョンの環境にコピーされます。両者の違いは、パイロットライトは最初に追加のアクションを実行しないと要求を処理できないのに対し、ウォームスタンバイは (縮小した容量レベルで) トラフィックを即座に処理できる点です。パイロットライトアプローチでは、サーバーの「起動」、場合によっては追加 (コア以外) のインフラストラクチャのデプロイ、スケールアップが必要ですが、ウォームスタンバイでは、スケールアップのみが必要です (すべてはデプロイ済みで、既に実行されています)。RTO と RPO のニーズに応じて、これらのアプローチのいずれかを選択してください。

AWS のサービス

ウォームスタンバイでも、「バックアップと復元」と「パイロットライト」で取り上げたすべての AWS のサービスを、データのバックアップ、データのレプリケーション、アクティブ/スタンバイのトラフィックルーティング、EC2 インスタンスを含むインフラストラクチャのデプロイに使用します。

AWS Auto Scaling は、AWS リージョン内の Amazon EC2 インスタンス、Amazon ECS タスク、Amazon DynamoDB スループット、Amazon Aurora レプリカなどのリソースをスケールするために使用します。Amazon EC2 Auto Scaling は、AWS リージョン内のアベイラビリティーゾーン全体で EC2 インスタンスのデプロイをスケールし、そのリージョン内での回復性を提供します。Auto Scaling を使用して、パイロットライト戦略またはウォームスタンバイ戦略の一環として、DR 用リージョンを実稼働能力にスケールアウトします。例えば、EC2 の場合は、Auto Scaling グループで目的の容量設定を増やします。この設定を手動で調整するには AWS Management Console を使用します。自動で調整するには、AWS SDK を使用します。または、新しい目的の容量値を使用し、AWS CloudFormation テンプレートを再デプロイして調整します。AWS CloudFormation のパラメータを使用すると、CloudFormation テンプレートをより簡単に再デプロイできます。実稼働容量へのスケールアップを制限しないように、DR 用リージョンのサービスクォータが十分に高く設定されていることを確認してください。

マルチサイト アクティブ/アクティブ

マルチサイト アクティブ/アクティブまたはホットスタンバイ アクティブ/パッシブ戦略の一環として、ワークロードを複数のリージョンで同時に実行できます。マルチサイト アクティブ/アクティブでは、デプロイ先のすべてのリージョンからのトラフィックを処理します。一方、ホットスタンバイでは、1 つのリージョンからのトラフィックのみを処理し、他のリージョンは災害対策専用として使用します。マルチサイト アクティブ/アクティブアプローチの場合、ユーザーはデプロイ先のすべてのリージョンでワークロードにアクセスできます。これは、災害対策として最も複雑でコストのかかるアプローチですが、適切なテクノロジーを選択して実装することで、ほとんどの災害で復旧時間をほぼゼロにまで短縮できます (ただし、データが破損した場合は、バックアップに依存する必要があり、通常は復旧時点がゼロ以外になります)。ホットスタンバイでは、アクティブ/パッシブ設定を使用し、ユーザーは単一のリージョンにのみ誘導され、DR 用リージョンにはトラフィックが送信されません。ほとんどのお客様にとって、第 2 リージョンで完全な環境を立ち上げる場合は、アクティブ/アクティブ設定を使用する方が合理的です。一方、ユーザートラフィックの処理に両方のリージョンを使用したくない場合は、ウォームスタンバイを使用する方がより経済的で、運用上の複雑さも軽減されます。

図 12 - マルチサイト アクティブ/アクティブアーキテクチャ (ホットスタンバイの場合は 1 つのアクティブパスを非アクティブに変更)

マルチサイト アクティブ/アクティブの場合、ワークロードは複数のリージョンで実行されるため、このシナリオではフェイルオーバーなどはありません。この場合の災害対策テストでは、リージョンの喪失に対するワークロードの反応に注目します。トラフィックのルーティング先が障害の発生したリージョンから移り、 他方のリージョンですべてのトラフィックを処理できるかを確認します。 データ災害に対するテストも必要です。バックアップと復旧は、依然として必要であり、定期的にテストする必要があります。また、データの破損、削除、または難読化を伴うデータ災害の復旧時間は常にゼロより長くなり、復旧点は常に災害の検出前の特定の時点になることにも注意してください。ほぼゼロの復旧時間を維持するために、マルチサイト アクティブ/アクティブ (またはホットスタンバイ) アプローチに伴う追加の複雑さやコストが必要である場合は、セキュリティを維持し、人為的エラーを防止して人為的災害を軽減する追加の工夫が必要になります。

AWS のサービス

ここでも、「バックアップと復元」、「パイロットライト」、「ウォームスタンバイ」で取り上げたすべての AWS のサービスを、データのバックアップ、データのレプリケーション、アクティブ/アクティブのトラフィックルーティング、EC2 インスタンスを含むインフラストラクチャのデプロイとスケーリングに使用します。

前述のアクティブ/パッシブのシナリオ (パイロットライトとウォームスタンバイ) では、Amazon Route 53 と AWS Global Accelerator の両方を使用して、ネットワークトラフィックをアクティブなリージョンにルーティングできます。アクティブ/アクティブ戦略の場合は、これらの両方のサービスを使用して、どのユーザーをどのアクティブなリージョンエンドポイントに誘導するかを決定するポリシーの定義も有効にします。AWS Global Accelerator では、各アプリケーションエンドポイントに送信するトラフィックの割合を制御するトラフィックダイヤルを設定します。Amazon Route 53 は、このパーセンテージアプローチに加えて、地理的近接性やレイテンシーベースのポリシーなど、他の利用可能な複数のポリシーをサポートしています。Global Accelerator は、AWS エッジサーバーの広範なネットワークを自動的に活用し、トラフィックを AWS ネットワークバックボーンにできるだけ早くオンボーディングしてリクエストのレイテンシーを短縮します。

この戦略のデータレプリケーションにより、RPO はほぼゼロになります。Amazon Aurora Global Database などの AWS のサービスでは、専用のインフラストラクチャを使用し、アプリケーションでデータベースを全面的に利用できるようにします。また、1 つのセカンダリリージョンへのレプリケーションに伴うレイテンシーは、一般的に 1 秒未満になります。アクティブ/パッシブ戦略では、書き込みはプライマリリージョンに対してのみ行われます。アクティブ/アクティブとの違いは、アクティブな各リージョンへの書き込みを処理する方法の設計にあります。ユーザーの読み取りは、最寄りのリージョンで処理するように設計するのが一般的です。これはローカルな読み取りと呼ばれます。書き込みには、いくつかのオプションがあります。

AWS CloudFormation は、複数の AWS リージョンの AWS アカウント間でインフラストラクチャを一貫してデプロイするための強力なツールです。AWS CloudFormation StackSets は、この機能を拡張し、1 回の操作で複数のアカウントやリージョンにわたって CloudFormation スタックを作成、更新、または削除できるようにします。AWS CloudFormation では YAML または JSON を使用して Infrastructure as Code を定義しますが、AWS Cloud Development Kit (AWS CDK) では、使い慣れたプログラミング言語を使用して Infrastructure as Code を定義できます。コードは CloudFormation に変換された後で、AWS にリソースをデプロイするために使用されます。