Traffic Director サービス ディスカバリ

Traffic Director は、サービスとエンドポイントのディスカバリを行います。これらの機能を使用すると、コードをサービスのエンドポイントとして実行する仮想マシン(VM)インスタンスとコンテナ インスタンスをグループ化できます。

Traffic Director はこれらのサービスを監視し、クライアントに最新の情報を提供します。そのため、いずれかのアプリケーションが Traffic Director クライアント(Envoy サイドカー プロキシなど)を使用してリクエストを送信することで、サービスの最新情報を利用できます。

Traffic Director のコンテキストでは、クライアントは VM またはコンテナ上で動作するアプリケーション コードで、サーバーへ送信するリクエストを作成します。サーバーは、このようなリクエストを受信するアプリケーション コードです。Traffic Director のクライアントとは、Traffic Director に接続される Envoy や gRPC などの xDS クライアントで、データプレーンの一部になります。

データプレーンでは、Envoy や gRPC は次の処理を行います。

  1. リクエストを調べ、そのリクエストをバックエンド サービス(デプロイ時に構成したリソース)に一致させます。
  2. リクエストが一致すると、Envoy または gRPC は、バックエンドまたはエンドポイントを選択し、そのバックエンドまたはエンドポイントにリクエストを転送します。

サービス ディスカバリ

Traffic Director は、サービス ディスカバリを行います。Traffic Director を構成するときに、バックエンド サービスを作成します。また、送信リクエスト(アプリケーション コードから送信され Traffic Director クライアントで処理されるリクエスト)を特定のサービスと照合する方法を指定するルーティング ルールも定義します。そのため、Traffic Director クライアントは、ルールと一致するリクエストを処理するときに、リクエストを受信するサービスを選択できます。

例:

  • アプリケーションが動いている VM があるとします。この VM には Envoy サイドカー プロキシがあり、Traffic Director に接続されており、アプリケーションに代わって送信リクエストを処理しています。
  • バックエンド サービスは、payments という名前で構成しました。このバックエンド サービスには 2 つのネットワーク エンドポイント グループ(NEG)バックエンドがあり、payments サービスのコードを実行するさまざまなコンテナ インスタンスを指しています。
  • 転送ルール(IP アドレス 0.0.0.0、ポート 80 を例として使用)、ターゲット プロキシ、URL マップ(payments サービスを指すホスト名 payments.example.com を例として使用)を含むルーティング ルール マップを構成しました。

この構成を使用して、(VM 上の)アプリケーションが HTTP リクエストをポート 80payments.example.com に送信すると、Traffic Director クライアントは、このリクエストは payments サービスに向けられたものだということを認識します。

Traffic Director をプロキシレス gRPC サービスで使用する場合、サービス ディスカバリは同じように機能します。ただし、gRPC ライブラリは、Traffic Director クライアントとして機能し、xDS リゾルバを指定するサービスに関する情報のみを取得します。デフォルトでは、Envoy は、Envoy ブートストラップ ファイルに指定された Virtual Private Cloud(VPC)ネットワークで構成されているすべてのサービスに関する情報を取得します。

エンドポイント ディスカバリ

サービス ディスカバリを使用すると、クライアントがサービスを認識できます。エンドポイント ディスカバリを使用すると、クライアントはコードを実行しているインスタンスを認識できます。

サービスを作成する際には、そのサービスのバックエンドも指定します。これらのバックエンドは、マネージド インスタンス グループ(MIG)の VM または NEG のコンテナです。Traffic Director では、こうした MIG と NEG をモニタリングして、インスタンスとエンドポイントが作成および削除されるタイミングを認識します。

Traffic Director は、これらのサービスに関する最新情報を継続的にクライアントと共有します。クライアントは、すでに存在しないエンドポイントに対するトラフィックの送信を避けることができます。また、新しいエンドポイントを認識し、そのエンドポイントが提供する追加の容量を利用できます。

上述の例では、Traffic Director は MIG-1 の 2 つの正常なエンドポイントと、サービス shopping-cart の MIG-2 に存在する 3 つの正常なエンドポイントを返します。MIG または NEG にエンドポイントを追加し、Traffic Director を設定する以外に、Traffic Director でサービス ディスカバリを有効にするための追加構成は必要ありません。

Traffic Director でのサイドカー プロキシによるトラフィック インターセプト

Traffic Director では、サイドカー プロキシ モデルをサポートしています。このモデルでは、アプリケーションがトラフィックを宛先に送信すると、iptables によってトラフィックがインターセプトされ、アプリケーションが実行されているホスト上のサイドカー プロキシにリダイレクトされます。サイドカー プロキシでは、トラフィックの負荷分散方法が決定され、トラフィックは宛先に送信されます。

Traffic Director が正しく構成されていることを前提とする次の図では、Envoy がサイドカー プロキシです。サイドカー プロキシがアプリケーションと同じホストで実行されています。

Web というサンプル サービスは、Traffic Director によって検出、負荷分散される仮想 IP アドレス(VIP)10.0.0.1:80 で構成されています。Traffic Director は、VIP とポートを提供する転送ルール構成から設定を検出します。サービス Web のバックエンドは、構成され機能していますが、図では Compute Engine VM ホストの外側にあります。

Traffic Director は、ホストからサービス Web に向かうトラフィックに最適なバックエンドは 192.168.0.1:80 であると判断します。

Traffic Director のホスト ネットワーキング。
Traffic Director のホスト ネットワーキング(クリックして拡大)

図のトラフィックの流れは次のとおりです。

  1. アプリケーションはサービス Web にトラフィックを送信し、このサービスは IP アドレス 10.0.0.1:80 に解決されます。
  2. ホストの Netfilter は、10.0.0.1:80 宛てのトラフィックが 10.0.0.1:15001 にリダイレクトされるように構成されています。
  3. トラフィックは、Envoy プロキシのインターセプト ポートである 127.0.0.1:15001 にリダイレクトされます。
  4. 127.0.0.1:15001 の Envoy プロキシのインターセプト リスナーがトラフィックを受信し、リクエストの元の宛先(10.0.0.1:80)を検索します。この検索により、Traffic Director によってプログラムされたとおり、最適なバックエンドとして 192.168.0.1:8080 が選択されます。
  5. Envoy は、ネットワーク経由で 192.168.0.1:8080 との接続を確立し、接続が終了するまでアプリケーションとこのバックエンドの間で HTTP トラフィックをプロキシします。

次のステップ

  • Traffic Director がサイドカー プロキシを使用して内部マイクロサービスのグローバルな負荷分散を行う方法については、Traffic Director の負荷分散をご覧ください。
  • Traffic Director の詳細については、Traffic Director の概要をご覧ください。