AWS App Mesh

AWS App Mesh は、マイクロサービス間の通信を、アプリケーションのコードに手を入れずに制御・可視化できるようにするマネージドなサービスメッシュです。各サービスのそばに Envoy プロキシをサイドカーとして配置し、サービス同士の通信をすべてこのプロキシ経由にすることで、ルーティングやリトライ、暗号化、メトリクス収集といった横断的な関心事をアプリの外側で一元的に扱えるようにします。

解決する課題

マイクロサービスが増えると、サービス間の通信そのものに関わる共通の悩みが各サービスに重複して現れます。従来はこれらを各アプリのコードやライブラリで個別に作り込むしかなく、次のような課題がありました。

• リトライ、タイムアウト、サーキットブレーカといった通信の堅牢化を、言語やフレームワークごとにばらばらに実装してしまう。
• カナリアリリースや重み付けでの段階的な切り替えをやりたくても、アプリ側にルーティングのロジックを抱え込む必要がある。
• どのサービスがどのサービスをどれだけ呼び、どこで遅延やエラーが出ているかという通信の可視化が、サービスごとに分断されてしまう。
• サービス間の転送中の暗号化や相互認証を、アプリの実装に依存して個別に担保しなければならない。

App Mesh は、これらの関心事を Envoy プロキシというデータプレーンに寄せ、メッシュという統一された設定面から制御することで解決します。アプリは相手の論理名に対して普通に通信するだけでよく、ルーティングや観測、暗号化はプロキシとメッシュ設定が担います。

主要概念と用語

• メッシュ: サービス間通信を束ねる論理的な境界。この中に配置したサービス群が、同じメッシュの設定とポリシーのもとで相互に通信する。
• 仮想サービス: 利用側から見た呼び出し先の論理名にあたる抽象。実体は仮想ノードか仮想ルーターのどちらかに紐づけられ、呼び出し側は実体を意識せずこの名前を使う。
• 仮想ノード: 実際のサービスの一群を指す論理ポインタ。受け付けるリスナーや、自分が呼び出す先（バックエンド）、ヘルスチェック、サービスディスカバリの設定を持つ。
• 仮想ルーター: 仮想サービスに来たトラフィックを、配下のルートに従って複数の仮想ノードへ振り分ける役割。重み付けやパスベースの振り分けの起点になる。
• ルート: 仮想ルーターの中で、パスやヘッダ、メソッドといった条件と、宛先となる仮想ノードおよびその重みを定義する。これでカナリアや段階的な切り替えを表現する。
• 仮想ゲートウェイ: メッシュの外から内へ入るトラフィックの入口。専用の Envoy として動き、外部リクエストをメッシュ内の仮想サービスへ取り次ぐ。
• Envoy プロキシ: 各サービスのサイドカーとして動くデータプレーンの実体。App Mesh の設定を受け取り、実際のトラフィック制御・暗号化・メトリクス収集を行う。

仕様・制限・クォータ

設計時に把握しておきたい性質は次のとおりです。具体的な上限値はリージョンや時期で変わりうるため、定性的に理解し、正確な数値は公式ドキュメントとサービスクォータの画面で確認してください。

• データプレーンは Envoy プロキシであり、AWS が提供する App Mesh 対応の Envoy イメージをサイドカーとして各タスクやポッドに同梱して動かす。
• 主に HTTP、HTTP/2、gRPC、および汎用の TCP を扱える。HTTP 系ではパスやヘッダによる細かなルーティングができ、TCP では経路の制御が中心になる。
• 対応する実行環境は Amazon ECS、AWS Fargate、Amazon EKS、EC2 上の Kubernetes、EC2 上のサービスなど幅広い。コンテナと仮想サーバーを同じメッシュに収められる。
• サービスディスカバリには AWS Cloud Map か DNS を利用でき、仮想ノードはこれらを通じて実体のエンドポイントを解決する。
• 1 つのメッシュに含められる仮想サービス・仮想ノード・仮想ルーター・ルートの数や、ルートあたりの宛先数などにはアカウント単位のクォータがある。大規模なメッシュでは事前に見積もる。
• メッシュは単一アカウント内に作るのが基本だが、共有を使えば複数アカウントのリソースを 1 つのメッシュに参加させることもできる。

内部の仕組み

App Mesh は、設定を司るコントロールプレーンと、実際に通信を運ぶデータプレーンに分かれています。

データプレーンの実体は、各サービスのそばに同梱される Envoy プロキシです。アプリのコンテナやプロセスから出入りするトラフィックは、すべてこのサイドカー Envoy を経由するように構成されます。Envoy は起動時に App Mesh のエンドポイントへ接続し、自分がどの仮想ノードに対応するか、どこへ何の条件で振り分けるか、どのバックエンドを呼ぶかといった設定を受け取ります。

コントロールプレーンは App Mesh のマネージドな部分で、利用者がメッシュ・仮想サービス・仮想ノード・仮想ルーター・ルートとして宣言した構成を、各 Envoy が理解できる設定へ変換し、継続的に配信します。利用者がルートの重みを変えると、その変更が対応する Envoy へ反映され、トラフィックの振り分けが切り替わります。

この分業により、アプリは相手の仮想サービス名へ通常どおり通信するだけで、実際の経路選択・リトライ・暗号化・メトリクス収集はサイドカーが担います。サービスディスカバリは仮想ノードに設定した Cloud Map や DNS を通じて解決され、実体が入れ替わっても論理名を入口とする一貫した通信が保たれます。アプリのコードを変えずに通信の振る舞いを外から制御できる点が、サービスメッシュの本質です。

