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