Zenn
サイバーエージェント Developer Productivity室Publicationへの投稿
🌐

VPC Latticeも仲間に入れてECSサービス間通信方法5選を比較

t-kikuc
2024/12/25に公開
AWS
ECS
serviceconnect
vpclattice
tech

本記事は、CyberAgent Group SRE Advent Calendar 2024の25日目の記事になります。

本記事では、ECSサービス間通信の選択肢である ALB、VPC Lattice、ECS Service Discovery、ECS Service Connect、App Mesh(終了予定) の5点を比較します。

App Mesh終了告知やre:Invent 2024でのVPC Lattice強化(ECSネイティブ統合,TCPをサポート)を受け、今後のECSサービス間通信の在り方が気になったため整理しました。

※ 本記事の内容は、2024/12/18時点での仕様に基づいています。

先にまとめ

ALB VPC Lattice ECS Service Discovery ECS Service Connect App Mesh（終了予定）
一言で 安定&汎用的 なんでも繋ぐALBの進化系 シンプル名前解決 ECS特化で簡単&多機能 複雑&多機能メッシュ
登場(GA) 2016年 2023年 2018年 2022年 2019年
構築・管理の容易さ 中程度 中程度 👍👍簡単 👍簡単め 👿👿複雑
💰費用 時間+LCU 時間+通信量+リクエスト数 👍👍激安 サイドカー サイドカー
🔭ログ・メトリクス 👍対応 👍対応 👿なし 👍対応 👍対応
🔭トレース 👿なし 👿なし 👿なし 👿なし 👍対応
🛡️ヘルスチェック 👍対応 👍対応 👍対応(コンテナレベル) 👍一応対応[1] 👍対応
🛡️自動リトライ 👿なし 👿なし 👿なし 👍対応 👍対応
🛡️サーキットブレーカー 👿なし 👿なし 👿なし 一部
(外れ値検出)		 👍対応
🚢対応デプロイタイプ 👍全て 一応全て 👍全て 👿ECSのみ 👍全て
🚢Canaryのやりやすさ 👍容易 👍容易 👿どうにか 👿不可 👍容易
🐙ECS以外からの名前解決 👍可能 👍可能 👍可能 👿不可 👍可能
🐙VPC間通信 👍可能(要VPC Peering等) 👍👍得意 👿不可 👍可能 👍可能
🐙アカウント間通信 👍可能(要VPC Peering等) 👍👍得意 👿不可 👿不可 👍可能

選定基準の一例を示します。

  • 「それなりに機能揃ってて、使い慣れてて、今後も消えないのがいい」
    -> ALB
  • 「ECS以外にもEKSやLambda等色々使ってて、かつ多くのVPC/アカウント同士を繋げたい」
    -> VPC Lattice
  • 「シンプルに名前解決できればOK。信頼性・可観測性は不要or自前実装する」
    -> Service Discovery
  • 「ECS間を信頼性・可観測性高く繋げたい。ECS以外との通信は少ないから別途考える」
    -> Service Connect
  • 「マイクロサービスの数が多く、信頼性・可観測性へのこだわりが強い。ECS以外も繋ぐ」
    -> App Mesh （終了予定なので、VPC Latticeか、Service Connect+αか...）

そもそもECSのサービス間通信とは

ECSサービス->ECSサービスの通信を指します。


ECSサービス間通信

単に「アクセス先をどう見つけるか」だけでなく、「アクセス先が落ちていたらどうするか」「通信の可観測性はどうか」など、様々な考慮事項があります。

実際にはLambdaやEC2からECSにアクセスする場合もあるので、本記事では比較観点の一つとして触れます。

各通信方法の概要

1. ALB

ALBはL7のLBで、ECS以外との接続にも利用可能です。
最も"枯れて"いて情報量が多い点と、「ALBがサービス終了することはないだろう」という安心感が強みだと思います。

接続方法

サービス間通信用のALBを構築し、そのドメイン名でアクセスします。


ALBでのサービス間通信

ALBにパスベースでルーティングルールを複数設定すれば、ALBを大量に作らずに済みます。

例）　/web なら service-webへ、 /app なら service-appへ

2. VPC Lattice

VPC LatticeはALBを抽象化したようなアプリケーション接続サービスで、2023年3月にGAしました。
EC2、EKS、Lambdaも接続でき、VPCまたぎやアカウントまたぎが強みです。

接続方法

Lattice Serviceのドメイン名+ポートでアクセスし、
Listenerで定義されたLattice Target Groupに紐づくECSサービスにアクセスします。


