今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025

AWS Summit Japan 2025 > Day2 Community Stage での登壇資料です。発表時間は20分間。

選定が難しくなっている2025年現在において、多少でもヒントになればと思います。

スライド内のリンク一覧

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

- AWS App Mesh から Amazon ECS Service Connect への移行
- AWS Product Lifecycle ページ

- 【AWS Black Belt Online Seminar】AWS App Mesh
- 第二十六回 ちょっぴりDD Amazon ECS Service Connect によるサービス間通信の管理
- PrivateLink and Lattice - Amazon VPC Lattice Service 編【AWS Black Belt】
- サービスメッシュは本当に必要なのか、何を解決するのか —— AWS Summit Tokyo 2019

- Application Load Balancer - Automatic Target Weights の発表

- AWS Containers Roadmap

Transcript

1. 今なら Amazon ECS の サービス間通信をどう選ぶか 2025-06-26 AWS Summit Japan 2025 Community Stage (Day 2) Tetsuya Kikuchi 1/51
2. ソフトウェアエンジニア として CI/CD を主に担当 所属： 株式会社サイバーエージェント ← 大手SIer Containers 分野の AWS Community Builder (2025 年〜) 好きなサービス： Amazon ECS 菊池 哲哉 (@t-kikuc) 2/51
3. Amazon Elastic Container Service ( 以下、ECS) の「サービス」間を繋ぐ主な方法 1. Application Load Balancer （以下、ALB ） 2. Amazon VPC Lattice （以下、VPC Lattice ） 3. Amazon ECS service discovery （以下、ECS service discovery ） 4. Amazon ECS Service Connect （以下、ECS Service Connect ） 5. AWS App Mesh （以下、App Mesh 。サポート終了決定） 3/51
4. ECS のサービス間の通信 4/51
5. ECS のサービス間の通信 5/51
6. ECS のサービス間の通信 6/51
7. 1. 現在なぜ、ECS サービス間通信の選定が難しいのか？ 2. 各方式の概要 3. 選定フローの一例 ゴール: ECS サービス間通信の選定が少しクリアになること 本日の内容 7/51
8. https://zenn.dev/cadp/articles/ecs-service-mesh-compare マイクロサービスとは何か？サービスメッシュとは何か？ 各方式の仕組みの詳細 カタログスペックの詳細な比較 ※ 本セッションでは、プロトコルは HTTP / HTTPS / gRPC に限定します。 参考: 「VPC Lattice も仲間に入れて 　　　 ECS サービス間通信方法5 選を比較」( 拙記事。2024 年末) 本日話さないこと 8/51
9. 背景: 現在なぜ、サービス間通信の選定が難しいのか？ 9/51
10. 今なら Amazon ECS の サービス間通信をどう選ぶか 10/51
11. 今なら Amazon ECS の サービス間通信をどう選ぶか 11/51
12. https://aws.amazon.com/jp/blogs/news/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect/ 「多機能が欲しい場合はどうすればいい？」 1. App Mesh のサポート終了が決定 12/51
13. https://aws.amazon.com/jp/products/lifecycle/ 2025 年5 月には AWS Product Lifecycle ページが登場 「技術選定は保守的にせざるを得なくなったなぁ... 」 2. 複数のサービスが終了決定 13/51
14. 2022 年: ECS Service Connect が GA 2023 年: VPC Lattice が GA 「それぞれの強み・弱みがまだわからない... 」 3. 新たな選択肢の登場 14/51
15. 今、ECS サービス間通信の選定がより一層難しい 背景 App Mesh 終了 複数のサービス終了 新たな選択肢の登場 選定への影響 → 多機能欲しいのに... → 選定が保守的/ 不安に → キャッチアップが必要 → 選択肢が多くて迷う 15/51
16. 今、ECS サービス間通信の選定がより一層難しい 背景 App Mesh 終了 複数のサービス終了 新たな選択肢の登場 選定への影響 → 多機能欲しいのに... → 選定が保守的/ 不安に → キャッチアップが必要 → 選択肢が多くて迷う 対策 → 本当に必要か検討する 16/51
17. 今、ECS サービス間通信の選定がより一層難しい 背景 App Mesh 終了 複数のサービス終了 新たな選択肢の登場 選定への影響 → 多機能欲しいのに... → 選定が保守的/ 不安に → キャッチアップが必要 → 選択肢が多くて迷う 対策 → 本当に必要か検討する → 将来性も推測する 17/51
18. 今、ECS サービス間通信の選定がより一層難しい 背景 App Mesh 終了 複数のサービス終了 新たな選択肢の登場 選定への影響 → 多機能欲しいのに... → 選定が保守的/ 不安に → キャッチアップが必要 → 選択肢が多くて迷う 対策 → 本当に必要か検討する → 将来性も推測する → 次のセクションで概説します 18/51
19. 今、ECS サービス間通信の選定がより一層難しい 背景 App Mesh 終了 複数のサービス終了 新たな選択肢の登場 選定への影響 → 多機能欲しいのに... → 選定が保守的/ 不安に → キャッチアップが必要 → 選択肢が多くて迷う 対策 → 本当に必要か検討する → 将来性も推測する → 次のセクションで概説します → 選定方法の一例を示します 19/51
20. おさらい: 各サービス間通信方式の概要 20/51
21. 1. 2016 年: ALB 2. 2018 年: ECS service discovery 3. 2019 年: App Mesh （サポート終了決定） 4. 2022 年: ECS Service Connect 5. 2023 年: VPC Lattice 主なサービス間通信方式 （GA 順） 21/51
22. L7 のロードバランサー ALB のドメイン名でアクセスし、ALB が負荷分散やヘルスチェックを担う 追加のインフラコンポネント管理が必要 1. ALB 22/51
23. リクエストパス等に応じたルーティングも可能なため、 ALB を大量に作成する必要はない 1. ALB 23/51
24. 名前解決に特化したシンプルな機能 リトライなどの制御やテレメトリデータの取得は自前実装が必要 2. ECS service discovery 24/51
25. 多機能なサービスメッシュを実現 可観測性、リトライ制御、柔軟なトラフィック制御、暗号化、認証など クライアント・サーバともに ECS 以外にも対応 構築・管理は複雑 3. App Mesh ( サポート終了決定) https://www.youtube.com/watch?v=IC7sxVh7HNM 詳細: Amazon Web Services Japan 公式 > 「 【AWS Black Belt Online Seminar 】AWS App Mesh 」 25/51
26. ALB / ECS service discovery / App Mesh の折衷として2022 年に登場 簡単な設定で、信頼性・可観測性を高められる。 ECS に特化 4. ECS Service Connect https://www.youtube.com/watch?v=emmk3U0whSQ 詳細: Amazon Web Services Japan 公式 > 「第二十六回 ちょっぴりDD Amazon ECS Service Connect によるサービス間通信の管理」 26/51
27. あらゆるアプリケーションを簡単に接続するサービス。2023 年に登場 ECS 、Amazon EC2 、Amazon EKS 、AWS Lambda 、複数VPC/ アカウント、... パスベースのルーティングなども設定可能 5. VPC Lattice https://www.youtube.com/watch?v=6_s_KuKkahY 詳細: Amazon Web Services Japan 公式 > 「PrivateLink and Lattice - Amazon VPC Lattice Service 編【AWS Black Belt 】 」 27/51
28. 「あとはスペックを比較すれば決められるか？」 28/51
29. 比較項目が多すぎるから（15 以上） そもそも判断基準が未確定だから 絶対に譲れない項目があれば楽 サービス/ 機能の将来性は、カタログスペックには載らないから 「あとはスペックを比較すれば決められるか？」 → まだ難しい 29/51
30. 選定フローの一例 30/51
31. 1. シンプルな構成を検討する 2. クロスアカウントでの方式を決める 3. 様々な観点で比較 4. 迷ったら ALB 31/51
32. 1. シンプルな構成を検討する 2. クロスアカウントでの方式を決める 3. 様々な観点で比較 4. 迷ったら ALB 32/51
33. A. モノリスで単一サービス B. North-South 通信のみの複数サービス サービス間通信が不要な構成の例 33/51
34. サービス間通信をなくすメリット 複雑性やレイテンシの増加を回避できる 関連機能のサポート終了への心配がなくなる 理由を明確にしておくと、後々の判断軸にもなる 「本当にサービス間通信は必要か？」 34/51
35. https://www.youtube.com/watch?v=ZwfdLAClzsc 「サービスメッシュは本当に必要なのか、何を解決するのか」 —— AWS Summit Tokyo 2019 参考 35/51
36. 1. シンプルな構成を検討する 2. クロスアカウントでの方式を決める 3. 様々な観点で比較 4. 迷ったら ALB 36/51
37. アカウント分割が先に確定し、検討必須な場合があるから（例：外部監査向け） ALB か VPC Lattice の2 択に絞れるから ECS Service Connect はクロスアカウント未対応 ECS service discovery はログ・メトリクスがないため、あまり適さない ALB VPC Lattice ECS service discovery ECS Service Connect クロスアカウ ント 可能 *1 一応可能 *2 - *1: Amazon VPC Peering や AWS Transit Gateway などが必要 *2: Amazon VPC Peering などのネットワーク設定と、Route53 のホストゾーン関連付け設定が必要 なぜクロスアカウントから考えるのか？ 37/51
38. 1. そもそもクロスアカウント通信をなくせないか？ 2. クロスアカウントは ALB か VPC Lattice か？ アカウントが多数なら VPC Lattice が強い。ALB は AWS Transit Gateway 等が必要。 3. アカウント内は [2] に統一するか？ クロスアカウントに関する選択 38/51
39. 1. シンプルな構成を検討する 2. クロスアカウントでの方式を決める 3. 様々な観点で比較 4. 迷ったら ALB 39/51
40. 比較観点は多い 本日触れる観点 費用 可観測性 信頼性 接続相手の幅広さ ＋ 将来性（推測） 本日は割愛する観点 設定の簡単さ デプロイの柔軟性 負荷分散アルゴリズム セキュリティ（暗号化、mTLS など） ハードクォータ ... 40/51
41. ECS service discovery は安価 絶対的に高価な選択肢はない（= ワークロード依存） ALB VPC Lattice ECS service discovery ECS Service Connect 主な課金 対象 時間 + LCU 時間 + 通信量 + リク エスト数 DNS サイドカーのリ ソース 費用 41/51
42. ECS service discovery 以外は横並び 分散トレースは AWS X-Ray と組み合わせることで実現も可能 ALB VPC Lattice ECS service discovery ECS Service Connect ログ・メトリク ス - トレース - - - - 可観測性 42/51
43. https://aws.amazon.com/jp/about-aws/whats-new/2023/11/application-load-balancer-availability-target-weights/ ECS Service Connect が優位 ALB VPC Lattice ECS service discovery ECS Service Connect ヘルスチェッ ク 自動リトライ - - - サーキット ブレーカー - *1 - - ( 外れ値検出) *1: Automatic Target Weights 機能が近い 信頼性 43/51
44. VPC Lattice が非常に強力 そもそもECS をメインにするか迷っているなら、ALB か VPC Lattice が有力 ALB VPC Lattice ECS service discovery ECS Service Connect クロスアカウント 可能 *1 一応可能 *2 - ECS 以外からのア クセス - *1: Amazon VPC Peering や AWS Transit Gateway などが必要 *2: Amazon VPC Peering などのネットワーク設定と、Route53 のホストゾーン関連付け設定が必要 接続相手の幅広さ 44/51
45. ラフな選定パターン A. 「それなりに機能が揃っていて、 　　ECS 間以外でも統一できるものがいい」 B. 「ECS 以外にもAmazon EKS やAWS Lambda 等色々 　　使っていて、かつ多くのVPC/ アカウントを繋げたい」 C. 「シンプルに名前解決だけで十分。 　　信頼性・可観測性は不要or 自前実装する」 D. 「ECS 間を簡単に信頼性・可観測性高く繋げたい。 　　ECS 以外との通信は少ないから別途考える」 → 　ALB → 　VPC Lattice → 　ECS service 　　discovery → 　ECS Serivce 　　Connect 45/51
46. 1. どれほど根幹のサービスか？ どれほど長命か？ 2. アップデートの質・量 例： 2024 年末に VPC Lattice が ECS ネイティブ統合と TCP 対応 3. サービス/ 機能の思想やポジションを理解する 例： ECS service discovery はシンプルさが肝で機能充足済なので、更新が少ないのは妥当 4. 公式Push の強さ 例： 4/11 に VPC Lattice 中心のイベント開催済 (AWS Application Networking Roadshow Japan 2025) 5. 公開ロードマップ( 次項) 将来性の推測材料 46/51
47. https://github.com/orgs/aws/projects/244/views/1 公式の containers-roadmap にて、対応状況を閲覧できる ※全量ではない 将来性の推測材料 > 公開ロードマップ 47/51
48. 1. シンプルな構成を検討する 2. クロスアカウントでの方式を決める 3. 様々な観点で比較 4. 迷ったら ALB 48/51
49. 枯れている： 2016 年に登場し、情報量や機能が多い 汎用的： ECS 以外にも接続可能 AWS Transit Gateway 等を用いれば、VPC 間・アカウント間も接続可能 North-South 通信にも利用可能 将来性： 急にサービス終了する確率は低そう 2024 年にはキャパシティユニット予約対応（通称「暖気」 ） 2009 年登場の Classic Load Balancer は非推奨ながらもまだ利用可能 ※ 将来的にこの選択肢が VPC Lattice や ECS Service Connect に変わる可能性はある どうしても迷ったら ALB を選ぶ 49/51
50. まとめ 50/51
51. 1. モノリスなど、サービス間通信が不要でシンプルな構成から検討する 2. クロスアカウントの部分から決める そもそも単一アカウントにできないか？ Application Load Balancer か Amazon VPC Lattice か？ 3. 様々な観点で比較 将来性を推測するために、情報収集や思想理解がより重要に 4. どうしても迷ったら Application Load Balancer 今なら Amazon ECS のサービス間通信をどう選ぶか 51/51