ある企業が Amazon EKS で Kubernetes クラスターを運用しており、数百のマイクロサービスをデプロイしています。サービス間のトラフィック暗号化（mTLS）、サービスディスカバリー、カナリアデプロイ、分散トレーシングを実装したいと考えています。既存の Kubernetes のデプロイメント定義を変更せずに、インフラレベルでこれらを実現したいと考えています。最も適切なアーキテクチャはどれですか？
- A. ALB Ingress Controller を EKS にデプロイし、カナリアデプロイは ALB のターゲットグループ重み付けで実装する。mTLS は各コンテナ内で証明書を管理する
- B. 各マイクロサービスのコードに gRPC インターセプターを追加して mTLS を実装し、Kubernetes の Service オブジェクトでサービスディスカバリーを管理する
- C. AWS App Mesh をサービスメッシュとして EKS クラスターに統合し、各 Pod に Envoy プロキシをサイドカーとして自動注入する。App Mesh と AWS X-Ray の統合で分散トレーシングを実現し、仮想ノードとルーターで mTLS とカナリアデプロイを設定する
- D. ECS Fargate に移行してサービスメッシュ機能を活用し、ECS の App Mesh 統合でカナリアデプロイと mTLS を実現する
解答と解説を見る
正解: C
AWS App Mesh はサービスメッシュのコントロールプレーンとして、既存の Kubernetes デプロイメントを変更せずにサイドカーコンテナ（Envoy）を自動注入できます。App Mesh で mTLS、サービスディスカバリー（仮想ノード）、カナリアデプロイ（仮想ルーター+ルート重み付け）を設定し、X-Ray 統合で分散トレーシングが実現できます。 B: アプリケーションコードへの gRPC インターセプター追加は「既存のデプロイメント定義を変更せず」という要件に反します。また、カナリアデプロイや分散トレーシングの統合も課題が生じます。 A: ALB Ingress Controller はクラスター外からのトラフィック管理に有効ですが、サービス間（東西）トラフィックの mTLS やサービスメッシュ機能は提供しません。各コンテナでの証明書管理は複雑で管理負荷が高くなります。 D: ECS への移行は既存の EKS/Kubernetes 投資を無駄にし、要件と大きく乖離しています。EKS のまま App Mesh を統合する方が適切です。
📚 関連サービスの解説: Amazon EKS ・ AWS X-Ray