AWS App Mesh で構築するサービスメッシュ - マイクロサービス間通信の制御と可観測性
Envoy サイドカーによるカナリアデプロイ、リトライポリシー、mTLS 暗号化を宣言的に設定し、X-Ray 統合でサービス間の依存関係を可視化する手法を紹介します。
App Mesh の概要とサービス終了について
App Mesh はマイクロサービス間の通信を制御・監視するサービスメッシュです。各サービスに Envoy プロキシをサイドカーとして配置し、サービス間のトラフィックをプロキシ経由でルーティングします。アプリケーションコードを変更せずに、トラフィックの重み付け、リトライ、タイムアウト、サーキットブレーカーを設定できます。ただし、AWS は 2024 年 9 月に App Mesh の新規顧客受付停止を発表し、既存利用者にはサービス終了に向けた移行を推奨しています。新規プロジェクトでは App Mesh を採用せず、ECS Service Connect または Amazon VPC Lattice を選択してください。既存利用者はサービス終了日までに移行計画を策定する必要があります。
トラフィック制御と可観測性
仮想ルーターでトラフィックの重み付けを設定し、カナリアデプロイで新バージョンに 10% のトラフィックを流すといった制御が可能です。重み付けを段階的に変更 (10% → 25% → 50% → 100%) することで、安全にトラフィックを移行できます。リトライポリシーでは HTTP 503 エラー時に最大 3 回リトライし、指数バックオフで待機する設定を宣言的に定義します。サーキットブレーカーは外れ値検出で実装され、エラー率が閾値を超えたエンドポイントを一時的にルーティング対象から除外します。X-Ray との統合で Envoy プロキシが自動的にトレースデータを送信し、サービス間の呼び出しチェーン、レイテンシ、エラー率を可視化できます。CloudWatch メトリクスでリクエスト数、レイテンシ、エラー率をサービスごとに監視できます。
mTLS とアクセス制御
App Mesh は Envoy プロキシ間の通信を mTLS で暗号化できます。ACM Private CA で発行した証明書を仮想ノードに設定すると、プロキシ間のハンドシェイクで相互認証が行われ、なりすましを防止します。SDS (Secret Discovery Service) により証明書のローテーションも自動化されます。アクセス制御では、仮想ノードのバックエンドとして許可するサービスを明示的に定義し、意図しないサービス間通信を遮断します。Envoy のアクセスログを CloudWatch Logs に送信し、どのサービスがどのエンドポイントにアクセスしたかを監査できます。 App Mesh のネットワーク設計を深く理解するには、専門書籍 (Amazon)が役立ちます。
App Mesh の料金体系と最適化
App Mesh 自体に追加料金は発生しません。コストは Envoy プロキシが消費するコンピューティングリソース (CPU・メモリ) に依存します。ECS タスクや EKS Pod のサイドカーとして動作するため、タスク定義でプロキシに割り当てるリソースを適切にサイジングすることが重要です。プロキシ 1 台あたり 256 MB のメモリと 0.25 vCPU が目安ですが、トラフィック量が多いサービスでは増量が必要です。X-Ray トレーシングを有効にする場合はトレースデータの保存料金が発生するため、サンプリングレートを調整してコストと可観測性のバランスを取ります。
移行先の選択 - ECS Service Connect と VPC Lattice
App Mesh からの移行先として AWS が推奨するのは ECS Service Connect と Amazon VPC Lattice の 2 つです。ECS Service Connect は ECS 内のサービス間通信に特化し、App Mesh と同様に Envoy ベースですがコントロールプレーンの設定が大幅に簡素化されています。仮想ノードや仮想ルーターの定義が不要で、ECS サービス定義に serviceConnectConfiguration を追加するだけでサービスディスカバリ、負荷分散、リトライが有効になります。一方 VPC Lattice は VPC 境界を越えたサービス間通信を提供し、ECS、EKS、Lambda、EC2 といった異なるコンピュートタイプを横断してルーティングできます。Envoy のようなサイドカープロキシが不要で、VPC Lattice サービスネットワークに参加するだけで相互接続が確立されるため、運用負荷が大幅に低減します。選択の基準として、ECS 内に閉じた通信なら Service Connect、マルチ VPC やマルチアカウントで異種コンピュートを跨ぐなら VPC Lattice が適しています。
移行時の設計判断と注意点
App Mesh から移行する際の主な設計判断は、既存のカナリアデプロイ (トラフィック重み付け) をどう実現するかです。ECS Service Connect ではサービス間の重み付けルーティングを直接サポートしていないため、CodeDeploy の Blue/Green デプロイ (ECS ネイティブ) で代替します。VPC Lattice は weighted target groups でトラフィック分割が可能であり、App Mesh の仮想ルーターに近い制御が実現できます。mTLS については、ECS Service Connect は TLS を自動的に有効化しますが相互認証 (mTLS) のカスタム CA 指定には制約があります。VPC Lattice は IAM 認証ポリシーによるサービス間の認可をネイティブに提供し、mTLS とは異なるアプローチでゼロトラスト的な通信制御を実現します。移行は段階的に行うことが推奨されます。まず新規サービスを移行先で構築し、既存サービスと App Mesh サービスの間で通信互換性を維持しながら、順次切り替えていく戦略が安全です。全サービスの一斉移行はリスクが高いため避けてください。
まとめ
App Mesh はマイクロサービス間の通信を Envoy プロキシで制御・監視するサービスメッシュです。トラフィックの重み付けによるカナリアデプロイ、リトライポリシー、サーキットブレーカーを宣言的に設定し、mTLS で通信を暗号化します。ただし AWS は新規顧客受付を停止しサービス終了を予定しているため、新規プロジェクトでは ECS Service Connect (ECS 内通信) または Amazon VPC Lattice (クロス VPC/クロスアカウント通信) を選択し、既存利用者は早期に移行計画を策定してください。