Amazon Route 53 Application Recovery Controller の準備状況チェック - Amazon Route 53 Application Recovery Controller
準備状況チェックとディザスタリカバリのシナリオ準備状況ルールが準備状況ステータスを判断する仕組み DNS ターゲットリソースの準備状況チェック: レジリエンシーの準備状況の監査

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

Amazon Route 53 Application Recovery Controller の準備状況チェック

本章では、リカバリグループとセルを作成して Amazon Route 53 Application Recovery Controller でアプリケーションをモデル化する方法について、また、Route 53 ARC がアプリケーションの準備状況を監査できるよう、準備状況チェックと準備状況の範囲を追加する方法について、説明します。

準備状況チェックを作成すると、リソースの準備状況ステータスをモニタリングできるようになります。準備状況チェックを使用すると、スタンバイ状態のアプリケーションのレプリカとそのリソースを、本番アプリケーションの容量、ルーティングポリシー、その他の詳細な設定を反映しながら、本番のレプリカと継続的に一致させることができます。一致しない場合には、容量を追加したり設定を変更したりすることにより、レプリカを再び一致させることができます。

重要

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

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

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

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

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

準備状況チェックを追加することで、準備状況ステータスをモニタリングできます。これには、 を使用した 、 での EventBridge、AWS Management Consoleまたは Route 53 ARC API アクションを使用する方法があります。また、リソースの準備状況ステータスを、セルの準備状況やアプリケーションの準備状況など異なるコンテキストでモニタリングすることもできます。Route 53 ARC のクロスアカウント認証機能を使用すると、分散したリソースを単一の AWS アカウントから簡単にセットアップしてモニタリングできます。

トピック

準備状況チェックとディザスタリカバリのシナリオ

Route 53 ARC の準備状況チェックでは、フェイルオーバートラフィックに対処するためアプリケーションがスケールしていることを、ユーザーが確認できるようにすることで、アプリケーションとリソースのリカバリ準備が整っているかどうかに関するインサイトを提供しています。準備状況チェックのステータスは、本番のレプリカが正常であることを示す合図として使用すべきではありません。ただし、アプリケーションやインフラストラクチャのモニタリングや、レプリカから、またはレプリカにフェイルオーバーすべきか否かを判断するヘルスチェックシステムの補完に使用することは可能です。

緊急時や停電時には、ヘルスチェックとその他の情報を組み合わせて、スタンバイがスケールアップされ、正常で、本番トラフィックをフェイルオーバーする準備が整っているかどうかを判断します。例えば、スタンバイの準備状況チェックのステータスが READY であることを確認することに加え、スタンバイのセルに対して実行する canary が、成功基準を満たしているかどうかを確認します。

Route 53 ARC の準備状況チェックは、単一の AWS リージョン、つまり米国西部 (オレゴン) でホストされているため、停電時や災害時に、準備状況チェックの情報が古くなったりチェックを利用できなくなったりする場合がありますのでご注意ください。詳細については、「Route 53 ARC のデータプレーンとコントロールプレーン」を参照してください。

準備状況ルールが準備状況ステータスを判断する仕組み

Route 53 ARC の準備状況チェックでは、事前定義された各リソースタイプのルールとそれらのルールの定義方法に基づいて、準備状況ステータスが判断されます。Route 53 ARC には、サポートされているリソースのタイプごとに、1 つのルールグループが含まれています。例えば、Route 53 ARC には、Amazon Aurora クラスター、Auto Scaling グループなどの準備状況ルールのグループが含まれています。準備状況ルールには、セット内のリソースを相互に比較するものもあれば、リソースセット内の各リソースに関する特定の情報を調べるものもあります。

ユーザーは、準備状況ルールやルールのグループを、追加、編集、削除できません。ただし、Amazon CloudWatch アラームを作成し、アラームの状態をモニタリングする準備状況チェックを作成できます。例えば、カスタム CloudWatch アラームを作成して Amazon EKS コンテナサービスをモニタリングし、準備状況チェックを作成してアラームの準備状況ステータスを監査できます。

リソースセットを作成すると、AWS Management Consoleにある各リソースタイプの、準備状況ルールをすべて表示できます。あるいは、リソースセットの詳細ページに移動して準備状況ルールを後で表示することもできます。準備状況ルールは「Route 53 ARC での準備状況ルール」セクションでも確認できます。

準備状況チェックで一連のルールを使って一連のリソースを監査する場合、各ルールの定義方法によって、すべてのリソースで結果を READY または NOT READY にするのか、それともリソースごとに結果を変えるのかが決まります。さらに、準備状況ステータスは複数の方法で表示できます。例えば、リソースセット内のリソースグループの準備状況ステータスを表示したり、リカバリグループまたはセル (リカバリグループのセットアップ方法に応じて AWS リージョンまたはアベイラビリティーゾーン) の準備状況ステータスの概要を表示したりできます。

