目次

• はじめに
• サービス概要
• 検証で得た知見
  • サービスメッシュ通信
  • 無停止リリース
  • 通信の振り分け
  • gRPCのエラー
  • ECSクラスターのスケールトリガー
  • ECS Service Connectの設定値反映タイミング
  • ECS Service Connectのチューニングレベル
  • タスク内の可観測性
  • ECS Service Connectのサービス閉塞
• 今後のUpdateについて
• 最後に
• 参考サイト

はじめに

Amazon ECS Service Connect（以下、ECS Service Connect）を現場で検証する機会がありました。
最終的に案件での採用には至りませんでしたが、本記事では、そのサービス概要とフィージビリティ検証を通じて得られた情報を共有します。

サービス概要

ECS Service Connectは、2022年にリリースされたAmazon Elastic Container Service(以下、ECS)の設定として提供される機能です。
この機能は、ECSのサービス検出、接続性、トラフィックの可観測性を簡略化します。
ECS Service Connectによるサービスの新しいつなぎ方 ⧉に記載の通り、ECS Service ConnectはこれまでのECSサービス間接続の課題を解消する新しい通信管理の機能であり、Application Load Balancer(以下、ALB)のコスト削減やトラフィック関連メトリクスが取得可能となります。

具体的には、今までECS上でマイクロサービスを実現する(ECSサービス間接続を行う)とき、代表的な3つの選択肢(下記の1～3)がありましたが、それぞれデメリットもありました。
マイクロサービスについては、こちら ⧉をご覧ください。

1. ALBの利用
   • メリット
     • トラフィックのテレメトリデータ(システムの状態を表すデータ)をALBで取得することが可能。
     • Blue/Greenデプロイメントが可能。
   • デメリット
     • 高可用性のためのインフラストラクチャの構成を慎重に計画する必要があり、追加のインフラストラクチャコストが発生する。
     • ALBを追加することでホップ数(目的地に到達するまでに経由することになる中継機器の数)が増加するので、ネットワークレイテンシーが増加する。
2. Amazon ECS Service Discovery(以下、ECS Service Discovery)の利用
   • メリット
     • Amazon Route53とAWS Cloud Map(以下、Cloud Map)を利用することで、シンプルなDNSサービスディスカバリーが可能。(通信したい相手のサービスを名前解決し、お互いが直接通信する形)
   • デメリット
     • あくまで名前解決を行うことまでが責任範囲になるので、トラフィックのテレメトリデータの取得が難しい。
     • トラフィックメトリクスの収集や、エンドポイントの正当性把握など、追加のアプリケーションコードが必要な場合が多い。
     • リトライ等の信頼性を保つ通信制御の実装を自前で行う必要がある。
     • 多くの場合、開発者はトラフィックメトリクスを収集し、ネットワーク呼び出しの耐障害性を高めるためのカスタムアプリケーションコードを記述する必要がある。
3. AWS App Mesh(以下、App Mesh)の利用
   • メリット
     • トラフィックを豊富に可視化できる。(サービス間の高度なトラフィック監視機能)
     • きめ細かなトラフィックの制御を行うことができる。(サービス間の高度なルーティング機能)
     • 暗号化や認証を行うことができる。
   • デメリット
     • ECSとは別のApp Mesh自体やEnvoy等の追加コンポーネントの管理が必要になる。
     • 柔軟性に伴い、複雑性が増す。
     • 2026年9月30日をもってサービス終了するため、今後の利用は推奨されない。

ECS Service Connectは1～3の良いとこ取りをしたいということで生まれました。

4. ECS Service Connectの利用
   • メリット
     • Cloud Mapが提供する名前空間を使用して論理名でサービスを参照および接続。
     • ロードバランサーをデプロイおよび構成することなく、ECSタスク間でトラフィックを自動的に分散。
     • ヘルスチェックが可能。
     • 503エラー(サーバーへのアクセス上限を超えたアクセスが発生した時)の自動再試行が可能。
     • コネクションの終了を適切に処理できる。
     • HTTP/1、HTTP/2、gRPC、TCPプロトコルをサポートしている。
   • デメリット
     • ECS Service Connectでサポートされるのは、ローリングデプロイを使用するサービスのみ。
     • Blue/Greenおよび外部デプロイタイプを使用するサービスはサポートしない。
     • Windowsコンテナをサポートしていない。
     • ECSサービスに紐付かないタスクをサポートしていない。

