Traffic Director の概要

このドキュメントは、Traffic Director とその機能を把握する必要があるネットワーク管理者とサービス オーナーを対象としています。

Traffic Director は、アプリケーション ネットワーキングを対象とするマネージド コントロール プレーンです。Traffic Director を使用すると、トラフィック管理やオブザーバビリティなどの高度なアプリケーション ネットワーキング機能を備えた、グローバルで可用性の高いサービスを提供できます。

デプロイに含まれるサービスとマイクロサービスの数の増加するにつれ、次のようなアプリケーション ネットワーキングにおける共通の課題に直面します。

  • どのようにして、サービスの復元性を実現するか。
  • どのようにして、トラフィックをサービスへ向かわせるか。また、サービス同士をどのように認識させ、相互に通信させるか。
  • どのようにして、サービスが相互に通信しているときに起きたことを把握するか。
  • どのようにして、サービスを停止させることなく更新を行うか。
  • どのようにして、デプロイを実現するインフラストラクチャを管理するか。
サービスは相互に通信する必要があります。
サービスは相互に通信する必要がある(クリックして拡大)

Traffic Director を使用すると、現代的なサービスベースのデプロイにおける、こうした課題を解決できます。Traffic Director は Google Cloud が管理するインフラストラクチャを利用するため、独自のインフラストラクチャを管理する必要はありません。アプリケーションのネットワーキングの複雑な管理は Traffic Director に任せ、ビジネス上の課題を解決するアプリケーション コードの提供に専念します。

サービス メッシュ用 Traffic Director

アプリケーション ネットワーキングの課題を解決する共通のパターンは、サービス メッシュを使用することです。Traffic Director では、サービス メッシュだけでなく、ニーズに合った他のデプロイ パターンもサポートされています。

一般的なサービス メッシュ。
一般的なサービス メッシュ(クリックして拡大)

一般的なサービス メッシュの場合、以下のようになります。

  • サービスは、Kubernetes クラスタにデプロイします。
  • 各サービスの Pod には、サイドカー プロキシとして実行される専用のプロキシ(通常は Envoy)があります。
  • 各サイドカー プロキシは、クラスタにインストールされているネットワーキング インフラストラクチャ(コントロール プレーン)と通信します。コントロール プレーンは、サービス メッシュ内のサービス、エンドポイント、ポリシーについて、サイドカー プロキシに通知します。
  • Pod がリクエストを送信または受信すると、そのリクエストは Pod のサイドカー プロキシに入ります。サイドカー プロキシは、そのリクエストを目的の宛先に送信するなどの処理を行います。

このドキュメントと他の Traffic Director ドキュメント内の図では、プロキシはピンクの六角形のアイコンで表現されています。コントロール プレーンは各プロキシに接続され、プロキシがリクエストの処理に必要とする情報を提供します。ボックス間の矢印はトラフィックのフローを示します。たとえば、Service A のアプリケーション コードがリクエストを送信すると、プロキシがそのリクエストを処理して、Service B に転送します。

このモデルによって、ネットワーキングのロジックをアプリケーション コードの外に出せます。アプリケーション ネットワーキングの処理はインフラストラクチャに任せて、ビジネス価値の提供に専念できます。

Traffic Director の相違点

Traffic Director は上記のモデルと似ていますが、重要な違いがあります。まず、Traffic Director は、Google Cloud のマネージド サービスであるという事実が根本にあります。インストールせず、クラスタ内で実行されないため、メンテナンスする必要はありません。

下の図では、Traffic Director がコントロール プレーンです。この Kubernetes クラスタには 4 つのサービスがあり、それぞれ Traffic Director に接続されるサイドカー プロキシがあります。Traffic Director は、プロキシがリクエストを転送するために必要な情報を提供します。たとえば、Service A に属する Pod 上のアプリケーション コードがリクエストを送信すると、この Pod とともに稼働するサイドカー プロキシがリクエストを処理して、Service B に属する Pod に転送します。

Traffic Director を使用したサービス メッシュの例。
Traffic Director を使用したサービス メッシュの例(クリックして拡大)

サービス メッシュよりも豊富なサポート

Traffic Director では、一般的なサービス メッシュよりも多くのタイプのデプロイがサポートされます。

