高度なトラフィック管理の概要

このドキュメントは、Traffic Director とサービスメッシュのコンセプトについて、中級から上級レベルの知識を持ち、Traffic Director のデプロイでトラフィックの管理方法を決定および構成するメッシュまたはプラットフォーム管理者とサービスデベロッパーを対象としています。このドキュメントは、サービスルーティング API にのみ適用されます。Traffic Director のデプロイで以前のロードバランシング API を使用している場合は、ロードバランシング API の高度なトラフィック管理の概要をご覧ください。Traffic Director のグローバルロードバランシング機能は、使用する API に関係なく使用できます。

Traffic Director は、トラフィックの処理方法をきめ細かく制御できる高度なトラフィック管理機能を提供します。Traffic Director は、次のようなユースケースをサポートします。

リクエストを 1 つ以上のサービスに転送する、きめ細かいトラフィックの振り分け
複数のサービスにトラフィックを分散させる、重みベースのトラフィック分割
あるデバッグサービスにリクエストを送信し、別のサービスにはコピーを送信する、トラフィックのミラーリングポリシートラフィックのミラーリングは、TCPRoute リソースや TLSRoute リソースではサポートされていません。
サービスのバックエンド間でのきめ細かいトラフィック分散（ロードバランシングの改善のため）

可用性とパフォーマンスの目標を達成するために使用できる高度なトラフィック管理機能の範囲は次のとおりです。このようなユースケースに Traffic Director を使用することで、アプリケーションコードを変更せずにトラフィックの管理方法を更新できます。

Traffic Director サービスメッシュのトラフィック管理は、次のリソースに依存します。

Mesh リソース。サービスメッシュを識別し、トラフィックの転送とポリシーの適用を行うコンポーネントを表します。Mesh リソースは、トラフィックインターセプトポートも識別します。
Gateway リソース。中間プロキシを識別し、IP address:port ペアのリストをリッスンしてトラフィックを転送し、ポリシーを適用するコンポーネントを表します。
Route リソース。複数のタイプのいずれかであり、メッシュのトラフィックルーティング情報が含まれます。Route リソースは、クライアントがトラフィックをバックエンドサービスに転送するために使用できるホスト名とポートを識別します。
バックエンドサービス。Route リソースが関連付けられています。

Route リソースには次のタイプがあります。

HTTPRoute。Envoy プロキシを使用するメッシュでのみ使用できます。HTTPRoute リソースを使用して Envoy プロキシを構成し HTTP リクエストを送信する場合は、このドキュメントのすべての機能を使用できます。
TCPRoute。Envoy プロキシを使用するメッシュでのみ使用できます。
TLSRoute。Envoy プロキシを使用するメッシュでのみ使用できます。
GRPCRoute。Envoy サイドカープロキシとプロキシレス gRPC を使用するメッシュで使用できます。プロキシレス gRPC サービスまたは Traffic Director でアプリケーションを使用する場合は、このドキュメントで説明している機能の一部が使用できません。

構成

高度なトラフィック管理を構成するには、Traffic Director の設定時と同じ Route とバックエンドサービスリソースを使用します。Traffic Director は、Envoy プロキシとプロキシレス gRPC アプリケーションを構成し、この高度なトラフィック管理のポリシーを適用します。

大まかな流れは次のとおりです。

サービスメッシュを識別する Mesh リソースを構成します。
送信リクエストの特性に基づいて、次の処理を行うように Route リソースを構成します。
1. リクエストのルーティング先となるバックエンドサービスを選択します。
2. 必要に応じて、追加のアクションを実行します。
宛先サービスが選択された後、バックエンドとエンドポイント間でトラフィックの分散を制御するように、バックエンドサービスを構成します。

トラフィックのルーティングとアクション

Traffic Director では、Mesh リソース、Route リソース、バックエンドサービスリソースの値に基づいてトラフィックがルーティングされます。ルーティングとアクションに関連する高度なトラフィック管理機能は、Route オブジェクトを使用して構成します。

以降のセクションでは、Route オブジェクトで設定できる高度なトラフィック管理機能について説明します。

リクエスト処理

クライアントがリクエストを送信すると、リクエストは次の順序で処理されます。

