AWS Resilience Hub のワークショップをやってみました。動いているシステムに対して設定した RTO/RPO が守れているのか、評価、検証するのに面白かったので紹介します。
AWS Resilience Hub ? 聞いたことあるような、ないような、そんな私でも完走できる充実したワークショップでした。
どんなワークショップなの？
以下のリンクとほぼほぼ同じ内容の AWS 主催のワークショップに参加しました。
ワークショップは以下の環境に対して Resilience Hub で定義した RTO/RPO に従い、Resilience Hub で設定した RTO/RPO を満たしているか評価、改善を進めるといった内容です。
構成図をみると NAT Gateway が片方の AZ にしかなく「あー、そういうことね」という環境なのですが、この環境を評価できるのが Resilience Hub です。自分で「あー、そういうことね」と思えなても Resilience Hub が教えてくれます、こんな感じで。
RTO/RPO を守れていない違反している項目について何がいけないのかまで教えてくれます。NAT Gateway をマルチ AZ 構成に変更しなさいとアドバイスくれます。また、リソース追加に伴う追加料金の目安まで出してくれます。
その他にはあえて障害を起こすために AWS Fault Injection Simulator（FIS）も利用します。FIS も試してみたかったという方は学べることが多く楽しめる内容だと思います。ワークショップを完走するまで2時間弱みておけばよろしいかと思います。
ワークショップをやっていく
私の参加したワークショップは EC2 + RDS もろもろの環境デプロイ済みでしたので Resilience Hub の操作からスタートでした。
Resilience Hub 初期設定
Resilience Hub の画面から耐障害性ポリシー作成します。
耐障害性ポリシーはどの程度の RTO/RPO を想定しているか決めます。プリセットで用意されているミッションクリティカルを選択しました。
アプリケーションの RTO/RPO と、インフラの RTO/RPO が設定されました。システム全体として一色単に考えず、アプリケーションと、インフラで分けて考えられています。という説明の座学も受けました。
アプリケーションを追加していきます。Resilience Hub が指すアプリケーションとは CloudFormation でデプロイした AWS リソース全体が該当します。
CloudFormation スタックを選択して Resilience Hub に登録します。
本当は有効化が推奨ですが Workshop なので無効化しています。
スタックから生成されたリソースが読み込まれました。除外設定もできるますが全リソースを対象としています。
ここで先程作成したポリシーを選択します。
Resilience Hub で評価できるソースは？
主要なところでは AWS CloudFormationスタック（CDK, SAM を含む）、Terraform ステートファイルでした。その他では、AWS Resource Groups 、AppRegistryアプリケーションが使えるそうです。基本 IaC が前提ですね。
- ステップ 3: AWS Resilience Hub アプリケーションにリソースを追加する - AWS Resilience Hub
- AWS Resilience Hub でアプリケーションのレジリエンスを測定、改善 | Amazon Web Services ブログ
診断
CloudFormation でデプロイしたリソース一式をアプリケーションとして Resilience Hub で管理されました。そのアプリケーションの耐障害性を評価します。
実行します。
レポートが作成されるまで待ちます。
1-2分で結果が表示されました。結果はポリシー違反でした。仮になにかしらのインシデントが発生した場合、ポリシーに定義された目標とする RTO/RPO 内でリカバリできないことを意味しています。
レポート名（ Assessment-report-hoge）をクリックすると詳細を確認できます。
どの項目が設定した RTO/RPO を満たせないのか表示されています。おもしろいです。
別タブには推奨される対応方法が表示されます。
項目選択すると理由が表示されます。S3 バケットはバージョニング未設定でした。
案の定 NAT Gateway はマルチ AZ 構成でないと指摘されていました。
推奨設定へ変更
ワークショップですので必要な設定に変更できるテンプレートが用意されいました。なんなら IaC の CI/CD も完備されており、CodeCommit に pushしたらCloudFormation スタック更新までかかります。各リソースの設定変更を行うのは、本ワークショップ本質的なところではないので充実した内容です。
再評価
スタックを更新し、必要な設定変更が適用されました。Resilienc Hub はアプリケーションの再読み込みが必要です。
NAT Gateway 2台目を確認できます。そして、新バージョンを発行します。
発行します。
再評価をクリックして新規レポート作成します。
ポリシーに合致し、無事設定した RTO/RPO を満たす構成となりました。真ん中２つのレポートは新バージョンの発行をし忘れた状態で再評価した結果です。すると、中途半端にレポート結果が変わり、NAT Gateway だけがマルチ AZ 構成ではないと指摘されたレポートとなりました。とにかくリソースに変更があったら新バージョンを発行するのが大切なアクションです。
レポート結果はオールグリーンです。
最終的にデプロイした構成した以下となりました。NAT Gateway 以外も細かいところでいろいろと問題はありました。
運用上の推奨事項
ダメな点の指摘だけではなく、運用改善に繋がるガイダンスも提供されます。推奨設定を入れる CloudFormation テンプレートを出力できるとのことでやっていきます。
Alarms はアプリケーションが正常な状態になるこことを監視するもので、特定のメトリクスが設定した基準を超過した場合にアラートを飛ばします。 Standard Operating Procedures (SOP) はアラームやサービス停止状態に陥った際に効率的に復旧させるための手順を定義したものです。 Fault injection experiment templates は AWS リソースの障害をシミュレーションすることで、アプリケーションの回復性に対するストレス検証を行うためのものです。
設定のテンプレートを出力します。
作成します。
標準運用手順も同様にテンプレートを作成します。
故障注入実験テンプレートも同様です。
テンプレートタブに出力結果が表示されました。
CloudFormation テンプレートは S3 に保存されていたので、S3 からダウンロードしました。
ダウンロードしたテンプレートは CloudFormation からデプロイしました。ハンズオン用に一部パラメータを編集する必要がありました。CloudFormation テンプレートが JSON で出力されるので編集はし辛いです。
CloudWatch Alarm のしきい値など、ハンズオン用ではなかったとしても編集して利用することが想定されています。JSON で出力されることは認識しておきましょう。
Fault Injection Simulator でカオスエンジニアリング
Resilienc Hub のアプリケーションの項目からから FIS を実行できます。伊達に Hub を名乗っていません。FIS のテンプレート自体は先のダウンロードしたテンプレートをデプロイして作成されたものです。RDS のフェイルオーバーを起こす障害を注入していきます。
実環境に手を加えるので確認画面がでます。
RDS のフェイルオーバーが起きるのでしょうか？
RDS を確認すると再起動中でした。強制的にフェイルオーバーがかけられています。
優秀なのですぐに利用可能になりました。
CloudWatch Synthetics 実行していた Canary がフェイルオーバーのタイミングで一度失敗しています。Canary も Resilience Hub から出力した CloudFormation テンプレートで設定したものです、便利ですね。
もう一方の障害注入も実行しました。こちらは CPU 負荷を上げるものです。
ガンガン負荷がかかっています。こちらの CloudWatch Alarm 設定も Resilience Hub から出力した CloudFormation テンプレートで設定したものです。
Resilience Hub から出力した CloudFormation テンプレートで設定された標準対応手順を使います。Auto Scaling グループの EC2 の待機数を変更する内容のものでした。
実行します。
必要パラメータをセットすると、Auto Scaling グループの EC2 の待機数を変更作業を System Manager からできます。
2個しかないキャパシティが
3個になりスケールアウトしました。
CPU 使用率をみてオートスケールすればいいんじゃないんですか？というツッコミはおいておいて、用意された運用手順を実行して障害回復までもっていけるという仕組みが用意されていることを覚えておきましょう。
IaC の CI/CD に組み込む
CloudFormation スタック更新時に RTO/RPO の設定値を満たさない変更が入ったら困りますよね。Resilience Hub のチェックを CI/CD に組み込めます。CodePipeline で体験してみます。スタックを更新して新規の S3 バケットをバージョンニング未設定で追加でデプロイしました。
設定した RTO/RPO 満たせていないリソース（バージョンニング未設定 S3 バケット）の追加はチェックに失敗しました。
このあと正常にパイプラインを通るコードをデプロイし直してワークショップは終わりです。
おわりに
記録用にメモを残しながらで2時間弱かかりました。私の参加したワークショップでは初期構築が終わっていたことを考慮すると、同じく2時間弱みておけば一通り試して学べるかと思います。
2023/9/6追記手作りリソースでもタグ付けをちゃんとしていれば Resilience Hub で評価できるとのことです。
Resilience Hub で評価できるソースは基本 IaC で管理されたリソースです。最低限 IaC で運用できないと Resilience Hub を活用できないです。
3