概要を理解するには、ECS Service Connectによるサービスの新しいつなぎ方 ⧉のスライドに加えて、Amazon Web Servicesブログに掲載のAmazon ECS Service Connect によるサービス間通信の管理 (15分) ⧉の動画が分かり易い内容となっていました。動画の後半には、curlとNginxを利用したデモも含まれているので、設定や操作のイメージが湧きやすく、おすすめです。

また、サービスを使用する場合の設定方法は、AWS ECS Service Connect について理解する ⧉に記載の通りです。概要として以下の流れで作成していきます。

1. ECSクラスターの作成 (Namespaceも併せて作成)
2. ECSサービスの作成 (ECS Service Connectの設定)

検証で得た知見

実際にECS Service Connectを触ってみたり、AWSサポートへの問い合わせを行ったりして分かったことをまとめます。

サービスメッシュ通信

• ECSクラスターが単一の場合でも複数の場合でも、ECS Service Connectで設定しているDNS名、ポートを使用してECSサービス間の通信が可能です。
• ECS Execを使用して、クライアント側からサービス側のコンテナに対してcurlコマンドを実行した際、レスポンスヘッダーが「server: envoy」になっていることからService Connectプロキシ(Envoy)が使用されていることを確認できます。
  (参考：ECS Exec を使用して Amazon ECS コンテナをモニタリングする ⧉、Amazon ECS Execを使ってみる ⧉)
• AWSサポートから「同一クラスター内通信か、クラスター間通信かによって通信速度の差異は生じません。」と回答受領しました。

無停止リリース

• ECS Service Connectの前段にNLBを置く構成の場合、NLBのDraining設定がECS Service Connectの設定よりも優位となります。
• ECS Service ConnectのConnection Drainingの設定はAmazon ECS Service Connect Agent ⧉に記載の「LISTENER_DRAIN_WAIT_TIME_S」が対応し、デフォルトで20秒に設定されており、現時点にてECS Service Connectでは当該環境変数を設定することができません。
• ECS Service Connect利用の際はタスクで利用するCPUやメモリのリソースに加え、Service Connectプロキシのためのリソースも追加する必要があります。(参考：プロキシリソース ⧉)
  Service Connectプロキシで利用するリソースを考慮しないと、タスクを実行するアプリケーションコンテナが過負荷状態となり、503 (Service Unavailable) エラーを返す可能性があります。
  • 検証の中では、ECSタスク定義でタスクのCPU、Memoryを調整してECSサービス(クライアントとサーバー)間の通信を確認した時、CPU:1024、Memory:2048を設定した時にエラー(503 Service Unavailable)が発生しました。
  • 503エラーが発生していた原因は、現状のECS Service Connectではアプリケーションコンテナのヘルスチェック成功（リクエストを受け付けられる状態）を待機してからリクエストをルーティングする機能がなく、プロキシはアプリケーションコンテナがリクエストを受け付けられるようになる前であってもリクエストをルーティングしてしまう可能性があるためです。
  • 検証で発生したような503エラーを回避するためには、①503エラーの発生を想定してクライアント側でのリトライを実装する、②Application Load Balancer(以下、ALB)などヘルスチェック機能があるサービスを利用するといった対策を検討する必要があります。
• ECSサービスの設定変更を行った場合は、サービスに紐付くECSタスクは徐々に切り替わり、順次置換されていきます。
• カナリアリリースは可能ですが、AWSによると、特定ユーザーへの限定リリース（ダークカナリアリリース）は行えず、今後も対応予定はないとされています。

通信の振り分け

