AWS Resilience Hub を使ったRTOとRPOの検証と改善

“Everything fails, all the time （故障しないものは無い）” とは、Amazon.com のバイスプレジデント兼最高技術責任者、ワーナー・ヴォゲルス氏の有名な言葉です。アプリケーションを設計および構築するときの一般的な目標は、アプリケーションを機能させることであり、次は、どのような障害が発生しても実行し続けることです。耐障害性を実現することは重要ですが、まずそれをどのように定義するか、そしてアプリケーションの耐障害性を判断するためにどの指標を使用するかを検討する必要があります。耐障害性は、RTO（目標復旧時間）およびRPO（目標復旧時点）と呼ばれる指標によって定義できます。RTO は、停止後にアプリケーションがどれだけ早く回復できるかを示す指標であり、RPO は、アプリケーションが許容できるデータ損失の最大量を示す指標です。

アプリケーションの RTO と RPO を設定する方法の詳細については、“Establishing RTO and RPO Targets for cloud applications” を参照してください。

AWS Resilience Hub は2021年11月に開始された新しいサービスです。このサービスは、AWSクラウド上のアプリケーションの耐障害性を定義、検証、追跡するのに役立つように設計されています。

アプリケーションの耐障害性ポリシーを定義することができます。これらのポリシーには、アプリケーション、インフラストラクチャ、アベイラビリティーゾーン、および、リージョンの障害に対する RTO と RPO の目標が含まれます。Resilience Hub の評価では、AWS Well-Architected フレームワークのベストプラクティスを使用しています。コンピューティング、ストレージ、データベース、ネットワークなどのアプリケーションのコンポーネントを分析し、潜在的な耐障害性の弱点を明らかにします。

このブログでは、Resilience Hub が 4種類の障害についてコンポーネントレベルで RTO と RPO を検証し、アプリケーションスタック全体の耐障害性を向上させるのに役立つ方法について説明します。

1. 顧客のアプリケーションの RTO と RPO
2. クラウドインフラストラクチャの RTO と RPO
3. クラウドインフラストラクチャのアベイラビリティーゾーン (AZ) 障害
4. AWS リージョンの障害

顧客のアプリケーションの RTO と RPO

アプリケーションの停止は、インフラストラクチャスタック（ハードウェア）が正常であるのに、アプリケーションスタック （ソフトウェア）が正常ではない場合に発生します。この停止は、構成変更、不適切なコードのデプロイ、インテグレーションの失敗などが原因である可能性があります。アプリケーションスタックの RTO と RPO の決定は、アプリケーションのクリティカル性と重要性、および、コンプライアンス要件によって異なります。たとえば、ミッションクリティカルなアプリケーションの RTO と RPO が 5 分であるとします。

例：クリティカルなビジネスアプリケーションが Amazon Simple Storage Service (Amazon S3) バケットからホストされ、リージョン間のレプリケーションやバージョニングを行わずにセットアップされました。図1 は、RTO と RPO の目標を 5分とした場合に、そのアプリケーションの RTO と RPO では回復不能であることを示しています。

評価を実行すると、図2 に示すように、Resilience Hub は Amazon S3 バケットのバージョニングを有効にする様に推奨事項を提示します。

バージョニングを有効にすると、推定される RTO が 5分、RPO が 0秒になります。バージョニングにより、バケットに保存されているオブジェクトの任意のバージョンを保存、取得、復元できるため、アプリケーションの耐障害性が向上します。

Resilience Hub は、推奨事項の実装に関連するコストも提供します。この場合、Amazon S3 バケットのバージョニングを有効にしても費用はかかりません。オブジェクトの各バージョンには、通常の S3 料金が適用されます。同じオブジェクトのバージョンはいくつでも保存できるため、バージョニングを利用する予定がある場合は、有効期限切れと削除のロジックを実装することをお勧めします。

Resilience Hubは、コスト、高可用性、変更を最小限にする、などの要件を満たすために、 1つまたは複数の推奨事項を提供できます。図2 に示すように、S3 バケットにバージョニングを追加すると、高可用性の最適化と、最小限の変更で実現可能な最善のアーキテクチャの両方が満たされます。

クラウドインフラストラクチャの RTO と RPO

クラウドインフラストラクチャの停止は、インフラストラクチャの基盤となるコンポーネントにハードウェア障害などが起きたときに発生します。コンポーネントの障害が原因で部分的な機能停止が発生したシナリオを考えてみましょう。

