AWS App Mesh から Amazon VPC Lattice への移行

この記事は Migrating from AWS App Mesh to Amazon VPC Lattice (記事公開日: 2024 年 10 月 1 日) を翻訳したものです。

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

マイクロサービスアーキテクチャの採用が進むにつれて、モダンな分散アプリケーションの複雑さを管理することが、多くの組織にとっての課題となっています。Amazon VPC Lattice は、re:Invent 2022 で発表されたフルマネージドサービスで、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、AWS Lambda、Amazon Elastic Compute Cloud (Amazon EC2) など、さまざまな AWS サービス間の通信の一貫した接続性、セキュリティ、監視を可能にします。AWS App Mesh は、Kubernetes クラスター内のサービスに高度なトラフィック管理と可観測性の機能を提供します。一方で VPC Lattice は、サイドカープロキシを管理する必要性をなくすことで、アプリケーションネットワーキングをシンプルにします。

本記事では、VPC Lattice が複雑な分散アプリケーションの管理をどのようにシンプルにできるかを探求し、App Mesh から VPC Lattice への移行に関する Amazon EKS のお客様へのガイダンスを提供します。

Amazon ECS で App Mesh を使用しているお客様は「AWS App Mesh から Amazon ECS Service Connect への移行」という記事をお読みいただくことをおすすめします。

App Mesh と VPC Lattice の比較

App Mesh と VPC Lattice はどちらもトラフィック管理とアプリケーション認識型ネットワーキングを提供しますが、基本的な概念とアーキテクチャが異なります。移行を開始する前に、これらの違いを理解することが重要です。

まず、リソースの論理的な境界線を提供するために、VPC Lattice には Service Network という概念があり、これは App Mesh の Service Mesh に相当します。次に、VPC Lattice でアプリケーション内のマイクロサービスを表すには Service を作成します。これは App Mesh の Virtual Service に相当します。 VPC Lattice の Target Group は、App Mesh の Virtual Node と同じく、サービスを Kubernetes Pod グループに紐づけます。最後に、VPC Lattice の Listener と Listener Rule は、App Mesh の Virtual Router と Route と似ています。これらは、Service 内の Target Group へのトラフィックルーティングを定義します。以下の図は、各サービスの異なるコンポーネント間の比較を示しています。

App Mesh リソースの VPC Lattice のリソースへの変換

アーキテクチャ上、App Mesh はトラフィックルーティングのため、Pod ごとにサイドカーコンテナとして実行されるセルフマネージドの Envoy プロキシに依存しています。対照的に、VPC Lattice はマネージドなコントロールプレーンとデータプレーンを提供するため、Pod 内にコンポーネントを追加する必要はありません。可観測性のため、App Mesh はメトリクスを Amazon CloudWatch に転送する Amazon CloudWatch Agent with Prometheus Metrics Collection のインストールを必要とします。一方で VPC Lattice は、CloudWatch でビルトインのメトリクスを提供します。

Amazon EKS 上で App Mesh を使用してアプリケーションを実行する場合、Kubernetes Ingress、AWS Load Balancer Controller、App Mesh Virtual Gateway を使用してクラスター外部にアプリケーションを公開することが一般的です。しかし、AWS アカウントや VPC をまたいでアプリケーションを公開するには、多くの場合 AWS Transit Gateway のような追加のネットワークリソースが必要です。 VPC Lattice は、ロードバランシングと AWS Resource Access Manager (RAM) を組み込むことで、この問題をネイティブに解決します。これにより、異なる AWS アカウントで実行されている他の AWS リソースから Kubernetes の Service にアクセスできるようになります。

さらに、VPC Lattice は Kubernetes リソースを VPC Lattice オブジェクトに紐づける Gateway API を実装しています。加えて、VPC Lattice は認証ポリシーによって AWS Identity and Access Management (IAM) 認証をサポートし、マイクロサービス間の大まかな粒度での認可を実現します。

