Application Load Balancer のターゲットグループ - エラスティックロードバランシング

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Application Load Balancer のターゲットグループ

ターゲットグループは、指定されたプロトコルとポート番号を使用して、登録済みのターゲット (EC2 インスタンスなど) ごとにリクエストをルーティングできます。1 つのターゲットを複数のターゲットグループに登録できます。ターゲットグループ単位でヘルスチェックを設定できます。ヘルスチェックは、ロードバランサーのリスナールールに指定されたターゲットグループに登録されたすべてのターゲットで実行されます。

各ターゲットグループは、1 つ以上の登録されているターゲットにリクエストをルーティングするために使用されます。各リスナーのルールを作成するときに、ターゲットグループと条件を指定します。ルールの条件が満たされると、トラフィックが該当するターゲットグループに転送されます。さまざまなタイプのリクエストに応じて別のターゲットグループを作成できます。たとえば、一般的なリクエスト用に 1 つのターゲットグループを作成し、アプリケーションのマイクロサービスへのリクエスト用に別のターゲットグループを作成できます。各ターゲットグループは 1 つのロードバランサーのみで使用できます。詳細については、「Application Load Balancer のコンポーネント」を参照してください。

ロードバランサーのヘルスチェック設定は、ターゲットグループ単位で定義します。各ターゲットグループはデフォルトのヘルスチェック設定を使用します。ただし、ターゲットグループを作成したときや、後で変更したときに上書きした場合を除きます。リスナーのルールでターゲットグループを指定すると、ロードバランサーは、ロードバランサーで有効なアベイラビリティーゾーンにある、ターゲットグループに登録されたすべてのターゲットの状態を継続的にモニタリングします。ロードバランサーは、正常な登録済みターゲットにリクエストをルーティングします。

ルーティング設定

デフォルトでは、ロードバランサーはターゲットグループの作成時に指定したプロトコルとポート番号を使用して、リクエストをターゲットにルーティングします。または、ターゲットグループへの登録時にターゲットへのトラフィックのルーティングに使用されるポートを上書きすることもできます。

ターゲットグループでは、次のプロトコルとポートがサポートされています。

  • プロトコル: HTTP、HTTPS

  • ポート: 1 ~ 65535

ターゲットグループが HTTPS プロトコルで設定されているか HTTPS ヘルスチェックを使用している場合に、HTTPS リスナーが TLS 1.3 セキュリティポリシーを使用すると、ターゲット接続には ELBSecurityPolicy-TLS13-1-0-2021-06 セキュリティポリシーが使用されます。これ以外の場合には ELBSecurityPolicy-2016-08 セキュリティポリシーが使用されます。ロードバランサーは、ターゲットにインストールする証明書を使用して、ターゲットとの TLS 接続を確立します。ロードバランサーはこれらの証明書を検証しません。したがって、自己署名証明書または期限切れの証明書を使用できます。ロードバランサーとそのターゲットは仮想プライベートクラウド (VPC) 内にあり、ロードバランサーとターゲット間のトラフィックはパケットレベルで認証されるため、ターゲットの証明書が有効でない場合でも、中間者攻撃やスプーフィングのリスクはありません。から出るトラフィック AWS は、これらの同じ保護を持たないため、トラフィックをさらに保護するために追加の手順が必要になる場合があります。

[Target type (ターゲットタイプ)]

ターゲットグループを作成するときは、そのターゲットの種類を指定します。それにより、このターゲットグループ内でターゲットを登録するときに指定するターゲットの種類が決定されます。ターゲットグループを作成した後で、ターゲットの種類を変更することはできません。

可能なターゲットの種類は次のとおりです。

instance

インスタンス ID で指定されたターゲット。

ip

ターゲットは IP アドレスです。

lambda

ターゲットは Lambda 関数です。

ターゲットの種類が ip の場合、次のいずれかの CIDR ブロックから IP アドレスを指定できます。

  • ターゲットグループの VPC のサブネット

  • 10.0.0.0/8 (RFC 1918)

  • 100.64.0.0/10 (RFC 6598)

  • 172.16.0.0/12 (RFC 1918)

  • 192.168.0.0/16 (RFC 1918)

