Traffic Director の機能

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

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

このドキュメントでは、Traffic Director で使用できる機能の概要を説明します。

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

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

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

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

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

サービス管理

Traffic Director によって構成されたメッシュ内のサービスは、サービス ディスカバリ、バックエンドの自動スケーリング、エンドポイントの自動登録によるメリットが得られます。

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

  • これらのサービスは、アプリケーション コードを実行するインスタンスによってサポートされます。これらのインスタンスは、必要に応じて動的にスケールアップまたはスケールダウンします。

  • 新しいインスタンスが作成または削除されたら、それらをサービスに関連付ける必要があります。これはエンドポイント登録と呼ばれます。

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

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

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

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

機能 サポート対象
メッシュ内の VM ベースのアプリケーション
メッシュ内のコンテナベースのアプリケーション
メッシュ外の VM ベースのアプリケーション
メッシュ外のコンテナベースのアプリケーション

データプレーン トポロジ

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

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

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

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

機能 サポート対象
REST API
Google Cloud Console
gcloud コマンドライン インターフェース
Deployment Manager
Terraform のサポート

リクエストのプロトコル

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

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

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

Traffic Director は高度なトラフィック管理ポリシーをサポートしており、このポリシーを使用してデータプレーンを通過するトラフィックを誘導、分割、形成できます。プロキシレス gRPC サービスを使用する Traffic Director では、ほとんどの高度なトラフィック管理が有効になっていないことに注意してください。

機能 Envoy プロキシのサポート プロキシレス gRPC のサポート
サフィックス / プレフィックス / 完全一致 / 正規表現の一致に基づく HTTP / レイヤ 7 のリクエスト ルーティング:
• ホスト名 ✔ 1.30.0 以降
• パス ✔ 1.31.0 以降
• ヘッダー ✔ 1.31.0 以降
• メソッド なし
• Cookie ✔ 1.31.0 以降
• リクエスト パラメータ なし
フォールト インジェクション
構成可能なタイムアウト
再試行数
リダイレクト なし
URI の書き換え
リクエスト/レスポンス ヘッダー変換
トラフィック分割
トラフィックのミラーリング
外れ値検出

負荷分散

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

機能 Envoy プロキシのサポート プロキシレス gRPC のサポート
重み付けに基づくトラフィック分割でのサービスの選択
リージョンに基づくバックエンド(インスタンス グループまたはネットワーク エンドポイント グループ)の選択(正常な状態でバックエンド容量のある最も近いリージョンを優先) ✔ 1.30.0 以降
レートベース(1 秒あたりのリクエスト数)の分散モードを使用したバックエンドの選択 ✔ 1.30.0 以降
使用率ベースの負荷分散モードに基づくバックエンドの選択(Compute Engine インスタンス グループの VM のみ) ✔ 1.30.0 以降
バックエンドあたりの構成可能な最大容量(Compute Engine と GKE のみ) ✔ 1.30.0 以降
サーキット ブレーカー
構成可能な負荷分散ポリシーに基づくバックエンドの選択*:
  • ラウンドロビン
  • 最少リクエスト
  • リングハッシュ
  • ランダム
  • 元の宛先
  • Maglev
ラウンドロビンのみ

* 詳細については、localityLbPolicy をご覧ください。

フェイルオーバー

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

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

ヘルスチェック

バックエンドの健全性を一元管理するためのヘルスチェック。リファレンス情報については、ヘルスチェックの概要をご覧ください。

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

オブザーバビリティ

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

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

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

セッション アフィニティ

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

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

ネットワーク トポロジ

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

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

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

コンプライアンス

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

コンプライアンス認定
HIPAA
ISO 27001、ISO 27017、ISO 27018
SOC1、SOC2、SOC3
PCI DSS