責任共有モデルとAWS Resilience Hub

AWS Resilience Hub は、アプリケーションにおけるレジリエンスの定義、追跡、管理を支援するために設計された AWS サービスです。このサービスでは、AWS Well-Architected のベストプラクティスを使用してワークロードのレジリエンスを理解し、改善するのに役立ちます。また、レジリエンスと運用上の推奨事項の両方を提供することで、お客様は目標復旧時点 (RPO) と目標復旧時間 (RTO) に関する組織およびワークロード毎の要件を一貫して満たすことができます。

このブログ記事では、レジリエンスのための責任共有モデルと、それが AWS Resilience Hub サービスを使用する際の考慮事項にどのように影響するかを見ていきます。

責任共有モデル

レジリエンスのための責任共有モデルについて詳しく知りたい場合は、ホワイトペーパー「 AWS におけるワークロードのディザスタリカバリ : クラウドにおける復旧」を読むことをお勧めします。以下の図は、お客様と AWS が共有する責任を示しています。AWS はクラウドのレジリエンスに責任を負い、お客様はクラウドにおけるレジリエンスに責任を負います。

図 1 – レジリエンスは AWS とお客様が分担する責任

このモデルでは、お客様が AWS Resilience Hub サービスを使用する際に配慮すべき、レジリエンスの推奨事項と運用上の推奨事項、という点を表しています。以下では、Resilience Hub ワークショップで用いられているアーキテクチャから具体例を取り上げて、これらのさまざまな側面について説明します。アーキテクチャや AWS Resilience Hub の使用方法に関する詳細情報や自習用の手順については、ワークショップのガイドに従ってください。

図 2 – AWS Resilience Hubワークショップのアーキテクチャ例

ここで使用されているアーキテクチャは、Application Load Balancer、EC2 Auto Scaling グループ内の EC2 インスタンス群、および RDS データベースで構成される 3 層アーキテクチャです。EC2 インスタンスは NAT ゲートウェイ経由のアウトバウンド接続が可能で、アプリケーションの静的コンテンツは S3 バケットに保存されます。

レジリエンスの推奨事項

AWS Resilience Hub でアプリケーションを評価した後、このサービスでは、設定した RTO/RPO の目標を達成するために、アーキテクチャ内のさまざまなワークロードコンポーネントにわたってレジリエンスの推奨事項を多数提示してくれます。すべてのRTO/RPOポリシーを実現するには、すべてのコンポーネントに関する推奨事項に取り組む必要があります。AWS Resilience Hub サービス内で管理できる潜在的な障害タイプの全リストは、レジリエンスポリシーの管理ドキュメントに記載されています。本ブログ記事では、ワークロードのデータベースに関するオプションの 2 つの推奨事項に焦点を当てます。オプション 1 は最小限の変更とコストの両方を最適化し、オプション 2 はアベイラビリティーゾーン障害時における最短の RTO/RPO を実現するように最適化します。お客様は、組織とワークロードの RTO/RPO のニーズを満たすために、どのオプションを採用するかについて、アーキテクチャ上の決定を下す必要があります。どちらのオプションも、AWS Resilience Hub で定義されているアプリケーションの設定されたポリシーを満たします。

図 3 – データベースのレジリエンスに関する推奨事項

この例では、オプション 1 を実装することを決定しました。ご覧のとおり、データベースはすでに RTO と RPO のレジリエンスポリシーを満たしていますが、新しい評価では、アベイラビリティーゾーン障害時における RTO/RPO をさらに最適化することが推奨されています。つまり、必要に応じてさらに最適化した RTO/RPO を実現できるということです。

図 4 – 推奨事項を実装した後のデータベースのレジリエンスに関する推奨事項

運用上の推奨事項

アラーム

ここでは、運用上の推奨事項に含まれるアラームセクションにおける、2 つのお客様の責任部分を見ていきます。

