翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Amazon Application Recovery Controller (ARC) での準備状況チェックとは
<a name="readiness-what-is"></a>

**注記**  
Amazon Application Recovery Controller (ARC) の準備状況チェック機能は、新規のお客様に公開されなくなりました。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、[「Amazon Application Recovery Controller (ARC) の準備状況チェックの可用性の変更](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-readiness-availability-change.html)」を参照してください。

ARC の準備状況チェックは、AWSプロビジョニングされた容量の不一致、サービスクォータ、スロットル制限、チェックに含まれるリソースの設定とバージョンの不一致を継続的に (1 分間隔で) 監査します。準備状況チェックではこれらの差異がユーザーに通知されるため、各レプリカの設定のセットアップが同じであり、ランタイム時の状態が同じであることを確認できます。準備状況チェックでは、設定したキャパシティがレプリカ間で一定であることを確認できますが、ユーザーに代わってレプリカのキャパシティを決めてくれると考えるべきではありません。例えば、別のセルが使用できなくなった場合に備えて、各レプリカの、十分なバッファ容量を備えた Auto Scaling グループのサイズを決めるには、アプリケーション要件を理解する必要があります。

クォータについては、ARC が準備状況チェックで不一致を検出すると、高いクォータに合わせて低いクォータを増やして、レプリカのクォータを調整する措置を講じることができます。クォータが一致すると、準備状況チェックのステータスが `READY` と表示されます (こちらは即時の更新プロセスではありません。また、合計時間は特定のリソースタイプやその他の要因に応じて変わります)。

最初のステップでは、アプリケーションを表す[リカバリグループ](recovery-readiness.recovery-groups.md)を作成するための、準備状況チェックをセットアップします。各リカバリグループには、個々の障害抑制ユニットまたはアプリケーションのレプリカのセルが含まれています。****次に、アプリケーション内のリソースタイプごとに[リソースセット](recovery-readiness.recovery-groups.readiness-scope.md)を作成し、そのリソースセットに準備状況チェックを関連付けます。**最後に、リソースを準備状況の範囲に関連付けます。そうすることで、リカバリグループ (アプリケーション) または個々のセル (レプリカ、つまりリージョンまたはアベイラビリティーゾーン (AZ)) 内のリソースに関する準備状況ステータスを取得できます。**

