Anthos Service Mesh と Traffic Director は Cloud Service Mesh になりました。詳細については、Cloud Service Mesh の概要をご覧ください。

ロードバランシング API の高度なトラフィック管理の概要

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

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

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

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

ターゲット HTTP プロキシを使用して Envoy プロキシを構成し HTTP リクエストを送信する場合は、このドキュメントのすべての機能を使用できます。
Cloud Service Mesh でプロキシレス gRPC サービスまたはアプリケーションを使用する場合は、一部の機能が使用できなくなります。
ターゲット TCP プロキシを使用して Envoy プロキシを構成し TCP リクエストを送信する場合は、ターゲット TCP プロキシを使用した構成に URL マップがないため、使用できる機能はありません。

詳細については、機能ページをご覧ください。

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

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

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

フィルタリング構成

Cloud Service Mesh の主な役割の 1 つは、転送ルール、ターゲットプロキシ、URL マップから構成情報を生成し、その情報を Cloud Service Mesh クライアント（Envoy プロキシや gRPC など）に送信することです。Cloud Service Mesh は、動作方法とトラフィックのルーティング方法を示す構成情報をクライアントに送ることでサービスメッシュを制御します。つまり、Cloud Service Mesh はコントロールプレーンです。

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

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

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

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

Cloud Service Mesh クライアントが接続すると、ブートストラップファイルから Cloud Service Mesh に情報が提供されます。
この情報には、Envoy プロキシや gRPC アプリケーションをデプロイするときにブートストラップファイルに指定するメタデータフィールドのコンテンツが Key-Value ペアの形式で含まれています。
メタデータフィルタは転送ルールに追加できます。転送ルールにリンクされた構成全体がフィルタされます。
メタデータフィルタを URL マップに追加できます。メタデータフィルタは、パスごとのルーティング基準で適用されます。
Cloud Service Mesh は、メタデータフィルタ条件に一致するメタデータを提示するクライアントにのみ構成を共有します。

Envoy のメタデータフィルタを構成する方法については、MetadataFilter の一致に基づいて構成フィルタリングを設定するをご覧ください。

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

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

以降のセクションでは、ルーティングルールマップで設定できる高度なトラフィック管理機能について説明します。

リクエスト処理

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

次のように、リクエストを特定のルーティングルールマップと照合します。
- Envoy を使用している場合:
  - リクエストの宛先 IP アドレスとポートが、ルーティングルールマップの転送ルールに指定されている IP アドレス / ポートと照合されます。負荷分散スキームに INTERNAL_SELF_MANAGED が設定されている転送ルールを含むルーティングルールマップだけが対象になります。
  - 転送ルールがリクエストに一致すると、ターゲット HTTP プロキシまたは gRPC プロキシが参照され、このプロキシから URL マップが参照されます。この URL マップに、ルーティングとアクションに使用される情報が含まれています。
- プロキシレス gRPC を使用している場合:
  - xds 名前解決スキームを使用する gRPC クライアントでは、チャネル URI のホスト名を解決するための DNS ルックアップは実行しません。このようなクライアントは、Cloud Service Mesh に LDS リクエストを送信して、ターゲット URI にある hostname[:port] を解決します。
  - 負荷分散スキームが INTERNAL_SELF_MANAGED の転送ルールのポートのみが、ターゲット URI のポートと比較されます（例: xds:///example.hostname:8080）。転送ルールの IP アドレスは使用されません。ターゲット URI にポートが指定されていない場合、ポートのデフォルト値は 80 です。
  - 転送ルールがリクエストに一致すると、ターゲット gRPC プロキシが参照され、このプロキシから URL マップが参照されます。この URL マップに、ルーティングとアクションに使用される情報が含まれています。
  - 複数の転送ルールがリクエストと一致する場合、ターゲット URI の hostname[:port] と一致するホストルールを含む URL マップが、ルーティングとアクションに使用されます。
適切な URL マップが見つかると、その URL マップが評価され、宛先のバックエンドサービスが特定されます。また、必要に応じてアクションが適用されます。
宛先のバックエンドサービスが選択されると、トラフィックは、バックエンドサービスリソースの構成に基づいて、そのバックエンドサービスの複数のバックエンドやエンドポイントに分散されます。

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

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

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

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

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

グローバル転送ルール
ターゲット HTTP プロキシ、ターゲット HTTPS プロキシ、またはターゲット gRPC プロキシ
URL マップ