たとえば、ミッションクリティカルなアプリケーションのコンポーネントの1つが、Elastic Compute Cloud (EC2) インスタンス上で実行される Amazon Elastic Container Service (ECS) で、目標とするインフラストラクチャの RTO と RPO が 1秒であるとします。図3 は、1秒という目標とするインフラストラクチャの RTO を達成できないことを示しています。

図 4 は、複数のアベイラビリティーゾーンに AWS Auto scaling グループと Amazon ECS キャパシティプロバイダーを追加するという Resilience Hub の推奨事項を示しています。

AWS Auto Scaling はアプリケーションを監視し、容量を自動的に調整して、可能な限り低いコストで安定して予測可能なパフォーマンスを維持します。Amazon ECS キャパシティプロバイダーは、クラスターが使用するタスクのインフラストラクチャを管理するために使用されます。クラスターに登録されているAmazon EC2インスタンスを自動的に管理するために、AWS Auto Scaling グループを使うことができます。Resilience Hub の推奨事項を適用すると、推定される RTO と RPO はほぼ 0秒で、変更後の推定コストは月額 16.98 USD になります。

AWS インフラストラクチャのアベイラビリティーゾーン (AZ) 障害

AWS グローバルインフラストラクチャは、高可用性 (HA) を実現するために AWS リージョンとアベイラビリティーゾーンを中心に構築されています。AWS リージョンには、物理的に分離され独立した複数のアベイラビリティーゾーンがあり、低レイテンシー、高スループット、冗長性の高いネットワークで接続されています。

たとえば、プライベートサブネット上のインスタンスがアウトバウンドトラフィックをインターネットに送信できるように、シングル AZ にパブリック NAT ゲートウェイをセットアップしました。Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを複数のアベイラビリティーゾーンにデプロイしました。

図5 は、アベイラビリティーゾーン障害からは回復不能であり、アベイラビリティーゾーンの RTO 目標を満たしていないことを示しています。NAT ゲートウェイはフルマネージドサービスであり、管理するハードウェアがないため、インフラストラクチャ障害に対する耐障害性（RTO 0秒）に優れています。もし NAT ゲートウェイを構成しているアベイラビリティーゾーンがダウンすると、他のアベイラビリティーゾーンにデプロイされたリソースはインターネットにアクセスできなくなります。

図6 は、対応する EC2 リソースが配置されている各アベイラビリティーゾーンに NAT ゲートウェイをデプロイするという Resilience Hub の推奨事項を示しています。

Resilience Hub の推奨に従えば、アベイラビリティーゾーン障害の発生時に RTO と RPO を最小の 0秒に抑え、アベイラビリティーゾーンに依存しないアーキテクチャを 月額 32.94 USD で稼働するように構築できます。

NAT Gateway を複数の AZ にデプロイすることで、アベイラビリティーゾーン障害時の RTO/RPO を最小に抑え、コストを最小限に抑え、変更も最小に抑えることができるため、3つのオプション全てで推奨事項は同じとなっています。

AWS リージョンの障害

AWS リージョンは、地理的に離れた複数の独立した AZ で構成されます。この設計により、最大限の耐障害性と安定性が実現されます。複数のデータセンターの停止または地域的なサービス停止のリスクを含む災害発生時に、AWS のリージョン全体に影響を及ぼす可能性のある自然災害や技術災害を軽減するために、マルチリージョンの災害復旧戦略を検討するのがベストプラクティスです。ワークロードが使用する 1つ以上のリージョンまたはリージョン内のサービスが利用できない場合、この種の障害はセカンダリリージョンに切り替えることで解決できます。マルチリージョンに依存するアプリケーションがある場合は、リージョンの RTO と RPO の定義が必要になる場合があります。

たとえば、グローバルなミッションクリティカルアプリケーションの一部としてシングル AZ 構成の Amazon RDS for MySQL を使用している場合に、4種類の障害タイプすべてに対して RTO 30 分 と RPO 15 分と設定したとします。各 RDS インスタンスは、ストレージに Amazon Elastic Block Store (Amazon EBS) ボリュームを使った Amazon EC2 インスタンス上で実行されます。RDS はデータベースのスナップショットを毎日作成し、そのスナップショットはバックグラウンドで耐久性のある Amazon S3 に保存されます。また、トランザクションログを最大 5分間隔で定期的に S3 にコピーして、必要に応じてポイントインタイムリカバリできるようにします。