• 負荷分散
  • シングルAZでのECSタスクの負荷分散
    • 単一ECSクラスター構成、複数ECSクラスター構成それぞれでサーバー側のECSタスクを2つずつ配置し、サービス間通信の全てのcurlコマンド実行でOKが返され、各ECSタスクの負荷分散の状況が、curlコマンドの実行レスポンスやサーバー側のECSコンテナログなどから確認できました。
  • マルチAZでのECSタスクの負荷分散
    • ECS Service Connect では各タスクにサイドカーコンテナを追加してプロキシとして動作させていて、負荷分散はこのサイドカーコンテナが担い、負荷分散のアルゴリズムはラウンドロビンです。
  • 接続元の ECSサービスに複数のタスクが存在する場合には、各タスクがそれぞれラウンドロビンによる負荷分散を行うため、接続元のタスク単位では均等になることが見込まれますが、全体としては各タスクがリクエストを送信したタイミング等により完全には均等にはならない可能性が想定されます。もし、全体としてリクエスト数を均等にすることを優先したい場合はALBの利用を検討する必要があります。
    • このECS Service Connectの負荷分散ロジックは変更できないため、当該挙動が許容できない場合は、ECS Service Connectは要件にあった機能ではない可能性があります。
• 異常なインスタンスが発生した場合
  • 異常なインスタンス(ヘルスチェックのエラー)が発生した場合、新しいタスクが起動し、curlコマンド実行でエラーが発生しないことを確認しました。また、旧タスクが停止された時間から、新タスクへのリクエストが行われていることをECSコンテナログから確認しました。
• リクエストのリトライ
  • AWS公式ドキュメントによると、ECS Service Connectのリトライは再試行回数:2で設定されていて、リトライ回数の設定変更はできません。(参考：再試行 ⧉)
  • Service Connectプロキシログの通常の設定ではリトライのログは出力されません。一方で、ECS Service Connect Agent が提供する API ⧉を使用してログレベルを上げることで、リトライのログの表示をすることは可能ですが、ホストにログイン可能なEC2起動タイプの場合のみ実現が可能で、Fargate起動タイプではホストにログインできないため、リトライログの確認は不可能です。

gRPCのエラー

• ECS Service ConnectのOutlier Detection機能でgRPCのエラーがカウントされるかは確認できません。
  • 外れ値検知（サーキットブレーカー）について、ECS Service Connect agent 上で動作する Envoy の設定項目について公開されたドキュメント上での情報を確認できない、Fargate 起動タイプのサービス上で動作する ECS Service Connect agent のEnvoyの設定項目をご確認いただくことはできない、とAWSサポートから回答受領しました。
• CloudWatchログ、メトリクスを確認して、gRPCのトラフィックについてエラーが発生することをケース1, 2でそれぞれ確認しました。
  • ケース1：サーバー側のECSサービスに付与されているセキュリティグループのインバウンドルールの一部(ポートを9090にしているルール)を削除して、UNAVAILABLEエラーをCloudWatchログで確認しました。
  • ケース2：サーバー側のECSコンテナを0台にして、UNAVAILABLEエラーをCloudWatchログで確認し、それぞれのケースで、CloudWatchメトリクスであるGrpcRequestCountにカウントされていないことも確認しました。
• gRPCのエラートラフィックをカウントするCloudWatchメトリクスは存在しませんが、AWS公式ドキュメント ⧉によると正常なgRPCトラフィックリクエスト数をカウントするメトリクス「GrpcRequestCount」は存在します。

ECSクラスターのスケールトリガー

• ECSタスクをFargateで実行する場合は、ECSクラスターのスケーリングは不要です。
• Amazon ECS サービスを自動的にスケーリングするためには、メトリクス値、アラーム、スケジュールを使用します。
• 手動スケーリング
  • 必要なタスクの数を変更することで、手動でのECSタスクのスケーリングができます。

ECS Service Connectの設定値反映タイミング

• ECS Service Connectの設定値を変更する時、ECS サービス更新によってECS Service Connectの新たな設定が反映された ECS タスクが起動します。
  • 設定値変更時に実行される API：UpdateService API(サービスの更新を行う)→RegisterInstance API(新たな ECS タスクが起動した際にこちらのタスクをサービスインスタンスとして登録する)→DeregisterInstance API(サービスインスタンスとして登録されていた古いタスクを登録解除する)
• ECS Service Connectを有効化し、タイムアウト値などのECS Service Connect設定値を変更した際に、ECS Service Connect Agent側へ設定反映されるタイミングが大きくずれる事象が発生する可能性はあります。
  • AWSサポートからは「新たな ECS タスクの起動の遅延には様々な要因がございますが、一例といたしまして、ECS タスク内のコンテナ起動時の処理による影響や AWS 基盤側の問題等が挙げれるかと存じます。一方で、新たなECSタスクの起動が完了してからサービスインスタンスとして登録する処理に遅延する事象の条件や原因をご案内いたしております具体的な公開情報を確認することはできませんでした。そのため、当方の環境にて検証いたしました限りでは ECS タスクが起動してから RegisterInstance API が実行されるまでに大きく遅延する事象は確認できておりませんが、お客様の環境にてECS Service Connect設定後に遅延する事象が発生いたしましたら、原因に関して調査いたしますためご連絡いただけますと幸いでございます。」と回答受領しました。