• 推奨アラームに必要な追加設定
• 推奨エンジンでカバーされないアラーム条件

推奨アラームに必要な追加設定

AWS Resilience Hub が推奨する推奨アラームの中には、追加の設定が必要なものがあります。以下の例では、対象の Amazon CloudWatch アラーム には CloudWatch Synthetics が必要であることがわかります。CloudWatch Synthetics を使用して、スケジュールに従って実行される設定可能なスクリプトであるカナリアを作成し、エンドポイントと API をモニタリングできます。正確な要件の詳細は、以下に示すように「前提条件」セクションに記載されています。

推奨エンジンではカバーされないアラーム条件

レジリエンス評価を実行する場合、AWS Resilience Hub はアプリケーションのレジリエンスをモニタリングするために Amazon CloudWatch アラームを設定することを推奨しています。これらのアラームは完全ではないため、アプリケーションの監視ニーズを十分に検討して、アプリケーションを完全に監視できるようにする必要があります。ベストプラクティスを満たすためのガイドとして、AWS Well-Architected フレームワーク (REL 6 : ワークロードリソースをどのように監視していますか？) を使用できます。

図 5 – アラームの前提条件

標準操作手順 (SOP)

SOPは、障害やアラームが発生した場合にアプリケーションを効率的に復旧するために設計された規範的な一連の手順です。AWS Resilience Hub は、アプリケーションコンポーネントに基づいて、準備すべき SOP を推奨します。

アプリケーションごとに要件が異なるため、AWS Resilience Hub が提供するデフォルトの AWS Systems Manager (SSM) ドキュメントのリストでは、すべてのニーズに対応できるわけではありません。ただし、デフォルトの SSM ドキュメントをコピーして、それをベースとして使用して、アプリケーションに合わせた独自のカスタムドキュメントを作成することはできます。

ドキュメントをコードベースに直接追加し、そこですべての変更を加えることで、最新のSOPをインフラストラクチャとともに確実にデプロイできます。

AWS Fault Injection Service (FIS) の実験と SSM ドキュメントを組み合わせ、CI/CD パイプラインで実行することで、SOP がワークロードに対して継続的にテストされていることがわかります。

運用準備状況レビュー (ORR) の一環として SOP レビューし、アプリケーションのニーズに合った最新の手順が整っていることを確認する必要があります。ORR のホワイトペーパーを確認して、その内容の詳細な概要を確認してください。ORR カスタムレンズに関するブログで説明されているように、AWS Well-Architected ツールを使用して ORR カスタムレンズを使用することもできます。これがどのように Well-Architected フレームワークと適合するかについては、運用上の優秀性の柱に含まれる OPS07-BP02 運用準備状況の一貫したレビューを参照してください。

Fault Injection Service (FIS) を用いた実験

ここでは、運用上の推奨事項に含まれる FIS セクションを見る際に、3 つのお客様の責任部分を見ていきます。

• 推奨される FIS 実験に必要な追加設定
• 推奨エンジンでカバーされていない FIS 要件
• 依存システムの網羅

推奨される FIS 実験に必要な追加設定

AWS Fault Injection Service (FIS) は、アプリケーションのパフォーマンス、可観測性、レジリエンスを向上させるための障害注入実験を実行する完全マネージド型のサービスです。障害注入実験を実行して、AWS リソースのレジリエンスと、アプリケーション、インフラストラクチャ、アベイラビリティーゾーン、および AWS リージョンの障害からの回復にかかる時間を測定できます。レジリエンスを測定するために、これらの障害注入実験では AWS リソースの中断をシミュレートします。中断の例としては、ネットワークが使用できないエラー、フェイルオーバー、EC2 Auto Scaling グループでのプロセスの停止、Amazon RDS でのブートリカバリ、アベイラビリティーゾーンの問題などがあります。障害注入実験が終了したら、アプリケーションがレジリエンスポリシーの RTO ターゲットに定義されている割り込みタイプから回復できるかどうかを判断できます。