重要

パブリックにルーティング可能な IP アドレスは指定できません。

サポートされているすべての CIDR ブロックによって、次のターゲットをターゲットグループに登録できます。

  • ロードバランサー VPC (同じリージョンまたは異なるリージョン) にピアリングされている VPC 内のインスタンス。

  • AWS IP アドレスとポート (データベースなど) でアドレス可能な リソース。

  • AWS Direct Connect または Site-to-Site VPN 接続 AWS を介して にリンクされたオンプレミスリソース。

注記

Local Zone 内にデプロイされた Application Load Balancer の場合、トラフィックを受信するには ip ターゲットが同じ Local Zone 内にある必要があります。

詳細については、AWS 「ローカルゾーンとは」を参照してください。

インスタンス ID を使用してターゲットを指定すると、トラフィックはインスタンスのプライマリネットワークインターフェイスで指定されたプライマリプライベート IP アドレスを使用して、インスタンスにルーティングされます。IP アドレスを使用してターゲットを指定する場合は、1 つまたは複数のネットワークインターフェイスからのプライベート IP アドレスを使用して、トラフィックをインスタンスにルーティングできます。これにより、インスタンスの複数のアプリケーションが同じポートを使用できるようになります。各ネットワークインターフェイスは独自のセキュリティグループを持つことができます。

ターゲットグループのターゲットの種類が lambda である場合、1 つの Lambda 関数を登録できます。ロードバランサーが Lambda 関数のリクエストを受け取ると、Lambda 関数を呼び出します。詳細については、「Lambda 関数を Application Load Balancer のターゲットとして使用する」を参照してください。

Application Load Balancer のターゲットとして、Amazon Elastic Container Service (Amazon ECS) を設定できます。詳細については、「Amazon Elastic Container Service デベロッパーガイド」の「Amazon ECS 用の Application Load Balancer を使用する」を参照してください。

IP アドレスタイプ

新しいターゲットグループを作成するときは、ターゲットグループの IP アドレスタイプを選択できます。これは、ターゲットとの通信、およびそれらのヘルスステータスのチェックに使用される IP バージョンを制御します。

Application Load Balancer は、IPv4 ターゲットグループと IPv6 ターゲットグループの両方をサポートします。デフォルトで選択されるのは IPv4 です。

考慮事項
  • ターゲットグループ内のすべての IP アドレスは、同じ IP アドレスタイプである必要があります。例えば、IPv4 ターゲットを IPv6 ターゲットグループに登録することはできません。

  • IPv6 ターゲットグループは、dualstack ロードバランサーのみで使用できます。

  • IPv6 ターゲットグループでは、IP およびインスタンスタイプのターゲットがサポートされています。

プロトコルバージョン

デフォルトでは、Application Load Balancer は HTTP/1.1 を使用してターゲットにリクエストを送信します。プロトコルバージョンを使用して、HTTP/2 または grPC を使用するターゲットにリクエストを送信できます。

次の表は、リクエストプロトコルとターゲットグループのプロトコルバージョンの組み合わせの結果をまとめたものです。

リクエストプロトコル プロトコルバージョン 結果
HTTP/1.1 HTTP/1.1 成功
HTTP/2 HTTP/1.1 成功
gRPC HTTP/1.1 エラー
HTTP/1.1 HTTP/2 エラー
HTTP/2 HTTP/2 成功
gRPC HTTP/2 ターゲットが grPC をサポートしている場合は成功
HTTP/1.1 gRPC エラー
HTTP/2 gRPC POST リクエストの場合は成功
gRPC gRPC 成功
gRPC プロトコルバージョンの考慮事項
  • サポートされているリスナープロトコルは HTTPS だけです。

  • リスナールールでサポートされるアクションタイプは、forward のみです 。

  • サポートされているターゲットタイプは、instanceip のみです。

  • ロードバランサーは、gRPC リクエストを解析し、パッケージ、サービス、メソッドに基づいて、適切なターゲットグループに gRPC 呼び出しをルーティングします。

  • ロードバランサーは、単項ストリーミング、クライアントサイドストリーミング、サーバーサイドストリーミング、および双方向ストリーミングをサポートします。

  • カスタムヘルスチェックメソッドには、/package.service/method という形式で指定する必要があります。

  • ターゲットからの正常な応答をチェックするときに使用する gRPC ステータスコードを指定する必要があります。

  • Lambda 関数をターゲットとして使用することはできません。

