NRIネットコム Blog

NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

トップ > Technology > 改めてECSサービス間通信を整理する

改めてECSサービス間通信を整理する

Technology Technology - AWS - ECS 基盤デザインウィーク

本記事は  基盤デザインウィーク  7日目の記事です。
🌈  6日目  ▶▶ 本記事 ▶▶  8日目  💻

こんにちは、梅原です。

皆さんはコンテナオーケストレーションサービスであるAmazon ECS使ってますでしょうか。今回はECSのサービス間通信の方法4つについてお話します。

ECSサービス間通信についてとその4つの方法

昨今、マイクロサービスという言葉をよく聞きますが、ECSでマイクロサービスを実現するためには、ECSサービスを小さな機能ごとに分割していく必要があります。
その機能同士が通信するために、ECSサービス間の通信をどのように実現するかを考える必要があります。 また、ECSサービス内のタスクは動的に変化するので、通信先タスクの複数IPアドレスを管理する仕組みが必要です。

今回はECSサービス間通信を実現する以下の4つの方法について説明します。

  • Elastic Load Balancer
  • ECS Service Discovery
  • AWS App Mesh
  • ECS Service Connect

本ブログ中では通信元となるECSサービスをサービスA、通信先となるサービスをサービスBとし、サービスAからサービスBに通信する時の流れを見ていきます。

1. Elastic Load Balancer

1つ目はELBを使う方法です。これは比較的馴染み深いのではないでしょうか。
サービスBをELBと紐づけておくことで、サービスBのタスクはELBのターゲットグループに登録されます。 サービスAからはELBのエンドポイントに対してリクエストすることで、サービスBへの通信を実施できます。

通信の流れとしては、サービスAがELBのエンドポイントに対してリクエストを送信。 受け取ったリクエストをターゲットグループ内のタスクに対してルーティングします。
そうすることで、サービスAはサービスBのIPを直接知らなくても、ELBを経由してリクエストを送信できます。 またELBは受けたリクエストを中継してくれるので、リクエスト数やHTTPステータスなどのメトリクスも取得可能です。

Elastic Load Balancerまとめ

メリット

  • パスベースルーティングや固定レスポンスなどELBの機能を使用可能
  • リクエストのメトリクスを取得可能
  • ECSサービスデプロイ方法にB/Gデプロイが選択可能

デメリット

  • 追加のインフラが必要（ELBの追加コストやVPC内のIPアドレス消費）
  • ELBを経由するので、タスクと直接通信に比べてレイテンシーが増加

2. ECS Service Discovery

2つ目はECS Service Discovery（サービス検出）です。
Service DiscoveryはAWS Cloud Mapと統合しています。Cloud MapはサービスとIPアドレスをマッピングして管理してくれるサービスです。
Service Discoveryでは、Cloud Map経由でRoute53のプライベートホストゾーンにタスクのIPが登録されます。Route53に名前解決した結果を元にタスクと直接通信します。

サービスBのタスクのIPアドレスがRoute53のプライベートホストゾーンのレコードに追加されます。 サービスAは、設定しておいたドメイン名で名前解決をして得たIPアドレスを元に、サービスBにリクエストを直接送信します。

サービスBのIPアドレスが変更されてもRoute53のホストゾーンに登録/削除されるので、サービスAは名前解決するドメインのみを知っておくことで通信できます。 また、Route53のホストゾーンはプライベートなので、同一VPCに存在しているリソースも名前解決が可能です。

コンソールでは以下のような設定をすることで、Service Discoveryを使用することができます。

名前解決するためのドメインは、｢{設定した名前}.{名前空間名}｣で名前解決可能です。上の例だと｢nginx.k-umehara-service｣です。 Route53には以下のようにレコードが追加されていきます。

レコードの種類は、AレコードとAAAAレコード、SRVレコードから選択でき、複数値回答でレコード追加されます。

注意点としては、リクエスト時に名前解決が必要なので、リクエスト元となるサービスのDNSキャッシュを意識しておく必要があります。

ECS Service Discoveryまとめ

メリット

  • 名前解決しているのみでシンプル
  • 追加のインフラは不要
  • 同一VPC内のリソースからも名前解決が可能

デメリット

  • 名前解決するのみなので、通信のメトリクスは取得不可

3. AWS App Mesh

3つ目はAWS App Meshを使用したサービスメッシュ方式です。

サービスメッシュとは、通信をアプリケーションではなく、インフラ（アプリケーションのプロキシ）側で制御してくれる技術です。 サービスメッシュを使うことで、アプリケーションの信頼性と可観測性が向上します。 ELBやService Discoveryでの通信では、リトライ処理やタイムアウト、通信のメトリクス取得といった処理はアプリ側で実装する必要があります。サービスメッシュは通信制御を行ってくれるので、前述の処理をアプリで実装する必要がありません。

