AWS App Mesh から Amazon ECS Service Connect への移行

この記事は Migrating from AWS App Mesh to Amazon ECS Service Connect (記事公開日: 2024 年 9 月 24 日) を翻訳したものです。

慎重に検討した結果、2026 年 9 月 30 日をもって AWS App Mesh のサポートを終了することを決定しました。この日まで、既存の AWS App Mesh のお客様は、AWS CLI や AWS CloudFormation による新しいリソースの作成や新しいアカウントのオンボーディングなど、通常通りにサービスを利用できます。また、AWS はこの期間中も、AWS App Mesh にセキュリティと可用性に関する重要な更新を引き続き提供します。新規のお客様は、2024 年 9 月 24 日以降、AWS App Mesh にオンボーディングできなくなります。

re:Invent 2022 で、AWS は Amazon ECS Service Connect をリリースしました。これは、Amazon Elastic Container Service (Amazon ECS) 内のマイクロサービスを接続する新しい方法です。本投稿では、Service Connect の詳細と、AWS App Mesh から Service Connect への移行戦略について説明します。Service Connect は、外れ値検出やリトライによって、コンテナ化されたマイクロサービスの信頼性を向上させます。また、アプリケーションレベルのネットワーキングメトリクスを Amazon CloudWatch に送信することで、オブザーバビリティも向上させます。Service Connect では、マネージドなネットワーキングデータプレーンを利用することで、サイドカープロキシの管理に伴う差別化につながらない重労働が不要になります。

App Mesh と Service Connect の比較

サービスメッシュは抽象化レイヤーを通じて、ルーティングルールを実装し、セキュリティレイヤーを追加し、オブザーバビリティを提供します。App Mesh から Service Connect への移行をはじめる前に、Service Connect の抽象化レイヤーを理解し、App Mesh の抽象化レイヤーと比較することが重要です。このセクションでは、Amazon ECS にデプロイされた多層アプリケーションを使用して、これらの抽象化を説明します。

次の図 1 は、サービスメッシュを実装する前のサンプルアプリケーションを示しています。フロントエンドサービスと、ユーザー、ストックという 2 つのバックエンドサービス API で構成されています。3 つのサービスは、長時間稼働するサービスとして Amazon ECS にデプロイされており、1 つ以上のタスクが実行されています。Application Load Balancer や Network Load Balancer といったロードバランサーは、耐障害性を提供し、アーキテクチャ内の各サービスのタスク全体にトラフィックを分散します。

図 1: サービス間のルーティングをロードバランサーで提供するサンプルアプリケーション

このアーキテクチャで App Mesh を利用する場合、抽象化によってルーティングルールとセキュリティ境界を実装します。各マイクロサービスは、App Mesh の Virtual Service にカプセル化されます。Virtual Service には、App Mesh の Virtual Node と呼ばれる複数のバージョンのアプリケーションがあり、App Mesh の Virtual Router が Virtual Node 間のルーティングルールを実装している場合があります。

次の図 2 は、App Mesh を利用するサンプルアプリケーションを示しています。3 つの Amazon ECS サービスの各タスクに対して、セルフマネージドの Envoy プロキシをサイドカーコンテナとしてデプロイします。このプロキシは、App Mesh のルーティング、信頼性、オブザーバビリティといった機能を実装しています。また、サービス間のクライアント側のルーティングも提供されるため、必要なロードバランサーの数を減らすことができます。AWS Cloud Map の名前空間はサービスディスカバリに利用され、各リソースは App Mesh リソースの論理的な境界である App Mesh の Mesh にアタッチされます。

図 2: App Mesh を利用するサンプルアプリケーション

Service Connect はこれらの抽象化を効率化し、サイドカーコンテナの Envoy プロキシは Service Connect プロキシとして AWS がフルマネージドに管理します。Service Connect の抽象化には「クライアント」と「サーバー」サービスが含まれます。「サーバー」サービスは、別のマイクロサービスと通信する場合、「クライアント」としても機能します。この場合、「クライアント / サーバー」サービスと呼ばれます。AWS Cloud Map の名前空間は、サービスを検出し、リソースの論理的な境界を定義します。

次の図 3 は、Service Connect を利用するサンプルアプリケーションのアーキテクチャを示しています。フロントエンドアプリケーションは「クライアント」サービスになり、AWS Cloud Map 名前空間の一部になりますが、エンドポイントは公開されません。ユーザー API とストック API は、どちらも名前空間にアタッチされた「サーバー」サービスであり、「クライアント」が接続するためのエンドポイントを公開しています。

図 3: Service Connect を利用するサンプルアプリケーション

App Mesh から Service Connect への移行

Amazon ECS サービスを、App Mesh の Mesh と Service Connect の名前空間の両方に同時に含めることはできません。したがって、移行を実行するには、Amazon ECS サービスを再作成する必要があります。このプロセス中のダウンタイムを回避するために、Blue/Green 移行戦略を実装できます。このアプローチでは、各 Amazon ECS サービスのコピーを作成し、2 つの環境間でトラフィックを徐々に移行します。Blue/Green 移行戦略でトラフィックをきめ細かく移行するには、Amazon Route 53 加重ルーティング、Amazon CloudFront の継続的デプロイ、Application Load Balancer の加重ターゲットグループなど、いくつかの方法があります。

