「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」
Application Load Balancer のターゲットグループ
各ターゲットグループは、1 つ以上の登録されているターゲットにリクエストをルーティングするために使用されます。各リスナーのルールを作成するときに、ターゲットグループと条件を指定します。ルールの条件が満たされると、トラフィックが該当するターゲットグループに転送されます。さまざまなタイプのリクエストに応じて別のターゲットグループを作成できます。たとえば、一般的なリクエスト用に 1 つのターゲットグループを作成し、アプリケーションのマイクロサービスへのリクエスト用に別のターゲットグループを作成できます。詳細については、「Application Load Balancer コンポーネント」を参照してください。
ロードバランサーのヘルスチェック設定は、ターゲットグループ単位で定義します。各ターゲットグループはデフォルトのヘルスチェック設定を使用します。ただし、ターゲットグループを作成したときや、後で変更したときに上書きした場合を除きます。リスナーのルールでターゲットグループを指定すると、ロードバランサーは、ロードバランサーで有効なアベイラビリティーゾーンにある、ターゲットグループに登録されたすべてのターゲットの状態を継続的にモニタリングします。ロードバランサーは、正常な登録済みターゲットにリクエストをルーティングします。
目次
ルーティング設定
デフォルトでは、ロードバランサーはターゲットグループの作成時に指定したプロトコルとポート番号を使用して、リクエストをターゲットにルーティングします。または、ターゲットグループへの登録時にターゲットへのトラフィックのルーティングに使用されるポートを上書きすることもできます。
ターゲットグループでは、次のプロトコルとポートがサポートされています。
-
プロトコル: HTTP、HTTPS
-
ポート: 1 ～ 65535
ターゲットグループが HTTPS プロトコルを使用して設定されているか、HTTPS ヘルスチェックを使用する場合、ターゲットへの TLS 接続には ELBSecurityPolicy-2016-08 ポリシーのセキュリティ設定が使用されます。ロードバランサーは、ターゲットにインストールする証明書を使用して、ターゲットとの TLS 接続を確立します。ロードバランサーはこれらの証明書を検証しません。したがって、自己署名証明書または期限切れの証明書を使用できます。ロードバランサーは仮想プライベートクラウド
(VPC) 内にあるため、ロードバランサーとターゲット間のトラフィックはパケットレベルで認証されるため、ターゲットの証明書が有効でない場合でも、中間者攻撃やスプーフィングのリスクはありません。
[Target type (ターゲットタイプ)]
ターゲットグループを作成するときは、そのターゲットの種類を指定します。それにより、このターゲットグループ内でターゲットを登録するときに指定するターゲットの種類が決定されます。ターゲットグループを作成した後で、ターゲットの種類を変更することはできません。
可能なターゲットの種類は次のとおりです。
instance-
インスタンス ID で指定されたターゲット。
ip-
ターゲットは IP アドレスです。
lambda-
ターゲットは Lambda 関数です。
ターゲットの種類が ip の場合、次のいずれかの CIDR ブロックから IP アドレスを指定できます。
これらのサポートされている CIDR ブロックを使用すると、ClassicLink インスタンス、ロードバランサー VPC にピアリング接続されている VPC 内のインスタンス (同一リージョンまたは異なるリージョン)、IP アドレスとポートでアドレス指定できる AWS リソース (例えば、データベース)、AWS Direct Connect または Site-to-Site VPN 接続を介して AWS にリンクされたオンプレミスリソースをターゲットグループに登録できます。
パブリックにルーティング可能な IP アドレスは指定できません。
インスタンス ID を使用してターゲットを指定すると、トラフィックはインスタンスのプライマリネットワークインターフェイスで指定されたプライマリプライベート IP アドレスを使用して、インスタンスにルーティングされます。IP アドレスを使用してターゲットを指定する場合は、1 つまたは複数のネットワークインターフェイスからのプライベート IP アドレスを使用して、トラフィックをインスタンスにルーティングできます。これにより、インスタンスの複数のアプリケーションが同じポートを使用できるようになります。各ネットワークインターフェイスは独自のセキュリティグループを持つことができます。
ターゲットグループのターゲットの種類が lambda である場合、1 つの Lambda 関数を登録できます。ロードバランサーが Lambda 関数のリクエストを受け取ると、Lambda 関数を呼び出します。詳細については、「ターゲットとしての Lambda 関数」を参照してください。
プロトコルバージョン
デフォルトでは、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のみです 。 -
サポートされているターゲットタイプは、
instanceとipのみです。 -
ロードバランサーは、gRPC リクエストを解析し、パッケージ、サービス、メソッドに基づいて、適切なターゲットグループに gRPC 呼び出しをルーティングします。
-
ロードバランサーは、単項ストリーミング、クライアントサイドストリーミング、サーバーサイドストリーミング、および双方向ストリーミングをサポートします。
-
カスタムヘルスチェックメソッドには、
/package.service/methodという形式で指定する必要があります。 -
ターゲットからの正常な応答をチェックするときに使用する gRPC ステータスコードを指定する必要があります。
-
Lambda 関数をターゲットとして使用することはできません。
HTTP/2 プロトコルバージョンの考慮事項
-
サポートされているリスナープロトコルは HTTPS だけです。
-
リスナールールでサポートされるアクションタイプは、
forwardのみです 。 -
サポートされているターゲットタイプは、
instanceとipのみです。 -
ロードバランサーは、クライアントからのストリーミングをサポートします。ロードバランサーは、ターゲットへのストリーミングをサポートしていません。
登録済みターゲット
ロードバランサーは、クライアントにとって単一の通信先として機能し、正常な登録済みターゲットに受信トラフィックを分散します。各ターゲットは、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 アドレスを登録できます。
ターゲットグループの属性
ターゲットグループの種類が 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-
スティッキーセッションが有効かどうかを示します。値は
trueまたはfalseです。デフォルト:false。 stickiness.app_cookie.cookie_name-
アプリケーション Cookie 名アプリケーション Cookie 名に、ロードバランサーで使用するために予約されている
AWSALB、AWSALBAPP、または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です。
ターゲットグループの種類が lambda である場合、以下のターゲット属性がサポートされています。
lambda.multi_value_headers.enabled-
ロードバランサーと Lambda 関数との間で交換されるリクエストとレスポンスのヘッダーに、値のまたは文字列の配列が含まれるかどうかを示します。使用できる値は、
trueまたはfalseです。デフォルト値はfalseです。詳細については、「複数値ヘッダー」を参照してください。
ルーティングアルゴリズム
デフォルトでは、ラウンドロビンルーティングアルゴリズムがターゲットグループレベルのリクエストのルーティングに使用されます。最小未処理リクエストルーティングアルゴリズムを指定できます。
アプリケーションのリクエストの複雑さに差がある場合や、ターゲットの処理能力に差がある場合は、最小未処理リクエストを使用することを検討してください。リクエストとターゲットが近い場合や、リクエストをターゲットに均等に分散させる必要がある場合は、ラウンドロビンが適切です。次の CloudWatch メトリクスを使用して、ラウンドロビンと最小未処理リクエストの効果を比較できます: RequestCount、TargetConnectionErrorCount、および TargetResponseTime。
考慮事項
-
最小の未処理のリクエストとスロースタートモードの両方を有効にすることはできません。
-
スティッキーセッションを有効にする場合、最初のターゲット選択の後、ターゲットグループのルーティングアルゴリズムを上書きします。
-
HTTP/2 を使用すると、ロードバランサーはリクエストを複数の HTTP/1.1 リクエストに変換します。そのため、最小の未処理のリクエストでは各 HTTP/2 リクエストは複数のリクエストとして扱われます。
-
WebSocket で最小尾未処理リクエストを使用する場合、ターゲットは最小未処理リクエストを使用して選択されます。ロードバランサーはこのターゲットへの接続を作成し、この接続を介してすべてのメッセージを送信します。
AWS CLI を使用してルーティングアルゴリズムを変更するには
load_balancing.algorithm.type 属性を指定して modify-target-group-attributes コマンドを使用します。
登録解除の遅延
Elastic Load Balancing は、登録解除するターゲットへのリクエストの送信を停止します。デフォルトでは、Elastic Load Balancing 登録解除プロセスを完了する前に 300 秒待って、ターゲットへ処理中のリクエストが完了するのを助けることができます。Elastic Load Balancing が待機する時間を変更するには、登録解除の遅延値を更新します。
登録解除するターゲットの初期状態は draining です。登録解除の遅延が経過すると、登録解除プロセスは完了し、ターゲットの状態は unused になります。ターゲットが Auto Scaling グループの一部である場合、ターゲットを終了して置き換えることができます。
登録解除するターゲットに未処理のリクエストやアクティブな接続がない場合は、Elastic Load Balancing は登録解除の遅延時間が経過するのを待たずに、即時登録解除プロセスを完了します。ただし、ターゲットの登録解除が完了しても、ターゲットのステータスは、登録解除の遅延が経過するまで
draining と表示されます。
登録解除の遅延が経過する前に登録解除するターゲットが接続を終了すると、クライアントは 500 レベルのエラー応答を受信します。
AWS CLI を使用して登録解除の遅延値を更新するには
deregistration_delay.timeout_seconds 属性を指定して modify-target-group-attributes コマンドを使用します。
スロースタートモード
デフォルトでは、ターゲットはターゲットグループを使用して登録され初期ヘルスチェックを渡した後、すぐにリクエストの全シェアを受信し始めます。スロースタートモードを使用すると、ロードバランサーがターゲットにリクエストの全シェアを送信し始めるまでの猶予期間が設定されます。
ターゲットグループのスロースタートを有効にした後、ターゲットグループによってそのターゲットが正常と見なされると、ターゲットはスロースタートモードになります。スロースタートモードのターゲットは、設定されたスロースタート期間が経過するか、ターゲットが異常になると、スロースタートモードを終了します。ロードバランサーは、スロースタートモードのターゲットに送信できるリクエスト数を直線的に増加させます。正常なターゲットがスロースタートモードを終了すると、ロードバランサーはリクエストの全シェアを送信できます。
考慮事項
-
ターゲットグループのスロースタートを有効にした時点で、ターゲットグループに登録されていた正常なターゲットは、スロースタートモードになりません。
-
空のターゲットグループでスロースタートを有効にし、その後、単一登録オペレーションを使用してターゲットを登録した場合、それらのターゲットはスロースタートモードになりません。新しく登録されたターゲットは、スロースタートモードになっていない正常なターゲットが 1 つ以上ある場合にのみ、スロースタートモードになります。
-
スロースタートモードのターゲットを登録解除すると、そのターゲットはスロースタートモードを終了します。同じターゲットを再度登録すると、ターゲットグループによって正常と見なされたときに、スロースタートモードになります。
-
スロースタートモードのターゲットが異常になった場合、ターゲットはスロースタートモードを終了します。ターゲットが正常になると、再びスロースタートモードになります。
-
スロースタートモードと最小の未処理のリクエストの両方を有効にすることはできません。
AWS CLI を使用してスロースタート期間の値を更新するには
slow_start.duration_seconds 属性を指定して modify-target-group-attributes コマンドを使用します。