基盤となる EC2 インスタンスに障害が発生した場合、RDS は自動的に同じアベイラビリティーゾーンで新しいインスタンスを起動し、EBS ボリュームをアタッチして回復を試みます。このシナリオでは、RTO は数分から数時間までさまざまとなります。その復旧時間は、データベースのサイズ、および、障害と回復の方法によって異なります。回復可能なインスタンスに障害が発生した場合、EBS ボリュームが回復される為、RPO はゼロになります。アベイラビリティーゾーン障害が発生した場合は、ポイントインタイムリカバリを使用して別のアベイラビリティーゾーンに新しいインスタンスを作成できます。シングル AZ では、リージョン障害に対する保護は提供されません。図7 は、リージョンに対する RTO 30分、RPO 15分は達成できないことを示しています。

図8 に示すように、Resilience Hub は、アベイラビリティーゾーン障害に対処し、費用対効果を高め、変更を最小限に抑えるために最適化すべき 3つの推奨事項を提示しています。

推奨事項 1「アベイラビリティーゾーン (AZ) の RTO/RPO に合わせて最適化」: このオプションで推奨される変更は、アベイラビリティーゾーン障害発生時の RTO と RPO を可能な限り低く抑えるのに役立ちます。シングル AZ 構成の RDS に対して、Resilience Hub は、アベイラビリティーゾーン障害時に目標とする RTO と RPO を達成するために、データベースを Aurora に変更し、同じリージョンにリードレプリカを 2つ追加することを推奨しています。また、リージョン障害に対する耐障害性を実現するために、リードレプリカを別のリージョンに追加することも推奨しています。図8 に示すように、これらの変更にかかる推定コストは、月額 66.85 USD です。

Amazon Aurora リードレプリカは、元のデータベースインスタンスと同じデータボリュームを共有します。Aurora は、データを失うことなくフェイルオーバーを完全に自動化することで、アベイラビリティーゾーン障害に対処します。Aurora は、複数の AZ にわたる同期レプリケーションにより、可用性の高いデータベースクラスターを作成します。Aurora は、複数の AZ にわたる同期レプリケーションにより、可用性の高いデータベースクラスターを作成します。これは、データのバックアップがクリティカルな考慮事項となる本番データベースにより適した選択肢であると考えられます。

推奨事項 2「コストの最適化」: これらの変更により、目標とする RTO と RPO を満たしながら、コストを最小限に抑えることができる様にアプリケーションを最適化できます。ここでの推奨事項は、シングル AZ 構成の Amazon RDS を維持した上で、プライマリリージョンにリードレプリカを作成し、セカンダリまたは別のリージョンに追加のリードレプリカを作成することです。これらの変更にかかる推定コストは、月額 54.38 USD です。リージョン障害中に、プライマリ DB インスタンスに障害が発生したり、接続できなくなった場合に、災害復旧 (DR) ソリューションとしてリードレプリカをスタンドアロンインスタンスに昇格させることができます。

推奨事項 3「変更を最小限に抑えるための最適化」: これらの変更は、実装の変更を最小限に抑えながら、目標とするRTOとRPOを達成するのに役立ちます。Resilience Hub は、マルチ AZ ライターとマルチ AZ リードレプリカを 2つの異なるリージョンに作成することを推奨しています。この変更にかかる推定コストは、月額 81.56 USD です。マルチ AZ 構成のデータベースインスタンスをプロビジョニングすると、Amazon RDS は自動的にプライマリデータベースインスタンスを作成し、データを別のアベイラビリティーゾーンのスタンバイインスタンスに同期的に複製します。インフラストラクチャに障害が発生した場合、Amazon RDS はスタンバイデータベースインスタンスへ自動的にフェイルオーバーします。データベースインスタンスのエンドポイントはフェイルオーバー後も同じままなので、アプリケーションは手動で管理作業を行うことなくデータベースの操作を再開できます。

3つの推奨事項はすべて、30分という目標とするアプリケーションの RTO と RPO を達成するのに役立ちますが、推定コストと労力は異なる場合があります。

まとめ

回復力のあるワークロードを構築するには、適切なベストプラクティスを実施する必要があります。この記事では、Resilience Hub が提供する推奨事項を使用して、ビジネスアプリケーションの耐障害性を向上させ、アプリケーション、インフラストラクチャ、アベイラビリティーゾーン、および、リージョンの障害に対して目標とする RTO と RPO を達成する方法を示しました。詳細を確認して自分でサービスを試すには、AWS Resilience Hub のページをご覧ください。

翻訳はプロフェッショナルサービス本部の川上が担当しました。原文はこちらです。