またApp Meshは、アプリケーションのプロキシであるenvoyを管理してくれるコントロールプレーンです。ECSで実装する際には、サイドカーコンテナとしてenvoyコンテナをデプロイします。envoyコンテナはデータプレーンとしてApp Meshが管理してくれます。
envoyを使うことで負荷分散や重み付けルーティングといった柔軟な通信制御をすることができます。

サービスBへ通信する場合は、Cloud MapへサービスBのIPアドレスを問い合わせし、それを元にenvoyコンテナが通信します。
まずはApp Meshにメッシュを作成をしておく必要があります。

envoyのアイコンはこちらから取得。

envoyコンテナがデプロイされると、App Meshの設定がenvoyコンテナに反映されます。 またタスクのIPアドレスはCloud Mapへ登録されます。
実際の通信は以下です。

サービスAからリクエスト時は、envoyコンテナがCloud MapにサービスBのIPアドレス情報を問い合わせます。その結果のIPアドレスに対してenvoy自身がリクエストします。またサービスB側でもenvoyがリクエストを受け取り、アプリコンテナへ渡されます。
サービスBのIPアドレスが変更されても、タスクのIPアドレスはCloud Mapで管理しているため、アプリ側はタスクのIPアドレスを知らなくてもCloud Mapへ問い合わせすることで通信できます。 またenvoyコンテナが通信自体をしているので、メトリクスやログもCloudWatchに出力することができます。

AWS App Meshまとめ

メリット

  • App Meshならではの柔軟な通信制御
  • 信頼性と可観測性の向上（アプリ実装の負担減）

デメリット

  • トラフィック制御が柔軟なために設定が複雑
  • ECSに加えてApp Meshの管理が必要

4. ECS Service Connect

最後はService Connectです。2022年のre:Inventで発表された機能です。
Service Connectを簡単にまとめると、上記3つの方法のいいとこ取りです。 ELBのようにメトリクスを取得でき、Service Discoveryのようにシンプルで、App Meshのように信頼性がある方法となっています。

Service Connectは、サイドカーコンテナとしてService Connect Agentコンテナがデプロイされます。Service Connect Agentにはenvoyも含まれているので、通信自体はService Connect Agentコンテナ経由です。 envoyコンテナはApp Mesh管理ではない代わりに、デフォルトの通信制御の設定が入っています。

サービスAからの通信の流れは、Service Connect AgentコンテナがCloud MapにサービスBのIPアドレス情報を問い合わせし、その結果を元に通信します。
サービスBのIPアドレスが変更されても、タスクのIPアドレスはCloud Mapで管理しているため、アプリ側はタスクのIPアドレスを知らなくてもCloud Mapへ問い合わせすることで通信できます。

Service Connectはコンソールで以下のような設定をすることで使用することができます。

リクエストを受ける側はクライアントとサーバー を選択し、リクエストする側はクライアント側のみを選択します。 DNSに設定した｢nginx-web｣でサービスBに通信することができます。

Service Connect Agentコンテナのデフォルト通信制御としては、負荷分散、リトライ処理、タイムアウト、外れ値検知があります。 また2024/01/22に発表されたアップデートで、変更不可だったデフォルトタイムアウト値の15秒が変更可能になったり、mTLS通信が可能になりました。

docs.aws.amazon.com

また通信はService Connect Agentコンテナが実施するので、以下ドキュメント記載のメトリクスやログもECSサービスのコンソールやCloudWachから見ることができます。

docs.aws.amazon.com

ECS Service Connectまとめ

メリット

  • Service Connect Agentを使うことでシンプルな実装が可能
  • 信頼性と可観測性の向上（アプリ実装の負担減）
  • 他クラスター他VPCからの接続も可能

デメリット

  • ECS間同士のみの通信
  • デプロイはローリングアップデートのみ
  • サイドカーコンテナがデプロイされるのでその分のリソースが必要

4つの方法比較

最後に4つの方法の比較を行います。

方式 通信の可観測性 通信の信頼性 通信の柔軟性 設定の容易さ 追加コンピュートリソース 追加インフラ 特記事項
ELB ◯ ✕ ◯ △ 不要 要 ELBの機能を使用可能。BGデプロイ選択可能
Service Discovery ✕ ✕ ✕ ◯ 不要 不要 同一VPCから接続可能
App Mesh ◯ ◯ ◯ ✕ 要 不要 App Meshの管理が必要
Service Connect ◯ ◯ △ ◯ 要 不要 他クラスターや他VPCのECSサービスから接続可能

最後に

いかがでしたでしょうか。あまりECSサービス間通信についてまとまった記事がなかったので書いてみました。
個人的な感想としては、Service DiscoveryやService Connectの設定はコンソールで完結できるシンプルさがあり、思ってた何倍も簡単に試すことができました。

また、どの方式を選択するかですが、ECSのベストプラクティスガイドによると、信頼性や可観測性、設定のシンプルさからService Connectが推奨されています。ですが、それぞれの方法でメリットデメリットがあるので、プロジェクトごとの条件を鑑みて、非機能要件にあった方法を検討する必要があります。

執筆者: 梅原 航 インフラエンジニア。 主にAWSを使ってます。