Google Cloud Platform Advent Calendar 2021 の 1 日目の記事です。

Anthos Service Mesh (以下、ASM) は Google Cloud が提供しているマネージドサービスメッシュです。
ASM には今年1年で多くのアップデートがありました。
GCP 以外の環境 (他のパブリッククラウドやオンプレミス) でも利用できるという Anthos のコンセプトにも関係しているのか、今年の ASM のアップデートでは実行環境やプロジェクトの要件に応じた複数の利用形態が登場しています。

選択肢が増えたことでドキュメントも拡充され、分量が増えているため、どのユースケースにどの利用形態が向いているのか、またどのオプションがどの利用形態で利用できるのか、といった情報を端的に掴むのがやや難しい面もあるのではないかと思います。
そこで今回は、ASM の利用形態と想定されるユースケースの違いについてざっくりと概要をご紹介し、これから ASM の導入を検討されている方に向けてヒントとなる情報を記せればと考えました。
なお、この記事では、GCP 上の GKE (公式ドキュメントでいうところの GKE clusters on Google Cloud) で利用する ASM の話にスコープを絞ります。

各構成の概要

記事執筆時点 (2021年11月29日) では、各構成の概要は以下のようになっています。
表に続いて、構成間の主な違いや共通点を説明します。

f:id:polar3130:20211130230021p:plain

構成間の主な違い

ASM In-cluster Control Plane (以下、ASM In-cluster CP) はコントロールプレーン (Istiod) をユーザのクラスタ内にデプロイする利用形態となっています。
従来から提供されてきた ASM の構成であり、Istiod のアップグレードタイミングやキャパシティを自分たちで制御したい場合に適しています。

f:id:polar3130:20211125144504p:plain

Managed ASM はコントロールプレーン (Istiod) を Google が管理する新しい利用形態です。
以下のイメージ図に示すように、コントロールプレーン (Istiod) がユーザのクラスタにデプロイされずとも、ASM を利用することができます。
Managed ASM では Istiod のアップグレードやキャパシティ管理をユーザが考慮する必要がなくなります。

f:id:polar3130:20211026132503p:plain

加えて、Managed ASM では Managed Data Plane の機能を利用することで、データプレーンにあたる Istio-proxy (Envoy) サイドカーのアップグレードを自動化することができます。
この構成では、以下のイメージ図に示すように、Data Plane Controller というコンポーネントがユーザのクラスタにデプロイされます。
Managed ASM のコントロールプレーンがアップグレードされる際に、併せてデータプレーンもアップグレードされます。

f:id:polar3130:20211125144453p:plain

構成を問わず共通して利用できる機能

mTLS の強制や、Ingress/Egress Gateway など、Istio としての基本的な機能は ASM In-cluster CP と Managed ASM のどちらでも利用可能です。
また、Cloud Operations (Cloud Monitoring, Cloud Logging, Cloud Trace, etc.) との統合や、Multi Cluster Service / Multi Cluster Ingress の利用といった Google Cloud の他の機能との統合も、多くの場合は ASM In-cluster CP と Managed ASM のどちらでも対応されています。

ユースケース

上記に示したように、現在の ASM には (Google Cloud の GKE で利用する場合だけでも) 複数の構成の選択肢があります。
以下では、いくつかのユースケースを提示しながら、各要件に合った ASM の構成をご紹介したいと思います。

ケース1. 世の中でより実績のある構成を求める場合

→ GKE Standard + ASM In-cluster CP + MeshCA

ASM のローンチ当初からサポートされてきた構成であり、GKE Autopilot や Managed ASM の登場以前は ASM と言えばこの構成を指していました。
Web で公開されている情報も ASM の利用形態の中で最も多く、 (私見ですが) 最も標準的な ASM の利用形態と言えるのではないかと思います。
構成上の制約が少なく、Private Cluster や VPC SC を使ったエンタープライズ向けの利用にもおすすめです。

この構成では GKE, ASM それぞれにアップグレードやキャパシティをユーザが管理してゆく必要があります。
GKE, ASM のアップグレードについては CloudNative Days Tokyo 2021 に登壇した際の資料で詳しくご紹介していますので、ご興味あればご参照頂ければと思います。

ケース2. とにかく一番手軽に使える ASM が欲しい場合

→ GKE Autopilot + Managed ASM + managed Data Plane + MeshCA + Standalone ASM

GKE, ASM の運用負荷が最小となる構成です。
GKE は Autopolot の場合リリースチャネルの利用が必須となるため、ユーザが GKE のコントロールプレーンおよびデータプレーン（ノード）のアップグレードを検討する必要はありません。
ASM もコントロールプレーンが Google によって管理され、コントロールプレーンの構成に伴ってデータプレーンも自動アップグレードされるため、ユーザによるアップグレードの検討は不要です。
Istio の各種機能を、最もインフラを意識せずに利用できる構成とも言えるのではないでしょうか。

CA は Mesh CA を利用することで証明書の管理も Google に任せることができ、Standalone ASM であれば Anthos API の有効化も不要です。
最近、Managed ASM はコンソールの GKE クラスタ作成フォームからも有効化できるようになりましたので、セットアップも非常に簡単化されています。
まずは ASM を試してみたい、という方におすすめです。

f:id:polar3130:20211026133822p:plain

ケース3. 可能な限りマネージドな領域を減らしたい場合

→ GKE Standard (+ Private Cluster) + ASM In-cluster CP + CAS

一見マネージドサービスの考え方とは反するように思えるかもしれませんが、GKE + ASM という構成を使いつつも可能な限り自分たちでコンポーネントのバージョンを制御したいという場合はあり得ます。

例えば以下のような要件が考えられます：

運用ルール上、システムコンポーネントのバージョンを記録・管理しており、自動でバージョンが上がってしまうことは極力避けたい ※
障害発生時に再現試験などを行うため、システムコンポーネントのバージョンを固定したい
業界標準や法規制等の対応で、サービスメッシュ内の通信の暗号化 (mTLS) にプライベート CA を用いる必要がある

(※ GKEのコントロールプレーンは、リリースチャネルを利用していない場合でもパッチレベルでは自動アップグレードが走ります)

マネージドな領域を減らしてでも、その他のメリット（Istio の設計や運用にあたって Google のサポートを受けられる、オープンソースの Istio のコミュニティサポートよりも長い期間ひとつの ASM バージョンを運用できる等）を理由に GKE + ASM の構成を採用したい、というケースはあると思いますので、ASM がエンタープライズで利用される場合にはこういった構成も選択肢のひとつになると考えられます。

まとめ

オプションを含めて様々な選択肢が採用できるになった ASM の現状と、いくつかのユースケースにおいて候補となる GKE, ASM の構成をご紹介しました。
これから ASM の利用を検討されている方々の参考になれば幸いです。

なお、この記事では主な機能の違いを示し、現在の ASM の概要をお伝えすることを目的としました。
選択可能な全機能のサポート状況を網羅的に把握されたい場合は下記の公式ドキュメントをご参照ください。

https://cloud.google.com/service-mesh/docs/supported-features
https://cloud.google.com/service-mesh/docs/supported-features-mcp

polar3130’s blog

あなたにぴったりな Anthos Service Mesh を見つけよう