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

Traffic Director は、サービスとエンドポイントを見つける機能を提供します。これにより、サービスのエンドポイントとしてコードを実行する VM とコンテナをグループ化できます。Traffic Director はこれらのサービスを監視し、クライアントに最新の情報を提供します。そのため、あるアプリケーションが Envoy サイドカー プロキシなどの Traffic Director クライアントを使用してリクエストを送信すると、サービスの最新情報が得られます。

Traffic Director の観点では、クライアントは VM またはコンテナ上で実行されるアプリケーション コードであり、サーバーに送信するリクエストを作ります。サーバーは、このようなリクエストを受信するアプリケーション コードです。Traffic Director クライアントは、Envoy か gRPC、または他の xDS クライアントで、Traffic Director に接続され、データプレーンの一部です。

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

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

Service Discovery

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.example.compayments サービスを指す)を含むルーティング ルール マップを構成しました。

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

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

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

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

サービスを作成する際には、そのサービスのバックエンドも指定します。それは、マネージド インスタンス グループ(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)は、VIP 10.0.0.1:80 に構成されています。そこで Traffic Director によって検出、負荷分散されます。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 トラフィックをプロキシします。