本日参加した「WPS301 IS your AWS GovCloud(US) architecture resilient?」というセッションで、AWS Resilience Hubというあまり聞きなじみのないサービスを触ってみたので記事にまとめました。
AWS Resilience Hub
AWS Resilience Hub は、AWS 上のアプリケーションの回復力を定義、検証、追跡するための一元的な場所を提供します。
AWSにおいて、回復性に関する推奨事項を提供する最も推奨される方法です。
RTOとRPOが最適になるよう、推奨事項を最適化し、そのためにどのような変更が必要なのかも提示してくれます。
- AWS Resilience Hub は、レジリエンシーポリシーで定義された RTO/RPO 要件を満たすためのアーキテクチャの変更を含むオプションなど、評価レポート内でレジリエンスの推奨事項を提供します。
利用方法
① レジリエンスポリシーの作成
RTOとRPOの目標を定義するポリシーを作成します。
作成済みのポリシーセットから選択することも、独自のポリシーを作成することも可能です。
② アプリケーションの追加
リソースコレクションとEKSの2つのデータソースでアプリケーションを記述可能です。
以下
- リソースコレクション:以下のうち1つからリソースを検出します。
CloudFormation スタック、AWS Resource Groups、AppRegistry アプリケーション、Terraform state filesの - EKS のみ:EKSクラスター内の名前空間のリソースを選択する場合に選択します。
- リソースコレクション & EKS:上記のどちらともからリソースを検出したい場合に選択します。
③ 評価レポートを確認
AWS Resilience Hubのアプリケーションの構造タブに移動します。
評価レポートを確認します。
AWS Resilience Hub に、アプリケーションで識別されたすべてのリソースが表示される。
AWS Resilience Hub は、レジリエンシーポリシーで定義された RTO/RPO 要件を満たすためのアーキテクチャの変更を含むオプションなど、評価レポート内でレジリエンスの推奨事項も提供されます。
④ 回復性向上のための推奨事項を確認
アプリケーションの各コンポーネントについて、AWS Resilience Hub はレジリエンス要件を満たすための推奨オプションを提示します。
また、提案されたアプリケーションアーキテクチャの変更によって追加コストが発生する可能性があるかどうかも示されます。
以下の観点からオプションは1~3つ出てくるようです。
- コストの最適化
- 最小限の変更で最適化
- アベイラビリティゾーン(AZ)のRTO/RPOのために最適化
※S3 についての以下の推定コストは、 $0 と表示されますが、このS3 バケットにはデータが保存されていないためです。AWS Resilience Hub は、予想されるコストを見積もって提供します。
⑤ リソースの設定を変更し、再評価を実行
ドリフト検出
- AWS Resilience Hub は、レジリエンスドリフト検出を提供します。この機能を使用すると、SNS トピックを介した通知をオプトインして、アプリケーションがビジネスで設定された復旧目標を満たさなくなった場合に警告を発することができます。
運用上の推奨事項
AWS Resilience Hubの運用にあたり、以下の3点が推奨されています。
アラーム
アプリケーションの正常性を監視し、指定したメトリクスがしきい値に達した場合にアラートを出すように設定しましょう。
アラームをテストして、しきい値が適切に設定されていることを確認することが重要です。
AWS Resilience Hub は、アプリケーションのレジリエンスターゲットに基づいて推奨されるアラームしきい値を提供します。
標準操作手順 (SOP)
中断が発生した場合にアプリケーションを回復するのに役立つ規範的な手順を提供します。
SOPは、アラームのトリガーとして使用可能で、特定の手順に従う必要がある場合に利用しましょう。
AWS Fault Injection Service 実験テンプレート
AWS Fault Injection Serviceは、AWS リソースに制御された中断を導入することで、アプリケーションの回復力を検証するように設計されています。
カオスエンジニアリングは、本番アプリケーションの中断に耐えられるシステムの能力に自信を持たせるために、障害をシミュレートしてシステム上で実験する分野です。AWS Resilience Hub は、アプリケーションの耐障害性を理解して改善するための優れた方法ですが、カオスエンジニアリングでは、障害に対するアプリケーションの応答を確認できるため、信頼性が高まります。中断に耐えられるという仮説が正確かどうかをテストしましょう。
おわりに
本番環境に入る前に問題を特定するために利用することが有用だと感じました。
回復性について、ダッシュボードから一元的に確認できるのは便利ですね!