次のように、リクエストを特定の Route リソースと照合します。
- Envoy を使用している場合:
  - HTTP リクエストのホストヘッダーは、各 HTTPRoute リソースまたは GRPCRoute リソースの hostnames フィールドと照合され、リクエストに正しい Route リソースが選択されます。hostnames フィールドがあるのは、HTTPRoute リソースと GRPCRoute リソースのみです。
  - この IP アドレスは、TCPPRoute を使用して TCP トラフィックをルーティングするために照合されます。
  - SNI と ALPN は TLSRoute を使用した TLS パススルーに使用されます。
  - Mesh または Gateway に関連付けられる HTTPRoute リソースと GRPCRoute リソースには、一意であるホスト名が必要です。競合するホスト名を持つ複数のルートを接続しようとすると、構成は拒否されます。
  - 同様に、TCPRoute の IP:Port フィールドは一意であることが必要です。そうでない場合、構成は拒否されます。
  - 同様に、SNI と ALPN は TLSRoute で一意である必要があります。
  - a.example.com と *.example.com など、重複するホスト名がある場合、リクエストはより具体的なルートに一致します。
- プロキシレス gRPC を使用している場合:
  - プロキシレス gRPC クライアントは、xds 名前解決スキームを使用します。Traffic Director にリクエストを送信して、ターゲット URI の hostname[:port] を解決します。
  - GRPCRoute リソースのポートのみが、ターゲット URI のポートと比較されます（例: xds:///example.hostname:8080）。ターゲット URI は、GRPCRoute の hostnames フィールド内の文字列と完全に一致する必要があります。
Route リソースには、追加のルーティング情報とルールを含めることができます。
宛先のバックエンドサービスが選択されると、トラフィックは、バックエンドサービスリソースの構成に基づいて、そのバックエンドサービスの複数のバックエンドやエンドポイントに分散されます。

2 番目のステップについては、次のセクション、ホストとパスに基づく単純なルーティングで説明します。3 番目のステップは、高度なルーティングとアクションで説明します。

ホストとパスに基づく単純なルーティング

Traffic Director は、簡素化されたルーティングスキームと高度なスキームをサポートしています。単純なスキームでは、ホストとパス（省略可）を指定します。リクエストのホストとパスが評価され、リクエストのルーティング先となるバックエンドサービスが決まります。

リクエストのホストとは、URL のドメイン名部分を意味します。たとえば、URL http://example.com/video/ のホストに相当する部分は、example.com です。
リクエストのパスとは、URL のホスト名に続く部分を意味します。たとえば、URL http://example.com/video/ のパスに相当する部分は、/video です。

ルーティングルールマップ内のホストとパスに基づいて、単純なルーティングを設定します。これは次の情報で構成されます。

グローバルな Mesh
HTTPRoute または GRPCRoute

ほとんどの構成は、HTTPRoute で行われます。最初のルーティングルールマップを作成した後は、HTTPRoute リソースを変更するだけで済みます。

最も単純なルールはデフォルトルールです。このルールでは、ホストルールにワイルドカード（*）を指定し、パスマッチャーにデフォルトのサービスを指定するだけです。デフォルトルールを作成した後は、異なるホストとパスを指定するルールを追加できます。これらのルールにより、送信リクエストが次のように評価されます。

リクエストのホスト（example.com など）が HTTPRoute のホスト名と一致する場合:
1. RouteRule が次に評価されます。RouteRule は、トラフィックを照合する方法と、トラフィックが一致したときのトラフィックのルーティング方法を指定します。
2. 各 RouteRule には、リクエストのパスに対して評価されるルート一致が 1 つ以上含まれます。
3. 一致した場合、リクエストは RouteAction で指定されたサービスに転送されます。

HTTPRoute のリソースフィールドとその仕組みの詳細については、Network Service API のドキュメントをご覧ください。

高度なルーティングとアクション

リクエストのホストとパスに基づいてリクエストをルーティングする場合、高度なルールを設定してリクエストをルーティングし、アクションを実行できます。

高度なルーティングとアクションの仕組みは次のとおりです。

単純なルーティングと同様に、リクエストのホストが HTTPRoute や GRPCRoute の URL マップで構成したホストルールと照合されます。リクエストのホストがホスト名と一致する場合は、HTTPRoute または GRPCRoute が評価されます。
ルートが選択された後に、アクションを適用できます。

高度なルーティング

