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

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

  • リクエストを 1 つまたは複数のサービスに転送するきめ細かいルーティング
  • リダイレクトやヘッダー変換など、リクエスト / レスポンス ベースのアクション
  • サービスのバックエンド間でのきめ細かいトラフィック分散(負荷分散の改善のため)

これらの高度なトラフィック管理機能は、可用性とパフォーマンスの目標を実現する際に役立ちます。このようなユースケースに Traffic Director を使用することで、アプリケーション コードを変更せずにトラフィックの管理方法を更新できます。

ユースケースの例

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

サンプルコードなど、ここに記載されていない例については、高度なトラフィック管理の構成高度なトラフィック管理で VM ベースのプロキシレス 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 による負荷分散(クリックして拡大)

高度なトラフィック管理の仕組み

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

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

  1. 送信リクエストの特性に基づいて、次の処理を行うようにルーティング ルール マップを構成します。

    1. リクエストのルーティング先となるバックエンド サービスを選択します。

    2. 必要に応じて、追加のアクションを実行します。

  2. 宛先サービスが選択された後、バックエンドとエンドポイント間でトラフィックの分散を制御するように、サービス(バックエンド サービス)を構成します。

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

Traffic Director では、ルーティング ルール マップは、転送ルール、ターゲット プロキシ、URL マップリソースから構成されます。ルーティングとアクションに関連する高度なトラフィック管理機能は、URL マップを使用して構成します。

ルーティング ルール マップには、高度なトラフィック管理の次の機能を設定できます。

リクエスト処理