マルチクラスタ Kubernetes

Traffic Director を使用すると、Kubernetes クラスタ間で機能するアプリケーション ネットワーキングを利用できます。次の図では、Traffic Director が Kubernetes クラスタのコントロール プレーンを us-central1europe-west1 に提供しています。リクエストは、us-central1 の 3 つのサービス、europe-west1 の 2 つのサービス、2 つのクラスタのサービス間でルーティングできます。

Traffic Director を使用したマルチクラスタ Kubernetes の例
Traffic Director を使用したマルチクラスタ Kubernetes の例(クリックして拡大)

サービス メッシュを、複数の Google Cloud リージョンにある複数の Kubernetes クラスタにわたって拡張できます。クラスタ内のサービスが、別のクラスタ内のサービスと通信できます。さらに、複数のクラスタの Pod で構成されるサービスを使用することもできます。

Traffic Director の近接ベースのグローバル負荷分散を使用すると、Service B 宛のリクエストは、そのリクエストを処理できる最も近い Pod に送られます。また、フェイルオーバーはシームレスに行われます。Pod がダウンすると、その Pod が別の Kubernetes クラスタ内にある場合でも、リクエストに対応可能な別の Pod へ自動的にリクエストがフェイルオーバーされます。

仮想マシン

Kubernetes の人気が高まりつつありますが、多くのワークロードは仮想マシン(VM)にデプロイされています。Traffic Director は、こうしたワークロードに対するアプリケーション ネットワーキングも解決し、VM ベースのワークロードと Kubernetes ベースのワークロードの相互運用を容易にします。

次の図では、外部アプリケーション ロードバランサを通じてトラフィックが Deployment に到着します。そのトラフィックは、asia-southeast1 にある Kubernetes クラスタの Service A と、europe-west1 にある VM の Service D に転送されます。

Traffic Director を使用した VM と Kubernetes の例。
Traffic Director を使用した VM と Kubernetes の例(クリックして拡大)

Google は、Traffic Director を使用して VM ベースのワークロードを設定するシームレスなメカニズムを提供します。Compute Engine VM インスタンス テンプレートにフラグを追加するだけで、インフラストラクチャの設定を処理します。このセットアップには、アプリケーション ネットワーキング機能を提供するプロキシのインストールと構成が含まれます。

プロキシレス gRPC

gRPC は、機能豊富なオープンソースの RPC フレームワークです。これを使用して、高性能なマイクロサービスを作成できます。Traffic Director を使用すると、アプリケーション ネットワーキング機能(サービス ディスカバリ、負荷分散、トラフィック管理など)を gRPC アプリケーションに簡単に持ち込むことができます。詳細については、Traffic Director と gRPC - サービス メッシュ用のプロキシレス サービスをご覧ください。

次の図では、gRPC アプリケーションは、あるリージョンの Kubernetes クラスタに基づいたサービスと、異なるリージョンの VM 上で実行されるサービスにトラフィックをルーティングしています。2 つのサービスにはサイドカー プロキシがあり、他のサービスはプロキシレスです。

Traffic Director を使用したプロキシレス gRPC アプリケーションの例
Traffic Director を使用したプロキシレス gRPC アプリケーションの例(クリックして拡大)

Traffic Director は、プロキシレス gRPC サービスをサポートしています。これは、xDS API をサポートする最新バージョンのオープンソース gRPC ライブラリを使用するサービスです。gRPC アプリケーションは、Envoy と同じ xDS API を使用して Traffic Director に接続できます。

アプリケーションを接続すると、gRPC ライブラリは、サービス ディスカバリ、負荷分散、トラフィック管理などのアプリケーション ネットワーキング機能を担います。これは、始めから gRPC に備わっている機能のため、サービス プロキシは必要ありません。そのため、プロキシレス gRPC アプリケーションと呼ばれます

上り(内向き)とゲートウェイ

多くのユースケースでは、Traffic Director で構成されていないクライアントを起点とするトラフィックを処理する必要があります。たとえば、マイクロサービスへのパブリック インターネット トラフィックの上り(内向き)が必要な場合があります。また、クライアントからのトラフィックを宛先に送信する前にトラフィックを処理するリバース プロキシとして、ロードバランサを構成することもできます。