料金設定については、App Mesh では Envoy プロキシの追加のコンピュートリソースに対してのみ料金が発生します。しかし、VPC Lattice のコストは、プロビジョニングされたサービスの数、各サービスへのトラフィックのデータ処理料金、各サービスが受信する HTTP リクエストの数 (HTTP/HTTPS リスナーのみ) に基づいて決定されます。詳細は、VPC Lattice の料金ページをご覧ください。

移行戦略

App Mesh から VPC Lattice へのアプリケーションの移行時には、インプレース、カナリア、Blue/Green など、複数の戦略から選択できます。適切な戦略は、ゼロダウンタイムの必要性やメンテナンスウィンドウを設定できるかどうかなど、アプリケーションの要件によって異なります。

インプレースでの移行戦略では、App Mesh で実装された既存の Kubernetes Pod を新しい Pod で置き換えます。このアプローチは、各 Pod が Envoy サイドカーコンテナを削除するために再起動されるので、移行中のダウンタイムを許容できるアプリケーションに適しています。

別の方法として Blue/Green デプロイ戦略では、VPC Lattice 用に構成された新しい Namespace にアプリケーションの 2 つ目のコピーをデプロイし、元のアプリケーションは App Mesh で運用を続けます。このアプローチでは、両方の環境を同時に実行しながら、ダウンタイムなしで App Mesh から VPC Lattice にトラフィックを徐々に移行できます。

移行のウォークスルー

このセクションでは、サンプルアプリケーションを App Mesh から Amazon VPC Lattice に移行するための手順の概要を、インプレース移行戦略を用いて説明します。詳細な手順については、本記事の後半で説明します。

このウォークスルーで使うアプリケーションは、Polyglot デモと呼ばれる複数階層のデモアプリケーションです。このアプリケーションは次の 3 つのマイクロサービスで構成されています。

フロントエンド：商品カタログのユーザーインターフェース
Product Catalog バックエンド：カタログに保存されているアイテムのリストを提供する REST API サービス
Catalog Detail バックエンド：バージョン番号やベンダー名など、各アイテムの追加情報を提供する REST API サービス

次の図は Polyglot デモのフロントエンドのユーザーインターフェースを示しています。これには、異なるサービス間のトラフィックフローのアーキテクチャ図が含まれています。フロントエンドサービスは Product Catalog サービスを呼び出します。Product Catalog サービスは次に Catalog Detail サービスを呼び出します。

Product Catalog アプリケーションのアーキテクチャ

移行のステップ

このセクションでは、App Mesh から VPC Lattice にアプリケーションを移行する際の主なステップについて説明します。

ステップ 1：Amazon EKS クラスターとサンプルアプリケーションのデプロイ

はじめに、eksctl を使用して今回のデモの基盤となる EKS クラスターを作成します。クラスターが作成されたら、App Mesh とVPC Lattice の機能を示すために、Polyglot デモアプリケーションをデプロイします。最後に、すべてが必要に応じて機能していることを確認するために、Polyglot デモアプリケーションのテストを実行します。

ステップ 2：App Mesh を使用してサンプルアプリケーションを設定する

AWS App Mesh Controller と関連する Kubernetes カスタムリソース定義 (CRD) をインストールします。これらのコンポーネントにより、Kubernetes API を通じて App Mesh リソースを作成できます。次に、App Mesh を使用して Polyglot デモアプリケーションを実装し、Virtual Service と Virtual Node を作成します。現実のシナリオであることを強調するために、Product Catalog サービスの 2 つのバージョンをデプロイし、VPC Lattice への移行中にアクティブな Canary ロールアウトをデモンストレーションします。最後に、アプリケーションをテストして、構成が正しいことを再確認します。これで、この環境は移行を開始する準備ができました。

ステップ 3：VPC Lattice リソースを作成する

AWS Gateway API Controllerと関連する Kubernetes CRDをインストールします。App Mesh Controller と同様に、Kubernetes API を通じて VPC Latticeリソースを作成できるようになります。続いて、移行に必要な中心となる VPC Lattice コンポーネントを作成します。これには、VPC Lattice Service Network にマッピングするクラスター内のVPC Lattice GatewayClass と Gateway、サンプルアプリケーションのトラフィックルールを作成するためのTargetGroupPolicy と HTTPRoute が含まれます。

