Traffic Director の機能

Traffic Director は、グローバル サービス メッシュでマイクロサービスを実行する際に有用です。このメッシュによってマイクロサービスのネットワーキングが処理されるため、アプリケーション コードを作成する際に基盤となるネットワークの複雑性を認識する必要がありません。アプリケーション ロジックをネットワーキング ロジックから分離することで、開発速度を向上させ、サービスの可用性を高め、組織に最新の DevOps プラクティスを導入できます。

サービス メッシュは、アプリケーション、xDS 互換のデータプレーン(一般的にはオープンソースの Envoy プロキシ)、メッシュのコントロール プレーンとしての Traffic Director で構成されます。

サービス メッシュで Traffic Director を使用してプロキシレス gRPC サービスをデプロイするには、サポートされているバージョンの gRPC を使用します。

このドキュメントでは、Traffic Director で使用できる機能の概要を説明します。値 N/A(なし)は、特定の Traffic Director 構成と互換性がないため、機能をサポートできないことを意味します。チェックマークや「N/A」を含まない空白スペースは、現時点では機能がサポートされていませんが、今後サポートされる可能性があることを意味します。

サービス メッシュ用のフルマネージド コントロール プレーン

Traffic Director は、Google Cloud で実行される、高可用性のマネージド コントロール プレーンのサービスです。コントロール プレーンをインストールまたは更新する必要がないため、サービス メッシュのインフラストラクチャで管理するコンポーネントが 1 つ減ります。

サポートされている xDS バージョン

Traffic Director は、オープンソースの xDS コントロール プレーン API を使用して、Envoy とプロキシレス gRPC クライアントを構成します。これらのクライアントは、アプリケーション コードに代わって、Traffic Director のアプリケーション ネットワーキング機能を提供します。

バージョン サポート
xDS v2 一般提供。一部の機能(サービス セキュリティなど)は、xDS v3 でのみ利用できます。xDS v2 のサポートは 2024 年 6 月 20 日に終了します。
xDS v3 一般提供

メッシュ サービスを実行するプラットフォーム

次のプラットフォームでアプリケーションを実行し、Traffic Director によって構成されたグローバル サービス メッシュに導入できます。

機能 サポート対象
Compute Engine 仮想マシン(VM)インスタンス
Google Kubernetes Engine(GKE)コンテナ インスタンス
Compute Engine コンテナ インスタンス上の Kubernetes

サービスの管理

Traffic Director によって構成されたメッシュ内のサービスには、以下のメリットがあります。

  • サービス ディスカバリ。メッシュ内のアプリケーションが別のアプリケーションにアクセスする必要がある場合は、そのサービスを名前で呼び出すことができます。

  • バックエンドの自動スケーリング。アプリケーション コードを実行するインスタンスが、必要に応じて動的にスケールアップまたはスケールダウンします。

  • エンドポイントの自動登録。新しいインスタンスが追加または削除されると、サービスに自動的に関連付けられます。

機能 サポート対象
Compute Engine VM のサイドカー プロキシの自動デプロイ
GKE Pod のサイドカー プロキシの自動インジェクション
ホスト名に基づくサービス ディスカバリ
CPU 使用率に基づくインスタンスの自動スケーリング
トラフィックの負荷や処理能力に基づくインスタンスの自動スケーリング
(マネージド インスタンス グループ(MIG)の Compute Engine VM のみ)
構成可能なヘルスチェックに基づくインスタンスの自動修復
Compute Engine VM の自動エンドポイント登録
GKE コンテナ インスタンス / Pod の自動エンドポイント登録
Service Directory 内のサービスとバックエンド サービスのバインド
プログラムでエンドポイントを追加または削除する API

データプレーン トラフィックのエンドポイント

マイクロサービスは、データプレーンを使用して、メッシュ内とメッシュ外のサービスにアクセスします。Traffic Director を使用すると、アプリケーション ロジックをネットワーキング ロジックから分離できるため、アプリケーションで行う必要があるのは、リクエストをデータプレーン(アプリケーションとともに実行されているサイドカー プロキシなど)に送信することのみです。データプレーンは、適切なエンドポイントにリクエストを送信します。

以下の表で、メッシュ内にあるとして記載されているアプリケーションは、Traffic Director のマネージド データプレーンを使用して他のサービスと通信するアプリケーションです。これらのアプリケーションは、メッシュ内のサービスのみでなく、メッシュ外のサービスにもトラフィックを送信できます。

機能 サポート対象
メッシュ内の VM ベースのアプリケーション
メッシュ内のコンテナベースのアプリケーション
メッシュ外の VM ベースのアプリケーション
メッシュ外のコンテナベースのアプリケーション
オンプレミスのデータセンターで動作しているアプリケーション
マルチクラウド環境のアプリケーション
Service Directory のエンドポイント

データプレーン トポロジ