HTTP/2 プロトコルバージョンの考慮事項
  • サポートされているリスナープロトコルは HTTPS だけです。

  • リスナールールでサポートされるアクションタイプは、forward のみです 。

  • サポートされているターゲットタイプは、instanceip のみです。

  • ロードバランサーは、クライアントからのストリーミングをサポートします。ロードバランサーは、ターゲットへのストリーミングをサポートしていません。

登録済みターゲット

ロードバランサーは、クライアントにとって単一の通信先として機能し、正常な登録済みターゲットに受信トラフィックを分散します。各ターゲットは、1 つ以上のターゲットグループに登録できます。

アプリケーションの需要が高まった場合、需要に対処するため、1 つまたは複数のターゲット グループに追加のターゲットを登録できます。登録処理が完了し、ターゲットが最初のヘルスチェックに合格するとすぐに、設定されたしきい値に関係なく、ロードバランサーは新たに登録したターゲットへのトラフィックのルーティングを開始します。

アプリケーションの需要が低下した場合や、ターゲットを保守する必要がある場合、ターゲットグループからターゲットを登録解除することができます。ターゲットを登録解除するとターゲットグループから削除されますが、ターゲットにそれ以外の影響は及びません。登録解除するとすぐに、ロードバランサーはターゲットへのリクエストのルーティングを停止します。ターゲットは、未処理のリクエストが完了するまで draining 状態になります。リクエストの受信を再開する準備ができると、ターゲットをターゲットグループに再度登録することができます。

インスタンス ID でターゲットを登録する場合は、Auto Scaling グループでロードバランサーを使用できます。Auto Scaling グループにターゲットグループをアタッチすると、ターゲットの起動時に Auto Scaling によりターゲットグループにターゲットが登録されます。詳細については、Amazon EC2 Auto Scaling ユーザーガイドのAuto Scaling グループへのロードバランサーのアタッチを参照してください。

制限
  • 同じ VPC に別の Application Load Balancer の IP アドレスを登録することはできません。もう一方の Application Load Balancer が、ロードバランサー VPC にピアリング接続されている VPC に含まれている場合は、その IP アドレスを登録できます。

  • ロードバランサー VPC (同じリージョンまたは異なるリージョン) とピア接続されている VPC にインスタンスがある場合、そのインスタンスをインスタンス ID で登録することはできません。このようなインスタンスは IP アドレスで登録できます。

ターゲットグループの属性

ターゲットグループは属性を編集することで設定できます。詳細については、「ターゲットグループ属性を編集する」を参照してください。

ターゲットグループの種類が instance または ip である場合、以下のターゲットグループ属性がサポートされています。

deregistration_delay.timeout_seconds

ターゲットを登録解除する前に Elastic Load Balancing が待機する時間。範囲は 0 ~ 3600 秒です。デフォルト値は 300 秒です。

load_balancing.algorithm.type

ロードバランシングアルゴリズムは、リクエストをルーティングするときにロードバランサーがターゲットを選択する方法を決定します。値は round_robinleast_outstanding_requestsweighted_random のいずれかです。デフォルト: round_robin

load_balancing.algorithm.anomaly_mitigation

load_balancing.algorithm.typeweighted_random である場合のみ使用できます。異常緩和が有効になっているかどうかを示します。値は on または off です。デフォルト: off

load_balancing.cross_zone.enabled

クロスゾーンロードバランサーが有効かどうかを示します。値は truefalse または use_load_balancer_configuration です。デフォルト: use_load_balancer_configuration

slow_start.duration_seconds

