AWS Resilience Hubを触ってみました。

初めに

AWS Resilience Hubのコンソルに接続します。まだ日本語の支援はしてないので全部英語になっていますね。AWS Resilience Hubを使用する前に対象になるリソースをCloudFormationで作成しました。

今回、対象になるアプリケーションの構成です。

シングルAZの上にPublic SubnetとPrivate Subnetが立てています。Public Subnetにはアプリケーションが起動する1つのEC2インスタンスとNat Gatewayが立ててあり、Private Subnetには1つのRDSインスタンスが立てている構成です。それではAWS Resilience Hubを使って復旧性を確認してみます。

アプリケーション追加

アプリケーションを追加するための四つのステップがあります。

1. Discover application structure

「Add application」ボタンを クリックして対象のアプリケーションを指定する画面に入ります。事前に作成したCloudformationスタックを指定します。今回は一つのスタックでリソースを作成しましたが、各リソース別のスタックがある場合、最大5つのスタックを指定することが可能です。

定期評価を行うScheduled assessmentオプションがあります。このオプションについて日間隔で評価を行うと説明していますが、詳細の内容は確認できませんでした。今回はテストなので一応無効化にします。

2. Identify resources

選択したスタックで評価対象になるリソース識別します。基本、評価対象でInclude状態ですが、Include resource, Exclude resource ボタンで評価する対象リソースを指定することが可能です。

3. Select policy

Select policy ステップではリソースに適用するポリシーを設定します。作成されているポリシーがあればそれを使っても大丈夫ですし新しいポリシーを作成してもいいです。私は「Create resiliency policy」ボタンを押して新しいポリシーを作成します。

DRや可用性などの知識がないと想定して、AWSから提供しているポリシーで作成します。Critical Application Tierポリシーを選択しました。

作成が完了できたら、Select policy画面に戻って作成したポリシーを設定して次のステップに行きます。

4. Review and publish

ここでは設定した内容を確認します。間違ったところがなかったら「Publish」ボタンを押してアプリケーションの追加を完了します。

アプリケーション評価

正常的にアプリケーションが追加されたらアプリケーションの評価ができます。Workflowの「Run new resiliency assessment」で新しい評価を実行します。

評価が終わると、その結果を簡単に確認できます。私は「ポリシー違反」結果が出ました。評価を行ったアプリケーションのRTO・RPOが設定したポリシーのRTO・RPOを満たすことができなかったという意味です。具体的な内容を確認するためレポートをクリックします。

結果レポート確認

結果レポートを確認します。レポート画面では簡略したレポートの結果と評価各項目の詳細な結果を確認できます。そして復旧性・運用上に関するAWS Resilience Hubの推薦も確認することが可能です。

まず、評価された項目の簡略な結果を確認します。

ECインスタンスのようなハードウェア側の問題が発生した状況を意味する「(Cloude)Infrastructure」のRTOの予測は１時間40分でポリシーで目標とした1時間より40分長いです。そして一つ以上のAZが使用できない状況を意味する「(Cloude)Availability Zone」は復旧不可能で予測されていますので「ポリシー違反」結果になりました。

次は各項目に関する詳細なことも確認します。Infrastructureに問題が発生するとdatabaseappcommponent(RDS)のRTOが1時間40分で予測されています。

「Availability Zone」にはdatabaseappcommponentとnetworkingappcomponentにポリシー違反があります。名前をクリックして詳細な情報を確認できます。そして予測した理由も確認できます。

networkingappcomponentの場合、NAT Gatewayが1つしか存在しないので復旧不可能（unrecoverable）に予測されました。そして、databaseappcommponentのRTO１時間40分の根拠はRDSバックアップから復旧されるまでの予想時間のことを確認できました。

推奨する復旧力事項

ポリシーを満たせる推奨事項を確認します。AWS Resilience Hubは3つの最適化方法を推薦しています。AZ中断の間、一番低いRTO・RPOが達成可能な推奨、コストを考慮した推奨、最小限の変更推奨です。

RDS に関して、シングルAZ→マルチAZへの変更を推奨しています。マルチAZに変更すると、各1時間40分、2分、2分の現在のRTOが5分、０、０に大幅に改善できますよね。評価したアプリケーションが単純な構成をしているのでAWS Resilience Hubが全部同じ最適化方法を推薦していると思います。

しかし、少し変なところがありました。「Estimated cost」は現在と変更後のコストを比較した項目です。Resilience Hubが構成を変更しても増えるコストが０だと話していますが、マルチAZ構成はPrimary 1, Standby 1 2台のDBインスタンスが必要になるので、1台のシングルAZ構成よりコストが高いはずです。推奨を適用する前にユーザー側でしっかり確認した方が良さそうです。

推奨する運用事項

運用上に必要なアラーム、SOP(Standard Operating Procedures)、AWS Fault Injection Simulatorを利用する故障注入実験ができるCloudFormationテンプレートを作成することが可能です。作成されたテンプレートは自動的にS3バケットに保存され、そのまま使えます。

アプリケーション修正

AWS Resilience Hubの推奨通りアプリケーションを修正しました。復旧力のためにマルチAZ設定の有効化とリソースがあるAZごと1つのNAT Gatewayをマネージドコンソールで作成しました。

修正が済ましたらAWS Resilience Hubに戻ってアプリケーションをアップデートします。

Workflowのステップ1でRepublishを行います。アップデート方法で「CloudFormationスタックのアップデート」と「Add resource」があります。スタックの変更がなかったのでリソースを手動で追加して、ステップ２の再評価を行います。

評価の結果は成功しました！

まとめ

AWS Resilience Hubを触ってみました。新しくリリースされたサービスなのでまだ情報が多くではないですが、使い方は難しくなかったと感じました。

私も復旧力に関して知識がないので、AWS側で提供しているポリシーはすごく良かったです。

AWS Resilience Hubはすごく有用だと思いました。私が間違ったかもしれませんが、推奨事項に関する予想コストが確実ではないことは気を付ける必要があると思います。

そして推奨事項でユーザーの状況を考慮した3つの方法を提案してくれて、ユーザー親和性が高いサービスだと感じられました。運用上に必要な設定はただの推奨だけではなくCloudFormationテンプレートまでダウンロードできるので、開発に関する時間もたくさん短縮できると思いました。

参照

https://docs.aws.amazon.com/ja_jp/resilience-hub/latest/userguide/what-is.html