設計パターン / ベストプラクティス

• 段階的リリースに使う: 仮想ルーターのルートで宛先仮想ノードへの重みを少しずつ移し、新バージョンへカナリア的に切り替える。アプリ側にデプロイのロジックを持たせずに、トラフィック移行を設定で表現する。
• 通信の堅牢化をメッシュに寄せる: リトライやタイムアウトをルートや仮想ノードの設定として持たせ、各言語での個別実装をやめる。横断的な方針をメッシュ側で統一できる。
• 入口は仮想ゲートウェイに集約する: メッシュ外からの流入を仮想ゲートウェイで受け、内部の仮想サービスへ取り次ぐ。外部公開の口を一点に絞り、ルーティングと観測をそろえる。
• サービスディスカバリと組み合わせる: 仮想ノードのディスカバリに Cloud Map を使い、動的に増減する実体に論理名で追従する。コンテナのスケールに通信制御を合わせやすくする。
• Envoy のリソースとバージョンを管理する: サイドカーの CPU やメモリを適切に確保し、AWS が提供する Envoy イメージのバージョンを計画的に更新する。データプレーンの健全性がメッシュ全体の前提になる。

運用・監視

• テレメトリの収集: Envoy が出すメトリクスやアクセスログ、分散トレースを CloudWatch や X-Ray、あるいは外部の監視基盤へ送り、サービス間の遅延やエラー率を可視化する。
• データプレーンの健全性: サイドカー Envoy が正しく起動し設定を受け取れているか、リソース不足で落ちていないかを継続的に確認する。アプリは正常でも Envoy が不調だと通信全体に影響する。
• 設定変更の追跡: メッシュや仮想ノード、ルートへの変更は CloudTrail に記録されるため、誰がいつルーティングを変えたかを監査できる。
• 構成のコード化: メッシュの構成要素を Infrastructure as Code で管理し、ルートの重みや暗号化設定の変更をレビュー可能にする。手作業での部分変更による不整合を避ける。
• Envoy の更新運用: AWS が提供する Envoy イメージの更新を定期的に取り込み、既知の不具合やセキュリティ修正を反映する。

コスト

App Mesh の料金は、おおむね次の考え方で捉えます。具体的な単価はリージョンや時期で変動するため、最新の料金ページで確認してください。

• App Mesh 自体の追加料金: コントロールプレーンの利用に対する直接の追加課金は発生せず、メッシュを構成すること自体に料金はかからないのが基本である。
• 実体リソースの料金: 実際のコストは、サイドカーとして動く Envoy が消費する分も含めた、ECS タスクや EKS ノード、EC2、Fargate といった基盤の利用料として発生する。
• 周辺サービスの料金: メトリクスやログ、トレースの送り先となる CloudWatch や X-Ray、サービスディスカバリの Cloud Map などに、それぞれの利用に応じた料金がかかりうる。
• 設計上の考慮: サイドカーを各タスクに増やす分だけ計算リソースの消費が増えるため、Envoy のリソース割り当てを過大にしないことが地味に効く。

セキュリティ

• 転送中の暗号化: 仮想ノード間の通信に TLS を設定し、サービス間のトラフィックを暗号化できる。証明書は AWS Certificate Manager や独自の仕組みで供給する。
• 相互 TLS 認証: 双方の Envoy が証明書を提示し合う相互 TLS により、通信相手の正当性を検証してなりすましを防ぐ。プライベートネットワーク内であっても認証を効かせられる。
• IAM による制御: メッシュや仮想サービス、ルートの作成・変更・削除といった操作は IAM ポリシーで制御し、構成を変更できる主体を絞る。
• 最小権限のディスカバリ: 仮想ノードが参照する Cloud Map や DNS の範囲を必要なものに限定し、意図しない宛先を解決させない。
• 多層防御: メッシュによるアプリ層の暗号化・認証に加え、セキュリティグループやサブネット設計といったネットワーク層の制御を併用し、到達性と認証の両面で絞り込む。

関連サービス・比較

サービス間通信を扱うという点で、App Mesh はしばしば Amazon VPC Lattice と比較されます。App Mesh は Envoy サイドカーを各サービスに配って細かな通信制御をデータプレーンで行う伝統的なサービスメッシュであり、VPC Lattice はサイドカーを持たずにマネージドな面でサービス間の接続・認可・観測を束ねるアプリネットワーキングです。新規構築では、サイドカー運用を避けられる VPC Lattice や、ECS に統合された ECS Service Connect が候補になります。

ハンズオン / CLI例

次は、メッシュを作成し、仮想ノードと仮想サービスを定義する基本的な流れの例です。識別子やリージョン、JSON で渡す仕様は自分の環境に合わせて置き換えてください。実運用では Envoy サイドカーの注入やサービスディスカバリの設定も併せて必要になります。

# サービス間通信を束ねるメッシュを作成する
aws appmesh create-mesh \
  --mesh-name my-mesh

# 仮想ノードを作成する。リスナーとディスカバリの仕様はファイルで渡す
aws appmesh create-virtual-node \
  --mesh-name my-mesh \
  --virtual-node-name orders-node \
  --spec file://orders-virtual-node-spec.json

# 仮想ノードを実体とする仮想サービスを作成する
aws appmesh create-virtual-service \
  --mesh-name my-mesh \
  --virtual-service-name orders.my-mesh.local \
  --spec '{"provider":{"virtualNode":{"virtualNodeName":"orders-node"}}}'

# 作成したメッシュ内の構成要素を確認する
aws appmesh list-virtual-services \
  --mesh-name my-mesh