ロードバランサーが新しく登録されたターゲットに、ターゲットグループに対するトラフィックのシェアを直線的に増加させて送信する期間 (秒)。範囲は 30 ~ 900 秒 (15 分) です。デフォルトは 0 秒 (無効) です。

stickiness.enabled

スティッキーセッションが有効かどうかを示します。値は true または false です。デフォルト: false

stickiness.app_cookie.cookie_name

アプリケーション Cookie 名 アプリケーション Cookie 名に、ロードバランサーで使用するために予約されている AWSALBAWSALBAPP、または AWSALBTG のプレフィックスを含めることはできません。

stickiness.app_cookie.duration_seconds

アプリケーションベースの Cookie の有効期間 (秒) この期間が過ぎると、Cookie は古いと見なされます。最小値は 1 秒で、最大値は 7 日間 (604800秒) です。デフォルト値は 1 日 (86400 秒) です。

stickiness.lb_cookie.duration_seconds

期間ベースの Cookie の有効期間 (秒) この期間が過ぎると、Cookie は古いと見なされます。最小値は 1 秒で、最大値は 7 日間 (604800秒) です。デフォルト値は 1 日 (86400 秒) です。

stickiness.type

維持の種類です。指定できる値は lb_cookie および app_cookie です。

target_group_health.dns_failover.minimum_healthy_targets.count

正常である必要があるターゲットの最小数。正常なターゲットの数がこの値を下回っている場合は、DNS でそのゾーンを異常とマークして、トラフィックが正常なゾーンにのみルーティングされるようにします。指定できる値は off または 1 から最大ターゲット数までの整数です。off の場合、DNS フェイルアウェイは無効になります。つまり、ターゲットグループ内のすべてのターゲットが異常でも、ノードは DNS から削除されません。デフォルトは 1 です。

target_group_health.dns_failover.minimum_healthy_targets.percentage

正常でなければならないターゲットの最小割合。正常なターゲットの割合がこの値を下回っている場合は、DNS でそのノードを異常としてマークし、トラフィックが正常なノードにのみルーティングされるようにします。指定できる値は off または 1 から最大ターゲット数までの整数です。off の場合、DNS フェイルアウェイは無効になります。つまり、ターゲットグループ内のすべてのターゲットが異常でも、ノードは DNS から削除されません。デフォルト: off

target_group_health.unhealthy_state_routing.minimum_healthy_targets.count

正常でなければならないターゲットの最小数。正常なターゲットの数がこの値を下回っている場合は、異常なターゲットを含むすべてのターゲットにトラフィックを送信します。範囲は 1 からターゲットの最大数です。デフォルトは 1 です。

target_group_health.unhealthy_state_routing.minimum_healthy_targets.percentage

正常でなければならないターゲットの最小割合。正常なターゲットの割合がこの値を下回っている場合は、異常なターゲットを含むすべてのターゲットにトラフィックを送信します。指定できる値は、off または 1 から 100 までの整数です。デフォルト: off

ターゲットグループの種類が lambda である場合、以下のターゲット属性がサポートされています。

lambda.multi_value_headers.enabled

ロードバランサーと Lambda 関数との間で交換されるリクエストとレスポンスのヘッダーに、値のまたは文字列の配列が含まれるかどうかを示します。使用できる値は、true または false です。デフォルト値は false です。詳細については、「複数値ヘッダー」を参照してください。

ルーティングアルゴリズム

ルーティングアルゴリズムとは、ロードバランサーがリクエストを受信するターゲットを決定する際に使う方法です。ターゲットグループレベルのリクエストのルーティングには、ラウンドロビンのルーティングアルゴリズムがデフォルトで使用されます。アプリケーションのニーズに応じて最小の未処理のリクエスト加重ランダムのルーティングアルゴリズムも利用できます。ターゲットグループは一度に 1 つのアクティブなルーティングアルゴリズムしか使用できませんが、ルーティングアルゴリズムは必要に応じて更新が可能です。

スティッキーセッションを有効にすると、選択したルーティングアルゴリズムが最初のターゲット選択に使用されます。それ以降の同じクライアントからのリクエストは、同じターゲットに、選択したルーティングアルゴリズムをバイパスして転送されます。

