

# Amazon ECS Service Connect コンポーネント
<a name="service-connect-concepts-deploy"></a>

Amazon ECS Service Connect を使用する場合、ネットワークリクエストを受け取るサーバーアプリケーション (クライアント/サーバーサービス) を実行するか、リクエストを行うクライアントアプリケーション (クライアントサービス) を実行するように各 Amazon ECS サービスを設定します。

Service Connect の使用を開始する準備が整ったら、クライアント/サーバーサービスから始めます。新しいサービスまたは既存のサービスに Service Connect 設定を追加できます。Amazon ECS は、名前空間に Service Connect エンドポイントを作成します。さらに、Amazon ECS は現在実行中のタスクを置き換える新しいデプロイをサービス内に作成します。

既存のタスクやその他のアプリケーションは、既存のエンドポイントや外部アプリケーションに引き続き接続できます。クライアント/サーバーサービスがスケールアウトによってタスクを追加すると、クライアントからの新しい接続はすべてのタスク間で分散されます。クライアント/サーバーサービスが更新されると、クライアントからの新しい接続は新バージョンのタスク間で分散されます。

既存のタスクを解決して新しいエンドポイントに接続することはできません。このエンドポイントを解決して接続できるのは、同じ名前空間に Service Connect 設定があり、このデプロイ後に実行を開始した新しいタスクだけです。

つまり、クライアントアプリケーションのオペレーターがアプリの設定が変更されるタイミングを決定しますが、サーバーアプリケーションのオペレーターはいつでも設定を変更できます。名前空間のエンドポイントのリストは、名前空間のサービスがデプロイされるたびに変更される可能性があります。既存のタスクと置換タスクは、最新のデプロイ後も同じように動作し続けます。

次に挙げるサンプルを参考にしてください。

まず、パブリックインターネット上で利用可能なアプリケーションを 1 つの AWS CloudFormation テンプレートと 1 つの CloudFormation スタックで作成していると仮定します。CloudFormation がパブリック検出と到達可能性を作成するのは、フロントエンドクライアントサービスを含めて、最後にする必要があります。フロントエンドクライアントサービスが実行されていて一般に公開されているのに、バックエンドは公開されていないという期間の発生を避けるために、サービスの作成はこの順序で行う必要があります。これにより、その期間中にエラーメッセージが一般に送信されるのを防ぐことができます。AWS CloudFormation では `dependsOn` を使用して、複数の Amazon ECS サービスを並列または同時に作成できないことを CloudFormation に示す必要があります。クライアントタスクが接続するバックエンドクライアント/サーバーサービスごとに、フロントエンドクライアントサービスに `dependsOn` を追加する必要があります。

次に、フロントエンドサービスが Service Connect 設定なしで存在すると仮定します。タスクは既存のバックエンドサービスに接続しています。まず、フロントエンドが使用する **DNS** または `clientAlias` と同じ名前を使用して、バックエンドサービスにクライアント/サーバー Service Connect 設定を追加します。これにより、新しいデプロイが作成されると共に、すべてのデプロイのロールバック検出や、AWS マネジメントコンソール、AWS CLI、AWS SDK などの、バックエンドサービスをロールバックして以前のデプロイと設定に戻す方法が作成されます。バックエンドサービスのパフォーマンスと動作に問題がなければ、クライアントまたはクライアント/サーバー Service Connect 設定をフロントエンドサービスに追加します。それらの新しいタスクに追加された Service Connect プロキシを使用するのは、新しいデプロイのタスクのみです。この設定に問題がある場合は、デプロイロールバック検出または AWS マネジメントコンソール、AWS CLI、AWS SDK などのバックエンドサービスをロールバックして以前のデプロイと設定に戻す方法を使用することで、ロールバックして以前の設定に戻すことができます。Service Connect ではなく DNS に基づく別のサービス検出システムを使用する場合、フロントエンドまたはクライアントアプリケーションは、ローカル DNS キャッシュの有効期限が切れてから新しいエンドポイントと変更されたエンドポイント設定の使用を開始しますが、これには通常数時間かかります。

## ネットワーク
<a name="service-connect-concepts-network"></a>

