翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
でのルーティングコントロールのベストプラクティス ARC
でのルーティング制御の復旧とフェイルオーバーの準備には、次のベストプラクティスをお勧めしますARC。
トピック
- 専用で存続期間の長い AWS 認証情報を安全かつ常にアクセス可能に保つ
ディザスタリカバリ (DR) シナリオでは、復旧タスクにアクセスして AWS 実行するための簡単なアプローチを使用して、システムの依存関係を最小限に抑えます。DR タスク専用の存続期間のIAM長い認証情報を作成し、必要に応じてアクセスできるように、認証情報をオンプレミスの物理的な金庫または仮想ボールトに安全に保管します。を使用するとIAM、アクセスキーなどのセキュリティ認証情報や、 AWS リソースへのアクセス許可を一元管理できます。DR 以外のタスクについては、AWS Single Sign-On
など、 AWS サービスを使ったフェデレーションアクセスを引き続き使用することが推奨されます。 リカバリクラスターのデータプレーン ARCを使用して でフェイルオーバータスクを実行するにはAPI、ユーザーにARCIAMポリシーをアタッチします。詳細については、「Amazon Application Recovery Controller のアイデンティティベースのポリシーの例 (ARC)」を参照してください。
- フェイルオーバーに関係するDNSレコードの低いTTL値を選択する
フェイルオーバーメカニズムの一部として変更する必要があるDNSレコード、特にヘルスチェック対象のレコードの場合は、低いTTL値を使用するのが適切です。このシナリオでは、 TTLを 60 秒または 120 秒に設定するのが一般的です。
DNS TTL (有効期限) 設定は、新しいレコードをリクエストする前にレコードをキャッシュする期間をDNSリゾルバーに指示します。を選択するとTTL、レイテンシーと信頼性、および変更への応答性がトレードオフされます。レコードTTLが短いほど、リDNSゾルバーはレコードの更新をより迅速に認識します。これは、 がクエリをより頻繁に実行する必要があることTTLを指定するためです。
詳細については、「Amazon Route 53 のベストプラクティス」のDNS「レコードTTLの値の選択」を参照してください。 DNS
- クライアントがエンドポイントに接続したままになる時間を制限する
ルーティングコントロールを使用して 間でシフトする場合 AWS リージョン 、Amazon Application Recovery Controller (ARC) がアプリケーショントラフィックを移動するために使用するメカニズムはDNS更新です。この更新により、すべての新しい接続が障害のある場所から遠ざけられます。
ただし、既存のオープン接続を持つクライアントは、クライアントが再接続するまで、障害が発生したロケーションに対してリクエストを引き続き行う場合があります。迅速な復旧を確保するために、クライアントがエンドポイントに接続したままになる時間を制限することをお勧めします。
Application Load Balancer を使用する場合は、
keepalive
オプションを使用して接続の継続時間を設定できます。詳細については、「Application Load Balancer ユーザーガイド」のHTTP「クライアントキープアライブ期間」を参照してください。 Application Load Balancerデフォルトでは、Application Load Balancer はHTTPクライアントキープアライブ期間の値を 3600 秒、つまり 1 時間に設定します。300 秒など、アプリケーションの目標復旧時間に合わせて値を小さくすることをお勧めします。HTTP クライアントキープアライブ期間を選択する場合、この値は一般的に再接続頻度が高いことによるトレードオフであり、レイテンシーに影響を与える可能性があります。また、すべてのクライアントを障害のある AZ またはリージョンからより迅速に遠ざけることができます。
- 5 つのリージョンクラスターエンドポイントとルーティングコントロールをブックマークまたはハードコードする ARNs
ARC リージョンクラスターエンドポイントのローカルコピーをブックマークに保存するか、エンドポイントの再試行に使用する自動化コードに保存することをお勧めします。障害イベント中に、非常に信頼性の高いデータプレーンクラスターでホストされていないAPIオペレーションなど、一部のARCAPIオペレーションにアクセスできない場合があります。DescribeCluster API オペレーションを使用して、ARCクラスターのエンドポイントを一覧表示できます。
- いずれかのエンドポイントをランダムに選択して、ルーティングコントロールの状態を更新します。
-
ルーティングコントロールは、障害に対処した場合でも高可用性を確保するため、5 つのリージョンエンドポイントを提供します。完全な回復性を実現するには、必要に応じて 5 つのエンドポイントすべてを使用できる再試行ロジックを用意することが重要です。クラスターエンドポイントを試す例など AWS SDK、 でのコード例の使用については、「」を参照してくださいを使用した Application Recovery Controller のコード例 AWS SDKs。
- コンソールではなく、非常に信頼性の高いデータプレーンAPIを使用してルーティングコントロールの状態を一覧表示および更新する
ARC データプレーン を使用してAPI、 ListRoutingControlsオペレーションでルーティングコントロールと状態を表示し、 オペレーションでフェイルオーバーのためにトラフィックをリダイレクトするようにルーティングコントロールの状態を更新しますUpdateRoutingControlState。 AWS CLI (これらの例のように) または のいずれかを使用して記述したコードを使用できます AWS SDKs。 ARCは、トラフィックをフェイルオーバーするために、データプレーンAPIの で非常に高い信頼性を提供します。でルーティングコントロールの状態を変更するAPI代わりに、 を使用することをお勧めします AWS Management Console。
データプレーン を使用するにはARC、 のリージョンクラスターエンドポイントのいずれかに接続しますAPI。そのエンドポイントが使用できない場合は、別のクラスターエンドポイントに接続します。
安全ルールが原因でルーティングコントロールの状態を更新できない場合は、そのルールを迂回して更新し、トラフィックをフェイルオーバーすることが可能です。詳細については、「安全ルールを上書きしてトラフィックを再ルーティングする」を参照してください。
- によるフェイルオーバーのテスト ARC
ARC ルーティングコントロールを使用して定期的にフェイルオーバーをテストし、プライマリアプリケーションスタックからセカンダリアプリケーションスタックにフェイルオーバーします。追加したARC構造がスタック内の正しいリソースと一致していること、およびすべてが期待どおりに機能することを確認することが重要です。これをテストするには、環境ARCに合わせて を設定した後、フェイルオーバー環境の準備が整うように定期的にテストする必要があります。その後、ユーザーのダウンタイムを回避するために、セカンダリシステムをすばやく稼働させる必要がある障害状況が発生します。