プロキシレス gRPC サービスを備えた Cloud Service Mesh の概要

このガイドでは、ユースケースとアーキテクチャ パターンなど、プロキシレス gRPC サービスを備えた Cloud Service Mesh のアーキテクチャの概要について説明します。

注: このガイドは、Google Cloud APIs を使用する Cloud Service Mesh のみに対応しており、Istio API には対応していません。詳細については、Cloud Service Mesh の概要をご覧ください。

Cloud Service Mesh のマネージド コントロール プレーンは、サービス メッシュとロード バランシングのユースケースでグローバル ルーティング、ロード バランシング、リージョン フェイルオーバーを実現します。これには、サイドカー プロキシとゲートウェイ プロキシを統合するデプロイメントが含まれます。プロキシレス gRPC アプリケーションの Cloud Service Mesh サポートは、サイドカー プロキシを必要とせずに gRPC アプリケーションがサービス メッシュに参加できる追加のデプロイモデルを提供します。

一般的な例では、gRPC クライアントはバックエンド ロジックをホストする gRPC サーバーと接続を確立します。Cloud Service Mesh は、接続するサーバー、サーバーの複数のインスタンスに負荷分散する方法、サーバーが実行されていない状態でリクエストを処理する方法に関する情報を gRPC クライアントに提供します。

Cloud Service Mesh の仕組みの概要については、Cloud Service Mesh の概要をご覧ください。

gRPC アプリケーションでの Cloud Service Mesh の仕組み

Cloud Service Mesh は、Envoy などのサイドカー プロキシの構成方法と同様に、サポートされている gRPC バージョンを使用して gRPC クライアントを構成します。ただし、Cloud Service Mesh に直接接続されたプロキシレス gRPC アプリケーションの場合、サイドカー プロキシは必要ありません。Cloud Service Mesh はオープンソースの xDS API を使用して gRPC アプリケーションを直接構成します。これらの gRPC アプリケーションは、xDS クライアントとして機能し、Cloud Service Mesh のグローバル コントロール プレーンに接続します。接続後、gRPC アプリケーションは、コントロール プレーンから動的構成を受け取り、エンドポイントの検出、負荷分散、リージョン フェイルオーバー、ヘルスチェックを有効にします。このアプローチにより、Cloud Service Mesh のデプロイ パターンの追加が可能になります。

最初の図では、サイドカー プロキシを使用することでサービス メッシュが有効になっています。

サイドカー プロキシを使用して有効になっているサービス メッシュ（クリックして拡大）

サイドカー プロキシを構成するため、Cloud Service Mesh は xDS API を使用します。クライアントはサイドカー プロキシを介してサーバーと通信します。

2 つ目の図では、プロキシレス gRPC クライアントを使用し、サイドカー プロキシなしでサービス メッシュが有効になっています。

プロキシレス gRPC を使用して有効になっているサービス メッシュ（クリックして拡大）

Cloud Service Mesh が構成する gRPC サービスのみをデプロイする場合は、プロキシをまったくデプロイせずにサービス メッシュを作成できます。これにより、サービス メッシュ機能を gRPC アプリケーションに簡単に導入できます。

名前解決

プロキシレス デプロイでの名前解決は次のように機能します。

1. サービスに接続するときに、gRPC クライアント チャネルで名前解決スキームとして xds を設定します。ターゲット URI の形式は xds:///hostname:port です。ポートを指定しないと、たとえば、ターゲット URI が xds:///example.hostname の場合、デフォルト値は 80 になります。
2. gRPC クライアントは、リスナー検出サービス（LDS） リクエストを Cloud Service Mesh に送信して、ターゲット URI の hostname:port を解決します。
3. Cloud Service Mesh は、一致するポートがある構成済みの転送ルールを検索します。次に、hostname:port に一致するホストルールに対応する URL マップを検索します。関連付けられたルーティング構成を gRPC クライアントに返します。

