Network Load Balancers のターゲットグループ
各ターゲットグループは、1 つ以上の登録されているターゲットにリクエストをルーティングするために使用されます。リスナーを作成するときは、デフォルトアクションのターゲットグループを指定します。トラフィックは、リスナー規則で指定されたターゲットグループに転送されます。さまざまなタイプのリクエストに応じて別のターゲットグループを作成できます。たとえば、一般的なリクエスト用に 1 つのターゲットグループを作成し、アプリケーションのマイクロサービスへのリクエスト用に別のターゲットグループを作成できます。詳細については、「Network Load Balancer のコンポーネント」を参照してください。
ロードバランサーのヘルスチェック設定は、ターゲットグループ単位で定義します。各ターゲットグループはデフォルトのヘルスチェック設定を使用します。ただし、ターゲットグループを作成したときや、後で変更したときに上書きした場合を除きます。リスナーのルールでターゲットグループを指定すると、ロードバランサーは、ロードバランサーで有効なアベイラビリティーゾーンにある、ターゲットグループに登録されたすべてのターゲットの状態を継続的にモニタリングします。ロードバランサーは、正常な登録済みターゲットにリクエストをルーティングします。詳細については、「Network Load Balancer ターゲットグループのヘルスチェック」を参照してください。
目次
ルーティング設定
デフォルトでは、ロードバランサーはターゲットグループの作成時に指定したプロトコルとポート番号を使用して、リクエストをターゲットにルーティングします。または、ターゲットグループへの登録時にターゲットへのトラフィックのルーティングに使用されるポートを上書きすることもできます。
Network Load Balancer のターゲットグループは、次のプロトコルとポートをサポートします。
-
プロトコル: TCP、TLS、UDP、TCP_UDP
-
ポート: 1 ~ 65535
ターゲットグループに TLS プロトコルが設定されている場合、ロードバランサーは、ターゲットにインストールした証明書を使用して、ターゲットと TLS 接続を確立します。ロードバランサーはこれらの証明書を検証しません。したがって、自己署名証明書または期限切れの証明書を使用できます。ロードバランサーは仮想プライベートクラウド (VPC) 内にあるため、ロードバランサーとターゲット間のトラフィックはパケットレベルで認証されるため、ターゲットの証明書が有効でない場合でも、中間者攻撃やスプーフィングのリスクはありません。
次の表は、リスナープロトコルとターゲットグループの設定のサポートされている組み合わせをまとめたものです。
リスナープロトコル | ターゲットグループプロトコル | ターゲットグループの種類 | ヘルスチェックプロトコル |
---|---|---|---|
TCP |
TCP | TCP_UDP |
インスタンス | ip |
HTTP | HTTPS | TCP |
TCP |
TCP |
alb |
HTTP | HTTPS |
TLS |
TCP | TLS |
インスタンス | ip |
HTTP | HTTPS | TCP |
UDP |
UDP | TCP_UDP |
インスタンス | ip |
HTTP | HTTPS | TCP |
TCP_UDP |
TCP_UDP |
インスタンス | ip |
HTTP | HTTPS | TCP |
[Target type (ターゲットタイプ)]
ターゲットグループを作成するときは、そのターゲットの種類を指定します。ターゲットの種類は、ターゲットの指定方法を決定します。ターゲットグループを作成した後で、ターゲットタイプを変更することはできません。
可能なターゲットの種類は次のとおりです。
instance
-
インスタンス ID で指定されたターゲット。
ip
-
IP アドレスで指定されたターゲット。
alb
-
ターゲットは Application Load Balancer です。
ターゲットの種類が ip
の場合、次のいずれかの CIDR ブロックから IP アドレスを指定できます。
重要
パブリックにルーティング可能な IP アドレスは指定できません。
サポートされているすべての CIDR ブロックによって、次のターゲットをターゲットグループに登録できます。
-
IP アドレスとポート (例: データベース) でアドレス可能な AWS リソース。
-
AWS Direct Connect または Site-to-Site VPN 接続を介して AWS にリンクされたオンプレミスのリソース
ターゲットグループでクライアント IP の保存が無効化されている場合、ロードバランサーは Network Load Balancer の IP アドレスと一意のターゲット (IP アドレスとポート) の組み合わせごとに 1 分あたり約 55,000 の接続をサポートできます。これらの接続数を超えた場合、ポート割り当てエラーが発生する可能性が高くなります。ポート割り当てエラーが発生した場合は、ターゲットグループにさらに多くのターゲットを追加します。
共有 Amazon VPC で (参加者として) Network Load Balancer を起動した場合、登録できるのは、共有されているサブネット内のターゲットだけです。
ターゲットタイプが alb
の場合、単一の Application Load Balancer をターゲットとして登録できます。詳細については、「Network Load Balancer のターゲットとして Application Load Balancer を使用する」を参照してください。
Network Load Balancer は、lambda
ターゲットタイプをサポートしていません。Application Load Balancer は、lambda
ターゲットタイプをサポートする唯一のロードバランサーです。詳細については、Application Load Balancer ユーザーガイドのターゲットとしての Lambda 関数を参照してください。
Network Load Balancer に登録されているインスタンスでマイクロサービスを使用している場合、ロードバランサーを使用してインスタンス間の通信を提供することはできません。ただし、ロードバランサーがインターネット向けであるか、インスタンスが IP アドレスで登録されている場合は除きます。詳しくは、「ターゲットからそのロードバランサーへのリクエストが接続タイムアウトになる」を参照してください。
リクエストのルーティングと IP アドレス
インスタンス ID を使用してターゲットを指定すると、トラフィックはインスタンスのプライマリネットワークインターフェイスで指定されたプライマリプライベート IP アドレスを使用して、インスタンスにルーティングされます。ロードバランサーは、データパケットの宛先 IP アドレスを書き換えてから、ターゲットインスタンスに転送します。
IP アドレスを使用してターゲットを指定する場合は、1 つまたは複数のネットワークインターフェイスからのプライベート IP アドレスを使用して、トラフィックをインスタンスにルーティングできます。これにより、インスタンスの複数のアプリケーションが同じポートを使用できるようになります。各ネットワークインターフェイスはそれぞれ独自のセキュリティグループを割り当てることができます。ロードバランサーは、宛先 IP アドレスを書き換えてから、ターゲットに転送します。
インスタンスへのトラフィックの許可の詳細については、ターゲットセキュリティグループ を参照してください。
ターゲットとしてのオンプレミスリソース
ターゲットのタイプが ip
である場合、AWS Direct Connect または Site-to-Site VPN 接続を介してリンクされたオンプレミスのリソース。
オンプレミスのリソースを使用する場合、これらのターゲットの IP アドレスは、引き続き次の CIDR ブロックのいずれかから取得する必要があります。
AWS Direct Connect の詳細については、「AWS Direct Connect とは」を参照してください。
AWS Site-to-Site VPN の詳細については、「AWS Site-to-Site VPN とは」を参照してください。
IP アドレスタイプ
新しいターゲットグループを作成するときは、ターゲットグループの IP アドレスタイプを選択できます。これは、ターゲットとの通信、およびそれらのヘルスステータスのチェックに使用される IP バージョンを制御します。
Network Load Balancer は、IPv4 ターゲットグループと IPv6 ターゲットグループの両方をサポートします。デフォルトで選択されるのは IPv4 です。IPv6 ターゲットグループは、Dualstack Network Load Balancer にのみ関連付けることができます。
考慮事項
-
ターゲットグループ内のすべての IP アドレスは、同じ IP アドレスタイプである必要があります。例えば、IPv4 ターゲットを IPv6 ターゲットグループに登録することはできません。
-
IPv6 ターゲットグループは、TCP または TLS リスナーを使用した
dualstack
ロードバランサーのみで使用できます。 -
IPv6 ターゲットグループでは、IP およびインスタンスタイプのターゲットがサポートされています。
登録済みターゲット
ロードバランサーは、クライアントにとって単一の通信先として機能し、正常な登録済みターゲットに受信トラフィックを分散します。各ターゲットグループでは、ロードバランサーが有効になっている各アベイラビリティーゾーンで少なくとも 1 つのターゲットが登録されている必要があります。各ターゲットは、1 つ以上のターゲットグループに登録できます。
アプリケーションの需要が高まった場合、需要に対処するため、1 つまたは複数のターゲット グループに追加のターゲットを登録できます。設定したしきい値に関係なく、登録処理が完了し、ターゲットが最初の初期ヘルスチェックに合格するとすぐに、ロードバランサーは新しく登録したターゲットへのトラフィックのルーティングを開始します。
アプリケーションの需要が低下した場合や、ターゲットを保守する必要がある場合、ターゲットグループからターゲットを登録解除することができます。ターゲットを登録解除するとターゲットグループから削除されますが、ターゲットにそれ以外の影響は及びません。登録解除するとすぐに、ロードバランサーはターゲットへのトラフィックのルーティングを停止します。ターゲットは、未処理のリクエストが完了するまで draining
状態になります。トラフィックの受信を再開する準備ができると、ターゲットをターゲットグループに再度登録することができます。
インスタンス ID でターゲットを登録する場合は、Auto Scaling グループでロードバランサーを使用できます。Auto Scaling グループにターゲットグループをアタッチすると、ターゲットの起動時に Auto Scaling によりターゲットグループにターゲットが登録されます。詳細については、Amazon EC2 Auto Scaling ユーザーガイドのAuto Scaling グループへのロードバランサーのアタッチを参照してください。
要件と考慮事項
-
インスタンスで使用されているインスタンスタイプが C1、CC1、CC2、CG1、CG2、CR1、G1、G2、HI1、HS1、M1、M2、M3、T1 のいずれかである場合、インスタンス ID でインスタンスを登録することはできません。
-
IPv6 ターゲットグループにインスタンス ID でターゲットを登録する場合、ターゲットにはプライマリ IPv6 アドレスが割り当てられている必要があります。詳細については、「Amazon EC2 ユーザーガイド」の「IPv6 アドレス」を参照してください。
-
インスタンス ID でターゲットを登録する場合、インスタンスは Network Load Balancer と同じ Amazon VPC にある必要があります。ロードバランサー VPC (同じリージョンまたは異なるリージョン) とピア接続されている VPC にインスタンスがある場合、そのインスタンスをインスタンス ID で登録することはできません。このようなインスタンスは IP アドレスで登録できます。
-
ターゲットを IP アドレスで登録し、その IP アドレスがロードバランサーと同じ VPC にある場合、ロードバランサーは、到達可能なサブネットからターゲットがアクセスしていることを確認します。
-
ロードバランサーは、有効になっているアベイラビリティーゾーン内のターゲットのみにトラフィックをルーティングします。有効になっていないゾーン内のターゲットは使用されません。
-
UDP および TCP_UDP ターゲットグループの場合、インスタンスがロードバランサー VPC の外部に存在するか、インスタンスタイプとして C1、CC1、CC2、CG1、CG2、CR1、G1、G2、HI1、HS1、M1、M2、M3、T1 のいずれかを使用しているときは、IP アドレスでインスタンスを登録しないでください。ロードバランサー VPC の外部に存在するか、サポートされていないインスタンスタイプを使用するターゲットは、ロードバランサーからのトラフィックを受信できても、応答できない場合があります。
ターゲットグループの属性
属性を編集することで、ターゲットグループを設定できます。詳細については、「ターゲットグループ属性を編集する」を参照してください。
次のターゲット グループの属性がサポートされています。これらの属性は、ターゲットグループタイプが instance
または ip
の場合にのみ変更できます。ターゲットグループタイプが alb
の場合、これらの属性は常にデフォルト値を使用します。
deregistration_delay.timeout_seconds
-
登録解除するターゲットの状態が
draining
からunused
に変わるのを Elastic Load Balancing が待機する時間。範囲は 0 ~ 3600 秒です。デフォルト値は 300 秒です。 deregistration_delay.connection_termination.enabled
-
ロードバランサーが登録解除タイムアウトの終了時に接続を終了するかどうかを示します。値は
true
またはfalse
です。新しい UDP/TCP_UDP ターゲットグループの場合、デフォルトはtrue
です。それ以外の場合は、デフォルトはfalse
です。 load_balancing.cross_zone.enabled
-
クロスゾーンロードバランサーが有効かどうかを示します。値は
true
、false
またはuse_load_balancer_configuration
です。デフォルト:use_load_balancer_configuration
。 preserve_client_ip.enabled
-
クライアント IP の保存が有効かどうかを示します。値は
true
またはfalse
です。ターゲットグループの種類が IP アドレスで、ターゲットグループプロトコルが TCP または TLS の場合、デフォルトは無効です。それ以外の場合、デフォルトは有効です。UDP および TCP_UDP ターゲットグループのクライアント IP 保存を無効にすることはできません。 proxy_protocol_v2.enabled
-
Proxy Protocol バージョン 2 が有効になっているかどうかを示します。Proxy Protocol は、デフォルトで無効になっています。
stickiness.enabled
-
スティッキーセッションが有効かどうかを示します。値は
true
またはfalse
です。デフォルト:false
。 stickiness.type
-
維持の種類です。有効な値は
source_ip
です。 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 から 100 までの整数です。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
。 target_health_state.unhealthy.connection_termination.enabled
-
ロードバランサーが異常なターゲットへの接続を終了するかどうかを示します。値は
true
またはfalse
です。デフォルト:true
。 target_health_state.unhealthy.draining_interval_seconds
-
異常なターゲットの状態が
unhealthy.draining
からunhealthy
に変わるのを Elastic Load Balancing が待機する時間。範囲は 0~360,000 秒です。デフォルト値は0秒です。[注:] この属性は、
target_health_state.unhealthy.connection_termination.enabled
がfalse
の場合にのみ設定できます。
ターゲットグループの正常性
デフォルトでは、ターゲットグループが少なくとも 1 つの正常なターゲットを持っている限り、そのターゲットグループは正常であると見なされます。フリートが大きい場合、トラフィックを処理する正常なターゲットが 1 つだけでは十分ではありません。代わりに、正常でなければならないターゲットの最小数または割合、および正常なターゲットが指定されたしきい値を下回ったときにロードバランサーが実行するアクションを指定できます。これにより、可用性が向上します。
異常な状態アクション
以下のアクションに対して正常なしきい値を設定できます。
-
DNS フェイルオーバー - ゾーン内の正常なターゲットがしきい値を下回ると、そのゾーンのロードバランサーノードの IP アドレスが DNS で異常とマークされます。そのため、クライアントがロードバランサーの DNS 名を解決すると、トラフィックは正常なゾーンにのみルーティングされます。
-
ルーティングフェイルオーバー - ゾーン内の正常なターゲットがしきい値を下回ると、ロードバランサーは、異常なターゲットを含め、ロードバランサーノードで使用可能なすべてのターゲットにトラフィックを送信します。これにより、特にターゲットが一時的にヘルスチェックに合格しなかった場合に、クライアント接続が成功する可能性が高まり、正常なターゲットが過負荷になるリスクが軽減されます。
要件と考慮事項
-
アクションに両方のタイプのしきい値 (数と割合) を指定した場合、ロードバランサーはどちらかのしきい値を超えるとアクションを実行します。
-
両方のアクションにしきい値を指定する場合、DNS フェイルオーバーのしきい値はルーティングフェイルオーバーのしきい値以上である必要があります。これにより、DNS フェイルオーバーはルーティングフェイルオーバーの有無にかかわらず発生します。
-
しきい値を割合として指定すると、ターゲットグループに登録されているターゲットの総数に基づいて、値が動的に計算されます。
-
ターゲットの合計数は、クロスゾーンロードバランサーがオフになっているかオンになっているかによって決まります。クロスゾーンロードバランサーがオフの場合、各ノードは独自のゾーン内のターゲットにのみトラフィックを送信します。つまり、しきい値は有効になっている各ゾーンのターゲット数に個別に適用されます。クロスゾーンロードバランサーがオンの場合、各ノードは有効なすべてのゾーンのすべてのターゲットにトラフィックを送信します。つまり、指定されたしきい値が有効になっているすべてのゾーンのターゲットの総数に適用されます。詳細については、「クロスゾーンロードバランサー」を参照してください。
-
DNS フェイルオーバーでは、ロードバランサーの DNS ホスト名から異常なゾーンの IP アドレスを削除します。ただし、ローカルクライアントの DNS キャッシュには、DNS レコードの有効期限 (TTL) が期限切れになる (60 秒) まで、これらの IP アドレスが含まれる場合があります。
-
DNS フェイルオーバーが発生すると、ロードバランサーに関連するすべてのターゲットグループに影響します。特にクロスゾーンロードバランサーがオフになっている場合は、この追加のトラフィックを処理するのに十分な容量が残りのゾーンにあることを確認してください。
-
DNS フェイルオーバーでは、すべてのロードバランサーゾーンが異常と見なされると、ロードバランサーは異常なゾーンを含むすべてのゾーンにトラフィックを送信します。
-
DNS フェイルオーバーにつながる可能性のある正常なターゲットが十分にあるかどうか以外にも、ゾーンのヘルスなどの要因があります。
例
次の例は、ターゲットグループのヘルス設定がどのように適用されるかを示しています。
シナリオ
-
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 は、プライマリロードバランサーが利用可能な場合はプライマリロードバランサーにトラフィックをルーティングし、利用できない場合はセカンダリロードバランサーにルーティングします。
ターゲットの正常性の評価を使用する
-
Network Load Balancer のエイリアスレコードで、ターゲットの正常性の評価が
Yes
に設定されている場合、alias target
値で指定されたリソースの正常性が、Route 53 により評価されます。Route 53 は、Network Load Balancer に対し、そのロードバランサーに関連付けられたターゲットグループのヘルスチェックを使用します。 -
Network Load Balancer 内のターゲットグループがすべて正常であれば、Route 53 はそのエイリアスレコードを正常とマークします。ターゲットグループが正常なターゲットを 1 つでも含んでいれば、そのターゲットグループはヘルスチェックに合格します。その後、Route 53 は、ルーティングポリシーに従ってレコードを返します。フェイルオーバールーティングポリシーが使用されている場合、Route 53 はプライマリレコードを返します。
-
Network Load Balancer のターゲットグループのいずれかに異常がある場合、そのエイリアスレコードは Route 53 のヘルスチェックに失敗します (fail-open) 。ターゲットの正常性の評価を使用している場合は、フェイルオーバールーティングポリシーが失敗します。
-
Network Load Balancer のすべてのターゲットグループが空 (ターゲットが存在しない状態) の場合、Route 53 は対象のレコードを異常と見なします (fail-open)。ターゲットの正常性の評価を使用している場合は、フェイルオーバールーティングポリシーが失敗します。
詳細については、Amazon Route 53 開発者ガイドの「DNS フェイルオーバーの設定」を参照してください。