翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ARC でのルーティングコントロールに関するベストプラクティス ARC でルーティングコントロールのリカバリとフェイルオーバーに備えるときは、以下のベストプラクティスに従うことをお勧めします。 **トピック** + [専用で存続期間の長い AWS 認証情報を安全かつ常にアクセス可能に保つ](#RCBestPracticeCredentials) + [フェイルオーバーに関連する DNS レコードの低い TTL 値を選択する](#RCBestPracticeLowerTTL) + [クライアントがエンドポイントに接続したままになる時間を制限する](#RCBestPracticeCurrentConnections) + [5 つのリージョンクラスターエンドポイントとルーティングコントロール ARNs](#RCBestPracticeBookmarkEndpoints) + [いずれかのエンドポイントをランダムに選択して、ルーティングコントロールの状態を更新します。](#RCBestPracticeRandomEndpoint) + [コンソールではなく、非常に信頼性の高いデータプレーン API を使用してルーティングコントロールの状態を一覧表示および更新する](#RCBestPracticeUseDataPlane) **専用で存続期間の長い AWS 認証情報を安全かつ常にアクセス可能に保つ** ディザスタリカバリ (DR) シナリオでは、復旧タスクにアクセスして AWS 実行するための簡単なアプローチを使用して、システムの依存関係を最小限に抑えます。DR タスク用に [IAM の長期間有効な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html)を作成し、オンプレミスの物理的な金庫または仮想ボールトにこれを保管して、必要に応じてアクセスできるようにします。IAM を使用すると、アクセスキーや AWS リソースへのアクセス許可などのセキュリティ認証情報を一元管理できます。DR 以外のタスクについては、[AWS Single Sign-On](https://aws.amazon.com/single-sign-on/) など、 AWS サービスを使ったフェデレーションアクセスを引き続き使用することが推奨されます。 リカバリクラスターのデータプレーン API を使って ARC でフェイルオーバータスクを実行するときは、ARC の IAM ポリシーをユーザーにアタッチできます。詳細については[Amazon Application Recovery Controller (ARC) のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)を参照してください。 **フェイルオーバーに関連する DNS レコードの低い TTL 値を選択する** フェイルオーバーの一環として変更する必要がある DNS レコード、特にヘルスチェックの対象となるレコードは、TTL 値を低く設定しておくのが適切です。このシナリオでは、TTL を 60 秒または 120 秒に設定するのが一般的です。 DNS TTL (有効期間) の設定は、新しいレコードをリクエストするまでに、どの程度の期間、レコードをキャッシュすべきかを DNS リゾルバーに伝えます。TTL を選択する際は、レイテンシーと信頼性の間、また、変化への反応との間でいずれかを優先しなくてはなりません。レコードの TTL を短くすると、DNS リゾルバーはレコードの更新をより頻繁に通知します。TTL から、クエリを頻繁に実行するように指示されるためです。 詳細については、「[Amazon Route 53 DNS のベストプラクティス](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html)」の「DNS レコードの TTL 値の選択」を参照してください。** **クライアントがエンドポイントに接続したままになる時間を制限する** ルーティングコントロールを使用して 間でシフトする場合 AWS リージョン 、Amazon Application Recovery Controller (ARC) がアプリケーショントラフィックを移動するために使用するメカニズムは DNS 更新です。この更新により、すべての新しい接続が障害のある場所から遠ざけられます。 ただし、既存のオープン接続を持つクライアントは、クライアントが再接続するまで、障害が発生したロケーションに対してリクエストを引き続き行う場合があります。迅速な復旧を確保するために、クライアントがエンドポイントに接続し続ける時間を制限することをお勧めします。 Application Load Balancer を使用する場合は、`keepalive` オプションを使用して接続の継続期間を設定できます。詳細については、「Application Load Balancer ユーザーガイド」の「[HTTP クライアントのキープアライブ期間](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#http-client-keep-alive-duration)」を参照してください。 Application Load Balancer では、HTTP クライアントのキープアライブ期間の値はデフォルトで 3600 秒 (1 時間) に設定されます。アプリケーションの目標復旧時間に合わせて、例えば 300 秒のように値を小さくすることをお勧めします。HTTP クライアントのキープアライブ時間を設定する際は、一般的に再接続が増えてレイテンシーに影響が出ることと、障害のある AZ やリージョンからすべてのクライアントをより早く切り替えられることとのトレードオフである点を考慮してください。 **5 つのリージョンクラスターエンドポイントとルーティングコントロール ARNs** ARC のリージョンクラスターエンドポイントの、ローカルコピーをブックマークに保存するか、エンドポイントを再試行するために使用する自動化コードに保存することをお勧めします。障害イベントが発生すると、信頼性が非常に高いデータプレーンクラスターでホストされていない ARC API オペレーションなど、一部の API オペレーションにアクセスできなくなることがあります。ARC クラスターのエンドポイントは、[DescribeCluster](https://docs.aws.amazon.com/recovery-cluster/latest/api/cluster-clusterarn.html) API オペレーションを使用すると一覧表示できます。 **いずれかのエンドポイントをランダムに選択して、ルーティングコントロールの状態を更新します。** ルーティングコントロールでは、障害が発生した場合でも高可用性を確保できるよう 5 つのリージョンエンドポイントが提供されています。十分な耐障害性を実現するには、必要に応じて 5 つのエンドポイントをすべて使用できる再試行ロジックを用意することが重要です。クラスターエンドポイントを試す例など、 AWS SDK でのコード例の使用については、「」を参照してください[AWS SDKsコード例](service_code_examples.md)。 **コンソールではなく、非常に信頼性の高いデータプレーン API を使用してルーティングコントロールの状態を一覧表示および更新する** ルーティングコントロールと状態を確認するときは、ARC データプレーン API を使って [ListRoutingControls](https://docs.aws.amazon.com/routing-control/latest/APIReference/API_ListRoutingControls.html) オペレーションを実行し、フェイルオーバーのためルーティングコントロールの状態を更新してトラフィックをリダイレクトするときは [UpdateRoutingControlState](https://docs.aws.amazon.com/routing-control/latest/APIReference/API_UpdateRoutingControlState.html) オペレーションを実行します。 AWS CLI [(これらの例のように)](getting-started-cli-routing.control-state.md) またはいずれかの AWS SDKs を使用して記述したコードを使用できます。ARC では、きわめて信頼性の高い方法として、データプレーンで API を使用してトラフィックをフェイルオーバーできます。 AWS マネジメントコンソールでルーティングコントロールの状態を変更するのではなく、こちらの API を使用することをお勧めします。 データプレーン API を使用するには、ARC のリージョンクラスターエンドポイントのいずれかに接続します。そのエンドポイントが使用できない場合は、別のクラスターエンドポイントに接続します。 安全ルールが原因でルーティングコントロールの状態を更新できない場合は、そのルールを迂回して更新し、トラフィックをフェイルオーバーすることが可能です。詳細については、「[安全ルールを上書きしてトラフィックを再ルーティングする](routing-control.override-safety-rule.md)」を参照してください。 **ARC でのフェイルオーバーのテスト** ARC のルーティングコントロールを使って、プライマリのアプリケーションスタックからセカンダリのアプリケーションスタックにフェイルオーバーして、定期的にフェイルオーバーをテストします。追加した ARC の構造がスタック内の正常なリソースと一致していること、および、すべてが予定どおりに機能していることを確認することが重要です。使用している環境に ARC をセットアップした後でこのテストを行い、フェイルオーバー環境の準備が整うように定期的にテストを続ける必要があります。障害が発生した場合には、ユーザーのダウンタイムを回避できるよう、セカンダリシステムを起動してすばやく稼働させる必要があります。