苦労は2年待て、さすれば簡単なサービスが出る
はじめに
皆様、こんばんは。sanbongawa(Shu Kawanishi)です。
昔App Meshについて記事を公開してたのですが、その内容からの派生です。
「App Mesh、便利だったけど、正直技術ハードル高いよね…」と感じてたでしょう!
VPC Latticeの方が、よりシンプルで強力なサービスを展開しているよということでそっちを使った方がいいねと思ったので記事にします。
App Meshの「これまで」とVPC Latticeの「これから」
App Meshの振り返り
App Meshはアプリケーション間の通信をプロキシして、通信制御を⾏うプロセスです。
「サイドカー」のEnvoyプロキシがその役割をしてくれてました。
このサイドカーモデルのおかげで、アプリケーションコードに手を加えることなく、App Meshを導入することができました。
しかし、Envoyサイドカーの導入は、メリットが大きかったが、プロキシ自体の管理やリソースオーバーヘッドなど問題があり、最もつらいなと思ったのは学習コスト(難しいという点ですね)だったなと思います。
Amazon VPC Latticeの登場
個人的にはひっそりと現れた今回の主役Amazon VPC Latticeですが、このサービスは、マイクロサービス間通信の簡素化、セキュリティ強化、モニタリング改善などを提供されるサービスでApp Meshと似たサービスだったのですが、AWSはAWS App Meshを2026年9月30日をもって非推奨化することを発表しました 。そっちになるのか、、
App MeshとVPC Lattice何が違うの?
私の理解としてはApp Meshのマネージドサービスが現れたということです。
マネージドなのはどこ?
App MeshとVPC Latticeを軽く比較するとこのよう違いです。
-
App Mesh: サービス間のトラフィックルーティングと制御のために、各アプリケーションにEnvoyプロキシをサイドカーコンテナとしてデプロイします。これによりコード変更なしで制御できますが、Envoyプロキシ自体の管理はユーザーの責任。
-
VPC Lattice: フルマネージドなコントロールプレーンとデータプレーンを提供するため、Envoyプロキシコンポーネントのデプロイや管理が不要。
この違いは、よくあるマネージメントサービスがめんどくさいことを代わりにやってくれるので便利です!!というApp Meshがキタ――(゚∀゚)――!!ですね。
機能比較
両サービスは共通の機能を提供しますが、その実装方法と責任範囲には違いがあります。
機能 | AWS App Mesh | Amazon VPC Lattice |
---|---|---|
サイドカー | 必須 | 不要 |
セットアップと管理の容易さ | 複雑 | 中程度 |
オブザーバビリティ | Envoy プロキシ自体、または CloudWatch Agent 等を経由してメトリクス収集が必要。X-Ray連携はEnvoy設定で可能。 | CloudWatchに組み込みのメトリクスを自動生成。X-Ray連携も可能 。 |
トラフィック管理 | クライアントサイド制御(リトライ、タイムアウト、接続プール)。 | リクエストレベルのルーティング、重み付けターゲットをサポート。 |
セキュリティ | 相互TLS (mTLS) をサポート | IAM認証ポリシー、セキュリティグループ、ネットワークACLsによる多層防御。TLS Passthroughで既存mTLSも利用可能(アプリ側の対応が必要)。 |
料金の考え方 | コンテナのサイドカーなのでリソース分となりシンプルです。 | マネージドのため、プロビジョニングされたサービス数、データ処理料金 (GB単位)、HTTPリクエストまたはTCP接続の数などから費用が算出されます。 |
非推奨になるなら移行しないと?
移行前に考えること
自問自答してみましょう!
- 既存情報: 現在のApp Meshはどのように利用されていますか。
- アプリケーションの互換性: 既存アプリケーション側に問題はありませんか。
- 依存関係のマッピング: システム間や通信の依存関係はありますか。
- 制御方法: ユーザーとシステムの間を管理制御する製品が変わるため、制御方法は全く一緒ではありません。新しい環境ではどのように制御するかを検討しましたか。
- リソース調整: ネットワーク帯域幅、CPU/MEM/ストレージの調整をしましょう。サイドカーがなくなることで、これまでサイドカーに割り当てていたリソースが不要になるか、アプリケーションコンテナが直接利用できるリソースが増える可能性があります。その分のリソース調整を検討しましょう。
実際に移行するならどうするか
どの移行方法を選ぶ?(In-place vs. Blue/Green vs. Canary)
App MeshからVPC Latticeへの移行とは言いますが、要はシステム移行です。
システムを止めることができるのか?から考えて下さい。
1. In-place migration(インプレース移行):
- コンテナ環境の中身を交換します。
- VPC Latticeは切り替え前に構築を終えるなど、事前作業と切り替え作業を分けて考える必要があります。
- 他の方式に比べ、システム停止時間を短く抑えるための調整がより難しい方式です。
2. Blue/Green deployment(ブルー/グリーンデプロイメント):
- VPC Lattice用に新しい環境をデプロイし、元のApp Meshデプロイメントは稼働させたままにします。
- 新しいVPC Lattice環境が準備されたらトラフィックを段階的に切り替えます。(※一斉の切り替えは個人的に推奨しません)
- 他に比べて個人的には最も安全な方式です。
3. Canary deployment(カナリアデプロイメント):
- App Meshと並行してVPC Latticeをデプロイし、トラフィックのごく一部をVPC Latticeに段階的に移行する戦略です。
- 他に比べて停止できないサービスに向いてる方式です。
App Mesh環境からの移行例
以前の検証で構築したApp Mesh環境(front
アプリケーションとEnvoyサイドカーを持つcolor
アプリケーションで構成されるもの)をAmazon VPC Latticeに移行する具体的なステップを見ていきましょう。
環境を作る → 通信テストをする → 切り替え → お片付け、といったステップが必要です!
1. VPC Latticeターゲットグループの作成とECSサービスへのマッピング
- ECSがVPC Latticeターゲットグループにターゲットを登録・解除できるよう、ECS タスクロールに必要なIAM権限 (例:
vpc-lattice:RegisterTargets
,vpc-lattice:DeregisterTargets
を含むポリシー) を付与します。 - 既存のバックエンドECSサービス(例:
color
アプリケーション)に対応するVPC Latticeターゲットグループを作成します。 - ECSサービスを構成し、そのコンテナIPアドレスがこれらの新しいVPC Latticeターゲットグループに動的に登録されるように設定します。
CLI例:
aws vpc-lattice create-target-group \
--name color-app-tg \
--type IP \
--config '{
"port": 80,
"protocol": "HTTP",
"vpcIdentifier": "<Your VPC Id>"
}'
aws ecs update-service \
--service color-app-service \
--cluster your-ecs-cluster \
--vpc-lattice-configurations '{
"roleArn":"<ARN of Infrastructure Role>",
"targetGroupArn":"<ARN of color-app-tg>",
"portName":"color-app-container-port"
}'
2. VPC Latticeコンストラクトの構成
- VPC Latticeのコアコンポーネントを構成します。
- サービスネットワーク
- VPC Latticeサービス
- リスナー
- ヘルスチェック
- VPCとの関連付け
- 作成したVPC Latticeターゲットグループをリスナーにマッピングします。
- ECSサービスが動作するVPCとサービスネットワークの関連付けのために、適切なセキュリティグループを設定し、VPC Latticeのプレフィックスリストからのインバウンドトラフィックを許可するようにします。
CLI例:
aws vpc-lattice create-service-network \
--name my-app-service-network
aws vpc-lattice create-service \
--name color-app-service-lattice \
--custom-domain-name color.int.example.com \
--certificate-arn <Your ACM Certificate ARN>
aws vpc-lattice create-listener \
--cli-input-json '{
"name": "color-app-listener",
"protocol": "HTTP",
"port": 80,
"serviceIdentifier": "<Id of color-app-service-lattice>",
"defaultAction": {
"forward": {
"targetGroups": [
{
"targetGroupIdentifier": "<Id of color-app-tg>",
"weight": 100
}
]
}
}
}'
aws vpc-lattice create-service-network-vpc-association \
--service-network-identifier <Id of my-app-service-network> \
--vpc-id <Your VPC Id> \
--security-group-ids <Your Security Group Id>
3. 通信テスト
- 通信テストに関しては、今回は移行例のため割愛します。
4. フロントの切替
- 検証が完了したら、本番トラフィックをVPC Latticeに切り替えるために、DNSを変更します。
5. 不要なリソースの削除
- 完全にVPC Latticeに移行したことを確認した後、未使用となったALB、そのターゲットグループ、およびリスナーを削除します。全ての通信フローがVPC Lattice経由で機能していることを確認しましょうね。
VPC Lattice移行における注意点と工夫
このBlogを書いているなかで感じたことですが、一番理解を深めないといけないのは、App Mesh (Envoy) と VPC Lattice の機能範囲の違いかもしれませんね。
App Mesh の場合: クライアント → Envoyサイドカー群 → アプリケーション
VPC Lattice の場合: クライアント → VPC Lattice → アプリケーション
Envoyサイドカー群が提供していたきめ細やかな制御(例えば、非常に複雑なリトライ戦略やカスタムルーティングロジックなど)のすべてを、VPC Lattice がそのまま対応することはできないようです。
VPC Lattice は多くの一般的なユースケースをシンプルに解決してくれますが、App Mesh + Envoy で実現していた高度なカスタマイズが必要な場合、その機能をアプリケーション側に持たせるか、アーキテクチャ全体でどうカバーするかを考える必要があり、そこがエンジニアの腕の見せ所でしょうね。
まとめ:VPC Latticeで未来のマイクロサービスへ
さて、今回は AWS App Mesh から Amazon VPC Lattice への移行について、そしてその違いを見てきましたね。
App Mesh はマイクロサービス間の通信制御に強力な機能を提供してくれましたが、「Envoy サイドカーの管理が大変…」「学習コストがちょっと…」と感じていた方もいらっしゃるのではないでしょうか。私もその一人でした!
そこへ登場したのが、今回の主役である Amazon VPC Lattice です。このサービスはフルマネージドで、あの面倒だったサイドカープロキシのデプロイや管理が不要になるんです。
VPC Lattice は、サービスディスカバリ、トラフィック管理、セキュリティ、オブザーバビリティといった機能を、App Mesh とは異なるアプローチで、よりシンプルかつ効率的に提供してくれます。特に、複数の VPC や AWS アカウントにまたがるような大規模なマイクロサービスの接続も、VPC Lattice ならグッと楽にしてくれるはずです。
とにもかくにも、App Mesh が2026年9月30日に非推奨となることも発表されています。
これを機に、皆さんのマイクロサービスアーキテクチャも、VPC Lattice を活用して、よりシンプルで、より運用しやすく、そして未来を見据えた形へとアップデートしていくことを検討してみてはいかがでしょうか!
Discussion