プロキシレス gRPC サービスを使用した Traffic Director の概要

このガイドでは、ユースケースとアーキテクチャ パターンなど、プロキシレス gRPC サービスを備えた Traffic Director のアーキテクチャの概要について説明します。このガイドでは、以前の Traffic Director API を対象としています。サービス ルーティング API の詳細については、概要をご覧ください。

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

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

Traffic Director の機能の概要については、Traffic Director の概要をご覧ください。

gRPC アプリケーションでの Traffic Director の仕組み

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

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

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

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

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

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

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

名前解決スキーム

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

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

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

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

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

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

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

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

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

ユースケース

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

負荷分散用にプロキシレス gRPC でサポートされているリソース。
負荷分散用にプロキシレス gRPC でサポートされているリソース（クリックして拡大）

ルーティング ルール マップ

ルーティング ルール マップは、メッシュでのリクエストのルーティング方法を定義します。これは、転送ルール、ターゲット gRPC プロキシ、URL マップで構成されています。ルーティング ルール マップは、ロード バランシング API を使用するデプロイにのみ適用されます。サービス ルーティング API または Gateway API を使用する場合は適用されません。

転送ルール

通常、転送ルールは、構成するサービスの仮想 IP アドレスとポートを使用して作成します。xds 名前解決スキームを使用する gRPC クライアントでは、チャネル URI のホスト名を解決するための DNS ルックアップは実行しません。このようなクライアントは、Traffic Director に LDS リクエストを送信して、ターゲット URI にある hostname[:port] を解決します。DNS ルックアップは実行されず、ホスト名の DNS エントリも不要です。

その結果、Traffic Director は IP アドレスを無視し、URI で指定されたポートのみで転送ルールを検索します。ポートのデフォルト値は 80 です。次に、Traffic Director は、転送ルールのターゲット プロキシに関連付けられている URL マップを参照して、一致するホストルールを探します。

したがって、転送ルールで、validateForProxyless フィールドが TRUE に設定されているターゲット gRPC プロキシを参照する場合は、IP アドレスを 0.0.0.0 に設定する必要があります。validateForProxyless が TRUE に設定されている場合、0.0.0.0 以外の IP アドレスを指定する構成は拒否されます。このチェックでは、他のルーティング ルールマップで同じポートを使用する、重複する転送ルールは検出されません。

次の点にご注意ください。

  • 転送ルールの負荷分散スキームは INTERNAL_SELF_MANAGED にする必要があります。
  • 転送ルールは複数所有できますが、各転送ルールの IP:port は一意でなければならず、ポートはホストルールで指定されたポートと一致する必要があります。
  • ターゲット URI のポートと一致するポートが複数の転送ルールにある場合、Traffic Director は、これらの転送ルールによって参照されている URL マップのホストルールで、一致する hostname[:port] を探します。Traffic Director は、ホストルールの hostname[:port] とターゲット URI で指定された hostname[:port] との完全一致を探します。ワイルドカード文字を含むホストルールとデフォルト ルールはスキップされます。

複数の一致が見つかった場合、動作は定義されておらず、予期しない動作が発生する可能性があります。通常、これは、次の両方の条件が満たされている場合に行われます。

  • 同じホスト名が複数の URL マップで使用されている。
  • ロード バランシング スキーム INTERNAL_SELF_MANAGED の複数の転送ルールで同じポートを指定している。

そのため、同じポートを指定する転送ルールで参照される複数の URL マップでは、同じホスト名を再利用しないことをおすすめします。

ターゲット gRPC プロキシ

ターゲット プロキシは URL マップを参照します。このマップには、トラフィックを正しいバックエンドにルーティングするために使用するルールが定義されています。gRPC アプリケーションに Traffic Director を構成する場合は、プロキシレス gRPC アプリケーションか、Envoy を使用する gRPC アプリケーションかに関係なく、ターゲット gRPC プロキシを使用します。ターゲット HTTP プロキシは使用しません。

ターゲット gRPC プロキシには、REST API の validateForProxyless というフィールドがあります。デフォルト値は FALSE です。このフィールドを TRUE に設定すると、構成チェックにより、プロキシレス gRPC と互換性のない機能の誤った有効化を防ぐことができます。

Google Cloud CLI の --validate-for-proxyless フラグは、validateForProxyless フィールドと同じです。

プロキシレス gRPC アプリケーションに対する Traffic Director のサポートには、サイドカー プロキシの gRPC アプリケーションで使用できるすべての機能が含まれないため、このフィールドを使用して無効な構成を拒否できます（この構成は URL マップまたはバックエンド サービス内で指定される場合があります）。構成の検証は、Traffic Director がサポートする gRPC の最新バージョンでサポートされている機能に基づいて行われます。

URL マップ

URL マップには、プロキシレス gRPC クライアントがトラフィックの送信に使用するルーティング ルールを定義します。URL マップには、hostname:port の形式の 1 つ以上のホストルールが含まれます。これらのホストルールはサービスに解決されます。

gRPC クライアントを構成するときは、クライアントが接続するサービスのターゲット URI を指定します。この URI は hostname:port 形式も使用します。この URI は、URL マップのホストルールのエントリに対応します。

たとえば、gRPC クライアントでターゲット URI xds:///myservice:8080 を構成した場合、Traffic Director は myservice:8080 の URL マップのホストルールに対応する構成を送信します。この構成には、その他の情報以外に、エンドポイントのリスト（特に、特定の gRPC サーバー インスタンスに対応する IP address:port ペア）が含まれています。

ターゲット URI にポートを指定しない場合は、80 がデフォルト値として使用されます。これは、次のことを意味します。

  • ターゲット URI xds:///myservice が URL マップのホストルール myservice と一致する。
  • ターゲット URI xds:///myservice:80 が URL マップのホストルール myservice:80 と一致する。
  • ターゲット URI xds:///myservice が URL マップのホストルール myservice:80 と一致しない。
  • ターゲット URI xds:///myservice:80 が URL マップのホストルール myservice と一致しない。

ターゲット URI の文字列と URL マップのホストルール内の文字列は同じである必要があります。

詳細については、URL マップの制限をご覧ください。

ヘルスチェック

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

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

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

バックエンド サービス

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

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

  • Traffic Director のすべてのデプロイで、バックエンド サービスの負荷分散スキームを INTERNAL_SELF_MANAGED にする必要があります。

バックエンド

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

次のステップ