高度なルーティングは前述の単純なルーティングと似ていますが、追加の一致条件を指定できます。たとえば、リクエストのヘッダーに一致するルールとして、ヘッダーの名前が完全に一致するか、部分的に一致する（接頭辞やサフィックスなど）ものを指定できます。ヘッダー名を正規表現と照合することや、ヘッダーの有無を確認する条件で評価することもできます。

headerMatches と queryParameterMatches のその他の一致条件と詳細については、network services REST API ページをご覧ください。

ホスト、パス、ヘッダー、クエリパラメータを一致条件と組み合わせることで、トラフィック管理を完全に満たす、きめ細かいルールを作成できます。詳しくは、次の表をご覧ください。

HTTP ベースのアプリケーション gRPC ベースのアプリケーション

	HTTP ベースのアプリケーション	gRPC ベースのアプリケーション
HTTP ホストと gRPC ホストの比較	ホストは、アプリケーションが呼び出す URL のドメイン名の部分です。たとえば、URL `http://example.com/video/` でホスト部分は `example.com` です。	ホストは、クライアントがチャネル URI で特定のサービスに接続するために使用する名前です。たとえば、チャネル URI `xds:///example.com` のホスト部分は `example.com` です。
HTTP パスと gRPC パスの比較	パスは、URL のホスト名に続く部分です。たとえば、URL `http://example.com/video` では、`/video` がパスの部分です。	パスは HTTP/2 リクエストの `:path` ヘッダーにあり、`/SERVICE_NAME/METHOD_NAME` のような形です。たとえば、`Example` gRPC サービスで `Download` メソッドを呼び出すと、`:path` ヘッダーの内容は `/Example/Download` のような形になります。
その他の gRPC ヘッダー（メタデータ）		gRPC は、gRPC クライアントと gRPC サーバー間でメタデータの送信をサポートし、RPC 呼び出しに関する追加情報を提供します。このメタデータは、Key-Value ペアの形式で HTTP/2 リクエストのヘッダーとして渡されます。

HTTP ホストと gRPC ホストの比較

ホストは、アプリケーションが呼び出す URL のドメイン名の部分です。

たとえば、URL http://example.com/video/ でホスト部分は example.com です。

ホストは、クライアントがチャネル URI で特定のサービスに接続するために使用する名前です。

たとえば、チャネル URI xds:///example.com のホスト部分は example.com です。

HTTP パスと gRPC パスの比較

パスは、URL のホスト名に続く部分です。

たとえば、URL http://example.com/video では、/video がパスの部分です。

パスは HTTP/2 リクエストの :path ヘッダーにあり、/SERVICE_NAME/METHOD_NAME のような形です。

たとえば、Example gRPC サービスで Download メソッドを呼び出すと、:path ヘッダーの内容は /Example/Download のような形になります。

その他の gRPC ヘッダー（メタデータ） gRPC は、gRPC クライアントと gRPC サーバー間でメタデータの送信をサポートし、RPC 呼び出しに関する追加情報を提供します。このメタデータは、Key-Value ペアの形式で HTTP/2 リクエストのヘッダーとして渡されます。

アクション

Traffic Director では、Envoy プロキシまたはプロキシレス gRPC アプリケーションがリクエストを処理するときに実行するアクションを指定できます。Traffic Director を使用することで、次のアクションを構成できます。

