本連載は、Google Cloudのアプリ開発とDBプロダクトにおけるスペシャリスト達が、Google Cloudプロダクトを利用した、クラウドネイティブな開発を実践する方法を解説しています。
第6回では、サービスメッシュについて紹介します。
主に対象となる読者は、クラウドを利用してアプリケーションを開発するエンジニア、またはその基盤を構築するエンジニア、サービス開発に携わるプロダクトマネージャーを想定しています。
マイクロサービスアーキテクチャの課題
これまでの連載ではクラウドネイティブなアプリケーションの開発について紹介しました。小さい独立して動作するサービスが連携するマイクロサービスアーキテクチャは、スケーラビリティ、独立した開発の容易さ、そして障害からの復旧力の強さなど、様々なメリットをもたらす可能性があります。
一方で、このアーキテクチャが複雑さも生み出すことになります。たとえば、サービスディスカバリ、サービス間コミュニケーション、セキュリティ、可観測性などに新たな課題が伴います。
そのような課題を解決する技術の一つがサービスメッシュです。
通信を制御・管理するサービスメッシュ
サービスメッシュは、マイクロサービス間の通信を制御し、管理するための専用のインフラストラクチャ層です。各サービス
同様の実装をサービスメッシュを使わずにアプリケーション自体に含めることもできますが、言語によって適切なライブラリを選択、実装し、そのメンテナンスを行うということは骨の折れる作業です。サービスメッシュを使用することで、アプリケーション開発者はビジネスロジックに集中でき、ネットワークの複雑さや運用上の課題に悩まされることがありません。また、一貫した方法でポリシーを適用し、サービス全体の動作を監視できます。
サービスメッシュはマイクロサービスが必須ではありません。マイクロサービスでないアプリケーションであっても、サービスメッシュを使用して通信を管理し、セキュリティと観測性を向上させることができます。サービスメッシュは、アプリケーションアーキテクチャに関係なく、モダンアプリケーションの通信の複雑性を解消できるのです。
オープンソースプロダクト Istio
サービスメッシュの実装には様々なプロダクトが存在しています。その中でも、メジャーなものの一つ、Istioを紹介します。Istioは、オープンソースのサービスメッシュプラットフォームであり、マイクロサービスアーキテクチャの管理と保護に広く使用されています。このプロジェクトはGoogle、IBM、Lyftの共同で開発されました。
Istioは、マイクロサービス間の通信を制御し、管理するための包括的なソリューションを提供します。サービスメッシュの中核として機能し、トラフィック管理、セキュリティ、観測性、ポリシーの適用などの機能を提供します。Istioは、主にKubernetesプラットフォームで動作するように設計されていますが、他のプラットフォームにも適用することが可能です。
Istioのもつ機能
- トラフィック管理：サービス間のトラフィックをインテリジェントにルーティングし、負荷分散、フェイルオーバー、カナリアリリースなどの機能を提供します。
- セキュリティ：相互TLS認証、認可、暗号化などの機能を通じて、サービス間の通信を保護します。
- 可観測性：トレース、メトリクス、ログなどの機能を提供し、マイクロサービスのパフォーマンスと動作を監視します。
- ポリシー適用：サービス間の通信に対して一貫したポリシーを適用し、アクセス制御、レート制限、クォータ管理などを行います。
Istioのアーキテクチャ
Istioは、データプレーンとコントロールプレーンの2つの主要コンポーネントで構成されています。
- データプレーン：サイドカープロキシ
（Envoy） で構成されます。各マイクロサービスの横に配置され、サービス間のすべてのネットワークトラフィックをインターセプトし、トラフィックの制御、ポリシー適用、およびデータの収集を行います。 - コントロールプレーン：Istiodというコンポーネントで構成されます。サービスディスカバリ、構成管理、セキュリティ、および証明書の発行を担当します。
Anthos Service Mesh
Anthos Service Mesh
ASMは、Istioの機能を継承しつつ、設定と管理を簡素化することに重点を置いています。これにより、ユーザーはサービスメッシュ自体の複雑さを気にすることなく、その利点を享受できます。ASM は、トラフィック管理、セキュリティ、観測性、およびポリシー適用の機能を提供し、マイクロサービスアプリケーションの運用を容易にします。
Anthos Service Meshのアーキテクチャ
ASMはプラットフォームによりアーキテクチャや動作に違いがあります。以降はGKEで実行されることを前提として記載します。
データプレーンについては、Istioと同様にEnvoyプロキシを利用しており、各サービスのサイドカーとして実装され、各機能を提供します。EnvoyプロキシはGoogle Cloudによってライフサイクルが管理されるManaged Data Plane
コントロールプレーンについては、Istiodに相当するコンポーネントがGoogle Cloudによるマネージドサービスとして提供されます。これをMCP
ASMの設定は、Google CloudのConsole
ASMは、Istioの力を借りつつ、管理の複雑さを抽象化することで、ユーザーにシームレスなサービスメッシュ体験を提供します。これにより、開発者と運用チームは、アプリケーションのビジネスロジックに集中し、サービスメッシュの運用についてはGoogle Cloudのマネージド機能をフル活用することが可能です。
またASMは、サービスメッシュへのIngressおよびEgressトラフィックを処理するためのマネージドゲートウェイを提供します。
サービス間のセキュリティ
ASM
これまで、ASMやIstioの様々な特徴や機能について紹介しました。ここからは、ASMの具体的な利用方法についていくつか紹介します。
mTLSの動作モードとしてSTRICTモード
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: istio-system
spec:
mtls:
mode: STRICT
サービスメッシュ内のトラフィックの管理
Istioでは、Gateway, VirtualService, DestinationRuleの3つのリソースを使用して、Envoyプロキシの設定を抽象化し、サービスメッシュ内のトラフィックを管理します。これらのリソースは、Envoyがトラフィックを適切に送受信できるように、必要な設定情報を提供します。
- Gateway：外部からのトラフィックを受信するための設定を定義します。これには、リッスンするポートやプロトコルなどが含まれます。
- VirtualService：トラフィックのルーティングルールを定義します。これには、トラフィックの宛先となるサービスや、条件に基づいたルーティングなどが含まれます。
- DestinationRule：サービスの異なるバージョンやサブセットを定義します。これは、VirtualServiceのルーティングルールで使用されます。
Envoyは、これらのリソースで定義された設定に基づいて動作します。Gatewayで定義された設定に従って外部からのトラフィックを受信し、VirtualServiceとDestinationRuleで定義されたルールに基づいてトラフィックを適切なサービスにルーティングします。
例えば、VirtualServiceとDestinationRuleを使用して、トラフィックを新旧のバージョンに分割するためのルールを定義することが可能です。これらのルールに基づいて、Envoyが実際にトラフィックを分割し、適切なサービスにルーティングします。
つまり、Istioのリソースは、Envoyがトラフィックを適切に制御できるように、必要な設定情報を提供するための抽象化された概念であると言えます。
VirtualServiceのユースケースの一例として、Traffic SplittingによるCanaryリリースについて紹介します。Canaryリリースとは、新しいバージョンのサービスを段階的にリリースし、一部のユーザーにのみ新しいバージョンを公開する手法です。これにより、新しいバージョンの動作を実際のトラフィックで検証し、問題がある場合にはすぐにロールバックすることができます。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-service
spec:
hosts:
- my-service.default.svc.cluster.local
http:
- route:
- destination:
host: my-service.default.svc.cluster.local
subset: v1
weight: 90
- destination:
host: my-service.default.svc.cluster.local
subset: v2
weight: 10
この VirtualServiceは、my-serviceの90%のトラフィックをバージョン v1に、10%のトラフィックをバージョン v2にルーティングしています。weightの値を徐々に変更しながら、v2の割合を増やしてすべてのトラフィックをv2にルーティングします。このような手法で、安定して新しいバージョンのアプリケーションをリリースすることもASMを利用することで簡単に実装できます。
その他の機能
ASMは、サービスメッシュ内のサービスの動作を監視し、問題の診断やパフォーマンスの最適化を行うための可観測性機能を提供しています。ログはCloud Logging、メトリクスはCloud MonitoringへというようにGoogle Cloudのマネージドサービスとネイティブに連携しています。また、専用ダッシュボードも提供されており、サービスのSLOを設定し、SLOの観点でサービスのモニタリングが可能となります。
他にもASMには運用に役立つダッシュボードがいくつか用意されています。以下はその一つ、サービス間の依存関係を示すUIになります。
また、ASMは、複数のKubernetesクラスタにまたがるサービスメッシュを構築することができます。これにより、異なるクラスタ上で実行されているサービス間の通信を、単一のサービスメッシュを通じて管理することができます。
まとめ
サービスメッシュは、サービス間通信の複雑性を管理するための重要な技術です。サービス間の通信を制御し、セキュリティ、信頼性、可観測性を提供します。Istioは、最も広く採用されているサービスメッシュの実装の一つであり、トラフィック管理、セキュリティ、可観測性などの機能を提供します。
ASMは、トラフィック管理、セキュリティ、可観測性などの基本機能に加えて、拡張性、マルチクラスタ対応などの高度な機能も提供しています。また、Google Cloudのその他のサービスとの統合により、包括的なマイクロサービス管理ソリューションを提供します。マイクロサービスアーキテクチャを採用する組織にとってサービスメッシュは不可欠なコンポーネントになりつつあります。ASMは、サービスメッシュ自体の複雑性を軽減させ、アプリケーションの開発と運用をサポートします。
なお、執筆時点
連載の終わりに
本連載をご覧いただき、誠にありがとうございます。私たちGoogle Cloudのアプリ開発とDBプロダクトのスペシャリスト達は、皆様にクラウドネイティブな開発の実践的な方法をお伝えすべく、記事の執筆に努めてまいりました。
クラウドネイティブな開発とは、クラウドコンピューティングの利点を最大限に活用し、スケーラブルで回復性の高いアプリケーションを構築するための方法論です。本連載では、Google Cloudが提供する 様々なプロダクトを用いて、クラウドネイティブな開発を実践する方法を、具体的な例を交えて解説してきました。
Google Cloudは、これからもクラウドネイティブな開発を支援するためのプロダクトとソリューションを提供してまいります。皆様のクラウドネイティブな開発の旅に、Google Cloudが貢献できることを楽しみにしております。
今後とも、どうぞよろしくお願いいたします。