Traffic Director の概要

オープン サービス メッシュ用 Traffic Director

サービス メッシュは、マイクロサービスなどの最新アプリケーションのデプロイにおいて普及しつつあります。サービス メッシュでは、データプレーンが Envoy などのサービス プロキシを使用してトラフィック フローを制御し、サービス メッシュのコントロール プレーンがポリシー、構成、情報をサイドカー プロキシに提供します。

コントロール プレーンとしてのサービス メッシュ(クリックで拡大)
コントロール プレーンとしてのサービス メッシュ(クリックして拡大)

サービス メッシュを使用すると、サービスを実行するために作成して保守する必要があるネットワーク コードの量が減少します。代わりに、サイドカー プロキシがビジネス ロジックとともにネットワーク機能を実行します。サイドカー プロキシを管理するには、サービス コントロール プレーンが必要です。

Traffic Director は、Google Cloud のサービス メッシュ用フルマネージド トラフィック コントロール プレーンです。Traffic Director を使用すると、複数のリージョンのクラスタと VM インスタンスにグローバル負荷分散を簡単にデプロイし、サイドカー プロキシからヘルスチェックをオフロードできます。Traffic Director はオープン標準 API(xDS v2)を使用してデータプレーン内のサイドカー プロキシと通信し、これにより選択したサービス メッシュのデータプレーンを使用できるようになります。

マイクロサービス環境におけるコントロール プレーンとしての Traffic Director(クリックで拡大)
マイクロサービス環境におけるコントロール プレーンとしての Traffic Director(クリックして拡大)

Traffic Director の機能

Traffic Director は次の特長を備えています。

  • Envoy などのオープン標準(xDS v2)サイドカー プロキシ向けに、Google Cloud で管理されるトラフィック管理コントロール プレーン。
  • マネージド インスタンス グループまたは非マネージド インスタンス グループネットワーク エンドポイント グループを使用するコンテナ インスタンスで実行され Traffic Director によって管理される VM サービスのインスタンスをデプロイできる機能。
  • トラフィック管理
  • エンドポイント向けのサービス ディスカバリ
  • グローバル負荷分散。1 つのサービス IP アドレスを使用して複数のリージョンにサービスをデプロイできます。
  • 需要に合わせた自動スケーリング
  • リクエストのルーティングとトラフィック ポリシー
  • 大規模なヘルスチェック
  • 可観測性

Traffic Director と Istio

Istio は、マイクロサービスを保護、接続、および監視するコントロール プレーンを提供します。これには、トラフィック管理のための Pilot、可観測性のための Mixer、サービス間セキュリティのための Istio Security という 3 つの要素があります。

Traffic Director は、Google Cloud によって管理される Pilot に加えて、グローバル負荷分散や一元管理のヘルスチェックなどの機能を備えています。ただし、Traffic Director は Istio API を使用して構成できません。構成には GCP API を使用します。Traffic Director と Pilot はどちらも、オープン標準 API(xDS v2)を使用してサイドカー プロキシと通信します。

Traffic Director によるグローバルな負荷分散

Traffic Director は、サイドカー プロキシを使用して内部マイクロサービスのグローバルな負荷分散を実現します。複数のリージョンにインスタンスを持つ内部マイクロサービス(サイドカー プロキシベース)をデプロイできます。 Traffic Director は、サイドカー プロキシにヘルス、ルーティング、バックエンドの情報を提供し、サイドカー プロキシがサービスの複数のクラウド リージョン内に存在するアプリケーション インスタンスに対する最適なトラフィックのルーティングを実行できるようにします。

次の図では、ユーザー トラフィックは外部のグローバル ロードバランサを介して Google Cloud デプロイに入ります。外部ロードバランサは、エンドユーザーの場所に応じて、us-central1 または asia-southeast1 のいずれかでフロントエンド マイクロサービスにトラフィックを分散します。

内部デプロイは、Frontend、Shopping Cart、Payments という 3 つのグローバル マイクロサービスを備えています。各サービスは、us-central1asia-southeast1 の 2 つのリージョンのマネージド インスタンス グループで実行されます。Traffic Director はグローバル負荷分散アルゴリズムを使用して、カリフォルニア州のユーザーからのトラフィックを us-central1 にデプロイされたマイクロサービスに転送し、シンガポールのユーザーからのリクエストを asia-southeast1 のマイクロサービスに転送します。

受信したユーザー リクエストは Frontend マイクロサービスにルーティングされます。その後 Frontend とともにホストにインストールされているサービス プロキシが、トラフィックを Shopping Cart に転送します。Shopping Cart とともにホストにインストールされているサイドカー プロキシが、トラフィックを Payments マイクロサービスに転送します。

グローバルな負荷分散のデプロイ(クリックして拡大)
グローバルな負荷分散のデプロイにおける Traffic Director(クリックして拡大)

次の例では、us-central1 でShopping Cart マイクロサービスを実行している VM が異常であることを示すヘルスチェック結果を受け取った場合、Traffic Director は Frontend マイクロサービスのサービス プロキシに、asia-southeast1 で実行中の Shopping Cart マイクロサービスにトラフィックをフェイルオーバーするよう指示します。自動スケーリングが Google Cloud のトラフィック管理と統合されているため、Traffic Director は追加のトラフィックの asia-southeast1 に存在するマネージド インスタンス グループに通知し、その結果マネージド インスタンス グループのサイズが増大します。

Traffic Director は、Payments マイクロサービスのすべてのバックエンドが正常であることを検出すると、Shopping Cart の Envoy プロキシに対して、お客様の構成み容量以内の範囲でトラフィックの一部を asia-southeast1 に送信し、残りを us-central1 にオーバーフローさせるよう指示します。