VPC LatticeによるECSサービス間連携

  • Lattice Service Network: Lattice Serviceの論理的な集合
  • Lattice Service: 「ALB一つ」に近く、ドメイン名や複数のListenerを持てる
  • Lattice Target Group: ELBのターゲットグループとほぼ同じだが、互換性はない

ECSとのネイティブ統合前

従来はECSの前段にALBが必要でしたが、2024/11/18のアップデートにより不要になりました。


従来: ECSの前段にALBが必要だった

複数のECSサービスを紐付ける

各ListenerにはALB同様に複数のListenerRuleを設定できます。
パスベースのルーティングを設定することで、1つのLattice Serviceに複数のECSサービスを紐づけられます。


1つのLattice Serviceに複数のECSサービスを紐づける

これにより管理性向上に加えてコスト低下が見込めます。
後述しますが、Lattice Service1つ毎に時間課金が発生するためです。

その他の特徴

3. ECS Service Discovery

ECS Service Discovery(サービス検出)は、簡単な名前解決機構を提供します。
信頼性や可観測性関連がほとんどないかわりに、シンプルかつ安価で済みます。

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html

接続方法

  1. クライアント側が<サービスのnamespace>.<hosted-zone名>で名前解決し、バックエンドのTaskのIPアドレスを取得する
  2. そのIPアドレスを使ってアクセスする


Service Discoveryの概観

他の方法と異なり、コンテナが対向サービスに対して直接通信できます。

4. ECS Service Connect

Service Connectは、ELB + Service Discovery + App Meshの折衷として2022年11月に登場しました。
ECS->ECSに特化している点と、簡単な設定で信頼性・可観測性周りを整備できる点が特徴です。

詳細はこちらをご覧ください。

https://speakerdeck.com/kashinoki38/ecs-service-connect-de-ecs-shang-nomaikurosabisunonai-zhang-hai-xing-toke-guan-ce-xing-wogao-meyou?slide=25

接続方法

Envoyベースのサイドカーコンテナ（Service Connect Agent）が通信を代行します。
Cloud Mapへの登録、Cloud Mapを介したアクセス先の検出、アクセスを自動でやってくれます。


Service Connectの概観

余談）LambdaやVPC Latticeとの統合

Service ConnectとLambdaと統合したりVPC Latticeと統合するリクエストが上がっています。
思想や仕組み的に困難な可能性もありますが、実現されるとService Connectの可能性が一気に広がると思います。

5. App Mesh （サービス終了予定）

App Meshは多機能なサービスメッシュを提供するサービスで、
[1]Envoyのマネージドコントロールプレーンと[2]Envoyサイドカーコンテナからなります。

2026/09/30をもってサービス終了することがアナウンスされています。移行先として以下の2つが推奨されていそうです。

接続方法

Service Connect同様、サイドカーが色々やってくれます。
サービス終了予定のため、仕組みの詳細は割愛します。


App Meshの概観

観点ごとに比較

ここからは基本的にApp Meshには触れません。
サービス終了予定である上に、複雑性以外では概ね強力だからです。

費用💰

ALB VPC Lattice 👑ECS Service Discovery ECS Service Connect App Mesh
費用 時間+LCU 時間+通信量+リクエスト数 👍👍激安 サイドカー サイドカー
  • Service Discoveryはサイドカーなども存在しないので、圧倒的に安いです
  • ALBはLCU単位の複雑な費用計算が必要です
  • VPC LatticeはLattice Service毎に時間課金があります
    • 時間課金のみで1Service月額約¥3.5kかかります（$0.0325/h x 24 x 30 x ¥150/$）
    • ECSサービス毎にLattice Serviceを作るのではなく、複数のECSサービスを1つのLattice Serviceに紐づけるのが費用面では良さそうです（ALBと同様）
  • Service Connectはサイドカーのリソースに課金されます
    • サイドカーの最低推奨スペックをx86のFargateで動かすと、1タスクあたり月額約¥1.4kかかります ($0.05056/h x 0.25 x 24 x 30 x ¥150/$)[2]
    • もちろん、トラフィックによってはより大きなサイズが必要になりえます
    • タスク数が多い場合、費用的に不利かもしれません

可観測性🔭

