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

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

ルーティングコントロールは、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 つのアプリケーションレプリカをスタンバイレプリカとして設定できます。アクティブなレプリカに障害が発生した場合、ユーザーのトラフィックをスタンバイレプリカに再ルーティングして、アプリケーションの可用性を復元できます。レプリカとの間でフェイルアウェイを行うかどうかは、モニタリングシステムとヘルスチェックシステムの情報に基づいて判断する必要があります。

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