ルーティングコントロールについて

ルーティングコントロールは、Amazon Route 53 のヘルスチェックを使用してトラフィックをリダイレクトします。ヘルスチェックは、Elastic Load Balancing のロードバランサーなど、リカバリグループでセルの最上位リソースに関連付けられた DNS レコードで設定されます。例えば、ルーティングコントロールの状態を Off (あるセルへのトラフィックフローを停止) に更新し、別のルーティングコントロールの状態を On (別のセルへのトラフィックフローを開始) に更新することで、あるセルから別のセルにトラフィックをリダイレクトできます。トラフィックフローを変更するプロセスは、ARC がそれを更新して、対応するルーティングコントロールの状態に基づいて正常または異常として設定した後、ルーティングコントロールに関連付けられた Route 53 ヘルスチェックです。

ルーティングコントロールは、DNS エンドポイントを持つすべての AWS サービスでのフェイルオーバーをサポートします。ディザスタリカバリ、またはアプリケーションのレイテンシー低下やその他の問題を検出したときに、ルーティングコントロールの状態を更新してトラフィックをフェイルオーバーできます。

また、ルーティングコントロールを使用してトラフィックを再ルーティングしても可用性が損なわれないように、ルーティングコントロールの安全ルールを設定することもできます。詳細については、「ルーティングコントロールの安全ルールの作成 」を参照してください。

ルーティングコントロール自体は、エンドポイントの基盤状態を監視するヘルスチェックではないという点に注意してください。例えば、Route 53 ヘルスチェックとは異なり、ルーティングコントロールは応答時間や TCP 接続時間をモニタリングしません。ルーティングコントロールは、ヘルスチェックを制御するシンプルなオン/オフスイッチです。通常、状態を変更してトラフィックをリダイレクトすると、その変更によってトラフィックがアプリケーションスタック全体における特定のエンドポイントに移動したり、アプリケーションスタック全体へのルーティングができなくなったりします。例えば、ルーティングコントロールの状態を On から Off に変更する単純なシナリオでは、DNS フェイルオーバーレコードに関連付けた Route 53 ヘルスチェックが更新され、トラフィックがエンドポイントの外に移動します。

ルーティングコントロールの使用方法

ルーティングコントロールの状態を更新してトラフィックを再ルーティングできるようにするには、ARC のクラスターエンドポイントのいずれかに接続する必要があります。接続しようとしているエンドポイントが使用できない場合は、別のクラスターエンドポイントで状態を変更してみてください。クラスターのエンドポイントは、定期的なメンテナンスや更新により、使用可能状態と使用不可状態が切り替わるため、ルーティングコントロールの状態を変更するプロセスは各エンドポイントを交代で試すように準備しておく必要があります。

ルーティングコントロールを作成するときは、ルーティングコントロールのヘルスチェックを各アプリケーションレプリカのフロントにある Route 53 DNS 名に関連付けるように DNS レコードを設定します。例えば、2 つのリージョンにそれぞれ 1 つずつ、2 つのロードバランサー間のトラフィックフェイルオーバーを制御するには、ルーティングコントロールのヘルスチェックを 2 つ作成し、それらを 2 つの DNS レコード (フェイルオーバールーティングポリシー付きのエイリアスレコード、それぞれのロードバランサーのドメイン名が付いたエイリアスレコードなど) に関連付けます。

また、ARC ルーティングコントロールと Route 53 ヘルスチェックおよび DNS レコードセットを併用し、加重ルーティングポリシーを持つ DNS レコードを使用することで、より複雑なトラフィックフェイルオーバーシナリオを設定することもできます。詳細な例については、ブログ AWS 記事「Amazon Application Recovery Controller (ARC) を使用した回復力の高いアプリケーションの構築」の「パート 2: マルチリージョンスタック」の「ユーザートラフィックのフェイルオーバーに関するセクションを参照してください。

ルーティングコントロール AWS リージョン を使用して のフェイルオーバーを開始すると、トラフィックフローに関連する手順により、トラフィックがすぐにリージョン外に移動しない場合があります。また、クライアントの動作と接続の再利用によっては、リージョン内の進行中の既存の接続が完了するまでに短い時間がかかる場合があります。お使いの DNS 設定やその他の要因によって、既存の接続が数分で完了したり、さらに時間がかかったりする場合があります。詳細については、「トラフィックシフトが迅速に終了するようにする」を参照してください。

ルーティングコントロールの利点

ARC のルーティングコントロールには、従来のヘルスチェックでトラフィックを再ルーティングする利点がいくつかあります。例：

• ルーティングコントロールでは、アプリケーションスタック全体をフェイルオーバーできます。これは、Amazon EC2 インスタンスのように、リソースレベルのヘルスチェックに基づいてスタックの個々のコンポーネントをフェイルオーバーするのとは対照的です。

• ルーティングコントロールでは、安全で簡単に手動で上書きができ、内部モニタが問題を検出しなかった場合に、トラフィックをメンテナンスのためにシフトしたり、障害からリカバリするためにシフトしたりできます。

• ルーティングコントロールと安全ルールを組み合わせて使用することで、完全に自動化されたヘルスチェックベースの自動化で発生する可能性のある一般的な副作用 (フェイルオーバーの準備が整っていないスタンバイインフラストラクチャへのフェイルオーバーなど) を防げます。

以下は、ルーティングコントロールをフェイルオーバー戦略に組み込んで、アプリケーションの耐障害性と可用性を向上させる例です AWS。

リージョン間で複数の (通常は 3 つの) 冗長レプリカを実行する AWS ことで、 で高可用性 AWS アプリケーションをサポートできます。そして、Amazon Route 53 のルーティングコントロールを使用して、トラフィックを適切なレプリカにルーティングできます。

例えば、1 つのアプリケーションレプリカをアクティブに設定してアプリケーショントラフィックを処理し、もう 1 つのアプリケーションレプリカをスタンバイレプリカとして設定できます。アクティブなレプリカに障害が発生した場合、ユーザーのトラフィックをスタンバイレプリカに再ルーティングして、アプリケーションの可用性を復元できます。モニタリングシステムとヘルスチェックシステムからの情報に基づいて、レプリカからフェイルアウェイするかレプリカへフェイルアウェイするかを決定する必要があります。

より迅速なリカバリを実現したい場合、アーキテクチャに合わせて選択できる別のオプションとしては、アクティブ/アクティブ実装があります。このアプローチでは、レプリカは同時にアクティブになります。つまり、トラフィックを別のアクティブなレプリカに再ルーティングするだけで、障害のあるアプリケーションレプリカからユーザーを遠ざけることで、障害から回復できます。