ステップ 4：サンプルアプリケーションを VPC Lattice に移行する

インプレースでの移行の場合、Envoy プロキシなどの既存の App Mesh コンポーネントを Pod から削除し、アプリケーションを新しい VPC Lattice エンドポイントで構成する必要があります。そのためにまず、Kubernetes Namespace にアノテーションを付与して、App Mesh Controller が Pod を操作できないようにします。次に、VPC Lattice エンドポイントを使うように、Polyglot デモアプリケーションを再デプロイします。最後に、Polyglot デモアプリケーションをテストして、VPC Lattice を通じて正しく機能することを確認します。

ステップ5：アプリケーションの公開とカナリアデプロイメントの実装

VPC Lattice では、アプリケーションへのトラフィックを許可するために Elastic Load Balancing (ELB) を使用する必要があります。このステップでは、App Mesh Virtual Gatewayを削除し、AWS Load Balancer Controller で新しい Network Load Balancer を作成します。最後に、Product Catalog の 2 番目のバージョンを再デプロイし、VPC Lattice HTTPRoute を使用して、重み付けルーティングにより両方の Pod 間でトラフィックを分散します。

VPC Lattice リソースの確認

VPC Lattice から App Mesh への移行した後に、VPC Lattice に関連するさまざまなリソースがアカウントでプロビジョニングされ、VPC Lattice コンソールで確認できます。

1. リソースの論理的な境界として VPC Lattice Service Network を作成しました。

AWS マネジメントコンソールで、Product Catalog Service Network を示すスクリーンショット

2. Kubernetes HTTPRoute を使って、アプリケーションの各階層に 1 つずつ、3 つの VPC Lattice Service を作成しました。

AWS コンソールでの、VPC Lattice Service のスクリーンショット

3. 3 つの VPC Lattice Target Group を作成し、各 VPC Lattice Service に 1 つずつアタッチしました。各Target Group のルーティングルールとヘルスチェックは、Kubernetes の TargetGroupPolicy リソースで設定しました。

AWS コンソールの VPC Lattice Target Group のスクリーンショット

4. 最後に、VPC Lattice を使って、サービスの HTTPRoute を更新することで、Product Detail マイクロサービスの 2 つのバージョン間でトラフィックを分散しました。以下の YAML スニペットのバックエンドルールは、アプリケーションの重み付けルーティングを示しています。

rules:
    - backendRefs:
        - name: proddetail
          namespace: prodcatalog-ns-lattice
          kind: Service
          port: 3000
          weight: 50
        - name: proddetail2
          namespace: prodcatalog-ns-lattice
          kind: Service
          port: 3000
          weight: 50

以下の図は、App Mesh から VPC Lattice に移行した後のアプリケーションのアーキテクチャを示しています。

VPC Lattice で実装された Polygot デモアプリケーション

ハンズオンの手順

このサンプルの移行を再現するには、この GitHub リポジトリのステップバイステップの説明をご覧ください。

まとめ

本記事では、分散アプリケーションのアプリケーションネットワーキングサービスである VPC Lattice を探求しました。App Mesh の機能・リソースと比較し、既存の App Mesh デプロイの移行戦略について説明しました。VPC Lattice は App Mesh と比較して、マルチアカウントネットワーキング、設定の簡素化、観測性の向上、その他の AWS サービスとのシームレスな統合といった、いくつかの利点を提供します。

詳細については、次の VPC Lattice のリソースとブログを参照してください。

Amazon VPC Lattice と Amazon EKS における AWS IAM 認証の実装

Amazon VPC Lattice を使用した、アプリケーションのためのセキュアなマルチアカウント・マルチ VPC 接続の構築

VPC Lattice と Pod Identity IAM セッションタグを使用した EKS クラスター間セキュア通信

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