グローバルな負荷分散のデプロイにおける Traffic Director を使用したフェイルオーバー(クリックして拡大)
グローバルな負荷分散のデプロイにおける Traffic Director を使用したフェイルオーバー(クリックして拡大)

Traffic Director の負荷分散コンポーネント

Traffic Director のセットアップ中に、いくつかの負荷分散コンポーネントを構成します。

  • VIP アドレス、ターゲット プロキシ、URL マップを含むグローバル転送ルール。これらはすべて Traffic Director のトラフィック ルーティング メカニズムの一部です。ターゲット プロキシはターゲット HTTP プロキシであることが必要です。
  • バックエンド サービス。構成値が含まれます。
  • ヘルスチェック。デプロイ内の VM とポッドのヘルスチェックを行います。

次の図は、Compute Engine VM または Google Kubernetes Engine のポッドで実行されているアプリケーション、Traffic Director のデプロイにおけるコンポーネントとトラフィックフローを示しています。

構成する Traffic Director リソース(クリックで拡大)
構成する Traffic Director のリソース(クリックして拡大)

この図は Traffic Director と、トラフィック ルーティングを決定するために使用するGoogle Cloud 負荷分散リソースを示しています。xDS API 互換サイドカー プロキシ(上記の Envoy など)は、クライアント VM インスタンスまたは Kubernetes ポッドで実行されます。Traffic Director はコントロール プレーンとして機能し、xDS API を使用して各プロキシと直接通信します。データプレーンでは、アプリケーションは Google Cloud 転送ルールで構成された VIP アドレスにトラフィックを送信します。トラフィックはサイドカー プロキシによってインターセプトされ、適切なバックエンド サービスにリダイレクトされます。次のセクションでは、トラフィック インターセプトと負荷分散について詳しく説明します。

サービス ディスカバリ

Traffic Director は、VM エンドポイントとコンテナ エンドポイントの両方を対象にサービス ディスカバリを提供します。サービス エンドポイントは、VM のマネージド インスタンス グループ(MIG)またはコンテナのネットワーク エンドポイント グループ(NEG)に追加できます。これらのサービス エンドポイントはサービス名に関連付けられています。Traffic Director はサービスのサービス ディスカバリを提供します。これは、ホスト名をクライアントからターゲット サービス名にマッピングし、負荷分散を行いサービス名のエンドポイントのヘルスチェックを実施することによって実現します。

Traffic Director サービス ディスカバリ(クリックして拡大)
Traffic Director サービス ディスカバリ(クリックして拡大)

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

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

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

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

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

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

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

この図におけるトラフィック フローは次のとおりです。

  1. アプリケーションはサービス Web にトラフィックを送信し、このサービスは IP アドレス 10.0.0.1, TCP:80 に解決されます。
  2. 10.0.0.1 TCP:80 を宛先とするトラフィックが IP アドレス 127.0.0.1 TCP:15001 にリダイレクトされるように、ホストの netfilter が構成されます。
  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 は Google Cloud APIs のみをサポートしています。Traffic Director は Istio API をサポートしていません。
  • Traffic Director は HTTP(HTTP/1.1 または HTTP/2)と gRPC トラフィックでのみサポートされています。
  • Traffic Director は共有 VPC をサポートしています。次の点に留意してください。
    • 転送ルールとそれに関連付けられたターゲット プロキシ、URL マップ、バックエンド サービス、バックエンドは、単一のプロジェクト(ホストまたはサービス プロジェクト)に存在する必要があります。複数のサービス プロジェクトがある場合は、各サービス プロジェクトにこれらのリソースの独自のセットを配置できます。
    • デフォルトでは、共有 VPC ネットワークを参照する転送ルールは、ホストとホスト プロジェクトに接続されたサービス プロジェクトに存在するすべての Envoy プロキシに対してアドバタイズされます。ただし、これらのプロキシが、ブートストラップまたは sidecar.env ファイルで共有 VPC ネットワークを指定する必要があります。この動作は、構成フィルタリングを使用して調整できます。
    • Traffic Director にアクセスできるのは、共有 VPC ネットワークに関連付けられた負荷分散スキーム INTERNAL_SELF_MANAGED を持つ転送ルールを少なくとも 1 つ含むプロジェクトのサービス アカウントのみです。
  • Traffic Director は VPC ネットワーク ピアリングをサポートしていません。
  • Traffic Director は、VPC ネットワーク内に存在し、名前が転送ルールで指定されたクライアントに対してのみ負荷分散をサポートします。
  • Traffic Director のバックエンド VM またはエンドポイントはすべて、クライアントと同じ VPC ネットワーク内に配置する必要があります。
  • Knative または Google Cloud のサーバーレス コンピューティングで実行されているサービスでは Traffic Director を使用できません。
  • Google Cloud で実行されているサービスにのみ、Traffic Director を使用して接続します。
  • このリリースでは、Traffic Director を使用した Google Cloud エンドポイントのみを構成できます。オンプレミスまたは別のクラウドのエンドポイントはサポートされていません。
  • このリリースでは、Traffic Director を使用して Google Cloud バックエンド VM または NEG のエンドポイントのみを構成できます。オンプレミスまたは別のクラウドの VM あるいはエンドポイントはサポートされていません。
  • このドキュメントでは Envoy プロキシについて説明しますが、Traffic Director では任意のオープン標準 API(xDS v2)プロキシを使用できます。ただし、Google では Traffic Director のテストについては、Envoy プロキシでのみ実施しています。
  • Traffic Director と連携するには、Envoy がバージョン 1.9.1 以降であることが必要です。
  • 既知のすべてのセキュリティに関する脆弱性が軽減されていることから、最新の Envoy バージョンを使用することを強くおすすめします。
  • Envoy のセキュリティ アドバイザリについては、Envoy のセキュリティ アドバイザリをご覧ください。

次のステップ