次の図 4 は、App Mesh から Service Connect へのアプリケーションの移行を示しています。エンドユーザーは Amazon Route 53 加重ルーティングを通じて、App Mesh 環境から Service Connect 環境へ徐々に移行されます。Service Connect は、アプリケーションレベルのネットワーキングメトリクスを無料の CloudWatch メトリクスとして提供します。この移行プロセスでは、Service Connect 環境に送信されるトラフィックの量を、加重レコードの重みを調整することで徐々に増加できます。Service Connect が提供するメトリクスを利用して、管理者は負荷の増加をモニタリングして設定の誤りを検出できます。

図 4: App Mesh を利用するアプリケーションから Service Connect を利用するアプリケーションへのトラフィック移行

各サービスメッシュの環境には個別のサービスディスカバリ実装があるため、サービスメッシュ環境をまたぐネットワーク通信はありません。エンドユーザーからの接続は、それぞれのサービスメッシュ内に残ります。たとえば、トラフィックが App Mesh を利用するフロントエンドに送信された場合、アクセスされるバックエンド API は App Mesh の Mesh に含まれるバックエンド API になります。App Mesh を利用するフロントエンドは、Service Connect 環境のバックエンドサービスとは通信できません。

機能の比較

Service Connect を利用すると、プロキシ管理や複数の抽象化レイヤーが不要になり、サービスメッシュの管理に伴うオーバーヘッドがなくなります。AWS は Service Connect に多くの投資を行っており、強力なロードマップを策定していますが、現時点では、すべての Envoy プロキシ機能が Service Connect で利用できるわけではありません。このセクションでは、Service Connect と App Mesh の機能の違いについて説明します。

ネットワークの信頼性の向上: App Mesh と Service Connect はどちらも、Envoy の外れ値検出やリトライを利用して、サービス間の信頼性を高めています。App Mesh ではこれらの設定を変更できますが、Service Connect では独自のデフォルトがあります。タイムアウトに関しては、Service Connect でも設定の変更が可能です。

高度なトラフィックルーティング: App Mesh では、仮想的なルーティングメカニズムを利用して、Virtual Router により複数の Virtual Node 間、すなわち複数のマイクロサービスのバージョン間でトラフィックをきめ細かくルーティングできます。Service Connect では、高度なトラフィックルーティングは利用できません。

オブザーバビリティ: App Mesh では、トラフィックメトリクスを取得してモニタリングサービスに送信し、オブザーバビリティダッシュボードを構築する必要があります。Service Connect では、アプリケーションレベルのネットワーキングメトリクスを無料の CloudWatch メトリクスとして提供します。これらのメトリクスは、CloudWatch コンソールと Amazon ECS コンソールに表示されます。

セキュリティ: App Mesh と Service Connect はどちらも、サービス間の通信を暗号化するための TLS をサポートしています。App Mesh では、AWS プライベート CA (AWS PCA) の GENERAL_PURPOSE モードの証明書を活用できます。一方で Service Connect では、簡単な設定で低コストな AWS PCA の SHORT_LIVED_CERTIFICATE モードの証明書を活用できます。また、App Mesh では相互 TLS 認証を実装できますが、Service Connect では相互 TLS 認証を利用することはできません。

リソースの共有: AWS Resource Access Manager (AWS RAM) では、App Mesh の Mesh を複数の AWS アカウントで共有できます。これにより、Mesh という同じ論理的な境界に属しながら、アプリケーションを複数のアカウントに分散できます。Service Connect では、AWS Cloud Map 名前空間を複数の AWS アカウントで共有することはできません。そのため、現時点では、サービスメッシュに含まれる全てのアプリケーションを、同じ AWS アカウントにデプロイする必要があります。

まとめ

本投稿では、App Mesh から Amazon ECS Service Connect への移行について説明し、2 つのサービスの主な違いを説明しました。Service Connect が提供する効率的な抽象化とマネージドなネットワーキングデータプレーン、およびトラフィックルーティング、オブザーバビリティ、セキュリティ、リソース共有に関する考慮事項について説明しました。

App Mesh を利用しており、Service Connect への移行を検討している場合は、本投稿で紹介している Blue/Green 移行戦略をご検討ください。Service Connect の詳細については、Amazon ECS ドキュメントと、Amazon ECS Immersion Day ワークショップをご確認ください。このワークショップでは、サンプルの小売アプリケーションをデプロイして、サービスを実際に体験できます。

App Mesh を利用する Amazon Elastic Kubernetes Service (Amazon EKS) のお客様向けの移行ガイダンスについては、今後の AWS ブログをお待ちください。

翻訳はソリューションアーキテクトの落水が担当しました。原文はこちらです。