翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 評価レポートのレビュー
評価レポートはアプリケーションの **[評価]** ビューにあります。
**評価レポートを検索するには**
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** で、アプリケーションを選択します。
1. **「評価**」タブで、**「障害耐性評価」セクションから評価**レポートを選択します。
レポートを開くと、以下のようになります。
+ 評価レポートの概要
+ 障害耐性を向上させるための推奨事項。
+ アラーム、SOP、テストの設定に関する推奨事項
+ タグを作成して管理し、 AWS リソースを検索してフィルタリングする方法
## 評価レポート
このセクションでは、評価レポートの概要を示します。 は、各中断タイプと関連するアプリケーションコンポーネントを AWS Resilience Hub 一覧表示します。また、実際の RTO ポリシーと RPO ポリシーを一覧表示し、アプリケーションコンポーネントがポリシー目標を達成できるかどうかを判断します。
**概要**:
アプリケーションの名前、障害耐性ポリシーの名前、およびレポートの作成日が表示されます。
**検出されたリソースドリフト**
このセクションでは、公開されたアプリケーションの最新バージョンに含まれた後に追加または削除されたすべてのリソースを一覧表示します。**入力ソースの再インポート** を選択して、入力ソースタブのすべての入力**ソース** (ドリフトしたリソースを含む) を再インポートします。**発行と評価**を選択して、更新されたリソースをアプリケーションに含め、正確な耐障害性評価を受け取ります。
ドリフトした入力ソースは、以下を使用して識別できます。
+ **[論理 ID]** - リソースの論理 ID を示します。論理 ID は、 AWS CloudFormation スタック、Terraform 状態ファイル、myApplications アプリケーション、または 内のリソースを識別するために使用される名前です AWS Resource Groups。
+ **変更** – 入力リソースが**追加**または削除されたかどうかを示します****。
+ **[ソース名]** - リソース名を示します。ソース名を選択すると、それぞれのアプリケーションで詳細が表示されます。手動で追加した入力ソースの場合、リンクは使用できません。たとえば、 AWS CloudFormation スタックからインポートされるソース名を選択すると、 のスタックの詳細ページにリダイレクトされます AWS CloudFormation。
+ **[リソースタイプ]** - リソースタイプを示します。
+ **アカウント** – 物理リソースを所有する AWS アカウントを示します。
+ **[リージョン]** – リソースがある AWS リージョンを示します。
**RTO**
アプリケーションが障害耐性ポリシーの目標を満たす見込みがあるかどうかをグラフィカルに表示します。これは、組織に重大な損害を与えることなく、アプリケーションが停止できる時間に基づくものです。この評価により、推定ワークロードの RTO が算出されます。
**RPO**
アプリケーションが障害耐性ポリシーの目標を満たす見込みがあるかどうかをグラフィカルに表示します。これは、ビジネスに重大な損害が発生する前に、データが失われる可能性のある時間に基づくものです。この評価により、ワークロードの推定 RPO が算出されます。
**詳細**
**[すべての結果]** タブと **[アプリケーションコンプライアンスドリフト]** タブに、各中断タイプの詳細な説明が表示されます。**[すべての結果]** タブにはコンプライアンスドリフトを含むすべての中断が表示され、**[アプリケーションコンプライアンスドリフト]** タブにはコンプライアンスドリフトのみが表示されます。中断タイプには、**[アプリケーション]**、クラウドインフラストラクチャ (**[インフラストラクチャ]** と **[アベイラビリティーゾーン**])、**[リージョン]** があり、それらに関する以下の情報が表示されます。
+ **AppComponent**
アプリケーションを構成するリソース。例えば、アプリケーションにはデータベースやコンピュートコンポーネントが含まれる場合があります。
+ **推定 RTO**
ポリシー設定がポリシー要件と一致しているかどうかを示します。**[推定 RTO]** と **[目標 RTO]** の 2 つの値が提供されます。例えば、**[目標 RTO]** に **[2 時間]**、**[推定ワークロード RTO]** に **[40 分]** という値が表示されている場合は、アプリケーションの現在の RTO が 2 時間であるのに対し、ワークロードの見積もり RTO は 40 分であることがわかります。推定ワークロード RTO の計算は、ポリシーではなく構成に基づいて行われます。その結果、選択したポリシーに関係なく、複数のアベイラビリティーゾーンのデータベースでは、アベイラビリティーゾーンの障害に対する推定ワークロード RTO は同じになります。
+ **RTO ドリフト**
前回の評価が成功した場合の推定ワークロード RTO からアプリケーションがずれている期間を示します。**[推定 RTO]** と **[RTO ドリフト]** という 2 つの値を提供しています。例えば、**[推定 RTO]** に **[2 時間]**、**[RTO ドリフト]**に **[40 分]** という値が表示される場合、アプリケーションが前回成功した評価の推定ワークロード RTO から 40 分ずれていることがわかります。
+ **推定 RPO**
各アプリケーションコンポーネントに設定した **[目標 RPO]** ポリシーに基づいて、 AWS Resilience Hub が推定した実際の **[推定ワークロード RPO]** ポリシーを表示します。例えば、アベイラビリティーゾーンの障害に対する障害耐性ポリシーの RPO 目標を 1 時間に設定したとします。推定結果はほぼゼロと計算される可能性があります。これは、すべてのトランザクションをコミットする Amazon Aurora が、複数のアベイラビリティーゾーンにまたがる 6 つのノードのうち 4 つで成功することを前提としています。ポイントインタイム復元には 5 分かかる場合があります。
指定しないで選択できる RTO と RPO の目標はリージョンだけです。一部のアプリケーションでは、AWS サービスに重大な依存関係があり、リージョン全体で使用できなくなる可能性がある場合に、復旧計画を立てておくと便利です。
リージョンの RTO や RPO の目標を設定するなど、このオプションを選択すると、そのような障害に対する推定復旧時間と運用上の推奨事項が表示されます。
+ **RPO ドリフト**
前回の評価で予測されたワークロードの RPO から、アプリケーションがどの程度ずれているかを示します。**[推定 RPO]** と **[RPO ドリフト]** という 2 つの値を提供しています。例えば、**[推定 RTO]** に **[2 時間]**、**[RTO ドリフト]** に **[40 分]** という値が表示される場合、アプリケーションが前回成功した評価の推定ワークロード RTO から 40 分ずれていることがわかります。
# 障害耐性に関する推奨事項の確認
障害耐性に関する推奨事項では、アプリケーションコンポーネントを評価し、推定ワークロードの RTO と推定ワークロードの RPO、コスト、最小限の変更によって最適化する方法を推奨しています。
では AWS Resilience Hub、**「このオプションを選択すべき理由**」の以下の推奨オプションのいずれかを使用して回復性を最適化できます。
**注記**
AWS Resilience Hub には、最大 3 つの AWS Resilience Hub 推奨オプションが用意されています。
リージョン RTO および RPO ターゲットを設定すると、 は推奨されるオプションに**リージョン RTO/RPO の最適化** AWS Resilience Hub を表示します。リージョン RTO および RPO ターゲットが設定されていない場合は、**Optimize for Availability Zone (AZ) RTO/RPO** が表示されます。障害耐性ポリシーの作成中にリージョン RTO/RPO ターゲットを設定する方法の詳細については、「」を参照してください[障害耐性ポリシーの作成](create-policy.md)。
アプリケーションとその構成の推定ワークロード RTO と推定ワークロード RPO 値は、データ量と個々の AppComponents を考慮して決定されます。ただし、これらの値は推定値にすぎません。アプリケーションの実際の復旧時間をテストするには、独自のテスト ( など AWS Fault Injection Service) を使用する必要があります。
**アベイラビリティーゾーン RTO/RPO に最適化する**
アベイラビリティーゾーン (AZ) の中断中の推定ワークロード復旧時間 (RTO/RPO) の最小値。RTO および RPO の目標を達成するために設定を十分に変更できない場合、ポリシーを満たす可能性に近づけるために、推定されるワークロード AZ 復旧時間の最小値が通知されます。
**リージョン RTO/RPO に最適化する**
リージョンの中断時の推定ワークロード復旧時間 (RTO/RPO) の最小値。RTO および RPO の目標を達成するために設定を十分に変更できない場合は、ポリシーを満たす可能性に近づけるために、ワークロードリージョンの推定復旧時間が最も短いことが通知されます。
**コストに合わせた最適化**
発生する可能性のある最低コストで、回復性ポリシーを満たします。最適化目標を達成するために設定を十分に変更できない場合は、設定がポリシーを満たす可能性に近づくために発生する可能性のある最低コストについて通知されます。
**最小化変更の最適化**
ポリシー目標を達成するために必要な最小限の変更。最適化目標を達成するために設定を十分に変更できない場合は、ポリシーを満たす可能性に近い設定に推奨される変更について通知されます。
最適化カテゴリの内訳には以下の項目が含まれます。
+ **説明**
によって提案される設定について説明します AWS Resilience Hub。
+ **変更**
推奨構成に切り替えるために必要なタスクを説明するためのテキスト変更リスト。
+ **基本コスト**
推奨される変更に関連する推定コスト。
**注記**
**基本コスト**は使用量によって異なり、エンタープライズ割引プログラム (EDP) の割引やオファーは含まれません。
+ **推定ワークロード RTO と RPO**
変更後の推定ワークロード RTO と推定ワークロード RPO。
AWS Resilience Hub は、アプリケーションコンポーネント (AppComponent) が障害耐性ポリシーに準拠できるかどうかを評価します。AppComponent が障害耐性ポリシーに準拠しておらず、AWS Resilience Hub がコンプライアンスを容易にするための推奨事項を作成できない場合、選択した AppComponent の復旧時間を AppComponent の制約内で満たすことができない可能性があります AppComponent 。AppComponent 制約の例としては、リソースタイプ、ストレージサイズ、リソース設定などがあります。
AppComponent の障害耐性ポリシーへの準拠を容易にするには、AppComponent のリソースタイプを変更するか、リソースが提供できる内容に合わせて障害耐性ポリシーを更新します。
# 運用上の推奨事項のレビュー
運用上の推奨事項には、 AWS CloudFormation テンプレートを使用してアラーム、SOPs、 AWS FIS 実験を設定するための推奨事項が含まれています。
AWS Resilience Hub には、アプリケーションのインフラストラクチャをコードとしてダウンロードおよび管理するための AWS CloudFormation テンプレートファイルが用意されています。そのため、アプリケーションコードに追加できるように、 AWS CloudFormation で推奨事項が提供されます。 AWS CloudFormation テンプレートファイルのサイズが 1 MB 以上で、500 を超えるリソースが含まれている場合、 は、各ファイルのサイズが 1 MB 以下で、最大 500 個のリソースが含まれている複数の AWS CloudFormation テンプレートファイル AWS Resilience Hub を生成します。テンプレートファイルが複数のファイルに分割されている場合 AWS CloudFormation 、 AWS CloudFormation テンプレートファイル名に が追加されます。ここで、 はシーケンス内のファイル番号`X`を示し`partXofY`、 はテンプレートファイルが分割された AWS CloudFormation ファイルの合計数`Y`を示します。例えば、テンプレートファイル `big-app-template5-Alarm-104849185070-us-west-2.yaml` が 4 つのファイルに分割されている場合、ファイル名は次のようになります。
+ `big-app-template5-Alarm-104849185070-us-west-2-part1of4.yaml`
+ `big-app-template5-Alarm-104849185070-us-west-2-part2of4.yaml`
+ `big-app-template5-Alarm-104849185070-us-west-2-part3of4.yaml`
+ `big-app-template5-Alarm-104849185070-us-west-2-part4of4.yaml`
ただし、大きな AWS CloudFormation テンプレートの場合は、ローカルファイルを入力として CLI/API を使用する代わりに、Amazon Simple Storage Service URI を指定する必要があります。
では AWS Resilience Hub、次のアクションを実行できます。
+ 選択したアラーム、SOPs、および AWS FIS 実験をプロビジョニングできます。アラーム、SOPs、 AWS FIS 実験をプロビジョニングするには、適切なレコメンデーションを選択し、一意の名前を入力します。 は、選択したレコメンデーションに基づいてテンプレート AWS Resilience Hub を作成します。**[テンプレート]** では、Amazon Simple Storage Service (Amazon S3) URL を通じて作成したテンプレートにアクセスできます。
+ 選択したアラーム、SOPs、およびアプリケーションに推奨された AWS FIS 実験を任意の時点で含めたり除外したりできます。詳細については、[運用上の推奨事項を含めるまたは除外する](exclude-recommend.md) を参照してください。
+ また、アプリケーションのタグを検索、作成、追加、削除、管理して、そのアプリケーションに関連するすべてのタグを確認することもできます。
# 運用上の推奨事項を含めるまたは除外する
AWS Resilience Hub には、アプリケーションの耐障害性スコアを向上させるために推奨されるアラーム、SOPs、および AWS FIS 実験 (テスト) を任意の時点で含めたり除外したりするためのオプションが用意されています。運用上のレコメンデーションの包含と除外は、新しい評価を実行した後にのみ、アプリケーションの耐障害性スコアに影響します。したがって、評価を実行して、更新された障害耐性スコアを取得し、アプリケーションへの影響を把握することをお勧めします。
アプリケーションごとに推奨事項を含めたり除外したりするためのアクセス許可の制限の詳細については、[AWS Resilience Hub レコメンデーションを含めるか除外するアクセス許可を制限する](include-exclude-limit-permissions.md) を参照してください。
**運用上の推奨事項をアプリケーションに含めたり除外したりするには**
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** で、アプリケーションを選択します。
1. **[評価]** を選択し、**[障害耐性評価]** 表から評価を選択します。評価を受けていない場合は、[での障害耐性評価の実行 AWS Resilience Hub](run-assessment.md) の手順を完了してからこのステップに戻ってください。
1. **[運用上の推奨事項]** タブを選択します。
1. 運用上の推奨事項をアプリケーションに含める、またはアプリケーションから除外するには、以下のステップを実行します。
**推奨アラームをアプリケーションに含めたり除外したりするには**
1. アラームを除外するには、以下のステップを実行します。
1. **[アラーム]** タブの **[アラーム]** テーブルから、除外するアラーム (**[未実装]** ステータス) をすべて選択します。アラームの現在の実装状況は、**[ステータス]** 列で確認できます。
1. **[アクション]** から **[選択項目を除外]** を選択します。
1. **[推奨項目を除外]** ダイアログから、以下のいずれかの理由 (オプション) を選択し、**[選択項目を除外]** を選択すると、選択したアラームがアプリケーションから除外されます。
+ **既に実装**済み – Amazon CloudWatch などの AWS サービスや他のサードパーティーサービスプロバイダーでこれらのアラームを既に実装している場合は、このオプションを選択します。
+ **[該当なし]** — アラームがビジネス要件に合わない場合は、このオプションを選択してください。
+ **[実装が複雑すぎる]** — アラームが複雑すぎて実装できないと思われる場合は、このオプションを選択してください。
+ **[その他]** — 推奨項目を除外するその他の理由を指定する場合は、このオプションを選択してください。
1. アラームを含めるには、次のステップを実行します。
1. **[アラーム]** タブの **[アラーム]** テーブルから、含めたいアラーム (**[除外]** ステータス) をすべて選択します。アラームの現在の実装状況は、**[ステータス]** 列で確認できます。
1. **[アクション]** から **[選択項目を含める]** を選択します。
1. **[推奨項目を含める]** ダイアログで **[選択項目を含める]** を選択すると、選択したすべてのアラームがアプリケーションに含められます。
**推奨標準作業手順 (SOP) をアプリケーションに含めたり除外したりするには**
1. 推奨 SOP を除外するには、以下のステップを実行します。
1. **[標準作業手順]** タブの **[SOP]** テーブルから、除外するすべての SOP (**[実施済み]** または **[未実装]**) を選択します。SOP の現在の実施ステータスは、**[ステータス]** 列で確認できます。
1. **[アクション]** から **[選択項目を除外]** を選択し、選択した SOP をアプリケーションから除外します。
1. **[推奨項目を除外]** ダイアログから、以下のいずれかの理由 (オプション) を選択し、**[選択項目を除外]** を選択して、選択した SOP をアプリケーションから除外します。
+ **[既に実装済み]** — これらの SOP を AWS サービスまたは他のサードパーティのサービスプロバイダーですでに実装している場合は、このオプションを選択してください。
+ **[該当なし]** — SOP がビジネス要件に合わない場合は、このオプションを選択してください。
+ **[実装が複雑すぎる]** — これらの SOP が複雑すぎて実装できないと思われる場合は、このオプションを選択してください。
+ **[なし]** — 理由を指定しない場合は、このオプションを選択してください。
1. SOP を含めるには、次のステップを実行します。
1. **[標準作業手順書]** タブの **[SOP]** テーブルから、含めたいアラーム (**[除外]** ステータス) をすべて選択します。アラームの現在の実装状況は、**[ステータス]** 列で確認できます。
1. **[アクション]** から **[選択項目を含める]** を選択します。
1. **[レコメンデーションを含める]** ダイアログで **[選択したものを含める]** を選択すると、選択したすべての SOP がアプリケーションに含められます。
**推奨テストをアプリケーションに含めたり除外したりするには**
1. 推奨テストを除外するには、以下のステップを実行します。
1. **[故障注入実験テンプレート]** タブの **[故障注入実験テンプレート]** テーブルから、除外したいテスト (**[実装済み]** または **[未実装]** ステータス) をすべて選択します。テストの現在の実装状況は、**[ステータス]** 列で確認できます。
1. **[アクション]** から **[選択項目を除外]** を選択します。
1. **[推奨項目を除外]** ダイアログから、以下のいずれかの理由 (オプション) を選択し、**[選択項目を除外]** を選択すると、選択した AWS FIS 実験がアプリケーションから除外されます。
+ **既に実装**済み – AWS サービスまたは他のサードパーティーサービスプロバイダーでこれらのテストを既に実装している場合は、このオプションを選択します。
+ **[該当なし]** — テストがビジネス要件に合わない場合は、このオプションを選択してください。
+ **[実装が複雑すぎる]** — テストが複雑すぎて実装できないと思われる場合は、このオプションを選択してください。
+ **[なし]** — 理由を指定しない場合は、このオプションを選択してください。
1. 推奨テストを含めるには、以下のステップを実行します。
1. **[故障注入実験テンプレート]** タブの **[故障注入実験テンプレート]** テーブルから、含めたいテスト (**[除外]** ステータス) をすべて選択します。テストの現在の実装状況は、**[ステータス]** 列で確認できます。
1. **[アクション]** から **[選択項目を含める]** を選択します。
1. **[推奨項目を含める]** ダイアログから **[選択したものを含める]** を選択すると、選択したすべてのテストがアプリケーションに含められます。