高度なトラフィック管理の概要
このドキュメントは、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
リソースを構成します。リクエストのルーティング先となるバックエンド サービスを選択します。
必要に応じて、追加のアクションを実行します。
宛先サービスが選択された後、バックエンドとエンドポイント間でトラフィックの分散を制御するように、バックエンド サービスを構成します。
トラフィックのルーティングとアクション
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
など、重複するホスト名がある場合、リクエストはより具体的なルートに一致します。
- HTTP リクエストのホストヘッダーは、各
- プロキシレス gRPC を使用している場合:
- プロキシレス gRPC クライアントは、
xds
名前解決スキームを使用します。Traffic Director にリクエストを送信して、ターゲット URI のhostname[:port]
を解決します。 GRPCRoute
リソースのポートのみが、ターゲット URI のポートと比較されます(例:xds:///example.hostname:8080
)。ターゲット URI は、GRPCRoute
のhostnames
フィールド内の文字列と完全に一致する必要があります。
- プロキシレス gRPC クライアントは、
- Envoy を使用している場合:
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
のホスト名と一致する場合:RouteRule
が次に評価されます。RouteRule
は、トラフィックを照合する方法と、トラフィックが一致したときのトラフィックのルーティング方法を指定します。- 各
RouteRule
には、リクエストのパスに対して評価されるルート一致が 1 つ以上含まれます。 - 一致した場合、リクエストは
RouteAction
で指定されたサービスに転送されます。
HTTPRoute
のリソース フィールドとその仕組みの詳細については、Network Service API のドキュメントをご覧ください。
高度なルーティングとアクション
リクエストのホストとパスに基づいてリクエストをルーティングする場合、高度なルールを設定してリクエストをルーティングし、アクションを実行できます。
高度なルーティングとアクションの仕組みは次のとおりです。
- 単純なルーティングと同様に、リクエストのホストが
HTTPRoute
やGRPCRoute
の URL マップで構成したホストルールと照合されます。リクエストのホストがホスト名と一致する場合は、HTTPRoute
またはGRPCRoute
が評価されます。 - ルートが選択された後に、アクションを適用できます。
高度なルーティング
高度なルーティングは前述の単純なルーティングと似ていますが、追加の一致条件を指定できます。たとえば、リクエストのヘッダーに一致するルールとして、ヘッダーの名前が完全に一致するか、部分的に一致する(接頭辞やサフィックスなど)ものを指定できます。ヘッダー名を正規表現と照合することや、ヘッダーの有無を確認する条件で評価することもできます。
headerMatches
と queryParameterMatches
のその他の一致条件と詳細については、network services
REST API ページをご覧ください。
ホスト、パス、ヘッダー、クエリ パラメータを一致条件と組み合わせることで、トラフィック管理を完全に満たす、きめ細かいルールを作成できます。詳しくは、次の表をご覧ください。
HTTP ベースのアプリケーション | gRPC ベースのアプリケーション | |
---|---|---|
HTTP ホストと gRPC ホストの比較 | ホストは、アプリケーションが呼び出す URL のドメイン名の部分です。 たとえば、URL |
ホストは、クライアントがチャネル URI で特定のサービスに接続するために使用する名前です。 たとえば、チャネル URI |
HTTP パスと gRPC パスの比較 | パスは、URL のホスト名に続く部分です。 たとえば、URL |
パスは HTTP/2 リクエストの たとえば、 |
その他の gRPC ヘッダー(メタデータ) | gRPC は、gRPC クライアントと gRPC サーバー間でメタデータの送信をサポートし、RPC 呼び出しに関する追加情報を提供します。このメタデータは、Key-Value ペアの形式で HTTP/2 リクエストのヘッダーとして渡されます。 |
アクション
Traffic Director では、Envoy プロキシまたはプロキシレス gRPC アプリケーションがリクエストを処理するときに実行するアクションを指定できます。Traffic Director を使用することで、次のアクションを構成できます。
アクション | API フィールド名 | 説明 |
---|---|---|
リダイレクト | redirect |
構成可能な 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 サービスに送信するサービス メッシュを構成しています。
より安全なデプロイを目的とした重み付けベースのトラフィック分割
既存の本番環境サービスの新しいバージョンを安全にデプロイできるとは限りません。テスト環境で問題が見つからなかったとしても、すべてのユーザーをすぐに新しいバージョンにルーティングしないほうがよい場合もあります。
Traffic Director を使用すると、重み付けベースのトラフィック分割を定義し、複数のサービスにトラフィックを分散できます。たとえば、トラフィックの 1% を新しいバージョンに送信してモニタリングし、すべて正常に機能していることを確認してから、新しいサービスにルーティングするトラフィックの割合を段階的に増やしていくことができます。
デバッグを目的としたトラフィック ミラーリング
問題をデバッグするときに、本番環境のトラフィックのコピーをデバッグ サービスに送信すると便利な場合があります。Traffic Director では、リクエストを 1 つのサービスに送信し、そのコピーを別のサービスに送信するように、リクエストのミラーリング ポリシーを設定できます。
パフォーマンス向上を目的としたきめ細かい負荷分散
アプリケーションの特性によっては、サービスのバックエンド間でトラフィックを分散する方法をきめ細かく制御することで、パフォーマンスと可用性が向上する場合があります。Traffic Director では、必要に応じてトラフィックが分散されるように、高度な負荷分散アルゴリズムを適用できます。
これまでの図とは異なり、次の図には宛先のバックエンド サービス(本番環境のサービス)とそのサービスのバックエンド(仮想マシン 1、仮想マシン 2、仮想マシン 3)があります。高度なトラフィック管理では、宛先バックエンド サービスを選択する仕組みと、その宛先サービスのバックエンド間でトラフィックを分散する仕組みを構成できます。
次のステップ
- メッシュの外部からメッシュ内部にトラフィックを転送する方法について、メッシュの上り(内向き)トラフィックで確認する。