# ロードバランサーを使用して Amazon ECS サービストラフィックを分散する
サービスは、オプションで Elastic Load Balancing を使用して、サービスのタスク間でトラフィックを均等に分散するように設定できます。
**注記**
タスクセットを使用するとき、セット内のすべてのタスクが Elastic Load Balancing を使用するように設定、または Elastic Load Balancing を使用しないように設定する必要があります。
AWS Fargate でホストされている Amazon ECS サービスでは、Application Load Balancer、Network Load Balancer、および Gateway Load Balancer がサポートされています。次の表を使用して、使用するロードバランサーのタイプを確認してください。
| ロードバランサーのタイプ | 以下の場合に使用 |
| --- | --- |
| Application Load Balancer | HTTP/HTTPS (またはレイヤー 7) トラフィックをルーティングします。Amazon Load Balancer は Amazon ECS サービスでの使用に便利な複数の機能を提供しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-load-balancing.html) |
| Network Load Balancer | TCP または UDP (またはレイヤー 4) トラフィックをルーティングします。 |
| Gateway Load Balancer | TCP または UDP (またはレイヤー 4) トラフィックをルーティングします。 ファイアウォール、侵入検知および防止システム、ディープパケットインスペクションシステムなどの仮想アプライアンスを使用します。 |
サービスで Network Load Balancer または Gateway Load Balancer でのみ使用できる機能が必要な場合を除き、最新の機能を利用できるように、Amazon ECS サービスで Application Load Balancer を使用することをお勧めします。これらのロードバランサーの違いについては、「[Elastic Load Balancing ユーザーガイド](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/)」の「Elastic Load Balancing とは」を参照してください。
ロードバランサーについては、お客様が利用された分のみのお支払いとなります。詳細については、[Elastic Load Balancing の料金表](https://aws.amazon.com/elasticloadbalancing/pricing/)を参照してください。
# Amazon ECS のロードバランサーのヘルスチェックパラメータを最適化する
ロードバランサーは、ロードバランサーに対して有効になっているアベイラビリティーゾーンの正常なターゲットにのみ、リクエストをルーティングします。各ターゲットはターゲットグループに登録されます。ロードバランサーは、ターゲットグループのヘルスチェック設定を使用して、各ターゲットの状態を確認します。ターゲットは、登録後に正常と見なされるためには、1 つのヘルスチェックに合格する必要があります。Amazon ECS はロードバランサーをモニタリングします。ロードバランサーは Amazon ECS コンテナに定期的にヘルスチェックを送信します。Amazon ECS エージェントはモニタリングし、ロードバランサーがコンテナの状態を報告するのを待ちます。この処理は、コンテナが正常状態にあると見なされる前に行われます。
Elastic Load Balancing の次の 2 つのヘルスチェックパラメータがデプロイ速度に影響します。
+ ヘルスチェック間隔: 個々のコンテナのヘルスチェック間のおおよその時間を秒単位で決定します。デフォルトでは、ロードバランサーは 30 秒ごとにチェックします。
このパラメータは以下の名前です。
+ Elastic Load Balancing API の `HealthCheckIntervalSeconds`
+ Amazon EC2 コンソールでの **[インターバル]**
+ 正常性しきい値: 異常なコンテナが正常であると判断されるまでに必要なヘルスチェックの連続成功回数を決定します。デフォルトでは、ロードバランサーはターゲットコンテナが正常であると報告する前に 5 回のヘルスチェックに合格する必要があります。
このパラメータは以下の名前です。
+ Elastic Load Balancing API の `HealthyThresholdCount`
+ Amazon EC2 コンソールの **[正常なしきい値]**
**重要:** 新しく登録されたターゲットの場合、正常なしきい値数の設定に関係なく、ターゲットを正常とみなすために必要なヘルスチェックは 1 回だけです。正常なしきい値数は、ターゲットが異常な状態から正常な状態に戻っている場合にのみ適用されます。
デフォルト設定では、ターゲットが異常な状態になった後回復した場合、コンテナの状態を判断するための合計時間は 2 分 30 秒 (`30 seconds * 5 = 150 seconds`) です。
サービスが 10 秒以内に起動して安定すれば、ヘルスチェックプロセスをスピードアップできます。プロセスを高速にするには、ヘルスチェックの間隔と正常なしきい値の数を減らします。
+ `HealthCheckIntervalSeconds` (Elastic Load Balancing API 名) または **[インターバル]** (Amazon EC2 コンソール名): 5
+ `HealthyThresholdCount` (Elastic Load Balancing API 名) または **[正常なしきい値]** (Amazon EC2 コンソール名): 2
この設定では、ヘルスチェックの処理にデフォルトの 2 分 30 秒かかるのに対し、10 秒かかります。
Elastic Load Balancing ヘルスチェックパラメータの詳細については、「*Elastic Load Balancing ユーザーガイド*」の「[ターゲットグループのヘルスチェック](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html)」を参照してください。
# Amazon ECS のロードバランサー Connection Draining パラメータを最適化する
最適化を可能にするために、クライアントはコンテナサービスへのキープアライブ接続を維持します。これにより、そのクライアントからの後続のリクエストが既存の接続を再利用できるようにします。コンテナへのトラフィックを停止したいときは、ロードバランサーに通知します。ロードバランサーはクライアントがキープアライブ接続を閉じたかどうかを定期的に確認します。Amazon ECS はロードバランサーをモニタリングし、キープアライブ接続が閉じられた (ターゲットが `UNUSED` の状態にある) ことをロードバランサーが報告するのを待ちます。
ロードバランサーがターゲットを `UNUSED` 状態へと移行するまで待機する時間の長さが登録解除の遅延です。以下のロードバランサーパラメータを設定して、デプロイをスピードアップできます。
+ `deregistration_delay.timeout_seconds`: 300 (デフォルト)
レスポンス時間が 1 秒未満のサービスの場合は、パラメータを次の値に設定して、クライアントとバックエンドサービスとの間の接続を切断するまでロードバランサーが 5 秒だけ待機するようにします。
+ `deregistration_delay.timeout_seconds`: 5
**注記**
ファイルのアップロードやストリーミング接続が遅いなど、リクエストの有効期間が長いサービスの場合は、この値を 5 秒に設定しないでください。
## SIGTERM 応答性
Amazon ECS は、まず停止シグナルをタスクに送信し、アプリケーションを終了してシャットダウンする必要があることを通知します。このシグナルは、STOPSIGNAL 命令を使用してコンテナイメージで定義でき、デフォルトで SIGTERM になります。次に、Amazon ECS は SIGKILL メッセージを送信します。アプリケーションが SIGTERM を無視する場合、Amazon ECS サービスはプロセスを終了する SIGKILL シグナルの送信を待つ必要があります。
Amazon ECS が SIGKILL メッセージの送信を待つ時間は、次の Amazon ECS エージェントオプションによって決まります。
+ `ECS_CONTAINER_STOP_TIMEOUT`: 30 (デフォルト)
コンテナエージェントパラメータの詳細については、GitHub の「[Amazon ECS コンテナエージェント](https://github.com/aws/amazon-ecs-agent/blob/master/README.md)」を参照してください。
待機時間を短縮するには、Amazon ECS エージェントパラメータを次の値に設定します。
+ `ECS_CONTAINER_STOP_TIMEOUT`: 2
アプリケーションに 1 秒以上かかる場合は、値に 2 を掛けて、その数値を値として使用します。
この場合、Amazon ECS はコンテナがシャットダウンされるまで 2 秒間待機し、アプリケーションが停止しなかったときに Amazon ECS は SIGKILL メッセージを送信します。
SIGTERM シグナルをトラップして反応するようにアプリケーションコードを変更することもできます。JavaScript の例を次に示します。
```
process.on('SIGTERM', function() {
server.close();
})
```
このコードにより、HTTP サーバーは新しいリクエストのリッスンを停止し、処理中のリクエストへの応答を終了します。イベントループは何も行わないため Node.js プロセスが終了します。これを考慮すると、プロセスが実行中のリクエストを完了するのに 500 ミリ秒しかかからない場合、プロセスは停止タイムアウトを待って SIGKILL を送信する必要がなく、早期に終了します。
# Amazon ECS 用の Application Load Balancer を使用する
Application Load Balancer では、アプリケーションレイヤー (HTTP/HTTPS) でルーティング決定を行い、パスベースのルーティングをサポートします。また、クラスター内の各コンテナインスタンスの 1 つまたは複数のポートにリクエストをルーティングできます。Application Load Balancer では、動的ホストポートマッピングをサポートしています。たとえば、タスクコンテナ定義で NGINX コンテナポートのポート 80、ホストポートのポート 0 を指定した場合、ホストポートはコンテナインスタンスの一時ポート範囲から動的に選択されます (最新の Amazon ECS に最適化された AMI の 32768～61000 など)。タスクの起動時に、NGINX コンテナは、インスタンス ID およびポートの組み合わせとして Application Load Balancer で登録されます。トラフィックは、コンテナに対応するインスタンス ID およびポートに分散されます。この動的なマッピングにより、同じコンテナインスタンスの単一のサービスから複数のタスクを持つことができます。詳細については、[「Application Load Balancer ユーザーガイド」を参照してください](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/)。
デプロイを高速化するためのパラメータ設定のベストプラクティスについては、以下を参照してください。
+ [Amazon ECS のロードバランサーのヘルスチェックパラメータを最適化する](load-balancer-healthcheck.md)
+ [Amazon ECS のロードバランサー Connection Draining パラメータを最適化する](load-balancer-connection-draining.md)
Amazon ECS で Application Load Balancer を使用する場合は、次の点を考慮してください。
+ Amazon ECS には、タスクの作成時および停止時に、ロードバランサーへのターゲットの登録および登録解除に必要なアクセス許可を提供するサービスリンク IAM ロールが必要です。詳細については、「[Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
+ IPv6 専用設定のサービスの場合は、Application Load Balancer のターゲットグループの IP アドレスタイプを `dualstack` または `dualstack-without-public-ipv4` に設定する必要があります。
+ `awsvpc` ネットワークモードを使用するタスクを含むサービスの場合、サービスのターゲットグループを作成するときに、`instance` ではなく、`ip` をターゲットタイプとして選択する必要があります 。これは、`awsvpc` ネットワークモードを使用するタスクは、Amazon EC2 インスタンスではなく、Elastic Network Interface に関連付けられているためです。
+ サービスが HTTP/HTTPS サービスのポート 80 やポート 443 など、複数の負荷分散されたポートにアクセスする必要がある場合は、2 つのリスナーを設定できます。1 つのリスナーは、リクエストをサービスに転送する HTTPS を担当し、別のリスナーは HTTP リクエストを適切な HTTPS ポートへのリダイレクトを担当します。詳細については、[Application Load Balancer ユーザーガイド](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-listener.html)の*「Application Load Balancer のアクセスログ」を参照してください*。
+ ロードバランサーのサブネット設定には、コンテナインスタンスが存在するアベイラビリティーゾーンすべてを含める必要があります。
+ サービスの作成後にロードバランサーの設定を AWS マネジメントコンソール から変更することはできません。AWS Copilot、AWS CloudFormation、AWS CLI、SDK のいずれかを使用して、AWS CodeDeploy ブルー/グリーンまたは外部ではなく、`ECS` ローリングデプロイコントローラのみのロードバランサー設定を変更できます。ロードバランサー設定を追加、更新、削除すると、Amazon ECS は、更新された Elastic Load Balancing 設定で新しいデプロイを開始します。これにより、タスクがロードバランサーに登録およびロードバランサーから登録解除されます。Elastic Load Balancing 設定を更新する前に、テスト環境でこれを検証することをお勧めします。設定の変更方法については、「*Amazon Elastic Containers Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」を参照してください。
+ サービスタスクがロードバランサーのヘルスチェック条件を満たさない場合、タスクは停止され、再起動されます。このプロセスは、サービスが実行中のタスクの必要数に達するまで続行されます。
+ ロードバランサーで有効にされているサービスに問題がある場合は、「[Amazon ECS のサービスロードバランサーのトラブルシューティング](troubleshoot-service-load-balancers.md)」を参照してください。
+ `instance` ターゲットタイプを使用する場合、タスクおよびロードバランサーは同じ VPC 内にある必要があります。`ip` ターゲットタイプを使用する場合、クロス VPC 接続がサポートされます。
+ 各サービスに固有のターゲットグループを使用します。
複数のサービスに同じターゲットグループを使用すると、サービスのデプロイ時に問題が発生する可能性があります。
+ Application Load Balancer に関連付けられているターゲットグループを指定する必要があります。
Application Load Balancer の作成方法については、「*Application Load Balancer*」の「[Application Load Balancer の作成](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html)」を参照してください。
# Amazon ECS 用の Network Load Balancer を使用する
[Network Load Balancer] により、トランスポートレイヤー (TCP/SSL) でルーティングの決定が行われます。毎秒数百万のリクエストを処理できます。ロードバランサーは、接続を受信すると、フローハッシュルーティングアルゴリズムを使用してデフォルトルールのターゲットグループからターゲットを選択します。リスナー構成で指定されたポート上の選択したターゲットへの TCP 接続を開こうとします。ヘッダーを変更せずにリクエストを転送します。Network Load Balancer では、動的ホストポートマッピングをサポートしています。たとえば、タスクコンテナ定義で NGINX コンテナポートのポート 80、ホストポートのポート 0 を指定した場合、ホストポートはコンテナインスタンスの一時ポート範囲から動的に選択されます (最新の Amazon ECS に最適化された AMI の 32768～61000 など)。タスクの起動時に、NGINX コンテナは、インスタンス ID およびポートの組み合わせとして Network Load Balancer で登録されます。トラフィックは、コンテナに対応するインスタンス ID およびポートに分散されます。この動的なマッピングにより、同じコンテナインスタンスの単一のサービスから複数のタスクを持つことができます。Network Load Balancer の詳細については、「[https://docs.aws.amazon.com/elasticloadbalancing/latest/network/](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/) のユーザーガイド」を参照してください。
デプロイを高速化するためのパラメータ設定のベストプラクティスについては、以下を参照してください。
+ [Amazon ECS のロードバランサーのヘルスチェックパラメータを最適化する](load-balancer-healthcheck.md)
+ [Amazon ECS のロードバランサー Connection Draining パラメータを最適化する](load-balancer-connection-draining.md)
Amazon ECS で Network Load Balancer を使用する場合は、次の点を考慮してください。
+ Amazon ECS には、タスクの作成時および停止時に、ロードバランサーへのターゲットの登録および登録解除に必要なアクセス許可を提供するサービスリンク IAM ロールが必要です。詳細については、「[Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
+ 1 つのサービスに 5 つ以上のターゲットグループをアタッチすることはできません。
+ IPv6 専用設定のサービスの場合は、Network Load Balancer のターゲットグループの IP アドレスタイプを `dualstack` に設定する必要があります。
+ `awsvpc` ネットワークモードを使用するタスクを含むサービスの場合、サービスのターゲットグループを作成するときに、`instance` ではなく、`ip` をターゲットタイプとして選択する必要があります 。これは、`awsvpc` ネットワークモードを使用するタスクは、Amazon EC2インスタンスではなく、Elastic Network Interface に関連付けられているためです。
+ ロードバランサーのサブネット設定には、コンテナインスタンスが存在するアベイラビリティーゾーンすべてを含める必要があります。
+ サービスの作成後にロードバランサーの設定を AWS マネジメントコンソール から変更することはできません。AWS Copilot、AWS CloudFormation、AWS CLI、SDK のいずれかを使用して、AWS CodeDeploy ブルー/グリーンまたは外部ではなく、`ECS` ローリングデプロイコントローラのみのロードバランサー設定を変更できます。ロードバランサー設定を追加、更新、削除すると、Amazon ECS は、更新された Elastic Load Balancing 設定で新しいデプロイを開始します。これにより、タスクがロードバランサーに登録およびロードバランサーから登録解除されます。Elastic Load Balancing 設定を更新する前に、テスト環境でこれを検証することをお勧めします。設定の変更方法については、「*Amazon Elastic Containers Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」を参照してください。
+ サービスタスクがロードバランサーのヘルスチェック条件を満たさない場合、タスクは停止され、再起動されます。このプロセスは、サービスが実行中のタスクの必要数に達するまで続行されます。
+ IP アドレスをターゲットとして設定し、クライアント IP の保持をオフにした Gateway Load Balancer を使用する場合、リクエストは Gateway Load Balancer のプライベート IP アドレスから送信されたと見なされます。これは、ターゲットのセキュリティグループで受信リクエストとヘルスチェックを許可するとすぐに、Gateway Load Balancer の背後にあるサービスが世界中からアクセス可能になることを意味します。
+ Fargate タスクでは、プラットフォームバージョン `1.4.0` (Linux) または `1.0.0` (Windows) を使用する必要があります。
+ ロードバランサーで有効にされているサービスに問題がある場合は、「[Amazon ECS のサービスロードバランサーのトラブルシューティング](troubleshoot-service-load-balancers.md)」を参照してください。
+ `instance` ターゲットタイプを使用する場合、タスクおよびロードバランサーは同じ VPC 内にある必要があります。`ip` ターゲットタイプを使用する場合、クロス VPC 接続がサポートされます。
+ Network Load Balancer のクライアント IP アドレスの保存は Fargate ターゲットと互換性があります。
+ 各サービスに固有のターゲットグループを使用します。
複数のサービスに同じターゲットグループを使用すると、サービスのデプロイ時に問題が発生する可能性があります。
+ Network Load Balancer に関連付けられているターゲットグループを指定する必要があります。
Network Load Balancer を作成する方法については、「*Network Load Balancers*」の「[Network Load Balancer の作成](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)」を参照してください。
**重要**
サービスのタスク定義で、`awsvpc` ネットワークモード (Fargate の場合に必要) が使用されている場合は、`instance` ではなく、`ip` をターゲットタイプとして選択する必要があります。これは、`awsvpc` ネットワークモードを使用するタスクは、Amazon EC2インスタンスではなく、Elastic Network Interface に関連付けられているためです。
インスタンス ID が C1、CC1、CC2、CG1、CG2、CR1、G1、G2、HI1、HS1、M1、M2、M3、および T1 のインスタンス ID でインスタンスを登録することはできません。IP アドレスで、これらの種類のインスタンスを登録することができます。
# Amazon ECS 用の Gateway Load Balancer を使用する
ゲートウェイロードバランサーは、開放型システム間相互接続 (OSI) モデルの第 3 層（ネットワークレイヤー）で機能します。すべてのポートですべての IP パケットをリッスンし、リスナールールで指定されたターゲットグループにトラフィックを転送します。5 タプル（TCP/UDP フローの場合）または 3 タプル（非 TCP/UDP フローの場合）を使用して、特定のターゲットアプライアンスへのフローのスティッキ状態を維持します。たとえば、タスクコンテナ定義で NGINX コンテナポートのポート 80、ホストポートのポート 0 を指定した場合、ホストポートはコンテナインスタンスの一時ポート範囲から動的に選択されます (最新の Amazon ECS に最適化された AMI の 32768～61000 など)。タスクの起動時に、NGINX コンテナは、インスタンス ID およびポートの組み合わせとして Gateway Load Balancer で登録されます。トラフィックは、コンテナに対応するインスタンス ID およびポートに分散されます。この動的なマッピングにより、同じコンテナインスタンスの単一のサービスから複数のタスクを持つことができます。詳細については、「*Gateway Load Balancers*」の「[What is a Gateway Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html)」を参照してください。
デプロイを高速化するためのパラメータ設定のベストプラクティスについては、以下を参照してください。
+ [Amazon ECS のロードバランサーのヘルスチェックパラメータを最適化する](load-balancer-healthcheck.md)
+ [Amazon ECS のロードバランサー Connection Draining パラメータを最適化する](load-balancer-connection-draining.md)
Amazon ECS で Gateway Load Balancer を使用する場合は、次の点を考慮してください。
+ Amazon ECS には、タスクの作成時および停止時に、ロードバランサーへのターゲットの登録および登録解除に必要なアクセス許可を提供するサービスリンク IAM ロールが必要です。詳細については、「[Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
+ IPv6 専用設定のサービスの場合は、Gateway Load Balancer のターゲットグループの IP アドレスタイプを `dualstack` に設定する必要があります。
+ `awsvpc` 以外のネットワークモードを使用するタスクがあるサービスの場合、Gateway Load Balancer はサポートされません。
+ ロードバランサーのサブネット設定には、コンテナインスタンスが存在するアベイラビリティーゾーンすべてを含める必要があります。
+ サービスの作成後にロードバランサーの設定を AWS マネジメントコンソール から変更することはできません。AWS Copilot、AWS CloudFormation、AWS CLI、SDK のいずれかを使用して、AWS CodeDeploy ブルー/グリーンまたは外部ではなく、`ECS` ローリングデプロイコントローラのみのロードバランサー設定を変更できます。ロードバランサー設定を追加、更新、削除すると、Amazon ECS は、更新された Elastic Load Balancing 設定で新しいデプロイを開始します。これにより、タスクがロードバランサーに登録およびロードバランサーから登録解除されます。Elastic Load Balancing 設定を更新する前に、テスト環境でこれを検証することをお勧めします。設定の変更方法については、「*Amazon Elastic Containers Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」を参照してください。
+ サービスタスクがロードバランサーのヘルスチェック条件を満たさない場合、タスクは停止され、再起動されます。このプロセスは、サービスが実行中のタスクの必要数に達するまで続行されます。
+ IP アドレスをターゲットとして設定した Gateway Load Balancer を使用する場合、リクエストは Gateway Load Balancer のプライベート IP アドレスから送信されたと見なされます。これは、ターゲットのセキュリティグループで受信リクエストとヘルスチェックを許可するとすぐに、Gateway Load Balancer の背後にあるサービスが世界中からアクセス可能になることを意味します。
+ Fargate タスクでは、プラットフォームバージョン `1.4.0` (Linux) または `1.0.0` (Windows) を使用する必要があります。
+ ロードバランサーで有効にされているサービスに問題がある場合は、「[Amazon ECS のサービスロードバランサーのトラブルシューティング](troubleshoot-service-load-balancers.md)」を参照してください。
+ `instance` ターゲットタイプを使用する場合、タスクおよびロードバランサーは同じ VPC 内にある必要があります。`ip` ターゲットタイプを使用する場合、クロス VPC 接続がサポートされます。
+ 各サービスに固有のターゲットグループを使用します。
複数のサービスに同じターゲットグループを使用すると、サービスのデプロイ時に問題が発生する可能性があります。
+ Gateway Load Balancer に関連付けられているターゲットグループを指定する必要があります。
Gateway Load Balancer を作成する方法については、「*Gateway Load Balancers*」の「[Gateway Load Balancer の開始方法](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html)」を参照してください。
**重要**
サービスのタスク定義で、`awsvpc` ネットワークモード (Fargate の場合に必要) が使用されている場合は、`instance` ではなく、`ip` をターゲットタイプとして選択する必要があります。これは、`awsvpc` ネットワークモードを使用するタスクは、Amazon EC2インスタンスではなく、Elastic Network Interface に関連付けられているためです。
インスタンス ID が C1、CC1、CC2、CG1、CG2、CR1、G1、G2、HI1、HS1、M1、M2、M3、および T1 のインスタンス ID でインスタンスを登録することはできません。IP アドレスで、これらの種類のインスタンスを登録することができます。
# Amazon ECS サービスに複数のターゲットグループを登録する
サービス定義で複数のターゲットグループを指定すると、Amazon ECS サービスは複数のロードバランサーからのトラフィックを送信し、複数のロードバランサーポートを公開できます。
複数のターゲットグループを指定してサービスを作成するには、Amazon ECS API、SDK、AWS CLI、または CloudFormation テンプレートを使用してサービスを作成する必要があります。サービスの作成後、AWS マネジメントコンソール に登録されているサービスとターゲットグループを表示できます。既存サービスのロードバランサー設定を変更するには、`[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)` を使用する必要があります。
次の形式を使用して、複数のターゲットグループをサービス定義で指定できます。サービス定義の完全な構文については、「[サービス定義テンプレート](sd-template.md)」を参照してください。
```
"loadBalancers":[
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
"containerName":"container_name",
"containerPort":container_port
},
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
"containerName":"container_name",
"containerPort":container_port
}
]
```
## 考慮事項
サービス定義で複数のターゲットグループを指定する際には、次の点を考慮する必要があります。
+ Application Load Balancer または Network Load Balancer を使用するサービスの場合、6 個以上のターゲットグループはアタッチできません。
+ サービス定義での複数のターゲットグループの指定は、次の条件でのみサポートされます。
+ サービスでは、Application Load Balancer またはNetwork Load Balancer を使用する必要があります。
+ サービスで (`ECS`) デプロイコントローラタイプを使用する必要があります。これは、Amazon ECS ネイティブ/ブルーグリーンデプロイ、またはローリング更新デプロイのいずれかです。
+ Fargate と EC2 の両方の起動タイプを使用するタスクを含むサービスでは、複数のターゲットグループの指定がサポートされます。
+ 複数のターゲットグループを指定するサービスを作成するときは、Amazon ECS サービスにリンクされたロールを作成する必要があります。ロールは、API リクエストの `role` パラメータを省略するか、CloudFormation の `Role` プロパティを省略することによって作成されます。詳細については、「[Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
## サービス定義の例
次に、サービス定義で複数のターゲットグループを指定するいくつかのユースケースの例を示します。サービス定義の完全な構文については、「[サービス定義テンプレート](sd-template.md)」を参照してください。
### 内部トラフィックと外部トラフィックに別々のロードバランサーを使用する
次のユースケースでは、サービスは 2 つの別個のロードバランサーを使用します。1 つは内部トラフィック用、もう 1 つはインターネット向けトラフィック用で、同じコンテナとポートに対して使用します。
```
"loadBalancers":[
//Internal ELB
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
"containerName":"nginx",
"containerPort":8080
},
//Internet-facing ELB
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
"containerName":"nginx",
"containerPort":8080
}
]
```
### 同じコンテナの複数のポートを公開する
次のユースケースでは、サービスは 1 つのロードバランサーを使用しますが、同じコンテナから複数のポートを公開します。例えば、Jenkins コンテナは、Jenkins ウェブインターフェイス用にポート 8080 を、API 用にポート 50000 を公開する場合があります。
```
"loadBalancers":[
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
"containerName":"jenkins",
"containerPort":8080
},
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
"containerName":"jenkins",
"containerPort":50000
}
]
```
### 複数のコンテナのポートを公開する
次のユースケースでは、サービスは 1 つのロードバランサーと 2 つのターゲットグループを使用して、個別のコンテナからポートを公開します。
```
"loadBalancers":[
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
"containerName":"webserver",
"containerPort":80
},
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
"containerName":"database",
"containerPort":3306
}
]
```