AWS App Mesh

Envoy プロキシベースのサービスメッシュで、マイクロサービス間の通信を可視化・制御し、トラフィック管理やリトライポリシーを一元的に適用する

概要

AWS App Mesh は、Envoy プロキシをデータプレーンとして利用するフルマネージドサービスメッシュです。ECS、EKS、EC2 上で稼働するマイクロサービス間の通信を透過的にインターセプトし、トラフィックルーティング、リトライ・タイムアウトポリシー、サーキットブレーカー、mTLS による暗号化をアプリケーションコードの変更なしに適用します。X-Ray や CloudWatch との統合により、サービス間通信のレイテンシ・エラー率・リクエスト量をリアルタイムで可視化できます。なお、App Mesh は 2024 年 9 月 24 日に新規利用の受付を終了し、2026 年 9 月 30 日にサポート終了が予定されています。移行先としては Amazon ECS Service Connect が公式に案内されており、以下の仕組みの解説はサービスメッシュ一般の設計理解としても有効です。

メッシュ構成要素とトラフィックルーティング

App Mesh の構成は、メッシュ (論理的な境界)、仮想サービス (サービスの抽象表現)、仮想ノード (実際のワークロード)、仮想ルーター (ルーティングルール) の 4 要素で成り立ちます。仮想ルーターにルートを定義することで、HTTP ヘッダー、パスプレフィックス、メソッドに基づく条件付きルーティングが可能です。カナリアデプロイでは、新バージョンの仮想ノードに 5% のトラフィックを流し、エラー率を監視しながら段階的に比率を上げる重み付きルーティングを設定します。リトライポリシーでは、HTTP 503 や接続エラーに対する最大リトライ回数とバックオフ間隔を仮想ノード単位で定義でき、一時的な障害からの自動復旧を実現します。gRPC プロトコルにもネイティブ対応しており、gRPC ステータスコードに基づくルーティングやヘルスチェックも設定可能です。

mTLS によるゼロトラスト通信とオブザーバビリティ

App Mesh は Envoy プロキシ間の通信を mTLS (相互 TLS) で暗号化し、サービス間のゼロトラスト通信を実現します。証明書の管理には ACM Private CA または Envoy の SDS (Secret Discovery Service) を利用し、証明書のローテーションも自動化されます。オブザーバビリティ面では、Envoy が生成するメトリクス (リクエスト数、レイテンシ分布、エラー率) を CloudWatch に送信し、X-Ray へのトレースデータ送信でサービス間の呼び出しチェーンを可視化します。Envoy のアクセスログを CloudWatch Logs や S3 に出力する設定も可能で、個別リクエストレベルのデバッグに活用できます。Grafana や Prometheus との連携では、Envoy の stats エンドポイントから直接メトリクスをスクレイピングする構成も取れます。

ECS・EKS 環境での導入パターンと運用設計

ECS 環境では、タスク定義に Envoy サイドカーコンテナと proxyConfiguration を追加することで App Mesh に参加させます。App Mesh Controller for ECS を利用すれば、サービスディスカバリ (Cloud Map) との連携が自動化され、新しいタスクの起動時に仮想ノードへの登録が自動的に行われます。EKS 環境では、App Mesh Controller for Kubernetes が CRD (Custom Resource Definition) を提供し、Kubernetes マニフェストで仮想サービスや仮想ノードを宣言的に管理できます。Pod に Envoy サイドカーを自動注入する Mutating Webhook により、既存のワークロードへの導入が容易です。運用上の注意点として、Envoy プロキシのリソース消費 (CPU・メモリ) がサービスごとに追加されるため、タスクや Pod のリソース割り当てを事前に見積もる必要があります。大規模環境では Envoy の設定伝播に数秒のラグが生じるため、デプロイ直後のルーティング不整合に備えたリトライ設計が重要です。

参考資料 (AWS 公式)

本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。

本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。

共有するXB!