デフォルトでは、Service Connect プロキシは、タスク定義ポートマッピングから `containerPort` をリッスンします。セキュリティグループルールでは、クライアントが実行されるサブネットからこのポートへの受信 (イングレス) トラフィックを許可する必要があります。

Service Connect サービス設定でポート番号を設定した場合であっても、Service Connect プロキシがリッスンするクライアント/サーバーサービスのポートは変更されません。このポート番号を設定すると、Amazon ECS はそれらのタスク内の Service Connect プロキシ上で、クライアントサービスが接続するエンドポイントのポートを変更します。クライアントサービスのプロキシは、`containerPort` を使用してクライアント/サーバーサービスのプロキシに接続します。

Service Connect プロキシがリッスンするポートを変更する場合は、クライアント/サーバーサービスの Service Connect 設定で `ingressPortOverride` を変更してください。このポート番号を変更する場合は、このサービスへのトラフィックが使用するこのポートのインバウンドトラフィックを許可する必要があります。

Service Connect 用に設定された Amazon ECS サービスにアプリケーションが送信するトラフィックは、Amazon VPC およびサブネットにおいて、ルートテーブルルールおよびネットワーク ACL ルールにより、使用している `containerPort` と `ingressPortOverride` のポート番号が許可されている必要があります。

 Service Connect を使用して VPC 間でトラフィックを送信できます。ルートテーブルルール、ネットワーク ACL、セキュリティグループに対する同じ要件が両方の VPC に適用されます。

例えば、2 つのクラスターは異なる VPC でタスクを作成します。各クラスターのサービスは、同じ名前空間を使用するように設定されています。これら 2 つのサービスのアプリケーションは、VPC DNS 設定なしで名前空間のすべてのエンドポイントを解決できます。ただし、VPC ピアリング、VPC またはサブネットのルートテーブル、そして VPC ネットワーク ACL により、`containerPort` と `ingressPortOverride` のポート番号のトラフィックが許可されない限り、プロキシは接続できません。

`bridge` ネットワークモードを使用するタスクでは、動的ポートの上限範囲でのトラフィックを許可するインバウンドルールを含むセキュリティグループを作成する必要があります。次に、Service Connect クラスター内のすべての EC2 インスタンスにセキュリティグループを割り当てます。

## Service Connect プロキシ
<a name="service-connect-concepts-proxy"></a>

Service Connect 設定を使用してサービスを作成または更新した場合、新しいタスクが開始されるたびに、Amazon ECS はタスクに新しいコンテナを追加します。別のコンテナを使用するこのパターンは、`sidecar` と呼ばれます。このコンテナはタスク定義には存在せず、設定できません。Amazon ECS は、サービス内のコンテナ設定を管理します。これにより、Service Connect を使用せずに、複数のサービス、名前空間、タスク間で同じタスク定義を再利用できます。

**プロキシリソース**
+ タスク定義では、CPU パラメータとメモリパラメータを設定する必要があります。

  Service Connect プロキシコンテナの処理能力を向上させるために、お客様のタスク CPU とメモリに、256 CPU ユニットと 64 MiB 以上のメモリを追加することをお勧めします。AWS Fargate では、ユーザーが設定できる最小のメモリ容量は 512 MiB です。Amazon EC2 では、タスク定義メモリが必要です。
+ サービスでは、Service Connect 設定でログ設定を設定します。
+ このサービスのタスクがピーク負荷時に 1 秒あたり 500 を超えるリクエストを受信すると予想される場合は、Service Connect プロキシコンテナのこのタスク定義で、タスク CPU に 512 CPU ユニットを追加することをお勧めします。
+ 名前空間内に 100 個以上の Service Connect サービス、または名前空間内のすべての Amazon ECS サービスに合計で 2000 個以上のタスクを作成する場合、Service Connect プロキシコンテナのタスクに対して 128 MiB のメモリを追加することをお勧めします。これは、名前空間内のすべての Amazon ECS サービスで使用されるすべてのタスク定義で行う必要があります。