構成のほとんどは、URL マップで行われます。最初のルーティングルールマップを作成した後は、ルーティングルールマップの URL マップ部分を変更するだけで済みます。次の図では、パスルールのアクションが次の図のアクションに類似しています。

ホストとパスのリソースに基づくルーティング。 — ホストとパスリソースに基づくルーティング（クリックして拡大）

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

リクエストのホスト（example.com など）がホストルールと一致する場合:
1. パスマッチャーが評価されます。
2. 各パスマッチャーには、リクエストのパスに対して評価される 1 つ以上のパスルールが定義されています。
3. 一致した場合、リクエストはパスルールで指定されたサービスに転送されます。
4. ホストルールが一致してもパスルールが一致しない場合、リクエストは各パスマッチャーに含まれているデフォルトサービスに転送されます。
リクエストが、指定したホストルールのいずれとも一致しない場合は、リクエストはデフォルトルールに指定されているサービスに転送されます。

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

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

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

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

単純なルーティングと同様に、リクエストのホストが URL マップで構成したホストルールと照合されます。リクエストのホストがホストルールと一致した場合、ホストルールのパスマッチャーが評価されます。
パスマッチャーには、リクエストに対して評価される 1 つ以上のルートルールが定義されています。このルートルールは、特定の一致条件（接頭辞の一致など）に従ってリクエスト属性（ホスト、パス、ヘッダー、クエリパラメータ）を比較し、優先度に従って評価されます。
ルートルールが選択された後に、アクションを適用できます。デフォルトのアクションは、リクエストを 1 つの宛先サービスにルーティングするものですが、別のアクションを構成することもできます。

高度なルーティング

高度なルーティングは前述の単純なルーティングと似ていますが、ルールの優先度と追加の一致条件を指定できます。

高度なルーティングの場合、各ルールに一意の優先度を指定する必要があります。この優先度により、ルートルールの評価順が決まります。優先度の低いルールは、優先度の高いルールよりも先に処理されます。リクエストがルールに一致すると、そのルールが適用され、他のルールは無視されます。

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

headerMatches と queryParameterMatches のその他の一致条件と詳細については、urlMaps 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 リクエストのヘッダーとして渡されます。

アクション

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

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

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

各ルートルールでは、次のいずれかのルートアクション（Google Cloud Console ではプライマリアクションと呼ばれます）を指定できます。

1 つのサービスへのトラフィックのルーティング（service）
複数のサービスへのトラフィックの分割（weightedBackendServices）
リダイレクト URL（urlRedirect）

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

リクエスト / レスポンスヘッダーの処理（headerAction）
トラフィックのミラーリング（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`	バックエンドが良好な状態で処理能力があれば、特定のクライアントからのリクエストを可能な限り同じバックエンドに送信します。 Cloud Service Mesh は、クライアント IP アドレス、HTTP Cookie ベース、HTTP ヘッダーベース、生成された Cookie アフィニティ（Cloud Service Mesh がそれ自身を生成したもの）の 4 つのセッションアフィニティオプションをサポートしています。
コンシステントハッシュ	`consistentHash`	HTTP ヘッダー、Cookie、その他のプロパティに基づくソフトセッションアフィニティを提供します。
サーキットブレーカー	`circuitBreakers`	バックエンドサービスへの接続量と接続あたりのリクエスト数の上限を設定します。
外れ値検出	`outlierDetection`	（1）正常でないバックエンドやエンドポイントを MIG や NEG から除外し、（2）十分に正常でトラフィックを再度受信できると見なされる場合に、バックエンドやエンドポイントを追加し直します。バックエンドやエンドポイントが正常かどうかは、サービスに関連付けられたヘルスチェックにより判断します。

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

ユースケースの例

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

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

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

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

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

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

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

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

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

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

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

Cloud Service Mesh のトラフィックミラーリング。 — Cloud Service Mesh のトラフィックミラーリング（クリックして拡大）

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

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

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

次のステップ

URL マップの詳細について、URL マップの概要と URL マップの使用で確認する。
メッシュの外部からメッシュ内部にトラフィックを転送する方法については、メッシュの上り（内向き）トラフィックをご覧ください。
サイドカープロキシデプロイを使用して機能を設定する方法について、Envoy を使用して高度なトラフィック管理を構成するで確認する。
プロキシレス gRPC デプロイを使用して機能を設定する方法について、プロキシレス gRPC サービスを使用した高度なトラフィック管理を構成するで確認する。