サービス メッシュ モデルでは、アプリケーションはデータプレーンを使用して通信します。このデータプレーンは、多くの場合、アプリケーションとともにデプロイされたサイドカー プロキシで構成されます。Traffic Director は柔軟性が高く、サービスのネットワーキングのニーズに適したデータプレーン トポロジをサポートします。

機能 サポート対象
アプリケーションとともに実行されるサイドカー プロキシ
プロキシレス gRPC アプリケーション
メッシュ内の 2 つのアプリケーション間の中間プロキシ
メッシュの境界のエッジプロキシ
複数のリージョンにある GKE クラスタまたは Compute Engine VM にまたがるメッシュ

プログラムによる API ドリブンの構成

すべての構成は、そのまま使用できる状態で REST API とダッシュボードを通じて公開されているため、大規模なチーム間で変更を自動化しプログラムによって変更を管理できます。一部の機能は Google Cloud コンソールでは構成できません。

機能 サポート対象
REST API
Google Cloud コンソール
Google Cloud CLI
Cloud Deployment Manager
Terraform のサポート

プロキシレス gRPC アプリケーションによる言語サポート

Traffic Director とともに動作するプロキシレス gRPC アプリケーションは、次のプログラミング言語を使用して作成できます。gRPC のさまざまな実装とバージョンでサポートされているサービス メッシュ機能の一覧については、GitHub をご覧ください。

言語 サポート対象
Java
Go
C++
Python
Ruby
PHP
ノード

リクエストのプロトコル

アプリケーションは、Traffic Director で構成されたデータプレーンを使用して通信する際に、次のリクエスト プロトコルを使用できます。

機能 サポート対象
HTTP
HTTPS
HTTP/2
TCP
gRPC

サービスのセキュリティ

Traffic Director は、次の構成のサービス セキュリティをサポートしています。

機能 Envoy gRPC
TLS と GKE Pod
mTLS と GKE Pod
アクセス制御と認可

ルーティングとトラフィック管理

Traffic Director は高度なトラフィック管理ポリシーをサポートしており、このポリシーを使用してデータプレーンを通過するトラフィックを誘導、分割、形成できます。

一部の高度なトラフィック管理機能は、プロキシレス gRPC サービスには使用できません。また、ターゲット TCP プロキシ リソースで利用できる、高度なトラフィック管理機能はありません。

Traffic Director が HTTP(S) 以外の TCP トラフィックを処理している場合、次の機能はサポートされません。

機能 HTTP(S) トラフィックまたは gRPC トラフィックを処理するように構成された Envoy プロキシでのサポート プロキシレス gRPC のサポート
サフィックス / プレフィックス / 完全一致 / 正規表現の一致に基づく HTTP / レイヤ 7 のリクエスト ルーティング:
• ホスト名
• パス
• ヘッダー
• メソッド なし
• Cookie
• リクエスト パラメータ なし
フォールト インジェクション
構成可能なタイムアウト なし
最大ストリーミング期間をご覧ください。
再試行数
再試行ごとのタイムアウトを除く
リダイレクト
URI の書き換え
リクエスト/レスポンス ヘッダー変換
トラフィック分割
トラフィックのミラーリング
外れ値検出
サーキット ブレーク
maxRequests のみ
最大ストリーミング期間

負荷分散

高度な負荷分散方法とアルゴリズムを構成して、サービス、バックエンド グループ(インスタンス グループまたはネットワーク エンドポイント グループ)、個別のバックエンドまたはエンドポイント レベルで負荷を分散できます。詳細については、バックエンド サービスの概要をご覧ください。

機能 HTTP(S)、TCP、gRPC のトラフィックを処理するように構成された Envoy プロキシでのサポート プロキシレス gRPC のサポート
リージョンに基づくバックエンド(インスタンス グループまたはネットワーク エンドポイント グループ)の選択(正常な状態でバックエンド容量のある最も近いリージョンを優先)
レートベース(1 秒あたりのリクエスト数)の分散モードを使用したバックエンドの選択
HTTP(S) 以外の TCP トラフィックではサポートされていません。
使用率ベースの負荷分散モードに基づくバックエンドの選択(Compute Engine インスタンス グループの VM のみ)
バックエンドあたりの構成可能な最大容量(Compute Engine と GKE のみ)

構成可能な負荷分散ポリシーに基づくバックエンドの選択。

各組み込みポリシーの詳細については、localityLbPolicy をご覧ください。

  • 単一の組み込みポリシーを使用する。次のいずれかを選択します。

    • ラウンドロビン
    • 最少リクエスト
    • リングハッシュ
    • ランダム
    • 元の宛先
    • Maglev

サービスの復元性

Traffic Director は、サービスの復元性を高める機能をサポートしています。たとえば、Traffic Director を使用して、Blue/Green デプロイ パターンカナリアテスト、サーキット ブレーカー(EnvoygRPC)などを実装できます。

