Cloud Service Mesh の概要
このドキュメントは、Cloud Service Mesh とその機能を把握する必要があるネットワーク管理者とサービス オーナーを対象としています。これは、ロード バランシング API を使用した構成に適用されるレガシー ドキュメントです。
Cloud Service Mesh は、アプリケーション ネットワーキングを対象とするマネージド コントロール プレーンです。Cloud Service Mesh を使用すると、トラフィック管理やオブザーバビリティなどの高度なアプリケーション ネットワーキング機能を備えた、グローバルで可用性の高いサービスを提供できます。
デプロイに含まれるサービスとマイクロサービスの数の増加するにつれ、次のようなアプリケーション ネットワーキングにおける共通の課題に直面します。
- どのようにして、サービスの復元性を実現するか。
- どのようにして、トラフィックをサービスへ向かわせるか。また、サービス同士をどのように認識させ、相互に通信させるか。
- どのようにして、サービスが相互に通信しているときに起きたことを把握するか。
- どのようにして、サービスを停止させることなく更新を行うか。
- どのようにして、デプロイを実現するインフラストラクチャを管理するか。
Cloud Service Mesh を使用すると、現代的なサービスベースのデプロイにおける、こうした課題を解決できます。Cloud Service Mesh は Google Cloud マネージド インフラストラクチャを利用するため、独自のインフラストラクチャを管理する必要はありません。アプリケーションのネットワーキングの複雑な管理は Cloud Service Mesh に任せ、ビジネス上の課題を解決するアプリケーション コードの提供に専念できます。
Cloud Service Mesh
アプリケーション ネットワーキングの課題を解決する共通のパターンは、サービス メッシュを使用することです。Cloud Service Mesh は、サービス メッシュと、ニーズに合った他のデプロイ パターンをサポートしています。
一般的なサービス メッシュの場合、以下のようになります。
- サービスは、Kubernetes クラスタにデプロイします。
- 各サービスの Pod には、サイドカー プロキシとして実行される専用のプロキシ（通常は Envoy）があります。
- 各サイドカー プロキシは、クラスタにインストールされているネットワーキング インフラストラクチャ（コントロール プレーン）と通信します。コントロール プレーンは、サービス メッシュ内のサービス、エンドポイント、ポリシーについて、サイドカー プロキシに通知します。
- Pod がリクエストを送信または受信すると、そのリクエストは Pod のサイドカー プロキシに入ります。サイドカー プロキシは、そのリクエストを目的の宛先に送信するなどの処理を行います。
このドキュメントと他の Cloud Service Mesh ドキュメント内の図では、プロキシはピンクの六角形のアイコンで表現されています。コントロール プレーンは各プロキシに接続され、プロキシがリクエストの処理に必要とする情報を提供します。ボックス間の矢印はトラフィックのフローを示します。たとえば、Service A のアプリケーション コードがリクエストを送信すると、プロキシがそのリクエストを処理して、Service B に転送します。
このモデルによって、ネットワーキングのロジックをアプリケーション コードの外に出すことができます。アプリケーション ネットワーキングの処理はインフラストラクチャに任せて、ビジネス価値の提供に専念できます。
Cloud Service Mesh の違い
Cloud Service Mesh は上記のモデルと似ていますが、重要な違いがあります。まず、Cloud Service Mesh は、Google Cloud のマネージド サービスであるという事実が根本にあります。インストールせず、クラスタ内で実行されないため、メンテナンスする必要はありません。
下の図では、Cloud Service Mesh がコントロール プレーンです。この Kubernetes クラスタには 4 つのサービスがあり、それぞれ Cloud Service Mesh に接続されるサイドカー プロキシがあります。Cloud Service Mesh は、プロキシがリクエストを転送するために必要な情報を提供します。たとえば、Service A に属する Pod 上のアプリケーション コードがリクエストを送信すると、この Pod とともに稼働するサイドカー プロキシがリクエストを処理して、Service B に属する Pod に転送します。
サービス メッシュよりも豊富なサポート
Cloud Service Mesh では、一般的なサービス メッシュよりも多くのタイプのデプロイがサポートされます。
マルチクラスタ Kubernetes
Cloud Service Mesh により、Kubernetes クラスタ間で機能するアプリケーション ネットワーキングを利用できます。次の図では、Cloud Service Mesh が Kubernetes クラスタのコントロール プレーンを us-central1 と europe-west1 に提供しています。リクエストは、us-central1 の 3 つのサービス、europe-west1 の 2 つのサービス、2 つのクラスタのサービス間でルーティングできます。
サービス メッシュを、複数の Google Cloud リージョンにある複数の Kubernetes クラスタにわたって拡張できます。クラスタ内のサービスが、別のクラスタ内のサービスと通信できます。さらに、複数のクラスタの Pod で構成されるサービスを使用することもできます。
Cloud Service Mesh の近接ベースのグローバルなロード バランシングを使用すると、Service B 宛のリクエストは、そのリクエストを処理可能な最も近い Pod に送られます。また、フェイルオーバーはシームレスに行われます。Pod がダウンすると、その Pod が別の Kubernetes クラスタ内にある場合でも、リクエストに対応可能な別の Pod へ自動的にリクエストがフェイルオーバーされます。
仮想マシン
Kubernetes の人気が高まりつつありますが、多くのワークロードは仮想マシン（VM）にデプロイされています。Cloud Service Mesh は、こうしたワークロードに対するアプリケーション ネットワーキングも解決し、VM ベースのワークロードと Kubernetes ベースのワークロードを相互運用できます。
次の図では、外部アプリケーション ロードバランサを通じてトラフィックが Deployment に到着します。そのトラフィックは、asia-southeast1 にある Kubernetes クラスタの Service A と、europe-west1 にある VM の Service D に転送されます。
Google は、Cloud Service Mesh を使用して VM ベースのワークロードを設定するシームレスなメカニズムを提供します。Compute Engine VM インスタンス テンプレートにフラグを追加するだけで、インフラストラクチャの設定を処理します。このセットアップには、アプリケーション ネットワーキング機能を提供するプロキシのインストールと構成が含まれます。
プロキシレス gRPC
gRPC は、機能豊富なオープンソースの RPC フレームワークです。これを使用して、高性能なマイクロサービスを作成できます。Cloud Service Mesh を使用すると、アプリケーション ネットワーキング機能（サービス ディスカバリ、ロード バランシング、トラフィック管理など）を gRPC アプリケーションで使用できます。詳細については、Cloud Service Mesh と gRPC - サービス メッシュ用のプロキシレス サービスをご覧ください。
次の図では、gRPC アプリケーションは、あるリージョンの Kubernetes クラスタに基づいたサービスと、異なるリージョンの VM 上で実行されるサービスにトラフィックをルーティングしています。2 つのサービスにはサイドカー プロキシがあり、他のサービスはプロキシレスです。
Cloud Service Mesh は、プロキシレス gRPC サービスをサポートしています。これは、xDS API をサポートする最新バージョンのオープンソース gRPC ライブラリを使用するサービスです。gRPC アプリケーションは、Envoy と同じ xDS API を使用して Cloud Service Mesh に接続できます。
アプリケーションを接続すると、gRPC ライブラリは、サービス ディスカバリ、ロード バランシング、トラフィック管理などのアプリケーション ネットワーキング機能を担います。これらの機能は始めから gRPC に備わっているため、サービス プロキシは必要ありません。そのため、プロキシレス gRPC アプリケーションと呼ばれます。
上り（内向き）とゲートウェイ
多くのユースケースでは、Cloud Service Mesh で構成されていないクライアントを起点とするトラフィックを処理する必要があります。たとえば、マイクロサービスへのパブリック インターネット トラフィックの上り（内向き）が必要な場合があります。また、クライアントからのトラフィックを宛先に送信する前にトラフィックを処理するリバース プロキシとして、ロードバランサを構成することもできます。
次の図では、外部アプリケーション ロードバランサによって外部クライアントに対する上り（内向き）中継が有効になり、トラフィックが Kubernetes クラスタ内のサービスに転送されています。内部アプリケーション ロードバランサは、VM で実行されているサービスに内部トラフィックを転送します。
Cloud Service Mesh は Cloud Load Balancing と連携して、マネージドの上り（内向き）中継を提供します。外部ロードバランサまたは内部ロードバランサを設定し、ロードバランサがトラフィックをマイクロサービスに送信するように構成します。上の図では、公共インターネットのクライアントは、外部アプリケーション ロードバランサを経由してサービスにアクセスします。Virtual Private Cloud（VPC）ネットワーク上にあるマイクロサービスなどのクライアントは、内部アプリケーション ロードバランサを使用してサービスにアクセスします。
ユースケースによっては、Cloud Service Mesh をセットアップしてゲートウェイを構成する必要がある場合があります。基本的に、ゲートウェイは 1 つ以上の VM で実行されている Envoy プロキシで、受信リクエストをリッスンして処理し、宛先に送信します。あらゆる Google Cloud リージョンまたは Google Kubernetes Engine（GKE）クラスタを宛先にすることができます。ハイブリッド接続を使用することで、Google Cloud から到達可能な Google Cloud の外部の宛先も利用可能です。どのような場合にゲートウェイを使用するかについては、メッシュの上り（内向き）トラフィックをご覧ください。
次の図では、europe-west1 リージョンにある VM が、プロキシを実行していない 3 つのサービスへのゲートウェイとして機能するプロキシを実行しています。外部アプリケーション ロードバランサと内部アプリケーション ロードバランサからのトラフィックは、ゲートウェイに転送され、続いて 3 つのサービスに転送されます。
複数の環境
Google Cloud、オンプレミス、その他のクラウドのいずれのサービスにおいても、またはそのすべてにサービスがある場合でも、アプリケーション ネットワーキングにおける基本的な課題は変わりません。どのようにして、トラフィックをこうしたサービスへ向かわせるかという課題です。また、どのようにして、こうしたサービスを互いに通信させるかという課題です。
次の図では、Cloud Service Mesh は、Google Cloud で実行されているサービスからのトラフィックを、別のパブリック クラウドで実行されている Service G、およびオンプレミスのデータセンターで実行されている Service E と Service F にルーティングします。Service A、Service B、Service C は、Envoy をサイドカー プロキシとして使用することに対し、Service D はプロキシレスの gRPC サービスです。
Cloud Service Mesh を使用すると、Google Cloud 外部の宛先にリクエストを送信できます。これにより、Cloud Interconnect または Cloud VPN を使用して、Google Cloud 内のサービスから他の環境のサービスまたはゲートウェイにプライベート トラフィックをルーティングできます。
Cloud Service Mesh の設定
Cloud Service Mesh の設定は 2 つの手順で構成されます。設定プロセスが完了すると、インフラストラクチャはアプリケーション ネットワーキングを処理し、Cloud Service Mesh はデプロイの変更に基づいてすべてを最新の状態に保ちます。
アプリケーションのデプロイ
まず、アプリケーション コードをコンテナか VM にデプロイします。Google では、VM インスタンスと Pod にアプリケーション ネットワーキング インフラストラクチャ（通常は Envoy プロキシ）を追加できる仕組みを提供しています。このインフラストラクチャは、Cloud Service Mesh と通信して、サービスについて学習するように設定されています。
Cloud Service Mesh を構成する
次に、グローバル サービスを構成し、トラフィックの処理方法を定義します。Cloud Service Mesh を構成するには、Google Cloud コンソール（一部の機能と構成用）、Google Cloud CLI、Traffic Director API、またはその他のツール（Terraform など）を使用します。
これらの手順を完了すると、Cloud Service Mesh でアプリケーション ネットワーキング インフラストラクチャを構成する準備が整います。
インフラストラクチャによるアプリケーション ネットワーキングの処理
アプリケーションが my-service にリクエストを送信すると、アプリケーション ネットワーキング インフラストラクチャ（Envoy サイドカー プロキシなど）が、Cloud Service Mesh から受信した情報に従ってそのリクエストを処理します。これにより、my-service へのリクエストを、受信可能なアプリケーション インスタンスにシームレスに転送できます。
モニタリングと継続的な更新
Cloud Service Mesh は、サービスを構成するアプリケーション インスタンスをモニタリングします。このモニタリングにより、Cloud Service Mesh は新しい Kubernetes Pod が作成された場合などに、サービスが正常な状態であるか、サービスの容量が変更されたかどうかを検出できます。この情報に基づいて、Cloud Service Mesh はアプリケーション ネットワーキング インフラストラクチャを継続的に更新します。
機能
Cloud Service Mesh の機能により、マイクロサービスにアプリケーション ネットワーキング機能が追加されます。このセクションでは、いくつかのポイントを説明します。
フルマネージドのコントロール プレーン、ヘルスチェック、負荷分散
インフラストラクチャの管理ではなく、ビジネス価値の提供に時間をかけたいとお考えなら、Cloud Service Mesh はフルマネージド ソリューションであるため、インフラストラクチャをインストール、構成、更新する必要はありません。Google でヘルスチェックやグローバル負荷分散に使用されているものと同じインフラストラクチャを利用できます。
オープンソース プロダクト上に構築
Cloud Service Mesh は、Envoy や Istio などの一般的なオープンソース プロジェクトが使用するのと同じコントロール プレーン（xDS API）を使用します。サポートされている API バージョンを確認するには、xDS コントロール プレーン API をご覧ください。
また、アプリケーション ネットワーキング機能を提供するインフラストラクチャ（ユースケースに応じて Envoy や gRPC のどちらか）もオープンソースであるため、独自仕様のインフラストラクチャに制限される心配はありません。
スケーリング
Cloud Service Mesh は、単発のアプリケーション ネットワーキング ソリューションから数千ものサービスで構成される大規模なサービス メッシュ デプロイメントまで、スケーリングのニーズを満たすように構築されています。
サービス ディスカバリとエンドポイントおよびバックエンドのトラッキング
アプリケーションが my-service にリクエストを送信すると、インフラストラクチャでシームレスにリクエストが処理され、正しい宛先に送信されます。アプリケーションは、IP アドレス、プロトコル、その他のネットワーキングの複雑性について認識する必要がありません。
グローバルなロード バランシングとフェイルオーバー
Cloud Service Mesh では、Google のグローバルなロード バランシングとヘルスチェックを使用して、クライアントとバックエンドのロケーション、バックエンドの近接性、健全性、容量に基づいてトラフィックを最適なバランスで分散させます。トラフィックを容量に余裕がある正常なバックエンドへ自動的にフェイル オーバーすることで、サービスの可用性が向上します。ビジネス要件に合わせてトラフィックが分散されるように、ロード バランシングをカスタマイズできます。
トラフィック管理
ルーティングとリクエストの操作（ホスト名、パス、ヘッダー、Cookie などに基づく）など、高度なトラフィック管理によって、サービス間のトラフィック フローを決定できます。カナリア デプロイの再試行、リダイレクト、重みベースのトラフィック分割などのアクションも適用できます。フォールト インジェクション、トラフィック ミラーリング、外れ値検出などの高度なパターンを使用すると、DevOps のユースケースで復元性が向上します。
オブザーバビリティ
アプリケーション ネットワーキング インフラストラクチャは、指標、ログ、トレースなど、Google Cloud Observability に集約できるテレメトリー情報を収集します。収集された情報により、知見の獲得やアラートの作成が可能になり、何か問題が発生した場合に通知を受け取れます。
VPC Service Controls
VPC Service Controls を使用すると、アプリケーションのリソースとサービスのセキュリティを強化できます。境界の外部から発生するリクエストからリソースとサービス（Cloud Service Mesh など）を保護するサービス境界にプロジェクトを追加できます。VPC Service Controls の詳細については、VPC Service Controls の概要をご覧ください。
VPC Service Controls で Cloud Service Mesh を使用する方法については、サポートされているプロダクトをご覧ください。
次のステップ
これは、主にロード バランシング API に適用されるレガシー ドキュメントです。ロード バランシング API を使用して Cloud Service Mesh を構成しないことを強くおすすめします。
Cloud Service Mesh をデプロイするには:
- Compute Engine と VM の場合は、サービス ルーティング API を使用します。
- Google Kubernetes Engine と Pod の場合は、Gateway API を使用します。
プロキシレス gRPC サービスのユースケースとアーキテクチャ パターンを確認するには、プロキシレス gRPC サービスの概要をご覧ください。
トラフィック管理でトラフィックの処理方法を制御する方法については、高度なトラフィック管理の概要をご覧ください。
Cloud Service Mesh が Google Cloud の外部に拡張された環境をサポートする方法について詳細は、次のドキュメントをご覧ください。