AWS Resilience Hub でアプリケーションの耐障害性を評価 - RTO/RPO 目標の達成状況を可視化
Resilience Hub によるアプリケーションの耐障害性評価、RTO/RPO ポリシーの設定、改善推奨事項の活用を解説します。
レジリエンス評価の必要性と Resilience Hub の位置づけ
アプリケーションの耐障害性 (レジリエンス) は、障害発生時の復旧時間 (RTO: Recovery Time Objective) と復旧可能なデータ時点 (RPO: Recovery Point Objective) で定量化されます。しかし多くの組織では RTO/RPO の目標値が曖昧であったり、現在のアーキテクチャがその目標を達成できるかの検証が行われていません。Resilience Hub はこの課題を解決し、アプリケーションの耐障害性を定量的に評価して RTO/RPO 達成状況を可視化するサービスです。CloudFormation スタック、Terraform 状態ファイル、AppRegistry に登録されたアプリケーション、または EKS クラスターからリソース構成を自動検出します。評価シナリオは AZ 障害、リージョン障害、アプリケーション障害、インフラ障害の 4 種類で、各シナリオに個別の RTO/RPO ターゲットを設定できます。検出されたリソースには EC2、RDS、DynamoDB、S3、ELB、Lambda、ECS、EKS などが含まれ、各リソースの構成 (マルチ AZ 配置、レプリケーション有無、バックアップ設定) を解析して耐障害性スコアを算出します。
レジリエンスポリシーの定義と評価の実行
Resilience Hub の利用はレジリエンスポリシーの定義から始まります。ポリシーでは各障害シナリオに対して RTO/RPO 目標を設定します。例えば「AZ 障害: RTO 1 時間、RPO 5 分」「リージョン障害: RTO 4 時間、RPO 1 時間」「アプリケーション障害: RTO 30 分、RPO 5 分」のように具体的に定義します。次にアプリケーションを登録し、CloudFormation スタック名を指定するとスタック内のリソースと依存関係が自動的にマッピングされます。評価を実行すると、各リソースの現在の設定を分析して推定 RTO/RPO を算出し、目標未達のリソースには優先度付きの改善推奨事項が提示されます。推奨の例として、シングル AZ の RDS を Multi-AZ に変更、S3 バケットのクロスリージョンレプリケーション有効化、Auto Scaling グループの最小台数引き上げ、DynamoDB のポイントインタイムリカバリ有効化などがあります。各推奨にはコスト影響と RTO/RPO 改善効果の見積もりが付記され、実装後に再評価を実行するとスコア差分が確認できます。
FIS 統合と障害テスト
Resilience Hub は FIS (Fault Injection Service) と連携し、評価結果に基づいた障害テストの推奨テンプレートを生成します。AZ 障害、EC2 インスタンスの停止、RDS フェイルオーバー、EBS I/O 一時停止、ネットワーク遅延注入などのシナリオで、アプリケーションが実際に RTO/RPO 目標を達成できるかを検証します。評価結果のスコアカードで各コンポーネントの耐障害性レベルを色別 (緑: 達成、黄: 一部未達、赤: 未達) で可視化し、改善の優先順位を明確にします。SOP (Standard Operating Procedure) の自動生成で障害発生時の対応手順を標準化し、Systems Manager Automation ドキュメントとして出力できます。評価 → 改善 → テスト → 再評価のサイクルを回すことで、アプリケーションのレジリエンスを継続的に向上させられます。 Resilience Hub について体系的に学びたい方は、関連書籍 (Amazon)も参考になります。
継続的な評価と運用統合
Resilience Hub は一度きりの評価ではなく、継続的なレジリエンス管理を支援します。アプリケーションのリソース構成が変更された場合、ドリフト検出で変更を検知し再評価を促します。EventBridge との統合で評価完了をトリガーにした通知や後続アクションを自動化でき、CI/CD パイプラインに評価ステップを組み込めばデプロイのたびに耐障害性の回帰を検出できます。Organizations 統合により、組織内の複数アカウントのアプリケーションを一元的に管理できます。評価は手動実行に加えスケジュール設定も可能で、月次や四半期の定期評価を自動化できます。
設計のベストプラクティスと落とし穴
Resilience Hub を効果的に運用するには、アプリケーション定義の粒度が重要です。モノリシックに全リソースを 1 アプリケーションにまとめるとスコアカードが煩雑になるため、ビジネスドメインやチーム単位でアプリケーションを分割し、各アプリケーションに適切な RTO/RPO ティアを割り当てます。Tier-1 (基幹系: RTO 5 分 / RPO 1 分)、Tier-2 (業務系: RTO 30 分 / RPO 1 時間)、Tier-3 (情報系: RTO 4 時間 / RPO 24 時間) のような段階を定義し、過剰設計を防ぎます。よくある落とし穴として、CloudFormation スタックに含まれないリソース (手動作成した S3 バケットや DNS レコード) が検出されない点があります。AppRegistry にリソースを登録するか、Resource Mapping で手動追加することで評価漏れを防ぎます。また、評価は静的な構成分析のため、実際の回復時間を保証するものではありません。FIS による実障害テストを併用して初めてスコアカードの信頼性を担保できます。
他の AWS サービスとの比較
耐障害性に関連する AWS サービスには AWS Backup、CloudWatch、Health Dashboard があり、それぞれ異なる役割を担います。AWS Backup はバックアップの集中管理とリストアを提供しますが、アーキテクチャ全体の耐障害性評価は行いません。CloudWatch はリアルタイムの異常検知に優れますが、RTO/RPO 目標との照合や改善推奨の生成はできません。Health Dashboard は AWS 基盤の障害通知に特化しています。Resilience Hub はこれらのサービスが提供するデータを組み合わせて、アプリケーション視点での包括的な耐障害性評価と改善ロードマップを提供する点が独自の価値です。Well-Architected Tool の信頼性ピラーとも補完関係にあり、Well-Architected Review が設計方針の定性レビューなのに対し、Resilience Hub は定量評価と具体的な改善アクションを自動化する役割を果たします。
Resilience Hub の料金
Resilience Hub の料金はアプリケーションの評価回数で課金されます。1 アプリケーションの評価あたり約 0.10 ドルで、アプリケーションの定義と RTO/RPO ポリシーの設定に追加料金は発生しません。FIS のテスト実行は別途 FIS の料金が発生します。評価対象のアプリケーションを重要度に基づいて選定し、ビジネスクリティカルなアプリケーションから優先的に導入することでコストを管理します。月次の定期評価であればアプリケーションあたりのコストは低額に収まりますが、CI/CD に組み込んで毎デプロイで評価する場合は評価回数の増加に注意が必要です。
まとめ
Resilience Hub はアプリケーションの耐障害性を定量的に評価し、RTO/RPO 目標の達成状況をコンポーネント単位で可視化するサービスです。レジリエンスポリシーで障害シナリオごとに目標を定義し、CloudFormation スタック、Terraform 状態ファイル、EKS クラスターからアーキテクチャを自動検出して 4 種類の障害シナリオで評価を実行します。改善推奨にはコスト影響の見積もりが付記され、FIS との連携で障害テストを自動化できます。ドリフト検出と CI/CD 統合で継続的な評価を実現し、アプリケーション単位の分割と RTO/RPO ティアの設計が効果的な運用の鍵となります。