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 が us-central1 と europe-west1 にある Kubernetes クラスタのコントロール プレーンを提供しています。リクエストは、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 ベースのワークロードを相互運用できます。
次の図では、トラフィックが外部アプリケーション ロードバランサを通じてデプロイに到達します。そのトラフィックは、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の外部に拡張された環境をサポートする方法については、次のドキュメントをご覧ください。