**プロキシ設定**  
アプリケーションは、アプリケーションと同じタスクでサイドカーコンテナ内のプロキシに接続します。Amazon ECS は、アプリケーションが同じ名前空間のエンドポイント名に接続されている場合にのみアプリケーションがプロキシに接続するように、タスクとコンテナを設定します。その他のすべてのトラフィックはプロキシを使用しません。他のトラフィックには、同じ VPC 内の IP アドレス、AWS サービス エンドポイント、外部トラフィックが含まれます。

**負荷分散**  
Service Connect は、Service Connect エンドポイントのタスク間の負荷分散にラウンドロビン方式を使用するようにプロキシを設定します。接続元のタスクにあるローカルプロキシは、エンドポイントを提供するクライアントサーバーサービス内のタスクの 1 つを選択します。  
例えば、「*local*」という名前空間の*クライアントサービス*として設定されたサービスで WordPress を実行するタスクについて考えてみます。MySQL データベースを実行する 2 つのタスクを持つ、他のサービスがあります。このサービスは、同じ名前空間内の Service Connect を通じて `mysql` と呼ばれるエンドポイントを提供するように構成されています。WordPress タスクでは、WordPress アプリケーションはエンドポイント名を使用してデータベースに接続します。この名前への接続は、同じタスクのサイドカーコンテナで実行されるプロキシに送られます。その後、プロキシはラウンドロビン方式を使用してどちらの MySQL タスクにも接続できます。  
負荷分散戦略: ラウンドロビン

**外れ値の検知**  
この機能では、以前に失敗した接続についてプロキシが保持しているデータを使用して、失敗した接続があったホストに新しい接続を送信しないようにします。Service Connect は、プロキシの外れ値検出機能を設定して、パッシブなヘルスチェックを提供します。  
前の例を使用すると、プロキシはいすれかの MySQL タスクに接続できます。プロキシが特定の MySQL タスクに複数の接続を行い、直近 30 秒間以内に 5 つ以上の接続が失敗した場合、プロキシはその MySQL タスクを 30 ～ 300 秒間回避します。

**再試行**  
Service Connect は、プロキシを通過して失敗した接続を再試行するようにプロキシを設定し、2 回目の試行では、前の接続のホストを使用しません。これにより、Service Connect を介した各接続が 1 回限りの理由で失敗することがなくなります。  
再試行回数: 2

**タイムアウト**  
Service Connect は、クライアント/サーバーアプリケーションが応答するまで最大時間待機するようにプロキシを構成します。デフォルトのタイムアウト値は 15 秒ですが、更新できます。  
任意指定のパラメータ:  
**idleTimeout** - アイドル時に接続がアクティブな状態を維持する時間 (秒)。`0` の値は、`idleTimeout` を無効にします。  
`HTTP`/`HTTP2`/`GRPC` の `idleTimeout` デフォルトは 5 分です。  
`TCP` に対する `idleTimeout` デフォルトは 1 時間です。  
**perRequestTimeout** - リクエストごとにアップストリームが完全なレスポンスで応答するまで待機する時間。`0` の値は `perRequestTimeout` をオフにします。これは、アプリケーションコンテナの `appProtocol` が `HTTP`/`HTTP2`/`GRPC` の場合にのみ設定できます。デフォルト値は 15 秒です。  
`idleTimeout` を `perRequestTimeout` より短い時間に設定すると、`perRequestTimeout` ではなく `idleTimeout` が到達した時点で接続は終了します。

## 考慮事項
<a name="service-connect-considerations"></a>

