Target groups for your Application Load Balancer - Elastic Load Balancing
Routing configurationTarget typeRegistered targetsTarget group attributesRouting algorithmDeregistration delaySlow start modeSticky sessions

英語の翻訳が提供されている場合で、内容が矛盾する場合には、英語版がオリジナルとして取り扱われます。翻訳は機械翻訳により提供されています。

Target groups for your Application Load Balancer

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

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

目次

Routing configuration

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

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

  • Protocols: HTTP, HTTPS

  • Ports: 1-65535

ターゲット グループがHTTPSプロトコルで構成されている場合、またはHTTPSヘルス チェックを使用している場合、ターゲットへのTLS接続は、 ELBSecurityPolicy2016-08 ポリシー。ロードバランサーは、ターゲットにインストールした証明書を使用して、ターゲットとのTLS接続を確立します。ロードバランサーはこれらの証明書を検証しません。したがって、自己署名証明書または期限切れの証明書を使用できます。ロードバランサーは仮想プライベートクラウド (VPC) 内にあるため、ロードバランサーとターゲット間のトラフィックはパケットレベルで認証されるため、ターゲットの証明書が有効でない場合でも、中間者攻撃やスプーフィングのリスクはありません。

Target type

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

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

instance

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

ip

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

lambda

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

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

  • The subnets of the VPC for the target group

  • 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)

これらのサポートされているCIDRブロックを使用すると、ターゲット グループに以下を登録できます。ClassicLinkインスタンス、ロードバランサーVPCとピアリングされるVPC内のインスタンス、IPアドレスとポート(データベースなど)でアドレス指定可能なAWSリソース、および AWS Direct Connect またはVPN接続。

重要

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

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

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

Registered targets

ロードバランサーは、クライアントにとって単一の通信先として機能し、正常な登録済みターゲットに受信トラフィックを分散します。各ターゲットは、1 つ以上のターゲットグループに登録できます。異なるポートを使用して、各 EC2 インスタンスまたは IP アドレスを同じターゲットグループに複数回登録できます。これにより、ロードバランサーはリクエストをマイクロサービスにルーティングできます。

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

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

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

Limits

  • You cannot register the IP addresses of another Application Load Balancer in the same VPC. If the other Application Load Balancer is in a VPC that is peered to the load balancer VPC, you can register its IP addresses.

Target group attributes

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

deregistration_delay.timeout_seconds

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

load_balancing.algorithm.type

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

slow_start.duration_seconds

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

stickiness.enabled

スティッキーセッションが有効かどうかを示します。

stickiness.lb_cookie.duration_seconds

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

stickiness.type

維持の種類です。有効な値は lb_cookie です。

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

lambda.multi_value_headers.enabled

ロードバランサーと Lambda 関数との間で交換されるリクエストとレスポンスのヘッダーに、値のまたは文字列の配列が含まれるかどうかを示します。可能な値は次のとおりです。 true または false。 デフォルト値は です。 false。 詳細については、以下を参照してください。 Multi-value headers.

Routing algorithm

デフォルトでは、ラウンドロビンルーティングアルゴリズムがターゲットグループレベルのリクエストのルーティングに使用されます。最小未処理リクエストルーティングアルゴリズムを指定できます。

アプリケーションのリクエストの複雑さに差がある場合や、ターゲットの処理能力に差がある場合は、最小未処理リクエストを使用することを検討してください。リクエストとターゲットが近い場合や、リクエストをターゲットに均等に分散させる必要がある場合は、ラウンドロビンが適切です。次の CloudWatch メトリクスを使用して、ラウンド ロビンと未処理でない要求の効果を比較できます。要求数、 ターゲット接続エラーカウント、および TargetResponseTime (目標応答時間).