準備状況 (つまり `READY` または `NOT READY`) は、準備状況チェックの範囲に含まれるリソースと、リソースタイプの一連のルールに基づいて決定されます。リソースタイプごとに[一連の準備状況ルール](recovery-readiness.rules-resources.md#recovery-readiness.list-rules)があり、ARC のチェックではこれを使ってリソースの準備状況を監査します。リソースが `READY` であるか否かの判断は、各準備状況ルールの定義方法に基づきます。準備状況ルールでは、通常リソースの評価が行われますが、リソースを相互に比較したり、リソースセット内の各リソースに関する特定の情報を調べたりする場合もあります。

準備状況チェックを追加することで、EventBridge、、ARC API アクションのいずれかの方法でAWS マネジメントコンソール準備状況ステータスをモニタリングできます。また、リソースの準備状況ステータスを、セルの準備状況やアプリケーションの準備状況など異なるコンテキストでモニタリングすることもできます。ARC の[クロスアカウント認可](recovery-readiness.cross-account.md)機能を使用すると、1 つのAWSアカウントから分散リソースを簡単にセットアップしてモニタリングできます。

## 準備状況チェックを使ってアプリケーションレプリカをモニタリングする
<a name="readiness-what-is.readiness-auditing"></a>

ARC は、*準備状況チェック*を使用してアプリケーションのレプリカを監査し、各レプリカが同じ構成設定で同じランタイムを持つことを確認します。準備状況チェックでは、アプリケーションのAWSリソース容量、設定、AWSクォータ、ルーティングポリシーを継続的に監査します。この情報は、レプリカがフェイルオーバーの準備が整っていることを確認するのに役立ちます。準備状況チェックは、リカバリ環境がスケールされ、必要なときにフェイルオーバーできるように構成されていることを確認するのに役立ちます。

以下のセクションでは、準備状況チェックの仕組みについて詳しく説明します。

### 準備状況チェックとアプリケーションレプリカ
<a name="readiness-what-is.readiness-auditing-details"></a>

リカバリに備えるには、別のアベイラビリティーゾーンまたはリージョンからのフェイルオーバートラフィックを吸収できる十分な予備の容量をレプリカに常に保持している必要があります。ARC はアプリケーションを継続的に (1 分ごとに) 検査して、プロビジョニングされた容量がすべてのアベイラビリティーゾーンまたはリージョンにわたって一致していることを確認します。

ARC が検査する容量には、例えば、Amazon EC2 インスタンス数、Aurora の読み取りおよび書き込みキャパシティユニット、Amazon EBS ボリュームサイズなどが含まれます。リソース値に合わせてプライマリレプリカの容量をスケールアップしたものの、スタンバイレプリカの対応する値も増やすことを忘れた場合、ARC が不一致を検出するため、スタンバイの値を増やすことができます。

**重要**  
準備状況チェックは、アプリケーションのレプリカの設定とランタイムの状態が一致していることを継続的に確認するときに、最も役立つサービスです。準備状況チェックは、本番のレプリカが正常かどうかを示すために使用すべきではありません。また、準備状況チェックを、災害発生時のフェイルオーバーの主要なトリガーとして使用すべきでもありません。

アクティブスタンバイ構成において、セルからまたはセルにフェイルオーバーするかどうかは、モニタリングのシステムやヘルスチェックのシステムに基づいてユーザーが判断する必要があります。準備状況チェックは、それらのシステムを補完するサービスとして捉えるのがよいでしょう。ARC の準備状況チェックは可用性が高くないため、システム停止中に準備状況チェックにアクセスできるとは限りません。さらに、チェックされたリソースは、災害時には利用できなくなる可能性もあります。

特定のセル (AWSリージョンまたはアベイラビリティーゾーン) またはアプリケーション全体のアプリケーションリソースの準備状況ステータスをモニタリングできます。EventBridge でルールを作成することで、準備状況チェックのステータスが変わったとき (`Not ready` に変わったときなど) に通知を受けることができます。詳細については、「[Amazon EventBridge により ARC で準備状況チェックを使用する](eventbridge-readiness.md)」を参照してください。準備状況ステータスは、 で表示することもAWS マネジメントコンソール、 などの API オペレーションを使用して表示することもできます`get-recovery-readiness`。詳細については、「[準備状況チェック API オペレーション](actions.readiness.md)」を参照してください。

### 準備状況チェックの仕組み
<a name="readiness-what-is.readiness-how-it-works"></a>

ARC は、*準備状況チェック*を使用してアプリケーションのレプリカを監査し、各レプリカが同じ構成設定で同じランタイムを持つことを確認します。

例えば、リカバリに備えるには、別のアベイラビリティーゾーンまたはリージョンからのフェイルオーバートラフィックを吸収できる十分な予備の容量を常に保持している必要があります。ARC はアプリケーションを継続的に (1 分ごとに) 検査して、プロビジョニングされた容量がすべてのアベイラビリティーゾーンまたはリージョンにわたって一致していることを確認します。ARC が検査する容量には、例えば、Amazon EC2 インスタンス数、Aurora の読み取りおよび書き込みキャパシティユニット、Amazon EBS ボリュームサイズなどが含まれます。リソース値に合わせてプライマリレプリカの容量をスケールアップしたものの、スタンバイレプリカの対応する値も増やすことを忘れた場合、ARC が不一致を検出するため、スタンバイの値を増やすことができます。

**重要**  
準備状況チェックは、アプリケーションのレプリカの設定とランタイムの状態が一致していることを継続的に確認するときに、最も役立つサービスです。準備状況チェックは、本番のレプリカが正常かどうかを示すために使用すべきではありません。また、準備状況チェックを、災害発生時のフェイルオーバーの主要なトリガーとして使用すべきでもありません。

アクティブスタンバイ構成において、セルからまたはセルにフェイルオーバーするかどうかは、モニタリングのシステムやヘルスチェックのシステムに基づいてユーザーが判断する必要があります。準備状況チェックは、それらのシステムを補完するサービスとして捉えるのがよいでしょう。ARC の準備状況チェックは可用性が高くないため、システム停止中に準備状況チェックにアクセスできるとは限りません。さらに、チェックされたリソースは、災害時には利用できなくなる可能性もあります。

特定のセル (AWSリージョンまたはアベイラビリティーゾーン) またはアプリケーション全体のアプリケーションリソースの準備状況ステータスをモニタリングできます。EventBridge でルールを作成することで、準備状況チェックのステータスが変わったとき (`Not ready` に変わったときなど) に通知を受けることができます。詳細については、「[Amazon EventBridge により ARC で準備状況チェックを使用する](eventbridge-readiness.md)」を参照してください。準備状況ステータスは、 で表示することもAWS マネジメントコンソール、 などの API オペレーションを使用して表示することもできます`get-recovery-readiness`。詳細については、「[準備状況チェック API オペレーション](actions.readiness.md)」を参照してください。