みなさん、こんにちは。サニービュー事業部の小寺です。
今日はデータレジリエンスのワークショップをre:Inventで受けた繋がりで、今更ながらAWS Resilience Hubを触ってみたお話です。
AWS Resilience Hubは2021年11月にGAになったサービスです。
AWS Resilience Hubとは
特に不透明な外部環境の中では、災害が発生した場合でも、お客様のために中断されることのない継続的なサービス提供が不可欠なアプリケーションも多いかと思います。止まると困る・・。よって、回復力のあるアプリケーションの構築と管理はビジネス継続といった観点でニーズが高いものですが、そのニーズに応えるべく障害に備えておくことも同様に不可欠です。
ソフトウェアやコードを参照して、アプリケーションのダウンタイムがないようにするだけでなく、アプリケーションをホストするために必要なネットワーク、データベース、仮想マシンなどで構成されるインフラストラクチャ スタック全体の構成の考慮も必要です。
システムの回復力をモニタリングすることは、災害やその他のインシデントが発生した場合でも、その堅牢性を確保するのに役立ちます。
みなさん、お馴染みアプリケーション堅朗性を評価するために使用される2つの観点があります。
● 目標復旧時間 (RTO): 障害から回復するのに必要な時間
● 目標復旧時点 (RPO): 事故が発生した場合に、データが失われる可能性のある最大時間枠。
このAWS Resilience Hubを利用すると、ビジネスのニーズとアプリケーションを考慮して、2 つのメトリックを秒、分、時間、または日で測定できます。
単に測定するだけではなく、特徴に記載しているPDCAを回していかに堅牢性の高いアプリケーションに改善していかプロセス改善も含めてクリアにしてくれるサービスです。
AWS Resilience Hubの特徴
AWS Security HubがAmazon GuardDuty・Inspectorなどのセキュリティー関連サービスを利用するように、AWS Resilience HubはAWS Fault Injection Simulator、AWS CloudFormation、AWS Systems Manager、Amazon CloudWatchなどの他のAWSサービスを利用してアプリケーションの復旧力を検査、勧奨事項、テストなどを行います。
AWS Resilience Hubの重要機能は下記の通りです。
・アプリケーションの追加
クロスリージョンスタックやクロスアカウントスタックなど、AWS CloudFormation を使用してアプリケーションを追加することができます。
・RTO・RPO定義（復旧力ポリシー設定）
アプリケーションの回復ポリシーを定義します。ここでは、アプリケーション、インフラストラクチャ、アベイラビリティーゾーン、およびリージョンの中断に対する RTO および RPOの復旧力のポリシーを定めます。
・復旧性評価
復旧性の評価については、AWS Well-Architected Framework のベストプラクティスを使用して、アプリケーションのコンポーネントを分析し、潜在的な回復力でどこの箇所に弱みがあるのかが評価できます。
評価後は課題になっている箇所に対してのの実用的なレコメンドが提供されます。
回復力の評価では、アプリケーションに関する AWS Systems Manager ドキュメントとして復旧手順を作成するのに役立つコードスニペットも生成されます。
このSystems Managerドキュメントは、標準作業手順書 (SOP) と呼ばれるものです。SOPから推奨される Amazon CloudWatch モニターとアラームのリストが生成され、アプリケーションをデプロした後に、 アプリケーションの回復体制について、運用側にも通知されるようになります。
・定期的テストや検証機能
アプリケーションを本番稼働環境にリリースする前に、目標とするRPO、RTOををアプリケーションが満たしているか定期的に検証する機能があります。
カオスエンジニアリングサービスである AWS Fault Injection Simulator (FIS) サービスと統合されているので、アプリケーションが定義された回復目標内に回復することを検証するため、実際の障害のフォールトインジェクションシミュレーションを行うことができます。
※カオスエンジニアリングサービスである AWS Fault Injection Simulator についての過去記事はこちら。
・モニタリング
サービスのダッシュボードから全体のアプリケーションポートフォリオの回復ステータスに表示を確認することができます。
Amazon CloudWatch や AWS Fault Injection Simulator などのサービスから、回復イベント (利用できないデータベースやレジリエンス検証の失敗など)、アラート、インサイトを集約してくれています。
AWS Resilience Hubを試してみる
(1)コンソール画面からダッシュボードにアクセスします。
(2)「アプリケーションを追加」をクリックします。
(3)アプリケーション名を入力し、「アプリケーション構造」から対象のアプリケーション内リソースを選びます。
以下の5つから選ぶことができます。
・CloudFormationスタック
・リソースグループ
・AppRegistry
・Terraform状態ファイル
・既存のアプリケーション
(3)スケジュールされた評価として。毎日のスケジュール評価をアクティブにするかどうかを選びます。
※デフォルトでは毎日のスケジュールされた評価がアクティブになっています。
(4)リソースを特定で、（3）で追加したアプリケーションが追加されていることを確認して、「次へ」をクリックします。
(5)ポリシーを選択画面で、耐障害性ポリシーの作成ができます。
まず作成方法として好きな「ポリシー」を作る方法と「推奨されるポリシーに基づいてポリシーを選択」の2つから選ぶことができます。
(6)今回は「推奨されるポリシーに基づいてポリシーを選択」を選んでみました。
(7)推奨される耐障害性ポリシーとして以下の7つから選ぶことができます。
・Non Critical Application
・Important Application
・Critical Application
・Global Critical Application
・Mission Critical Application
・Global Mission Critical Application
・Foundational Core Service
(8)今回は「Foundational Core Service」にしてみました。「作成」をクリックします。
(9)先ほど作成したポリシーを選んで、「次へ」をクリックします。
(10)内容を確認して、「発行」をクリックします。
(11)無事にアプリケーションが発行されました。次に「耐障害性を評価」をクリックします。評価レポートが自動的に作成されます。
(12)「評価」タブをみてみると「耐障害性評価」の箇所では、「コンプライアンスステータス」が「ポリシー違反」になっていました。
(13)詳細を確認するためにレポートを選択します。 ダッシュボードには、リージョン、アベイラビリティーゾーン、インフラストラクチャ、およびアプリケーションレベルのインシデントで予想される RTO/RPO がポリシーとどのように比較されるかが示されます。
(14)「耐障害性に関するレコメンデーション」では、アプリケーションのコンポーネントが耐障害性ポリシーに準拠しているかどうかがわかります。
(15)「オペレーションに関するレコメンデーション」では、アラーム、SOP、FIS 実験を設定して、アプリケーションの耐障害性を高めることを推奨しています。
(16)レコメンデーションをセットアップをクリックすると、FIFSやSOPに基づく実験が実行されます。
本記事ではここは実行せずに、アプリの堅朗性の確認までを範囲としました。
料金
Resilience Hubで測定したいアプリケーションの数に基づいて、課金される仕組です。Resilience Hub は 6 か月間、最大3つのアプリケーションを無料で試すことができます。その後、Resilience Hub の料金はアプリケーションあたり月額 15.00 USDの料金がかかります。正式な料金はこちらから。
※耐障害性評価を実行すると、他サービスの利用が自動的に開始されます。Resilience Hub はCloudWatch アラームなどのサービスをプロビジョニングする場合があるため、追加料金が適用される場合があることにご注意ください。
まとめ
いかがでしたでしょうか。今日はAWS Resilience Hubを使ってみました。
ミッションクリティカルなシステムをAWS上で稼働させている方は最初は3つまで無料なので、ぜひ検証されてみてはいかがでしょうか。