ラウンドロビン
  • ラウンドロビンのルーティングアルゴリズムは、ターゲットグループ内の正常なターゲットにリクエストを均等かつ順番のとおりにルーティングします。

  • このアルゴリズムは、受信するリクエスト間で複雑さが類似している場合、登録されたターゲットの処理能力が類似している場合、またはターゲット間でリクエストを均等に分散する必要がある場合によく使用されます。

最小の未処理のリクエスト
  • 最も未処理のリクエストのルーティングアルゴリズムは、進行中のリクエストの数が最も少ないターゲットにリクエストをルーティングします。

  • このアルゴリズムは通常、受信するリクエスト間で複雑さが異なり、登録されたターゲットの処理能力が異なる場合に使用されます。

  • HTTP/2 をサポートするロードバランサーが HTTP/1.1 のみをサポートするターゲットを使用している場合、リクエストは複数の HTTP/1.1 リクエストに変換されます。この設定では、最小の未処理のリクエストのアルゴリズムは、各 HTTP/2 リクエストを複数のリクエストとして扱います。

  • WebSockets を使用すると、ターゲットは最小の未処理のリクエストのアルゴリズムを使用して選択されます。一度選択すると、ロードバランサーはこのターゲットへの接続を作成して、すべてのメッセージをこの接続を介して送信します。

  • 最小の未処理のリクエストのルーティングアルゴリズムは、スロースタートモードでは使用できません。

加重ランダム
  • 加重ランダムのルーティングアルゴリズムは、ターゲットグループ内の正常なターゲットにリクエストを均等に、ランダムな順序でルーティングします。

  • このアルゴリズムは、自動ターゲット加重 (ATW) の異常緩和をサポートします。

  • 加重ランダムのルーティングアルゴリズムは、スロースタートモードでは使用できません。

  • 加重ランダムルーティングアルゴリズムは、スティッキーセッションでは使用できません。

ターゲットグループのルーティングアルゴリズムを変更する

ターゲットグループのルーティングアルゴリズムはいつでも変更できます。

新しいコンソールを使用してルーティングアルゴリズムを変更するには
  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインの [ Load Balancing (ロードバランシング) ] で [ Target Groups (ターゲットグループ) ] を選択します。

  3. ターゲットグループの名前を選択して、その詳細ページを開きます。

  4. ターゲットグループの詳細 ページの [属性] セクションで [編集] を選択します。

  5. [ターゲットグループ属性を編集] ページの [トラフィックの設定] セクションにある [ロードバランシングアルゴリズム] で、[ラウンドロビン][最小の未処理のリクエスト][加重ランダム] のいずれかを選択します。

  6. [Save changes] (変更の保存) をクリックします。

を使用してルーティングアルゴリズムを変更するには AWS CLI

load_balancing.algorithm.type 属性を指定して modify-target-group-attributes コマンドを使用します。

ターゲットグループのヘルス

デフォルトでは、ターゲットグループが少なくとも 1 つの正常なターゲットを持っている限り、そのターゲットグループは正常であると見なされます。フリートが大きい場合、トラフィックを処理する正常なターゲットが 1 つだけでは十分ではありません。代わりに、正常でなければならないターゲットの最小数または割合、および正常なターゲットが指定されたしきい値を下回ったときにロードバランサーが実行するアクションを指定できます。これにより、可用性が向上します。

異常な状態アクション

以下のアクションに対して正常なしきい値を設定できます。

  • DNS フェイルオーバー - ゾーン内の正常なターゲットがしきい値を下回ると、そのゾーンのロードバランサーノードの IP アドレスが DNS で異常とマークされます。そのため、クライアントがロードバランサーの DNS 名を解決すると、トラフィックは正常なゾーンにのみルーティングされます。

  • ルーティングフェイルオーバー - ゾーン内の正常なターゲットがしきい値を下回ると、ロードバランサーは、異常なターゲットを含め、ロードバランサーノードで使用可能なすべてのターゲットにトラフィックを送信します。これにより、特にターゲットが一時的にヘルスチェックに合格しなかった場合に、クライアント接続が成功する可能性が高まり、正常なターゲットが過負荷になるリスクが軽減されます。