• ECS Service Connect Agent側への設定反映タイミングを確認するには、Service Connectプロキシログでは確認できないので、CloudTrail 内の RegisterInstance/ DeregisterInstance API の実行履歴を確認します。

ECS Service Connectのチューニングレベル

• Envoy固有のパラメータ
  • Envoyの設定変更について、AWSドキュメントにて「これらの環境変数は、App Meshで使用する場合は設定でき、ECS Service Connectで使用する場合は設定できません。」と記載があります。
  • ECSタスク定義でService Connectプロキシコンテナ向けにEnvoyの変数を設定できるか実機で確認しましたが、設定できないことを確認しました。
  • Service Connectプロキシ（Envoy）コンテナには、ECS Execでアクセスは行えません。
• 流量制御
  • システムが処理できる以上のデータを制限することで、データ損失や性能低下を防ぐための機能を期待していましたが、AWSによると、「現状、グローバル/ローカルレートリミット機能は提供しておらず、今後も予定はありません。理由としては、レートリミットによるEnvoyからのエラー応答でエラーレートが上がり、アプリケーションの実装も複雑になるためです。」と回答を受けました。
• サーキットブレーカー(外れ値検知)
  • 具体的にEnvoyのOutlier detectionやCircuit breakersでどんな設定がなされているかは確認できていません。AWSサポートから「ECS Service Connect agent上で動作するEnvoyの設定項目について、公開されたドキュメント上での情報を確認できておりません。」「Fargate 起動タイプのサービス上で動作するECS Service Connect agentのEnvoyの設定項目をご確認いただくことはできません。」と回答受領しました。

タスク内の可観測性

• CloudWatchログ
  • 検証を通して、既にECSコンテナログ、Service Connectプロキシ(Envoy)ログを確認できることは判明しています。ただ、Service Connectプロキシのログについて、基本的にはService Connectプロキシが正常に動作しているかを確認するためのログであるため、当該ログにはリトライのログは取得されません。ECS Fargateを使用する場合、Service Connectプロキシの出力についてはホストにログイン可能ではないためログレベルの変更ができず、限られたEnvoyログのみが確認できます。
• CloudWatchメトリクス
  • ECS Service Connectの可観測性機能を使用してトラフィックメトリクスを収集可能です。 デフォルトで確認できる項目には、各ECSサービスの正常/異常なエンドポイントの数や受信/送信トラフィック量があります。
  • 確認できるECSのメトリクスの一覧 ⧉に、「このメトリクスは、Amazon ECS Service Connect を設定した場合にのみ使用できます。」というメトリクスが明記されています。

ECS Service Connectのサービス閉塞

• ECS Service Connectにサービス閉塞の機能はありません。
  • AWSサポートから、「ECS Service Connectを有効化した状態で、ECS Service AがECS Service BおよびECS Service Cにそれぞれサービスメッシュで接続する場合、 ECS Service A→ECS Service Bの経路は接続性を維持しつつ、ECS Service A→ECS Service Cの経路を遮断（任意のHTTPレスポンスコードを返却）するような機能はありません。」と回答がありました。

最後に

ECS Service Connectではリリースの要件を満たすことができず、結果として案件での採用までは叶わなかったのですが、今後のサービスアップデートにより採用される機会も増えるかと思います。
もしECS Service Connectを利用する際に、本記事が少しでも参考になれば幸いです。

参考サイト

• New – Amazon ECS Service Connect Enabling Easy Communication Between Microservices ⧉
• Service Connect を使用して Amazon ECS サービスを短縮名で接続する ⧉
• ECS Service Connectによるサービスの新しいつなぎ方 ⧉
• ECSの新ネットワーク機能「Service Connect」がリリースされました！ ⧉
• ECS の「サービス検出」と「Service Connect」を AWS マネジメントコンソールから作成してみる ⧉