AWS Resilience Hub が推奨する FIS 実験の中には、追加の設定が必要なものもあります。以下の例では、この FIS を用いた実験には既存の CloudWatch アラームが必要であることがわかります。正確な要件の詳細は、AWS Resilience Hub からの通知に記載されています。

図 6 – 追加の FIS 設定

推奨エンジンでカバーされていない FIS 要件

AWS Resilience Hub でリストされている実験はすべてを網羅しているわけではありません。利用可能な実験をワークロード要件と照らし合わせて評価する必要があります。この例では、S3、Auto Scaling グループ、RDS の実験の推奨事項と、ロードバランサーに対するネットワーク実験があります。他に実行したい実験があるかもしれません。たとえば、アプリケーションが EBS の一時的な I/O 停止をどのように処理するかを確認したい場合があります。

図7 – FISの実験

依存関係の網羅

最後に、ワークロードは組織内の他の依存関係に依存している可能性があります。レジリエントなシステムを構築するためにどのような実験が必要かについて、依存するチーム間で交渉する必要があります。AWS Resilience Hub は、関連する個々のワークロードに関する実験を推奨できますが、実験の依存関係の側面については、お客様が適切に評価して実装する必要があります。その良い例が、Well-Architected の運用上の優秀性の柱である OPS04 にあります。

オペレーショナル・インテグレーション

上で説明した考慮事項に加えて、その他の考慮事項がいくつかあります。

その他の運用要件

前のセクションで説明したように、AWS Resilience Hub の運用上の推奨事項はすべてを網羅しているわけではありません。追加のアラーム、SOP、FIS 実験が必要な場合、AWS Resilience Hub の外部でこれらを作成して維持するのはお客様の責任です。

テンプレートを使用して個別ではなくワークロード単位に統合する

AWS Resilience Hub による運用上の推奨事項はアプリケーション単位に統合される必要があります。ハードコーディングされたリソースは、顧客チームにより動的なものに置き換えることができます。AWS Resilience Hubのドキュメントには、その方法を概説した CloudFormation の例が掲載されています (AWS CloudFormation を使用して運用上の推奨事項をアプリケーションに統合する) 。

標準化されたレジリエンス戦略の出発点としてテンプレートを使用する

レジリエンス導入の第一歩として AWS Resilience Hub を使用している場合は、プラクティスを標準化することが重要です。アラーム、SOP、FIS 実験は、個々のチームだけでなく組織全体のレジリエンス戦略の一部となるはずです。既存の ORR または開発中の ORR に AWS Resilience Hub を含めると、レジリエンスの戦略を定義するのに役立ちます。

新しい推奨事項を継続的に確認する

レジリエンスと運用の両方に関する新しい推奨事項は、サービスが拡大し、追加の AWS サービスのサポートが追加されるにつれて、定期的に AWS Resilience Hub に追加されます。定期的な ORR の一環として、ワークロードの要件を継続的に評価して見直すことは、お客様の責任です。これには、AWS Resilience Hub の追加機能が含まれます。AWS Resilience Hub のアプリケーション耐性スコアを追跡することで、アラーム、SOP、FIS 実験が定期的にテストされているかどうかもわかります。詳細については、このブログ記事「 AWS Resilience Hub スコアの使用方法」を参照してください。

結論

AWS Resilience Hub を使用すると、レジリエンスの取り組みのさまざまな段階にいるお客様が、ワークロードとアプリケーションのレジリエンスを定義、追跡、管理できるようになります。お客様は、組織とワークロードの期待に応えるだけでなく、クラウドにおけるレジリエンスに対する責任もカバーするために、AWS Resilience Hub の推奨事項に加えて、どのような追加要件やリソースを実装する必要があるかを定義する必要があります。

翻訳はソリューションアーキテクトの松本が担当しました。原文はこちらです。