Considerations

  • You cannot enable both least outstanding requests and slow start mode.

  • If you enable sticky sessions, this overrides the routing algorithm of the target group after the initial target selection.

  • With HTTP/2, the load balancer converts the request to multiple HTTP/1.1 requests, so least outstanding request treats each HTTP/2 request as multiple requests.

  • When you use least outstanding requests with WebSockets, the target is selected using least outstanding requests. The load balancer creates a connection to this target and sends all messages over this connection.

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

  1. https://console.aws.amazon.com/ec2/ で Amazon EC2 コンソールを開きます。

  2. ナビゲーションペインの [LOAD BALANCING] で [ターゲットグループ] を選択します。

  3. ターゲットグループを選択します。

  4. [説明] タブで、[属性の編集] を選択します。

  5. [Edit attributes (属性の編集)] ページの [Load balancing algorithm (ロードバランシングアルゴリズム)] で、[Round robin (ラウンドロビン)] または [Least outstanding requests (最小の未処理のリクエスト)] を選択し、[Save (保存)] を選択します。

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

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

Deregistration delay

Elastic Load Balancing は、登録解除するターゲットへのリクエストの送信を停止します。デフォルトでは、Elastic Load Balancing 登録解除プロセスを完了する前に 300 秒待って、ターゲットへ処理中のリクエストが完了するのを助けることができます。Elastic Load Balancing が待機する時間を変更するには、登録解除の遅延値を更新します。

ターゲットの登録解除の初期状態は draining。 登録解除の遅延が経過すると、登録解除プロセスが完了し、ターゲットの状態は unused。 ターゲットが Auto Scaling グループの場合は、終了して置換できます。

登録解除するターゲットに未処理のリクエストやアクティブな接続がない場合は、Elastic Load Balancing は登録解除の遅延時間が経過するのを待たずに、即時登録解除プロセスを完了します。ただし、ターゲットの登録解除が完了しても、ターゲットのステータスは、登録解除の遅延が経過するまで draining と表示されます。

登録解除の遅延が経過する前に登録解除するターゲットが接続を終了すると、クライアントは 500 レベルのエラー応答を受信します。

コンソールを使用して登録解除の遅延値を更新するには

  1. https://console.aws.amazon.com/ec2/ で Amazon EC2 コンソールを開きます。

  2. ナビゲーションペインの [LOAD BALANCING] で [ターゲットグループ] を選択します。

  3. ターゲットグループを選択します。現在の値が [説明] タブに [登録解除の遅延] として表示されます。

  4. [説明] タブで、[属性の編集] を選択します。

  5. [Edit attributes] ページで、必要に応じて [Deregistration delay] の値を変更し、[Save] を選択します。

AWS CLI を使用して登録解除の遅延値を更新するには

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

Slow start mode

デフォルトでは、ターゲットはターゲットグループを使用して登録され初期ヘルスチェックを渡した後、すぐにリクエストの全シェアを受信し始めます。スロースタートモードを使用すると、ロードバランサーがターゲットにリクエストの全シェアを送信し始めるまでの猶予期間が設定されます。

ターゲットグループのスロースタートを有効にした後、ターゲットグループによってそのターゲットが正常と見なされると、ターゲットはスロースタートモードになります。スロースタートモードのターゲットは、設定されたスロースタート期間が経過するか、ターゲットが異常になると、スロースタートモードを終了します。ロードバランサーは、スロースタートモードのターゲットに送信できるリクエスト数を直線的に増加させます。正常なターゲットがスロースタートモードを終了すると、ロードバランサーはリクエストの全シェアを送信できます。

Considerations

  • When you enable slow start for a target group, the healthy targets registered with the target group do not enter slow start mode.

  • When you enable slow start for an empty target group and then register targets using a single registration operation, these targets do not enter slow start mode. Newly registered targets enter slow start mode only when there is at least one healthy target that is not in slow start mode.

  • If you deregister a target in slow start mode, the target exits slow start mode. If you register the same target again, it enters slow start mode when it is considered healthy by the target group.

  • If a target in slow start mode becomes unhealthy, the target exits slow start mode. When the target becomes healthy, it enters slow start mode again.

  • You cannot enable both slow start mode and least outstanding requests.