機能 HTTP(S)、TCP、gRPC のトラフィックを処理するように構成された Envoy プロキシでのサポート プロキシレス gRPC のサポート
重み付けに基づくトラフィック分割でのサービスの選択
サーキット ブレーク
maxRequests のみ

サービスとバックエンドの容量管理

Traffic Director は、サービスとバックエンドの容量を考慮し、サービスのバックエンド間でトラフィックの分散を最適化します。Traffic Director は、Google Cloud インフラストラクチャと統合され、容量データが自動的に収集されます。また、手動で容量を設定して構成することもできます。

機能 サポート対象
マネージド インスタンス グループ(MIG)内の VM インスタンスについて、バックエンドの容量と使用率を CPU に基づき自動的に追跡。
リクエスト率に基づく MIG とネットワーク エンドポイント グループ(NEG)の VM とコンテナ インスタンスの手動の容量とオーバーライド。
手動の容量ドレイン。

フェイルオーバー

エンタープライズのワークロードは通常、サービスの稼働時間を確保するために高可用性のデプロイに依存します。Traffic Director は、マルチゾーン / マルチリージョンの冗長性を有効にすることで、これらのタイプのデプロイをサポートします。

機能 サポート対象
正常な状態のバックエンド容量を持ち同じリージョン内に存在する別のゾーンへの自動フェイルオーバー。
正常な状態でバックエンド容量のある最も近いリージョンへの自動フェイルオーバー。

ヘルスチェック

Traffic Director は、バックエンドの健全性を判断する一元化されたヘルスチェックをサポートしています。ただし、バックエンド サービスに Service Directory サービスのサービス バインディングが含まれている場合、ヘルスチェックは設定できません。

リファレンス情報については、ヘルスチェックの概要をご覧ください。

機能 サポート対象
gRPC ヘルスチェック
HTTP ヘルスチェック
HTTPS ヘルスチェック
HTTP/2 ヘルスチェック
TCP ヘルスチェック

構成可能なヘルスチェック:

  • ポート
  • チェック間隔
  • タイムアウト
  • 正常と異常のしきい値
構成可能なリクエストパス(HTTP、HTTPS、HTTP/2)
構成可能なリクエスト文字列またはパス(TCP または SSL)
構成可能な想定レスポンス文字列

オブザーバビリティ

オブザーバビリティ ツールは、サービス メッシュの理解に役立つモニタリング、デバッグ、パフォーマンスに関する情報を提供します。次の機能は、デフォルトで提供されているか、データプレーンで構成できます。このオブザーバビリティ データを生成するために、アプリケーション コードで特別な操作を行う必要はありません。

サービスの状態を示すダッシュボードはプロキシレス gRPC サービスで使用できますが、データプレーン ロギングとトレースは構成できません。Traffic Director では gRPC アプリケーションのロギングとトレースを構成できません。ロギングとトレースは、オープンソース サイトで利用可能なトラブルシューティング セクションまたは gRPC ガイドの手順で有効にできます。たとえば、OpenCensus を使用すると、プロキシレス gRPC サービスで指標の収集とトレースを有効にできます。

機能 プロキシのサポート プロキシレス gRPC サービスのサポート
サービスの正常性を示すダッシュボード
データプレーン ロギング
データプレーン トレース

セッション アフィニティ

多くの場合、クライアントとサーバー間の通信では連続した複数のリクエストが行われます。このような場合は、連続するクライアント リクエストを同じバックエンドまたはサーバーにルーティングすることが有効です。Traffic Director には、バックエンドが正常な状態で使用可能な容量を保持している限り、特定のクライアントからのリクエストをベスト エフォート方式で同じバックエンドに送信するための構成可能なオプションが用意されています。詳細については、バックエンド サービスの概要をご覧ください。

機能 HTTP(S) プロキシでのサポート TCP プロキシでのサポート プロキシレス gRPC サービスのサポート
クライアント IP アドレス
HTTP Cookie なし
HTTP ヘッダー なし
生成された Cookie(最初のリクエストでクライアント Cookie を設定) なし

ネットワーク トポロジ

Traffic Director は一般的な Google Cloud ネットワーク トポロジをサポートしています。

機能 サポート対象
Google Cloud プロジェクトの単一ネットワーク
Google Cloud プロジェクトの複数のメッシュ
Google Cloud プロジェクトの複数のゲートウェイ
共有 VPC(複数の Google Cloud プロジェクト間で共有される単一のネットワーク)

Traffic Director での共有 VPC のサポートの詳細については、制限事項をご覧ください。

コンプライアンス

Traffic Director は以下の標準に準拠しています。

コンプライアンス認定 サポート対象
HIPAA
ISO 27001、ISO 27017、ISO 27018
SOC1、SOC2、SOC3
PCI DSS

次のステップ