Traffic Director のターゲット プロキシ

Traffic Director を構成すると、構成するリソースの 1 つがターゲット プロキシになります。

Traffic Director の観点では、ターゲット プロキシは主に次の 2 つの目的で使用されます。

  1. 特定のタイプを持つ。このタイプは、Traffic Director クライアントが、サービスに関連付けられたバックエンド / エンドポイントへの接続を確立するときに、使用するプロトコルを認識するために使用されます。

  2. 他のリソース(転送ルールや URL マップなど)と組み合わせて、ルーティング ルール マップを作成する。ルーティング ルール マップは、ターゲット プロキシのタイプに応じて、追加のルーティング機能(ルーティング ルールなど)を提供します。通常、無効な選択肢は、ユーザー インターフェースに表示されないか、API によって拒否されます。

リクエスト プロトコル別の対応するターゲット プロキシ タイプ

Traffic Director は、構成しているターゲット プロキシのタイプに基づいて、クライアント向けに異なる構成を生成します。別のターゲット プロキシ タイプを構成すると、クライアントは特定のリクエスト プロトコルを使用します。

  • ターゲット HTTP プロキシ: Traffic Director のクライアントは、HTTP 接続を開始します。
  • ターゲット gRPC プロキシ: Traffic Director のクライアントは、gRPC 接続を開始します。
  • ターゲット TCP プロキシ: Traffic Director のクライアントは、TCP 接続を開始します。

1 つのタイプのみの選択に限定されるわけではありません。たとえば、あるサービスに対処するときに HTTP を使用する一方で、他のサービスに対処するときは TCP を使用する場合があります。そのようなユースケースでは、ターゲット HTTP プロキシとターゲット TCP プロキシの両方を作成する必要があります。

ルーティング ルール マップにおける有効なリソースの組み合わせ

構成ミスを回避するため、Traffic Director では、次のようなルーティング ルール マップのみ作成できます。

  • 転送ルール -> グローバル ターゲット HTTP プロキシ -> URL マップ ->(1 つ以上のバックエンド サービス)
  • 転送ルール -> グローバル ターゲット gRPC プロキシ -> URL マップ ->(1 つ以上のバックエンド サービス)
  • 転送ルール -> グローバル ターゲット TCP プロキシ -> (1 つのバックエンド サービス)

ヘルスチェックとバックエンド グループは上記のリストに含まれていません。

Google Cloud Console を使用してターゲット HTTP プロキシを設定する場合、ターゲット プロキシはルーティング ルール マップ構成の一部として暗黙的に設定されます。TCP プロキシの設定は、コンソールではまだサポートされていません。

gcloud コマンドライン インターフェースや API を使用する場合は、ターゲット プロキシを明示的に構成する必要があります。

ターゲット HTTP プロキシを使用する場合のトラフィック処理

HTTP ベースのサービスを構成すると、通常、各サービス インスタンスと一緒に Envoy プロキシがデプロイされます。この Envoy プロキシは、Traffic Director によって構成され、サービス メッシュ データプレーンの一部であり、次のようにしてトラフィックを処理します。

Envoy プロキシが送信リクエストを受け取り、リクエストの宛先 IP とポートを、ターゲット HTTP プロキシを参照する各転送ルールに構成された IP およびポートと比較します。一致するものが見つかると、Envoy プロキシは、ターゲット HTTP プロキシの対応する URL マップに従ってリクエストを評価します。

ターゲット TCP プロキシを使用する場合のトラフィック処理

TCP ベースのサービスを構成すると、通常、各サービス インスタンスと一緒に Envoy プロキシがデプロイされます。この Envoy プロキシは、Traffic Director によって構成され、サービス メッシュ データプレーンの一部であり、次のようにしてトラフィックを処理します。

Envoy プロキシが送信リクエストを受け取り、リクエストの宛先 IP とポートを、ターゲット TCP プロキシを参照する各転送ルールに構成された IP およびポートと比較します。各転送ルールは、デフォルトのバックエンド サービスを指す TCP トラフィックをターゲット プロキシに転送します。このプロキシはヘルスチェックを指定し、適切なバックエンドを決定します。

ターゲット gRPC プロキシを使用する場合のトラフィック処理

gRPC ベースのサービスを構成すると、通常、サービス インスタンスと一緒に Envoy プロキシはデプロイされません。その代わり、gRPC ライブラリは Traffic Director によって構成され、サービス メッシュ データプレーンの一部として次のようにトラフィックを処理します。

gRPC ライブラリは、URI で指定された hostname[:port] と、ターゲット gRPC プロキシによって参照されるすべての URL マップのホストルールを比較します。一致するものが見つかると、gRPC ライブラリは、一致するホストルールに関連付けられたパスルールに従ってリクエストを評価します。

ゲートウェイと中間プロキシのトラフィック インターセプトを構成する

サービス メッシュには通常、次のものがあります。

  • サービス インスタンスには、それぞれ専用の Envoy サイドカー プロキシまたは gRPC ライブラリがあります。
    • Envoy を使用している場合は、サービス インスタンスが送信リクエストをインターセプトして Envoy プロキシへリダイレクトするように構成されています。
  • 送信リクエストは、Envoy プロキシか gRPC ライブラリが処理します。

また、Traffic Director を使用してゲートウェイや中間プロキシを構成することもできます。この設定では、Envoy プロキシはサービス インスタンスとは離れて存在しています。1 つのポートの受信リクエストをリッスンし、受信するとそれを処理します。

このタイプの設定では、インターセプトやリダイレクトを構成する必要はありません。代わりに、ターゲット HTTP プロキシで --proxy-bind フラグを有効にするだけで済みます。これにより、受信トラフィック インターセプトが構成され、Envoy プロキシが IP アドレスとポート(転送ルールで構成)で受信リクエストをリッスンするようになります。

一方、転送ルールはターゲット プロキシを参照しています。したがって、ターゲット HTTP プロキシで --proxy-bind を有効にすると、プロキシはこのターゲット HTTP プロキシを参照する転送ルールの IP アドレスとポートでリッスンします。

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

  • サービス メッシュに Traffic Director を使用する場合、通常はサイドカー プロキシが送信トラフィックを受信して転送するため、--proxy-bind を使用する必要はありません。
  • --proxy-bind フラグは、ターゲット gRPC プロキシには使用できません。

ターゲット プロキシのリソース

ターゲット プロキシの追加、削除、一覧表示、情報の取得には、REST API または gcloud SDK を使用します。

ただし、次の gcloud コマンドを使用してターゲット プロキシに関する情報を取得できます。

gcloud compute [target-http-proxies | target-tcp-proxies | target-grpc-proxies ] list
gcloud compute [target-http-proxies | target-tcp-proxies | target-grpc-proxies ] describe target-proxy-name

API

REST API でのターゲット プロキシ操作時に使用できるプロパティとメソッドについては、次のページをご覧ください。

gcloud SDK

gcloud コマンドライン ツールについては、次のページをご覧ください。

次のステップ

詳細情報