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

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

このドキュメントは、Cloud Service Mesh とサービスメッシュのコンセプトについて、中級から上級レベルの知識を持ち、Cloud Service Mesh のデプロイにおけるトラフィックの管理方法を決定および構成するメッシュまたはプラットフォーム管理者とサービスデベロッパーを対象としています。

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

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

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

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

Mesh リソース。サービスメッシュを識別し、トラフィックの転送とポリシーの適用を担うコンポーネントを表します。Mesh リソースは、トラフィックインターセプトポートも識別します。
Gateway リソース。中間プロキシを識別し、IP address:port ペアのリストをリッスンしてトラフィックを転送し、ポリシーを適用するコンポーネントを表します。
Route リソース。複数のタイプがあり、メッシュのトラフィックルーティング情報が含まれます。Route リソースは、クライアントがバックエンドサービスにトラフィックを転送するために使用できるホスト名とポートを識別します。Route リソースのタイプは次のとおりです。
- HTTPRoute。Envoy プロキシを使用するメッシュでのみ使用できます。HTTPRoute リソースを使用して Envoy プロキシを構成し HTTP リクエストを送信する場合は、このドキュメントのすべての機能を使用できます。
- TCPRoute。Envoy プロキシを使用するメッシュでのみ使用できます。
- TLSRoute。Envoy プロキシを使用するメッシュでのみ使用できます。
- GRPCRoute。Envoy サイドカープロキシとプロキシレス gRPC を使用するメッシュで使用できます。Cloud Service Mesh でプロキシレス gRPC サービスまたはアプリケーションを使用する場合、このドキュメントで説明する一部の機能は使用できません。
バックエンドサービス。Route リソースが関連付けられています。

構成

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

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

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

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

Cloud Service Mesh では、トラフィックは 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 名前解決スキームを使用します。Cloud Service Mesh にリクエストを送信して、ターゲット URI の hostname[:port] を解決します。
  - GRPCRoute リソースのポートのみが、ターゲット URI のポート（xds:///example.hostname:8080 など）と比較されます。ターゲット URI は、GRPCRoute の hostnames フィールドの文字列と完全に一致する必要があります。
Route リソースには、その他のルーティング情報とルールを含めることができます。
宛先のバックエンドサービスが選択されると、トラフィックは、バックエンドサービスリソースの構成に基づいて、そのバックエンドサービスの複数のバックエンドやエンドポイントに分散されます。

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

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

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

リクエストのホストとは、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 のリソースフィールドとその仕組みの詳細については、ネットワークサービス 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 リクエストのヘッダーとして渡されます。

アクション

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

アクション	API フィールド名	説明
リダイレクト	`redirect [pathredirect?]`	構成可能な 3xx レスポンスコードが返されます。`Location` レスポンスヘッダーに適切な URI を設定すると、リダイレクトアクションで指定されたホストとパスが置き換わります。
URL の書き換え	`urlRewrite`	選択したバックエンドサービスにリクエストを送信する前に、URL のホスト名部分、URL のパス部分、またはその両方を書き換えます。
ヘッダー変換	`requestHeaderModifier/responseHeaderModifier?`	リクエストヘッダーを追加または削除してから、バックエンドサービスにリクエストを送信します。バックエンドサービスからレスポンスを受信した後にレスポンスヘッダーを追加または削除することもできます。
トラフィックのミラーリング	`requestMirrorPolicy`	選択したバックエンドサービスにリクエストを転送するだけでなく、構成済みのミラーバックエンドサービスに「ファイアアンドフォーゲット」方式で同じリクエストを送信します。ロードバランサは、ミラーリングされたリクエストを送信するバックエンドからのレスポンスを待ちません。ミラーリングは、バックエンドサービスの新しいバージョンのテストに利用できます。また、本番環境バージョンではなくバックエンドサービスのデバッグ環境バージョンで本番環境のエラーをデバッグすることもできます。
重み付けに基づくトラフィック分割	`weightDestination.serviceName`	個々のバックエンドサービスに割り当てられたユーザー定義の重み付けに応じて、一致したルールのトラフィックを複数のバックエンドサービスに分散できます。この機能は、段階的なデプロイや 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`	バックエンドが良好な状態で処理能力があれば、特定のクライアントからのリクエストを可能な限り同じバックエンドに送信します。 Cloud Service Mesh では、クライアント IP アドレス、HTTP Cookie ベース、HTTP ヘッダーベース、生成された Cookie アフィニティ（Cloud Service Mesh がそれ自身を生成したもの）の 4 つのセッションアフィニティオプションをサポートしています。
コンシステントハッシュ	`consistentHash`	HTTP ヘッダー、Cookie、その他のプロパティに基づくソフトセッションアフィニティを提供します。
サーキットブレーカー	`circuitBreakers`	バックエンドサービスへの接続量と接続あたりのリクエスト数の上限を設定します。
外れ値検出	`outlierDetection`	（1）正常でないバックエンドやエンドポイントを MIG や NEG から除外し、（2）十分に正常でトラフィックを再度受信できると見なされる場合に、バックエンドやエンドポイントを追加し直します。バックエンドやエンドポイントが正常かどうかは、サービスに関連付けられたヘルスチェックにより判断します。

トラフィック分散のさまざまな手段とその仕組みについては、次のドキュメントをご覧ください。

backendServices REST API ページ
バックエンドサービスの概要

ユースケースの例

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

サンプルコードなどの他の例については、Envoy で高度なトラフィック管理を構成するとプロキシレス 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 では、リクエストを 1 つのサービスに送信し、そのコピーを別のサービスに送信するように、リクエストのミラーリングポリシーを設定できます。

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

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

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

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

Cloud Service Mesh でのロードバランシングの詳細については、高度なロードバランシングの概要をご覧ください。

次のステップ

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