要件と考慮事項

  • ターゲットが Lambda 関数であるターゲットグループでは、この機能は使用できません。Application Load Balancer が Network Load Balancer または Global Accelerator のターゲットである場合は、DNS フェイルオーバーのしきい値を設定しないでください。

  • アクションに両方のタイプのしきい値 (数と割合) を指定すると、どちらかのしきい値に達したときにロードバランサーがアクションを実行します。

  • 両方のアクションにしきい値を指定する場合、DNS フェイルオーバーのしきい値はルーティングフェイルオーバーのしきい値以上である必要があります。これにより、DNS フェイルオーバーはルーティングフェイルオーバーの有無にかかわらず発生します。

  • しきい値を割合として指定すると、ターゲットグループに登録されているターゲットの総数に基づいて、値が動的に計算されます。

  • ターゲットの合計数は、クロスゾーンロードバランサーがオフになっているかオンになっているかによって決まります。クロスゾーンロードバランサーがオフの場合、各ノードは独自のゾーン内のターゲットにのみトラフィックを送信します。つまり、しきい値は有効になっている各ゾーンのターゲット数に個別に適用されます。クロスゾーン負荷分散がオンの場合、各ノードはすべての有効ゾーンのすべてのターゲットにトラフィックを送信します。つまり、指定されたしきい値はすべての有効ゾーンのターゲットの総数に適用されます。

  • DNS フェイルオーバーでは、ロードバランサーの DNS ホスト名から異常のあるゾーンの IP アドレスを削除します。ただし、ローカルクライアントの DNS キャッシュには、DNS レコードの有効期限 (TTL) が期限切れになる (60 秒) まで、これらの IP アドレスが含まれる場合があります。

  • DNS フェイルオーバーが発生すると、ロードバランサーに関連するすべてのターゲットグループに影響します。特にクロスゾーンロードバランサーがオフになっている場合は、この追加のトラフィックを処理するのに十分な容量が残りのゾーンにあることを確認してください。

  • DNS フェイルオーバーでは、すべてのロードバランサーゾーンが異常と見なされると、ロードバランサーは異常なゾーンを含むすべてのゾーンにトラフィックを送信します。

  • DNS フェイルオーバーにつながる可能性のある正常なターゲットが十分にあるかどうか以外にも、ゾーンのヘルスなどの要因があります。

モニタリング

ターゲットグループのヘルスを監視するには、「CloudWatch metrics for target group health」(ターゲットグループのヘルスの CloudWatch メトリクス) を参照してください。

次の例は、ターゲットグループのヘルス設定がどのように適用されるかを示しています。

シナリオ
  • 2 つのアベイラビリティーゾーン A と B をサポートするロードバランサー

  • 各アベイラビリティーゾーンには 10 の登録済みターゲットが含まれています

  • ターゲットグループには、次のターゲットグループのヘルス設定があります。

    • DNS フェイルオーバー - 50%

    • ルーティングフェイルオーバー - 50%

  • アベイラビリティーゾーン B で 6 つのターゲットが失敗

クロスゾーンロードバランサーがオフの場合
  • 各アベイラビリティーゾーンのロードバランサーノードは、アベイラビリティーゾーンの 10 個のターゲットにのみトラフィックを送信できます。

  • アベイラビリティーゾーン A には 10 個の正常なターゲットがあり、これは正常なターゲットの必要な割合を満たしています。ロードバランサーは引き続き、10 の正常なターゲット間でトラフィックを分散します。

  • アベイラビリティーゾーン B には正常なターゲットが 4 つしかなく、これはアベイラビリティーゾーン B のロードバランサーノードのターゲットの 40% です。これは正常なターゲットの必要なパーセンテージを下回っているため、ロードバランサーは次のアクションを実行します。

    • DNS フェイルオーバー - アベイラビリティーゾーン B が DNS で異常とマークされています。クライアントはロードバランサー名をアベイラビリティーゾーン B のロードバランサーノードに解決できず、アベイラビリティーゾーン A は正常であるため、クライアントはアベイラビリティーゾーン A に新しい接続を送信します。

    • ルーティングフェイルオーバー - 新しい接続がアベイラビリティーゾーン B に明示的に送信されると、ロードバランサーは、異常なターゲットを含むアベイラビリティーゾーン B のすべてのターゲットにトラフィックを分散します。これにより、残りの正常なターゲット間でのシステム停止を防ぐことができます。

