いわさです。
AWS 規範ガイダンスなどを眺めていたところ「Resilience Lifecycle Framework」というガイドが AWS より提供されていることに気が付きました。
このガイドは昨年 2023 年 の re:Invent で登場した AWS Resilience Competency の中心的なリソースの一つでもあり、2023 年 10 月初版という新しいガイドです。
次の公式ドキュメントから利用することが可能です。
内容としてはそこまで多くなかったのですが、今回要点をまとめて数分で内容を把握出来るようにしてみました。
Resilience Lifecycle Framework ってなんだ？
「目標の設定」、「設計と実装」、「評価とテスト」、「運用」、「対応と学習」のライフサイクルのステップごとにレジリエンス（回復力、復元力）を向上させるためのベストプラクティスがまとめられているフレームワークです。
RTO/RPO 要件を整理して設計をしたり、マルチ AZ やマルチリージョンを意識して実装したりなど「よくやってるわ」みたいなものもあれば、Operational Readiness Review (ORR) やレジリエンスモデリングなど「これ良さそう」みたいなものもあり、とても参考になります。
このフレームワークでは以下の 5 つのステップごとにレジリエンスの観点でやれることが紹介されています。
- ステージ 1: 目標を設定する
- ステージ 2: 設計と実装
- ステージ 3: 評価とテスト
- ステージ 4: 運用
- ステージ 5: 応答して学習する
ステージ 1: 目標を設定する
そもそもレジリエンスは実装＆運用コストとのトレードオフが発生するので、どのアプリケーションのどの部分にどういうレジリエンスレベルが必要なのか目標設定を行う必要があります。
具体的なステップとしてビジネスインパクト分析（BIA）を行ったうえで、目標復旧時点 (RPO)、目標復旧時間 (RTO)、サービスレベル目標 (SLO) などの目標を設定することが紹介されています。
ビジネスインパクト分析（BIA）については次のホワイトペーパー「Disaster Recovery of On-Premises Applications to AWS」にてより詳細にプロセスが紹介されています。
ステージ 2: 設計と実装
目標を設定したら、レジリエンスを意識した設計と実装を行います。
フレームワークではこのステージで採用候補となるいくつかのサービスやガイドが紹介されています。
前ステージで設定した目標にあわせて採用を検討しましょう。
AWS Well-Architected Framework
AWS Elastic Disaster Recovery
Operational Readiness Reviews (ORRs)
レジリエンス分析フレームワーク
レジリエンスライフサイクルフレームワークと同時期に登場したフレームワークです。
このフレームワークについてはまだ DevelopersIO で紹介されていませんでした。数日中に同じようにまとめてみたいと思います！
ステージ 3: 評価とテスト
このステージでは設計・実装したワークロードを運用環境へデプロイするために行うことの出来るステップが紹介されています。
Resilience Hub でワークロードの RTO や RPO を管理し、負荷テストソリューションや AWS Fault Injection Service を活用して負荷や障害をシミュレーションすることで評価を行うことが出来ます。
AWS Resilience Hub
負荷テストソリューション
AWS Fault Injection Service (旧：AWS Fault Injection Simulator)
ステージ 4: 運用
このステージでは運用環境にデプロイしたあとにレジリエンス目標を維持出来るように運用をします。
運用中のオブザーバビリティについては通常のワークロードと同様なのですが、継続的にレジリエンスを評価することが必要です。リリースした時点だけでなく、運用中もレジリエンスレベルを維持することが必要です。
そのプロセスとして前のステージで実施したような評価を運用フェーズでも繰り返し実施することが推奨されています。
また、AWS Well-Architected フレームワークレビューを通して定期的なレビューも実施します。
更に高度なシナリオでは、ゲームデイや、運用環境でのカオスエンジニアリングも推奨されています。
本番環境におけるカオスエンジニアリングテストの重要性については次の記事でも紹介されています。
ステージ 5: 応答して学習する
このステージでは実際にインシデントが発生した際にどのように分析を行いそこから学びを得るのか、あるいはアラートの精度などを見直すことで、改善を行うためものです。
AWS Well-Architected Framework の信頼性の柱では、インシデント発生後の COE（Correct of Error）プロセスに言及されています。
フレームワーク内でもインシデント分析レポートの作成ポイントに触れられており、とてもおもしろいです。
さいごに
本日は、AWS 規範ガイダンス「Resilience Lifecycle Framework」をしっかり読まなくても雰囲気だけでも伝わるようにまとめてみました。
これからレジリエンスに取り組んでいく方は是非目を通してください。
必ずしもこれらの全てを行う必要はないのですが、それぞれのステージでどういう選択肢があるのか知っておくことは重要ですね。
一部特定のサービスが紹介されている部分はありますが、これはそのままどのパブリッククラウドにも適用できるフレームワークではないでしょうか。
17