アクション	API フィールド名	説明
リダイレクト	`redirect [pathredirect?]`	構成可能な 3xx レスポンスコードが返されます。`Location` レスポンスヘッダーに適切な URI を設定すると、リダイレクトアクションで指定されたホストとパスが置き換わります。
URL の書き換え	`urlRewrite`	選択したバックエンドサービスにリクエストを送信する前に、URL のホスト名部分、URL のパス部分、またはその両方を書き換えます。
ヘッダー変換	`requestHeaderModifier/responseHeaderModifier?`	リクエストヘッダーを追加または削除してから、バックエンドサービスにリクエストを送信します。バックエンドサービスからレスポンスを受信した後にレスポンスヘッダーを追加または削除することもできます。
トラフィックのミラーリング	`requestMirrorPolicy`	選択したバックエンドサービスにリクエストを転送するだけでなく、構成済みのミラーバックエンドサービスに「ファイアアンドフォーゲット」方式で同じリクエストを送信します。ロードバランサは、ミラーリングされたリクエストを送信するバックエンドからのレスポンスを待ちません。ミラーリングは、バックエンドサービスの新しいバージョンのテストに利用できます。また、本番環境バージョンではなくバックエンドサービスのデバッグ環境バージョンで本番環境のエラーをデバッグすることもできます。
重み付けに基づくトラフィック分割	`weiDestination.serviceNameght`	個々のバックエンドサービスに割り当てられたユーザー定義の重み付けに応じて、一致したルールのトラフィックを複数のバックエンドサービスに分散できます。この機能は、段階的なデプロイや A/B テストの構成に利用できます。たとえば、トラフィックの 99% をアプリケーションの安定バージョンを実行しているサービスに送信し、残りの 1% を同じアプリケーションの新しいバージョンを実行している別のサービスに送信するようにルートアクションを構成できます。
再試行数	`retryPolicy`	ロードバランサが失敗したリクエストを再試行する条件、再試行までのロードバランサの待機時間、再試行の最大回数を構成します。
タイムアウト	`timeout`	選択したルートのタイムアウトを指定します。タイムアウトは、リクエストが完全に処理されてからレスポンスが完全に処理されるまでの時間です。タイムアウトにはすべての再試行が含まれます。
フォールトインジェクション	`faultInjectionPolicy`	高レイテンシ、サービス過負荷、サービス障害、ネットワークパーティショニングなどの障害をシミュレートするリクエストを処理する際にエラーを発生させます。この機能は、サービスの復元力を疑似的にテストするために利用できます。
セキュリティポリシー	`corsPolicy`	クロスオリジンリソースシェアリング（CORS）ポリシーが、CORS リクエストを適用するために設定を処理します。

アクションとその機能の詳細については、Network Services API のページをご覧ください。

各ルートルールで、次のいずれかのルートアクションを指定できます。

1 つのサービスへのトラフィックのルーティング（destination.serviceName）
複数のサービスへのトラフィックの分割（destination.weight）
リダイレクト URL（redirect）

また、前述のルートアクションと次のルートアクション（Google Cloud コンソールではアドオンアクションと呼ばれます）を組み合わせることもできます。

リクエストヘッダーまたはレスポンスヘッダーの操作（requestHeaderModifier/responseHeaderModifier）
トラフィックのミラーリング（requestMirrorPolicy）
URL ホスト、パス、またはその両方を書き換える（urlRewrite）
失敗したリクエストの再試行（retryPolicy）
タイムアウトの設定（timeout）
フォールトを挿入するトラフィックの割合（faultInjectionPolicy）
CORS ポリシーの追加（corsPolicy）

アクションは特定のルールに関連付けられているため、Envoy プロキシまたはプロキシレス gRPC アプリケーションは、処理中のリクエストに基づいて異なるアクションを適用できます。

サービスのバックエンド間でのトラフィック分散

リクエストの処理で説明しているように、クライアントは送信リクエストを処理するときに宛先サービスを選択します。宛先サービスを選択すると、リクエストを受信するバックエンド / エンドポイントを特定する必要があります。

上の図では、簡単に Rule と表されていますが、通常、Rule は、ホストルール、パスマッチャー、1 つ以上のパスルールかルートルールです。宛先サービスは、（Backend）Service です。Backend 1、…、Backend n が実際にリクエストを受け取り、処理します。これらのバックエンドは、サーバー側のアプリケーションコードをホストする Compute Engine 仮想マシン（VM）インスタンスなどです。

デフォルトでは、リクエストを処理するクライアントは、容量のある最も近い正常なバックエンドにリクエストを送信します。特定のバックエンドのオーバーロードを回避するため、後続のリクエストはラウンドロビン負荷分散アルゴリズムを使用して、宛先サービスの他のバックエンド間で負荷分散されます。ただし、この動作を細かく制御する必要があることもあります。

負荷分散、セッションアフィニティ、バックエンドの保護

各サービスに次のトラフィック分散ポリシーを設定できます。

