Traffic Director は、トラフィックの処理方法をきめ細かく制御できる高度なトラフィック管理機能を提供します。Traffic Director は、次のようなユースケースに対応しています。
- リクエストを 1 つまたは複数のサービスに転送するきめ細かいルーティング
- リダイレクトやヘッダー変換など、リクエスト / レスポンス ベースのアクション
- サービスのバックエンド間でのきめ細かいトラフィック分散（負荷分散の改善のため）
これらの高度なトラフィック管理機能は、可用性とパフォーマンスの目標を実現する際に役立ちます。このようなユースケースに Traffic Director を使用することで、アプリケーション コードを変更せずにトラフィックの管理方法を更新できます。
ユースケースの例
高度なトラフィック管理はさまざまなユースケースに対応しています。このセクションでは、その一部を説明します。
サンプルコードなど、ここに記載されていない例については、高度なトラフィック管理の構成と高度なトラフィック管理で VM ベースのプロキシレス gRPC サービスを設定するをご覧ください。
パーソナライズを目的としたきめ細かいトラフィック ルーティング
リクエストのパラメータに従ってトラフィックをサービスにルーティングできます。たとえば、この機能を使用すると、Android ユーザー向けにカスタマイズされたエクスペリエンスを提供できます。次の図では、Traffic Director を使用して、汎用的なサービスではなく、user-agent:Android ヘッダーを含むリクエストを Android サービスに送信するサービス メッシュを構成しています。
Android に設定された user-agent ヘッダーに基づくルーティング（クリックして拡大）より安全なデプロイを目的とした重み付けベースのトラフィック分割
既存の本番環境サービスの新しいバージョンを安全にデプロイできるとは限りません。テスト環境で問題が見つからなかったとしても、すべてのユーザーをすぐに新しいバージョンにルーティングしないほうがよい場合もあります。
Traffic Director を使用すると、重み付けベースのトラフィック分割を定義し、複数のサービスにトラフィックを分散できます。たとえば、トラフィックの 1% を新しいバージョンに送信してモニタリングし、すべて正常に機能していることを確認してから、新しいサービスにルーティングするトラフィックの割合を段階的に増やしていくことができます。
デバッグを目的としたトラフィック ミラーリング
問題をデバッグするときに、本番環境のトラフィックのコピーをデバッグ サービスに送信すると便利な場合があります。Traffic Director では、リクエストを 1 つのサービスに送信し、そのコピーを別のサービスに送信するように、リクエストのミラーリング ポリシーを設定できます。
パフォーマンス向上を目的としたきめ細かい負荷分散
アプリケーションの特性によっては、サービスのバックエンド間でトラフィックを分散する方法をきめ細かく制御することで、パフォーマンスと可用性が向上する場合があります。Traffic Director では、必要に応じてトラフィックが分散されるように、高度な負荷分散アルゴリズムを適用できます。
これまでの図とは異なり、次の図には宛先のバックエンド サービス（本番環境のサービス）とそのサービスのバックエンド（仮想マシン 1、仮想マシン 2、仮想マシン 3）があります。高度なトラフィック管理を使用すると、宛先のバックエンド サービスの選択方法と、その宛先サービスのバックエンド間でトラフィックを分散する方法を構成できます。
高度なトラフィック管理の仕組み
Traffic Director を設定するときに、ルーティング ルール マップとバックエンド サービス リソースを使用して高度なトラフィック管理を構成します。Traffic Director は、Envoy プロキシとプロキシレス gRPC アプリケーションを構成し、この高度なトラフィック管理のポリシーを適用します。
大まかな流れは次のとおりです。
送信リクエストの特性に基づいて、次の処理を行うようにルーティング ルール マップを構成します。
リクエストのルーティング先となるバックエンド サービスを選択します。
必要に応じて、追加のアクションを実行します。
宛先サービスが選択された後、バックエンドとエンドポイント間でトラフィックの分散を制御するように、サービス（バックエンド サービス）を構成します。
トラフィックのルーティングとアクション
Traffic Director では、ルーティング ルール マップは、転送ルール、ターゲット プロキシ、URL マップリソースから構成されます。ルーティングとアクションに関連する高度なトラフィック管理機能は、URL マップを使用して構成します。
ルーティング ルール マップには、高度なトラフィック管理の次の機能を設定できます。
リクエスト処理
クライアントが送信したリクエストは次のように処理されます。
- 特定のルーティング ルール マップとリクエストを照合します。この照合は次のように行われます。
- Envoy を使用している場合:
- リクエストの宛先 IP アドレスとポートが、ルーティング ルール マップの転送ルールに指定されている IP アドレス / ポートと照合されます。負荷分散スキームに
INTERNAL_SELF_MANAGEDが設定されている転送ルールを含むルーティング ルール マップだけが対象になります。 - 転送ルールがリクエストに一致すると、ターゲット HTTP プロキシまたは gRPC プロキシが参照され、このプロキシから URL マップが参照されます。この URL マップに、ルーティングとアクションに使用される情報が含まれています。
- リクエストの宛先 IP アドレスとポートが、ルーティング ルール マップの転送ルールに指定されている IP アドレス / ポートと照合されます。負荷分散スキームに
- プロキシレス gRPC を使用している場合:
- リクエストの IP アドレスは無視されます。ターゲット gRPC プロキシを参照する転送ルールを作成する場合、使用できる IP アドレスは
0.0.0.0だけです。負荷分散スキームにINTERNAL_SELF_MANAGEDが設定されている転送ルールを含むルーティング ルール マップだけが対象になります。 - ターゲット URI のポート（xds:///foo.myservice:8080 など）が、負荷分散スキームが
INTERNAL_SELF_MANAGEDの転送ルールに指定されたポートと照合されます。転送ルールの IP アドレスは使用されません。 - 転送ルールがリクエストに一致すると、ターゲット gRPC プロキシが参照され、このプロキシから URL マップが参照されます。この URL マップに、ルーティングとアクションに使用される情報が含まれています。
- リクエストの IP アドレスは無視されます。ターゲット gRPC プロキシを参照する転送ルールを作成する場合、使用できる IP アドレスは
- Envoy を使用している場合:
- 適切な URL マップが見つかると、その URL マップが評価され、宛先のバックエンド サービスが特定されます。また、必要に応じてアクションが適用されます。
- 宛先のバックエンド サービスが選択されると、トラフィックは、バックエンド サービス リソースの構成に基づいて、そのバックエンド サービスのバックエンドまたはエンドポイント間で分散されます。
2 番目のステップについては、次のセクション、ホストとパスに基づく単純なルーティングで説明します。3 番目のステップは、高度なルーティングとアクションで説明します。
ホストとパスに基づく単純なルーティング
Traffic Director は、高度なスキームだけでなく、単純なルーティング スキームもサポートしています。アクションを含む高度なルーティング スキームについては、次のセクション、高度なルーティングとアクションで説明します。単純なスキームでは、ホストとパス（省略可）を指定します。リクエストのホストとパスが評価され、リクエストのルーティング先となるサービスが決まります。
- リクエストのホストは、URL のドメイン名の部分になります。たとえば、URL
http://example.com/video/でホスト部分はexample.comです。 - リクエストのパスは、URL でホスト名に続く部分になります。たとえば、
http://example.com/videoでは/videoです。
ホストとパスに基づく単純なルーティングの設定
ホストとパスに基づく単純なルーティングは、ルーティング ルール マップに設定します。次の情報を指定します。
- グローバル転送ルール
- ターゲット HTTP プロキシまたはターゲット gRPC プロキシ
- URL マップ
ほとんどの構成は URL マップで行います。通常、最初のルーティング ルール マップを作成した後は、ルーティング ルール マップの URL マップの部分だけを変更します。次の図のパスルールには、次のセクションで説明する図と類似したアクションが設定されています。
最も単純なルールはデフォルト ルールです。このルールでは、ホストルールにワイルドカード（*）を指定し、パスマッチャーにデフォルトのサービスを指定するだけです。デフォルト ルールを作成した後、異なるホストとパスを指定するルールを追加できます。これらのルールにより、送信リクエストが次のように評価されます。
リクエストのホスト（example.com など）がホストルールと一致する場合:
- パスマッチャーが評価されます。
- 各パスマッチャーには、リクエストのパスに対して評価される 1 つ以上のパスルールが定義されています。
- 一致した場合、リクエストはパスルールで指定されたサービスにルーティングされます。
- 各パスマッチャーにはデフォルト サービスが定義されています。ホストルールが一致してもパスルールが一致しない場合、このサービスにリクエストがルーティングされます。
リクエストが、指定したホストルールのいずれとも一致しない場合、リクエストはデフォルト ルールに指定されているサービスにルーティングされます。
URL マップリソースのフィールドとその機能の詳細については、urlMaps REST API のページをご覧ください。
高度なルーティングとアクション
リクエストのホストとパスに基づいてリクエストをルーティングする場合、高度なルールを設定してリクエストをルーティングし、アクションを実行できます。
高度なルーティングとアクションの仕組みは次のとおりです。
- 単純なルーティングと同様に、リクエストのホストが URL マップで構成したホストルールと照合されます。リクエストのホストがホストルールと一致した場合、ホストルールのパスマッチャーが評価されます。
- パスマッチャーには、リクエストに対して評価される 1 つ以上のルートルールが定義されています。
- このルートルールは、特定の一致条件（接頭辞の一致など）に従ってリクエスト属性（ホスト、パス、ヘッダー、クエリ パラメータ）を比較し、優先度に従って評価されます。
- ルートルールを選択すると、アクションが適用される場合があります。デフォルトのアクションは、リクエストを 1 つの宛先サービスにルーティングするものですが、別のアクションを構成することもできます。
高度なルーティング
高度なルーティングは、前述の単純なルーティングと似ていますが、以下で説明するように、ルールの優先度と追加の一致条件を指定できます。
高度なルーティングの場合、各ルールに一意の優先度を指定する必要があります。この優先度により、ルートルールの評価順が決まります。優先度の低いルールは、優先度の高いルールよりも先に処理されます。リクエストがルールに一致すると、そのルールが適用され、他のルールは無視されます。
高度なルーティングでは、追加の一致条件を設定できます。たとえば、ヘッダーの名前が完全に一致するか、部分的に一致する場合（接頭辞やサフィックスなど）にルールがリクエストのヘッダーと一致するように指定できます。ヘッダー名を正規表現と照合することもできます。また、ヘッダーの有無を確認する条件で評価することもできます。
ホスト、パス、ヘッダー、クエリ パラメータを優先度と一致条件と組み合わせることで、トラフィック管理を完全に満たす、きめ細かいルールを作成できます。
HTTP ホストと gRPC ホスト
HTTP ベースのアプリケーションを作成する場合は、アプリケーションが呼び出す URL のドメイン名の部分がホストになります。たとえば、URL http://example.com/video/ でホスト部分は example.com です。
gRPC ベースのアプリケーションを作成する場合は、クライアントが特定のサービスに接続するためにチャネル URI で使用する名前がホストになります。たとえば、チャネル URI xds:///example.com のホスト部分は example.com です。
HTTP パスと gRPC パス
HTTP ベースのアプリケーションを作成する場合、URL でホスト名に続く部分がパスになります（たとえば、http://example.com/video の /video）。
gRPC ベースのアプリケーションを作成する場合、パスは 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 フィールド名） | 説明 |
|---|---|
リダイレクト（urlRedirect） |
構成可能な 3xx レスポンス コードが返されます。Location レスポンス ヘッダーに適切な URI を設定すると、リダイレクト アクションで指定されたホストとパスが置き換わります。 |
URL の書き換え（urlRewrite） |
選択したバックエンド サービスにリクエストを送信する前に、URL のホスト名部分、URL のパス部分、またはその両方を書き換えます。 |
ヘッダー変換（headerAction） |
リクエスト ヘッダーを追加または削除してから、バックエンド サービスにリクエストを送信します。バックエンド サービスからレスポンスを受信した後にレスポンス ヘッダーを追加または削除することもできます。 |
トラフィックのミラーリング（requestMirrorPolicy） |
選択したバックエンド サービスにリクエストを転送するだけでなく、構成済みのミラー バックエンド サービスに「ファイア アンド フォーゲット」方式で同じリクエストを送信します。ロードバランサは、ミラーリングされたリクエストを送信するバックエンドからのレスポンスを待ちません。 ミラーリングは、バックエンド サービスの新しいバージョンのテストに利用できます。また、本番環境バージョンではなくバックエンド サービスのデバッグ環境バージョンで本番環境のエラーをデバッグすることもできます。 |
重み付けに基づくトラフィック分割（weightedBackendServices） |
個々のバックエンド サービスに割り当てられたユーザー定義の重み付けに応じて、一致したルールのトラフィックを複数のバックエンド サービスに分散できます。 この機能は、段階的なデプロイや A/B テストの構成に利用できます。たとえば、トラフィックの 99% をアプリケーションの安定バージョンを実行しているサービスに送信し、残りの 1% を同じアプリケーションの新しいバージョンを実行している別のサービスに送信するようにルート アクションを構成できます。 |
再試行回数（retryPolicy） |
ロードバランサが失敗したリクエストを再試行する条件、再試行までのロードバランサの待機時間、再試行の最大回数を構成します。 |
タイムアウト（timeout） |
選択したルートのタイムアウトを指定します。タイムアウトは、リクエストが完全に処理されてからレスポンスが完全に処理されるまでの時間です。タイムアウトにはすべての再試行が含まれます。 |
フォールト インジェクション（faultInjectionPolicy） |
高レイテンシ、サービス過負荷、サービス障害、ネットワーク パーティショニングなどの障害をシミュレートするリクエストを処理する際にエラーを発生させます。この機能は、サービスの復元力を疑似的にテストするために利用できます。 |
セキュリティ ポリシー（corsPolicy） |
クロスオリジン リソース シェアリング（CORS）ポリシーが、CORS リクエストを適用するために設定を処理します。 |
アクションの詳細とその仕組みについては、URL マップ API リファレンスをご覧ください。
各ルートルールで、次のいずれかのルート アクションを指定できます（Google Cloud Console では、このアクションをプライマリ アクションといいます）。
- 1 つのサービスへのトラフィックのルーティング（
service）。 - 複数のサービスへのトラフィックの分割（
weightedBackendServices）。 - リダイレクト URL（
urlRedirect）
また、前述のルート アクションと次のルート アクション（Google Cloud Console ではアドオン アクション）を 1 つ以上組み合わせることができます。
- リクエスト / レスポンス ヘッダーの処理（
headerAction） - トラフィックのミラーリング（
requestMirrorPolicy） - URL ホスト / パスの書き換え（
urlRewrite） - 失敗したリクエストの再試行（
retryPolicy） - タイムアウトの設定（
timeout） - フォールトを挿入するトラフィックの割合（
faultInjectionPolicy） - CORS ポリシーの追加（
corsPolicy）
アクションは特定のルートルールに関連付けられているため、Envoy プロキシまたはプロキシレス gRPC アプリケーションは、処理中のリクエストに基づいて異なるアクションを適用できます。
サービスのバックエンド間でのトラフィック分散
リクエストの処理で説明しているように、クライアントは送信リクエストを処理するときに宛先サービスを選択します。宛先サービスを選択したら、リクエストを受信するバックエンド / エンドポイントを特定する必要があります。
上の図では Rule と簡単に表していますが、この部分は通常、ホストルール、パスマッチャー、1 つ以上のパスルールまたはルートルールになります。宛先サービスは (Backend) Service です。Backend 1、…、Backend n が実際にリクエストを受け取り、処理します。サーバー側のアプリケーション コードをホストする Compute Engine 仮想マシンなどがバックエンドになります。
デフォルトでは、リクエストを処理するクライアントは、最も近くにあり、正常で容量が足りているバックエンドにリクエストを送信します。特定のバックエンドに負荷をかけないように、ラウンドロビン負荷分散アルゴリズムを使用して、宛先サービスのバックエンド間で後続のリクエストを負荷分散します。ただし、この動作をより細かく制御しなければならない場合もあります。
負荷分散、セッション アフィニティ、バックエンドの保護
各サービスに次のトラフィック分散ポリシーを設定できます。
| ポリシー（API フィールド名） | 説明 |
|---|---|
負荷分散モード（balancingMode） |
宛先サービスが選択された後に、ネットワーク エンドポイント グループまたはマネージド インスタンス グループが選択される方法を制御します。同時接続数やリクエスト率などに基づいて負荷を分散するように分散モードを構成できます。 |
負荷分散ポリシー（localityLbPolicy） |
ネットワーク エンドポイント グループまたはマネージド インスタンス グループ内のバックエンド間でトラフィックを分散するために使用する負荷分散アルゴリズムを設定します。さまざまなアルゴリズム（ラウンドロビン、最小リクエストなど）を選択してパフォーマンスを最適化できます。 |
セッション アフィニティ（sessionAffinity） |
セッション アフィニティでは、バックエンドが良好な状態で処理能力があれば、特定のクライアントからのリクエストを可能な限り同じバックエンドに送信します。Traffic Director は、クライアント IP アドレス、HTTP Cookie ベース、HTTP ヘッダーベース、Traffic Director によって生成される Cookie アフィニティの 4 種類のセッション アフィニティ オプションをサポートしています。 |
コンシステント ハッシュ（consistentHash） |
HTTP ヘッダー、Cookie、その他のプロパティに基づくソフト セッション アフィニティを提供します。 |
サーキット ブレーカー（circuitBreakers） |
バックエンド サービスへの接続量と接続あたりのリクエスト数の上限を設定します。 |
外れ値検出（outlierDetection） |
（1）マネージド インスタンス グループまたはネットワーク エンドポイント グループから正常でないバックエンドまたはエンドポイントを削除し、（2）トラフィックを受信できると判断された場合にバックエンドまたはエンドポイントを追加する条件を指定します。バックエンドまたはエンドポイントが正常とみなされるかどうかは、サービスに関連付けられたヘルスチェックによって決まります。 |
トラフィック分散オプションとその仕組みについては、バックエンド サービスの API リファレンスをご覧ください。
次のステップ
- 高度なトラフィック管理の構成で、これらの機能をサイドカー プロキシのデプロイで設定する方法を確認する。
- 高度なトラフィック管理で VM ベースのプロキシレス gRPC サービスを設定するで、これらの機能をプロキシレス gRPC のデプロイで使用する方法を確認する。