クロスゾーンロードバランサーがオンの場合
  • 各ロードバランサーノードは、両方のアベイラビリティーゾーンの 20 の登録済みターゲットすべてにトラフィックを送信できます。

  • アベイラビリティーゾーン A には 10 個の正常なターゲット、アベイラビリティーゾーン B には 4 個の正常なターゲット、合計 14 個の正常なターゲットがあります。これは両方のアベイラビリティーゾーンのロードバランサーノードのターゲットの 70% であり、正常なターゲットの必要な割合を満たしています。

  • ロードバランサーは、両方のアベイラビリティーゾーンの 14 個の正常なターゲット間でトラフィックを分散します。

ロードバランサーの Route 53 DNS フェイルオーバーを使用する

Route 53 を使用して DNS クエリをロードバランサーにルーティングする場合は、同時に Route 53 によりロードバランサーの DNS フェイルオーバーを設定することもできます。フェイルオーバー設定では、ロードバランサー用のターゲットグループのターゲットに関する正常性チェックが Route 53 によって行われ、利用可能かどうかが判断されます。ロードバランサーに正常なターゲットが登録されていない場合、またはロードバランサー自体で不具合が発生している場合、Route 53 は、トラフィックを別の利用可能なリソース (正常なロードバランサーや、Amazon S3 にある静的ウェブサイトなど) にルーティングします。

例えば、www.example.com 用のウェブアプリケーションがあり、異なるリージョンにある 2 つのロードバランサーの背後で冗長なインスタンスを実行するとします。1 つのリージョンのロードバランサーは、主にトラフィックのルーティング先として使用し、もう 1 つのリージョンのロードバランサーは、エラー発生時のバックアップとして使用します DNS フェイルオーバーを設定する場合は、プライマリおよびセカンダリ (バックアップ) ロードバランサーを指定できます。Route 53 は、プライマリロードバランサーが利用可能な場合はプライマリロードバランサーにトラフィックをルーティングし、利用できない場合はセカンダリロードバランサーにルーティングします。

ターゲットの正常性の評価を使用する
  • Application Load Balancer のエイリアスレコードでターゲットの正常性の評価が Yes に設定されている場合、Route 53 は alias target 値で指定されたリソースの正常性を評価します。Application Load Balancer の場合、Route 53 は、ロードバランサーに関連付けられたターゲットグループのヘルスチェックを使用します。

  • Application Load Balancer 内のすべてのターゲットグループが正常である場合、Route 53 はエイリアスレコードを正常としてマークします。ターゲットグループに少なくとも 1 つの正常なターゲットが含まれている場合、ターゲットグループのヘルスチェックは合格となります。その後、Route 53 は、ルーティングポリシーに従ってレコードを返します。フェイルオーバールーティングポリシーを使用すると、Route 53 はプライマリレコードを返します。

  • Application Load Balancer 内のターゲットグループのいずれかが異常な場合、エイリアスレコードは Route 53 ヘルスチェックに失敗します (フェイルオープン)。ターゲットの正常性の評価を使用している場合は、フェイルオーバールーティングポリシーが失敗します。

  • Application Load Balancer 内のすべてのターゲットグループが空である (ターゲットがない) 場合、Route 53 はレコードが異常であるとみなします (フェイルオープン)。ターゲットの正常性の評価を使用している場合は、フェイルオーバールーティングポリシーが失敗します。

詳細については、Amazon Route 53 開発者ガイドの「DNS フェイルオーバーの設定」を参照してください。