次の図では、外部アプリケーション ロードバランサによって外部クライアントに対する上り(内向き)中継が有効になり、トラフィックが Kubernetes クラスタ内のサービスに転送されています。内部アプリケーション ロードバランサは、VM で実行されているサービスに内部トラフィックを転送します。

上り(内向き)中継用の Cloud Load Balancing を持つ Traffic Director。
上り(内向き)中継用の Cloud Load Balancing を持つ Traffic Director(クリックして拡大)

Traffic Director は Cloud Load Balancing と連携して、マネージドの上り(内向き)中継を提供します。外部ロードバランサまたは内部ロードバランサを設定し、ロードバランサがトラフィックをマイクロサービスに送信するように構成します。上の図では、公共インターネットのクライアントは、外部アプリケーション ロードバランサを経由してサービスにアクセスします。Virtual Private Cloud(VPC)ネットワーク上にあるマイクロサービスなどのクライアントは、内部アプリケーション ロードバランサを使用してサービスにアクセスします。

ユースケースの中には、Traffic Director をセットアップしてゲートウェイを構成することがあります。基本的に、ゲートウェイは 1 つ以上の VM で実行されている Envoy プロキシで、受信リクエストをリッスンして処理し、宛先に送信します。あらゆる Google Cloud リージョンまたは Google Kubernetes Engine(GKE)クラスタを宛先にすることができます。ハイブリッド接続を使用することで、Google Cloud から到達可能な Google Cloud の外部の宛先も利用可能です。どのような場合にゲートウェイを使用するかについては、メッシュの上り(内向き)トラフィックをご覧ください。

次の図では、europe-west1 リージョンにある VM が、プロキシを実行していない 3 つのサービスへのゲートウェイとして機能するプロキシを実行しています。外部アプリケーション ロードバランサと内部アプリケーション ロードバランサからのトラフィックは、ゲートウェイに転送され、続いて 3 つのサービスに転送されます。

ゲートウェイの構成に使用された Traffic Director。
ゲートウェイの構成に使用された Traffic Director(クリックして拡大)

複数の環境

Google Cloud、オンプレミス、その他のクラウドのいずれのサービスにおいても、またはそのすべてにサービスがある場合でも、アプリケーション ネットワーキングにおける基本的な課題は変わりません。どのようにして、トラフィックをこうしたサービスへ向かわせるかという課題です。また、どのようにして、こうしたサービスを互いに通信させるかという課題です。

次の図では、Traffic Director は、Google Cloud で実行されているサービスから別のパブリック クラウドで実行されている Service G と、オンプレミスのデータセンターで実行されている Service EService F の両方にトラフィックを転送します。Service AService BService C は、Envoy をサイドカー プロキシとして使用することに対し、Service D はプロキシレスの gRPC サービスです。

環境間の通信に使用される Traffic Director。
環境間の通信に使用される Traffic Director(クリックして拡大)

Traffic Director を使用すると、Google Cloud 外部の宛先にリクエストを送信できます。これにより、Cloud Interconnect または Cloud VPN を使用して、Google Cloud 内のサービスから他の環境のサービスまたはゲートウェイにプライベート トラフィックをルーティングできます。

Traffic Director の設定

Traffic Director の設定は、2 つの手順から成ります。設定プロセスが完了すると、インフラストラクチャはアプリケーション ネットワーキングを処理し、Traffic Director はデプロイの変更に基づいてすべてを最新の状態に保ちます。

アプリケーションのデプロイ

まず、アプリケーション コードをコンテナか VM にデプロイします。Google では、VM インスタンスと Pod にアプリケーション ネットワーキング インフラストラクチャ(通常は Envoy プロキシ)を簡単に追加できる仕組みを提供しています。このインフラストラクチャは、Traffic Director と通信して、サービスについて学習するように設定されています。

Traffic Director を構成する

次に、グローバル サービスを構成し、トラフィックの処理方法を定義します。Traffic Director を構成するには、Google Cloud コンソール(一部の機能と構成用)、Google Cloud CLI、Traffic Director API、またはその他のツール(Terraform など)を使用します。

この手順が完了すると、Traffic Director でアプリケーション ネットワーキング インフラストラクチャを構成する準備が整います。