各ルールの説明の文言には、そのルールが適用されたときにどのようにリソースを評価し、準備状況ステータスを判断するのかが説明されています。ルールは、各リソースを検査するか、リソースセット内のすべてのリソースを検査して準備状況を判断するように定義されています。具体的には、ルールは以下のように機能します。

  • ルールは、リソースセット内の各リソースを検査して条件を確認します。

    • すべてのリソースで条件が確認されると、すべてのリソースは READY に設定されます。

    • 1 つのリソースで条件の確認に失敗すると、そのリソースは NOT READY に設定され、それ以外のセルは READY のままとなります。

    例: MskClusterState: は各 Amazon MSK クラスターを検査し、ACTIVE の状態になっていることを確認します。

  • このルールは、リソースセット内のすべてのリソースを検査して条件を確認します。

    • 条件が確認されると、すべてのリソースは READY に設定されます。

    • 条件を満たさないリソースがある場合、すべてのリソースは NOT READY に設定されます。

    例:VpcSubnetCount: はすべての VPC サブネットを検査し、それらのサブネット数が同じであることを確認します。

  • 重要度の低いルール: このルールは、リソースセット内のすべてのリソースを検査して条件を確認します。

    • いずれかのリソースが条件を満たさなかったとしても、準備状況は変わりません。このような動作をするルールには、説明に注記が付きます。

    例: ElbV2CheckAzCount: は各 Network Load Balancer を検査し、アタッチされているアベイラビリティーゾーンが 1 つのみであることを確認します。注: このルールは準備状況ステータスには影響しません。

また、Route 53 ARC では、クォータに関して追加の対策を講じています。準備状況チェックで、サポートされているリソースのサービスクォータ (リソースの作成とオペレーションの最大値) のセル間に不一致が見つかった場合、Route 53 ARC は、クォータが低い方のリソースで、自動的にクォータを引き上げます。これは、クォータ (制限) に対してのみ適用されます。キャパシティに関しては、アプリケーションのニーズに応じて、ユーザーが必要なキャパシティを追加する必要があります。

準備状況チェックのステータスが に変わったときなど、準備状況チェックの Amazon EventBridge 通知を設定することもできますNOT READY。その後、設定の不一致が検出されると、 から通知 EventBridge が送信され、修正作業が講じられて、アプリケーションレプリカが整合し、復旧の準備が整っていることを確認できます。詳細については、「Amazon での Route 53 ARC の使用 EventBridge」を参照してください。

DNS ターゲットリソースの準備状況チェック: レジリエンシーの準備状況の監査

Route 53 ARC の、DNS ターゲットリソースの準備状況チェックを使うと、アプリケーションのアーキテクチャとレジリエンシーの準備状況を監査できます。このタイプの準備状況チェックでは、アプリケーションのアーキテクチャと Amazon Route 53 のルーティングポリシーを継続的にスキャンして、クロスゾーンおよびクロスリージョンの依存関係を監査します。

リカバリ重視のアプリケーションには、アベイラビリティーゾーンまたは AWS リージョンに対してサイロ化された複数のレプリカがあるため、各レプリカで、互いに無関係に障害が発生することがあります。正しくサイロ化するようにアプリケーションを調整する必要がある場合に、Route 53 ARC は、必要に応じてアーキテクチャを更新できる変更を提案します。これにより、レジリエンスとフェイルオーバーへの備えを確保できます。

Route 53 ARC は、アプリケーション内のセル (レプリカまたは障害抑制ユニットを表す) の数と範囲、およびセルがアベイラビリティーゾーンごとまたはリージョンごとにサイロ化されているかどうかを、自動的に検出します。次に、Route 53 ARC は、セル内のアプリケーションリソースを識別してユーザーに情報を提供し、それらがアベイラビリティーゾーンまたはリージョンに正しくサイロ化されているかどうかを判断します。例えば、特定のアベイラビリティーゾーンを対象とするセルがある場合、準備状況チェックでは、ロードバランサーとその背後にあるターゲットも、それらのゾーンにサイロ化されているかどうかをモニタリングできます。

この情報を使用することで、セル内のリソースを正しいゾーンまたはリージョンに一致させるために、変更すべきことがあるかどうかを判断できます。

開始するには、アプリケーション用の DNS ターゲットリソースと、それらのリソースセットおよび準備状況チェックを作成します。詳細については、「Route 53 ARC でアーキテクチャの推奨事項を取得する」を参照してください。