クライアントが送信したリクエストは次のように処理されます。

  1. 特定のルーティング ルール マップとリクエストを照合します。この照合は次のように行われます。
    1. Envoy を使用している場合:
      1. リクエストの宛先 IP アドレスとポートが、ルーティング ルール マップの転送ルールに指定されている IP アドレス / ポートと照合されます。負荷分散スキームに INTERNAL_SELF_MANAGED が設定されている転送ルールを含むルーティング ルール マップだけが対象になります。
      2. 転送ルールがリクエストに一致すると、ターゲット HTTP プロキシまたは gRPC プロキシが参照され、このプロキシから URL マップが参照されます。この URL マップに、ルーティングとアクションに使用される情報が含まれています。
    2. プロキシレス gRPC を使用している場合:
      1. リクエストの IP アドレスは無視されます。ターゲット gRPC プロキシを参照する転送ルールを作成する場合、使用できる IP アドレスは 0.0.0.0 だけです。負荷分散スキームに INTERNAL_SELF_MANAGED が設定されている転送ルールを含むルーティング ルール マップだけが対象になります。
      2. ターゲット URI のポート(xds:///foo.myservice:8080 など)が、負荷分散スキームが INTERNAL_SELF_MANAGED の転送ルールに指定されたポートと照合されます。転送ルールの IP アドレスは使用されません。
      3. 転送ルールがリクエストに一致すると、ターゲット gRPC プロキシが参照され、このプロキシから URL マップが参照されます。この URL マップに、ルーティングとアクションに使用される情報が含まれています。
  2. 適切な URL マップが見つかると、その URL マップが評価され、宛先のバックエンド サービスが特定されます。また、必要に応じてアクションが適用されます。
  3. 宛先のバックエンド サービスが選択されると、トラフィックは、バックエンド サービス リソースの構成に基づいて、そのバックエンド サービスのバックエンドまたはエンドポイント間で分散されます。

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. パスマッチャーが評価されます。
  2. 各パスマッチャーには、リクエストのパスに対して評価される 1 つ以上のパスルールが定義されています。
  3. 一致した場合、リクエストはパスルールで指定されたサービスにルーティングされます。
  4. 各パスマッチャーにはデフォルト サービスが定義されています。ホストルールが一致してもパスルールが一致しない場合、このサービスにリクエストがルーティングされます。

リクエストが、指定したホストルールのいずれとも一致しない場合、リクエストはデフォルト ルールに指定されているサービスにルーティングされます。

URL マップリソースのフィールドとその機能の詳細については、urlMaps REST API のページをご覧ください。

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

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

高度なルーティング(クリックして拡大)
高度なルーティング(クリックして拡大)

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

  1. 単純なルーティングと同様に、リクエストのホストが URL マップで構成したホストルールと照合されます。リクエストのホストがホストルールと一致した場合、ホストルールのパスマッチャーが評価されます。
  2. パスマッチャーには、リクエストに対して評価される 1 つ以上のルートルールが定義されています。
    1. このルートルールは、特定の一致条件(接頭辞の一致など)に従ってリクエスト属性(ホスト、パス、ヘッダー、クエリ パラメータ)を比較し、優先度に従って評価されます。
  3. ルートルールが選択された後、アクションが適用される場合があります。デフォルトのアクションは、リクエストを 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 リファレンスをご覧ください。

フィルタリング構成

Traffic Director の主な役割の 1 つは、構成を生成して、その構成をさまざまな Traffic Director クライアント(Envoy プロキシや gRPC アプリケーションなど)に送信することです。Traffic Director は、クライアントに構成を送信することでサービス メッシュを制御し、クライアントに必要な指示を行います。つまり、Traffic Director はコントロール プレーンです。

Traffic Director で構成を作成または更新すると、Traffic Director により、この構成はクライアントが理解できる言語に変換されます。デフォルトでは、Traffic Director はこの構成をすべてのクライアントと共有します。また、特定の構成を受け取る Traffic Director クライアントを調整できます。つまり、特定のクライアントに構成をフィルタリングできます。

これは高度な機能ですが、次のような場合は、構成のフィルタリングが便利です。

  • 組織で共有 VPC ネットワーキング モデルを使用し、複数のチームが別々のサービス プロジェクトで Traffic Director を使用している。構成を他のサービス プロジェクトから分離する場合は、特定の Traffic Director クライアントが構成のサブセットのみを受け取るように構成をフィルタリングします。
  • Traffic Director で非常に多くのルーティング ルールとサービスを構成しており、すべての Traffic Director クライアントに大量の構成を送信したくない。大規模で複雑な構成を使用して送信リクエストを評価する必要がある場合、単純な構成でリクエストを評価する場合よりもパフォーマンスが低下する可能性があります。

構成フィルタリングは、メタデータ フィルタのコンセプトに基づいています。

  1. Traffic Director クライアントが接続すると、ブートストラップ ファイルから Traffic Director に情報が提供されます。
  2. この情報には、Envoy プロキシまたは gRPC アプリケーションをデプロイするときにブートストラップ ファイルに指定するメタデータ フィールドのコンテンツが Key-Value ペアの形式で含まれています。
  3. ルーティング ルール マップで構成した転送ルールやルートルールにメタデータ フィルタを追加できます。
  4. これらのリソースにメタデータ フィルタを追加すると、Traffic Director は、メタデータ フィルタ条件に一致するメタデータを含むクライアントにのみ構成を提供します。

メタデータ フィルタは転送ルールに適用できます。この場合、ルーティング ルール マップと関連サービスは、一致するメタデータを示す Traffic Director クライアントとのみ共有されます。

特定のルートルールにメタデータ フィルタを適用することもできます。この場合、Traffic Director は特定のルーティング ルールと関連サービスを、一致するメタデータを示す Traffic Director クライアントと共有します。メタデータ フィルタの構成方法については、MetadataFilter 一致に基づく構成フィルタリングの設定をご覧ください。

制限事項

  • Traffic Director でプロキシレス gRPC サービスを使用する場合、このドキュメントで説明している一部の機能は構成できません。サポートされている機能については、ルーティングとトラフィック管理負荷分散Traffic Director の機能の他の表をご覧ください。

  • Traffic Director でプロキシレス gRPC アプリケーションを使用する場合に適用されるその他の制限については、概要ガイドの制限事項をご覧ください。

次のステップ