Service Connect を使用する場合は、次の点を考慮してください。
+ Fargate で実行されるタスクが Service Connect を使用するには、Fargate Linux プラットフォームバージョン `1.4.0` 以上を使用する必要があります。
+ コンテナインスタンスの Amazon ECS エージェントバージョンには `1.67.2` 以降が必要です。
+ コンテナインスタンスが Service Connect を使用するには、Amazon ECS 最適化 Amazon Linux 2023 AMI バージョン `20230428` 以降、または Amazon ECS 最適化 Amazon Linux 2 AMI バージョン `2.0.20221115` を実行する必要があります。これらのバージョンには、Amazon ECS コンテナエージェントに加えて Service Connect エージェントがあります。Service Connect エージェントの詳細については、GitHub の「[Amazon ECS Service Connect エージェント](https://github.com/aws/amazon-ecs-service-connect-agent)」を参照してください。
+ コンテナインスタンスには、リソース `arn:aws:ecs:region:0123456789012:task-set/cluster/*` に対する `ecs:Poll` のアクセス許可が必要です。`ecsInstanceRole` を使用している場合は、アクセス許可を追加する必要はありません。`AmazonEC2ContainerServiceforEC2Role` 管理ポリシーには、必要なアクセス許可があります。詳細については、「[Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md)」を参照してください。
+ `bridge` ネットワークモードを使用し、Service Connect を使用するタスクは、`hostname` コンテナ定義パラメータをサポートしません。
+ Service Connect を使用するには、タスク定義でタスクメモリ制限を設定する必要があります。詳細については、「[Service Connect プロキシ](#service-connect-concepts-proxy)」を参照してください。
+ コンテナのメモリ制限を設定するタスク定義はサポートされていません。

  コンテナにはコンテナメモリ制限を設定できますが、タスクメモリ制限はコンテナメモリ制限の合計よりも大きい数値に設定する必要があります。タスク制限内の追加の CPU とメモリで、コンテナ制限に割り当てられていないものは、Service Connect プロキシコンテナや、コンテナ制限を設定していない他のコンテナによって使用されます。詳細については、「[Service Connect プロキシ](#service-connect-concepts-proxy)」を参照してください。
+ 同じ AWS アカウントに存在する、または AWS Resource Access Manager を使用して AWS アカウントと共有されている同じリージョンに存在する任意の AWS Cloud Map 名前空間を使用するように Service Connect を設定できます。共有名前空間の使用について詳しくは、「[共有 AWS Cloud Map 名前空間を使用した Amazon ECS Service Connect](service-connect-shared-namespaces.md)」を参照してください。
+ 各サービスは 1 つの名前空間のみに属することができます。
+ サービスが作成したタスクのみがサポートされます。
+ すべてのエンドポイントは、名前空間内で一意である必要があります。
+ すべての検出名は、名前空間内で一意である必要があります。
+ アプリケーションが新しいエンドポイントを解決できるようにするには、既存のサービスを再デプロイする必要があります。最新のデプロイ後に名前空間に追加された新しいエンドポイントは、タスク構成には追加されません。詳細については、「[Amazon ECS Service Connect コンポーネント](#service-connect-concepts-deploy)」を参照してください。
+ Service Connect は、クラスターが削除されても名前空間を削除しません。AWS Cloud Map で名前空間を削除する必要があります。
+ Application Load Balancer のトラフィックは、デフォルトで `awsvpc` ネットワークモードの Service Connect エージェントを経由してルーティングされます。サービス以外のトラフィックを Service Connect エージェントをバイパスさせたい場合は、Service Connect サービス設定の `[ingressPortOverride](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)` パラメータを使用してください。
+ Service Connect with TLS は `bridge` ネットワークモードをサポートしていません。`awsvpc` ネットワークモードのみサポートされています。
+ `awsvpc` モードでは、Service Connect プロキシは IPv4 専用およびデュアルスタック設定のサービスの IPv4 localhost `127.0.0.1` にトラフィックを転送します。IPv6 専用設定のサービスの場合、プロキシはトラフィックを IPv6 localhost `::1` に転送します。サービスが IPv4 専用またはデュアルスタック設定から IPv6 専用に更新されたときに、両方の localhost をリッスンするようにアプリケーションを設定することをお勧めします。詳細については、「[EC2 の Amazon ECS タスクネットワークオプション](task-networking.md)」および「[Fargate における Amazon ECS タスクのネットワークオプション](fargate-task-networking.md)」を参照してください。

**Service Connect では、次に示すの機能はサポートされていません。**
+ Windows コンテナ
+ HTTP 1.0
+ スタンドアロンのタスク
+ CodeDeploy および外部デプロイタイプを搭載したブルー/グリーン使用するサービス
+ Amazon ECS Anywhere の `External` コンテナインスタンスは、Service Connect ではサポートされていません。
+ PPv2
+ FIPS モード