Cloud Service Mesh で構成するホストルールは、すべての URL マップで一意でなければなりません。たとえば、example.hostname、example.hostname:80、example.hostname:8080 はすべて異なるルールです。

異なるデプロイタイプでの名前解決

名前解決スキームは、プロキシレス デプロイと Envoy プロキシを使用するデプロイで異なります。

gRPC クライアントは xds 名前解決スキームを使用してサービスに接続することで、Cloud Service Mesh からサービス構成を受信します。gRPC クライアントは gRPC サーバーと直接通信します。

サイドカー プロキシとプロキシレス デプロイのパターンを組み合わせて、柔軟性を高めることができます。組み合わせのパターンは、組織やネットワークが複数の機能要件、運用ニーズ、gRPC のバージョンで複数のチームをサポートしている場合は、特に便利です。

次の図では、プロキシレス gRPC クライアントと、サイドカー プロキシを使用する gRPC クライアントの両方が gRPC サーバーと通信しています。サイドカー プロキシを使用する gRPC クライアントでは、dns 名前解決スキームを使用します。

プロキシレス gRPC クライアントとサイドカー プロキシを使用する gRPC クライアントで構成されるサービス メッシュ（クリックして拡大）

ユースケース

以下のユースケースは、Cloud Service Mesh をプロキシレス gRPC アプリケーションで使用するケースを理解する際に役立ちます。デプロイメントには、プロキシレス gRPC アプリケーション、サイドカー プロキシがある gRPC アプリケーション、またはその両方を組み合わせたものが含まれる可能性があります。

大規模なサービス メッシュ内のリソースの効率性

サービス メッシュに数百または数千のクライアントとバックエンドが含まれている場合、サイドカー プロキシの実行によりリソースの全体的な使用量が増加することがあります。プロキシレス gRPC アプリケーションを使用する場合、デプロイにサイドカー プロキシを導入する必要はありません。プロキシレスのアプローチにより、効率が上がります。

高性能な gRPC アプリケーション

一部のユースケースでは、リクエストとレスポンスのレイテンシが 1 ミリ秒でも問題になる場合があります。このような場合、クライアント側のサイドカー プロキシ（場合によってはサーバー側のサイドカー プロキシ）を介してすべてのリクエストを渡す代わりに、プロキシレス gRPC アプリケーションを使用すると、レイテンシを短縮できる場合があります。

サイドカー プロキシをデプロイできない環境のサービス メッシュ

環境によっては、クライアント アプリケーションまたはサーバー アプリケーションとともに、サイドカー プロキシを追加のプロセスとして実行できないことがあります。また、iptables の使用などにより、リクエストのインターセプトとリダイレクトを行うマシンのネットワーク スタックを構成できない場合があります。この場合、プロキシレス gRPC アプリケーションの Cloud Service Mesh を使用することで、サービス メッシュ機能を gRPC アプリケーションに導入できます。

異種混合サービス メッシュ

プロキシレス gRPC アプリケーションと Envoy の両方が Cloud Service Mesh と通信するため、サービス メッシュには両方のデプロイモデルを含めることができます。両方のモデルを含めると、異なるアプリケーションや開発チームに固有の運用、パフォーマンス、機能ニーズに対応できます。

プロキシを使用するサービス メッシュからプロキシを使用しないメッシュへの移行

Cloud Service Mesh が構成したサイドカー プロキシを使用した gRPC アプリケーションがすでにある場合は、プロキシレス gRPC アプリケーションに移行できます。

gRPC クライアントがサイドカー プロキシでデプロイされると、DNS を使用して接続先ホスト名を解決します。サイドカー プロキシはトラフィックをインターセプトして、サービス メッシュ機能を提供します。