コンソールを使用してスロースタート期間の値を更新するには

  1. https://console.aws.amazon.com/ec2/ で Amazon EC2 コンソールを開きます。

  2. ナビゲーションペインの [LOAD BALANCING] で [ターゲットグループ] を選択します。

  3. ターゲットグループを選択します。現在の値が [説明] タブに [スロースタート期間] として表示されます。

  4. [説明] タブで、[属性の編集] を選択します。

  5. [属性の編集] ページで、必要に応じて [スロースタート期間] の値を変更し、[保存] を選択します。スロースタートモードを無効にするには、期間を 0 に設定します。

AWS CLI を使用してスロースタート期間の値を更新するには

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

Sticky sessions

スティッキーセッションは、ターゲットグループ内の同じターゲットにリクエストをルーティングするメカニズムです。これは、クライアントに連続したエクスペリエンスを提供するために状態情報を維持するサーバーに役立ちます。スティッキーセッションを使用するには、クライアントが Cookie をサポートしている必要があります。

ロードバランサーは、クライアントから初めてリクエストを受信すると、そのリクエストをターゲットにルーティングし、選択されたターゲットに関する情報をエンコードする AWSALB という Cookie を生成し、Cookie を暗号化し、Cookie をクライアントへのレスポンスに含めます。クライアントは、受信した Cookie を、ロードバランサーへの後続のリクエストに含める必要があります。ロードバランサーがクライアントから Cookie を含むリクエストを受信したときに、ターゲットグループのスティッキーセッションが有効になっており、かつリクエストが同じターゲットグループに送信されると、ロードバランサーは Cookie を検出し、リクエストを同じターゲットにルーティングします。Cookie は存在するがデコードできない場合、あるいは登録解除されたターゲットまたは異常なターゲットを参照している場合、ロードバランサーは新しいターゲットを選択し、新しいターゲットに関する情報で Cookie を更新します。

ターゲットグループレベルでスティッキーセッションを有効にします。ロードバランサー生成のクッキーの維持期間を秒単位で設定することもできます。期間はリクエストごとに設定されます。そのため、各期間の有効期限が切れる前にクライアントがリクエストを送信すると、スティッキーセッションが継続されます。

CORS (クロスオリジンリソース共有) リクエストでは、ブラウザによっては維持の有効化を SameSite=None; Secure に求めます。この場合、Elastic Load Balancing は 2 番目の維持 Cookie である AWSALBCORS を生成します。この Cookie には、元の維持 Cookie と同じ情報に加えてこの SameSite 属性が含まれています。クライアントは両方の Cookie を受け取ります。

Application Load Balancer はロードバランサーによって生成されるクッキーのみをサポートします。このクッキーのコンテンツはローテーションキーを使用して暗号化されます。ロードバランサーによって生成されたクッキーを複合あるいは編集することはできません。

Considerations

  • If you are using multiple layers of Application Load Balancer, you can enable sticky sessions on one layer only, because the load balancers would use the same cookie name.

  • WebSockets connections are inherently sticky. If the client requests a connection upgrade to WebSockets, the target that returns an HTTP 101 status code to accept the connection upgrade is the target used in the WebSockets connection. After the WebSockets upgrade is complete, cookie-based stickiness is not used.

  • Application Load Balancer use the Expires attribute in the cookie header instead of the Max-Age header.

  • Application Load Balancer do not support cookie values that are URL encoded.

コンソールを使用してスティッキーセッションを有効にするには

  1. https://console.aws.amazon.com/ec2/ で Amazon EC2 コンソールを開きます。

  2. ナビゲーションペインの [LOAD BALANCING] で [ターゲットグループ] を選択します。

  3. ターゲットグループを選択します。

  4. [説明] タブで、[属性の編集] を選択します。

  5. [Edit attributes] ページで、以下を実行します。

    1. [Enable load balancer generated cookie stickiness] を選択します。

    2. [Stickiness duration] で、1 秒から 7 日の間の値を指定します。

    3. [Save] を選択します。

AWS CLI を使用してスティッキーセッションを有効にするには

stickiness.enabled および stickiness.lb_cookie.duration_seconds 属性を指定して modify-target-group-attributes コマンドを使用します。