ポリシー	API フィールド名	説明
負荷分散モード	`balancingMode`	宛先サービスが選択された後にネットワークエンドポイントグループ（NEG）やマネージドインスタンスグループ（MIG）が選択される仕組みを制御します。分散モードは、同時接続とリクエスト率に基づいて負荷を分散するように構成できます。
負荷分散ポリシー	`localityLbPolicy`	NEG や MIG 内のバックエンド間でトラフィックを分散するために使用する負荷分散アルゴリズムを設定します。パフォーマンスを最適化するために、さまざまなアルゴリズム（ラウンドロビンや最小リクエストなど）から選択できます。
セッションアフィニティ	`sessionAffinity`	バックエンドが良好な状態で処理能力があれば、特定のクライアントからのリクエストを可能な限り同じバックエンドに送信します。 Traffic Director では、クライアント IP アドレス、HTTP Cookie ベース、HTTP ヘッダーベース、生成された Cookie アフィニティ（Traffic Director がそれ自身を生成したもの）の 4 つのセッションアフィニティオプションをサポートしています。
コンシステントハッシュ	`consistentHash`	HTTP ヘッダー、Cookie、その他のプロパティに基づくソフトセッションアフィニティを提供します。
サーキットブレーカー	`circuitBreakers`	バックエンドサービスへの接続量と接続あたりのリクエスト数の上限を設定します。
外れ値検出	`outlierDetection`	（1）正常でないバックエンドやエンドポイントを MIG や NEG から除外し、（2）十分に正常でトラフィックを再度受信できると見なされる場合に、バックエンドやエンドポイントを追加し直します。バックエンドやエンドポイントが正常かどうかは、サービスに関連付けられたヘルスチェックにより判断します。

トラフィック分散のさまざまな手段とその仕組みについては、backendServices REST API ページとバックエンドサービスの概要をご覧ください。

ユースケースの例

高度なトラフィック管理はさまざまなユースケースに対応しています。このセクションでは、その一部を説明します。

サンプルコードなど、ここに記載されていない例については、Envoy を使用して高度なトラフィック管理を構成するとプロキシレス gRPC サービスを使用して高度なトラフィック管理を構成するをご覧ください。

パーソナライズを目的としたきめ細かいトラフィックルーティング

リクエストのパラメータに従ってトラフィックをサービスにルーティングできます。たとえば、このサービスを使用すると、Android ユーザー向けにカスタマイズされたエクスペリエンスを提供できます。次の図では、Traffic Director を使用して、user-agent:Android ヘッダーを含むリクエストを、汎用的なサービスに対してではなく Android サービスに送信するサービスメッシュを構成しています。

Android に設定された user-agent ヘッダーに基づくルーティング。 — `Android` に設定された `user-agent` ヘッダーに基づくルーティング（クリックして拡大）

より安全なデプロイを目的とした重み付けベースのトラフィック分割

既存の本番環境サービスの新しいバージョンを安全にデプロイできるとは限りません。テスト環境で問題が見つからなかったとしても、すべてのユーザーをすぐに新しいバージョンにルーティングしないほうがよい場合もあります。

Traffic Director を使用すると、重み付けベースのトラフィック分割を定義し、複数のサービスにトラフィックを分散できます。たとえば、トラフィックの 1% を新しいバージョンに送信してモニタリングし、すべて正常に機能していることを確認してから、新しいサービスにルーティングするトラフィックの割合を段階的に増やしていくことができます。

Traffic Director の重み付けに基づくトラフィック分割。 — Traffic Director による重み付けに基づくトラフィック分割（クリックして拡大）

デバッグを目的としたトラフィックミラーリング

問題をデバッグするときに、本番環境のトラフィックのコピーをデバッグサービスに送信すると便利な場合があります。Traffic Director では、リクエストを 1 つのサービスに送信し、そのコピーを別のサービスに送信するように、リクエストのミラーリングポリシーを設定できます。

Traffic Director のトラフィックミラーリング。 — Traffic Director によるトラフィックミラーリング（クリックして拡大）

パフォーマンス向上を目的としたきめ細かい負荷分散

アプリケーションの特性によっては、サービスのバックエンド間でトラフィックを分散する方法をきめ細かく制御することで、パフォーマンスと可用性が向上する場合があります。Traffic Director では、必要に応じてトラフィックが分散されるように、高度な負荷分散アルゴリズムを適用できます。

これまでの図とは異なり、次の図には宛先のバックエンドサービス（本番環境のサービス）とそのサービスのバックエンド（仮想マシン 1、仮想マシン 2、仮想マシン 3）があります。高度なトラフィック管理では、宛先バックエンドサービスを選択する仕組みと、その宛先サービスのバックエンド間でトラフィックを分散する仕組みを構成できます。

Traffic Director の負荷分散。 — Traffic Director によるロードバランシング（クリックして拡大）

次のステップ

メッシュの外部からメッシュ内部にトラフィックを転送する方法について、メッシュの上り（内向き）トラフィックで確認する。