インフラストラクチャによるアプリケーション ネットワーキングの処理

アプリケーションが my-service にリクエストを送信すると、アプリケーション ネットワーキング インフラストラクチャ(Envoy サイドカー プロキシなど)が、Traffic Director から受信した情報に従ってそのリクエストを処理します。これにより、my-service へのリクエストを、受信可能なアプリケーション インスタンスにシームレスに転送できます。

モニタリングと継続的な更新

Traffic Director は、サービスを構成するアプリケーション インスタンスをモニタリングします。このモニタリングにより、Traffic Director は新しい Kubernetes Pod が作成された場合などに、サービスが正常な状態であるか、サービスの容量が変更されたかどうかを検出できます。この情報に基づいて、Traffic Director はアプリケーション ネットワーキング インフラストラクチャを継続的に更新します。

特徴

Traffic Director の特徴により、マイクロサービスにアプリケーション ネットワーキング機能が追加されます。このセクションでは、いくつかのポイントを説明します。

フルマネージドのコントロール プレーン、ヘルスチェック、負荷分散

インフラストラクチャの管理ではなく、ビジネス価値の提供に時間をかけたいとお考えなら、稼働率の SLA 付きのフルマネージド ソリューションである Traffic Director を使用すると、インフラストラクチャをインストール、構成、更新する必要がなくなります。Google でヘルスチェックやグローバル負荷分散に使用されているものと同じインフラストラクチャを利用できます。

オープンソース プロダクト上に構築

Traffic Director は、EnvoyIstio などのよく利用されているオープンソース プロジェクトで使用されているのと同じコントロール プレーン(xDS)API を使用します。サポートされている API バージョンを確認するには、xDS コントロール プレーン API をご覧ください。

アプリケーション ネットワーキング機能をユースケースに応じて提供するインフラストラクチャ(Envoy や gRPC)は、オープンソースであるため、独自仕様のインフラストラクチャにロックインされる心配はありません。

規模

Traffic Director は、単発のアプリケーション ネットワーキング ソリューションから数千ものサービスで構成される大規模なサービス メッシュ デプロイメントまで、スケーリングのニーズを満たすように構築されています。

サービス ディスカバリとエンドポイントおよびバックエンドのトラッキング

アプリケーションが my-service にリクエストを送信すると、インフラストラクチャでシームレスにリクエストが処理され、正しい宛先に送信されます。アプリケーションは、IP アドレス、プロトコル、その他のネットワーキングの複雑性について認識する必要がありません。

グローバルなロード バランシングとフェイルオーバー

Traffic Director は、Google のグローバルなロード バランシングとヘルスチェックを使用して、クライアントとバックエンドのロケーション、バックエンドの近接性、健全性、容量に基づいてトラフィックを最適なバランスで分散させます。トラフィックを容量に余裕がある正常なバックエンドへ自動的にフェイル オーバーすることで、サービスの可用性が向上します。ビジネス要件に合わせてトラフィックが分散されるように、ロード バランシングをカスタマイズできます。

トラフィック管理

ルーティングとリクエストの操作(ホスト名、パス、ヘッダー、Cookie などに基づく)など、高度なトラフィック管理によって、サービス間のトラフィック フローを決定できます。カナリア デプロイの再試行、リダイレクト、重みベースのトラフィック分割などのアクションも適用できます。フォールト インジェクション、トラフィック ミラーリング、外れ値検出などの高度なパターンを使用すると、DevOps のユースケースで復元性が向上します。

オブザーバビリティ

アプリケーション ネットワーキング インフラストラクチャは、指標、ログ、トレースなど、Google Cloud Observability に集約できるテレメトリー情報を収集します。収集された情報により、知見の獲得やアラートの作成が可能になり、何か問題が発生した場合に通知を受け取れます。

VPC Service Controls

VPC Service Controls を使用すると、アプリケーションのリソースとサービスのセキュリティを強化できます。境界の外部から発生するリクエストからリソースとサービス(Traffic Director など)を保護するサービス境界にプロジェクトを追加できます。VPC Service Controls の詳細については、VPC Service Controls の概要をご覧ください。

VPC Service Controls で Traffic Director を使用する方法については、サポートされているプロダクトのページをご覧ください。

次のステップ