ALB VPC Lattice ECS Service Discovery ECS Service Connect App Mesh
ログ・メトリクス 👍対応 👍対応 👿なし 👍対応 👍対応
トレース 👿なし(IDは付与される) 👿なし 👿なし 👿なし 👍対応
  • Service Discoveryは思想的に可観測性を削っていて、今後も対応はないと思います
  • トレースはApp Meshの独擅場で、EnvoyサイドカーによってX-RayやDatadog等にデータを送信できました
  • Service ConnectもEnvoyベースなので、今後トレースが対応される可能性もあると思います
  • ALBはリクエストヘッダーにX-Amzn-Trace-Idが付与されますが、これ単体ではリッチな分散トレーシングはできません

信頼性🛡️

ALB VPC Lattice ECS Service Discovery 👑ECS Service Connect App Mesh
ヘルスチェック 👍
対応		 👍対応 👍対応
(コンテナレベル)		 👍一応対応[1:1] 👍対応
自動リトライ 👿
なし		 👿なし 👿なし 👍対応 👍対応
サーキットブレーカー 👿
なし		 👿なし 👿なし 一部(外れ値検出) 👍対応
  • ヘルスチェックは不可欠と思いますが、自動リトライやサーキットブレーカーは必須ではないと思います
  • Service Connectが自動リトライと外れ値検出の点で優位です
    • 自動リトライでは、失敗したタスクとは別のタスクにリトライされます
  • App Meshのサーキットブレーカーは、[1]外れ値検出 +[2]接続プール からなるようです
    • 外れ値検出(outlier detection): 実トラフィックを監視して、エラーが多いホストへのルーティングを止める
    • 接続プール: 同時接続数またはリクエスト数を制限

https://aws.amazon.com/about-aws/whats-new/2020/11/aws-app-mesh-introduces-circuit-breaker-capabilities/?nc1=h_ls

デプロイ🚢

👑ALB VPC Lattice ECS Service Discovery ECS Service Connect App Mesh
対応デプロイタイプ 👍
全て		 一応全て 👍全て 👿ECSのみ 👍全て
Canaryのやりやすさ 👍
容易		 👍容易 👿どうにか 👿不可 👍容易

※ ECSのデプロイタイプは、ECS(ローリングアップデート)、CODE_DEPLOY(Blue/Green)、EXTERNAL(外部デプロイ)の3種です。

  • ALBが最も扱いやすいです。ECSとよく統合されていて、制約が少ないです
  • VPC LatticeはListenerRuleを操作することでALB同様にCanaryが可能です
    • Internal-ALBを配置する場合は、結局ALBなのですべてのデプロイタイプに対応でき、柔軟なデプロイを実現できます
    • ただしECSとのネイティブ統合においてはECSデプロイタイプしか選択できません
  • Service Discoveryはすべてのデプロイタイプに対応しているものの、ルーティングを柔軟に制御する機構がないため、Canaryは困難です[3]
  • Service ConnectはECSデプロイタイプしか使えず、デプロイの自由度は低いです。

接続相手の幅広さ🐙

ALB 👑VPC Lattice ECS Service Discovery ECS Service Connect App Mesh
ECS以外からの名前解決 👍可能 👍可能 👍可能 👿不可 👍可能
VPC間通信 👍可能(要VPC Peering等) 👍👍得意 👿不可 👍可能 👍可能
アカウント間通信 👍可能(要VPC Peering等) 👍👍得意 👿不可 👿不可 👍可能
  • VPC Latticeのアイデンティティであり、最も得意とする領域です
  • ALBは通常のVPC内リソースであり、VPCやアカウントを跨ぐ際にはVPC Peeringなどの補助が必要です
  • Service DiscoveryはVPCやアカウントを跨げませんが、それゆえにシンプルさを保てると思います
  • Service ConnectはECS特化であり、最も限定的です

おわりに

費用面や複雑さを考慮すると、「そもそもECSサービス間通信を減らす」という選択肢もある気がします。

VPC LatticeとService Connectの成長に今後も注目したいです。

脚注

  1. 現状では「タスクがHEALTHYになる前でもルーティングされる」ケースがあるようです https://github.com/aws/containers-roadmap/issues/2334 ↩︎ ↩︎

  2. サイドカー用にタスク毎に最低 256CPU(=0.25vCPU)と64MiB の追加が推奨されています。https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-connect-concepts-deploy.html#service-connect-concepts-proxy ↩︎

  3. 強引な方法はこちらを参照してください https://qiita.com/t-kikuc/items/69957ee2c6b490a01b6d ↩︎

サイバーエージェント Developer Productivity室
サイバーエージェント Developer Productivity室Publication

株式会社サイバーエージェント Developer Productivity室です。 全社の開発生産性向上のために活動しています。PipeCDやBucketeerというOSSも開発しています。

Discussion