gRPC クライアントが gRPC サーバーと通信するためにプロキシレス ルートとサイドカー プロキシ ルートのどちらを使用するのかは、使用する名前解決スキームを変更することで定義できます。プロキシレス クライアントは xds 名前解決スキームを使用し、サイドカー プロキシは dns 名前解決スキームを使用します。一部の gRPC クライアントでは、ある gRPC サーバーと通信する場合にはプロキシレス ルートを使用し、別の gRPC サーバーと通信する場合はサイドカー プロキシ ルートを使用することもあります。これにより、プロキシレス デプロイに段階的に移行できます。

プロキシを使用するサービス メッシュからプロキシなしのメッシュに移行するには、プロキシレス gRPC クライアントが使用する新しい Cloud Service Mesh サービスを作成します。同じ API を使用して、既存のバージョンと新しいバージョンに Cloud Service Mesh を構成できます。

プロキシレスとプロキシベースのメカニズムを使用して異なるサービスと通信する gRPC クライアントのサービス メッシュ（クリックして拡大）

アーキテクチャとリソース

プロキシレス gRPC サービスの構成データモデルは Cloud Service Mesh 構成モデルを拡張したもので、このガイドで説明している追加事項と制限事項が適用されます。この制限は一時的なものです。プロキシレス gRPC はまだ Envoy のすべての機能をサポートしているわけではありません。また、RPC 固有の機能もあります。たとえば、gRPC を使用する HTTP リダイレクトはサポートされません。このガイドの構成モデルを理解するには、Cloud Service Mesh のコンセプトと構成をよく理解しておくことをおすすめします。

次の図は、プロキシレス gRPC アプリケーション用に構成する必要があるリソースを示しています。

ロード バランシング用にプロキシレス gRPC でサポートされているリソース（クリックして拡大）

注: 一部の Cloud Service Mesh 機能は、プロキシレス gRPC アプリケーションではまだサポートされていません。詳細については、機能ページをご覧ください。サポートされていない機能が必要な場合は、Envoy を gRPC アプリケーションで使用できます。通常、Envoy を使用する gRPC アプリケーションの Cloud Service Mesh の構成は、以降のセクションで説明する構成データモデルに従います。

ヘルスチェック

gRPC ヘルスチェックでは、バックエンド仮想マシン（VM）インスタンスまたはネットワーク エンドポイント グループ（NEG）で実行されている gRPC サービスのステータスを確認できます。

gRPC サーバーが gRPC ヘルスチェック プロトコルを実装していないために gRPC ヘルスチェックを使用できない場合は、代わりに TCP ヘルスチェックを使用できます。HTTP、HTTPS、HTTP/2 ヘルスチェックは使用しません。

詳しくは、gRPC ヘルスチェックと gRPC ヘルスチェックの追加フラグをご覧ください。

バックエンド サービス

バックエンド サービスは、gRPC クライアントが gRPC サーバーと通信する方法を定義します。gRPC のバックエンド サービスを作成する場合は、プロトコル フィールドを GRPC に設定します。

• プロトコルが GRPC に構成されたバックエンド サービスには、サイドカー プロキシを介して gRPC アプリケーションからアクセスできます。その場合は、gRPC クライアントで xds 名前解決スキームを使用しないでください。

• Cloud Service Mesh のすべてのデプロイで、バックエンド サービスのロード バランシング スキームを INTERNAL_SELF_MANAGED にする必要があります。

バックエンド

バックエンドは gRPC サーバー インスタンスをホストします。Compute Engine では、gRPC サーバー インスタンスをホストするバックエンドとしてマネージド インスタンス グループまたは非マネージド インスタンス グループを使用できます。Google Kubernetes Engine ではゾーン NEG を使用できます。

次のステップ

• サービス ルーティング API とその仕組みについては、概要をご覧ください。
• プロキシレス gRPC アプリケーションで Cloud Service Mesh を構成する準備を行うには、プロキシレス gRPC サービスを使用した Cloud Service Mesh の設定を準備するをご覧ください。
• プロキシレス gRPC デプロイメントに適用される制限については、プロキシレス gRPC の上限と制限事項をご覧ください。