高度なトラフィック管理の概要
このドキュメントは、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リソースを構成します。リクエストのルーティング先となるバックエンド サービスを選択します。
必要に応じて、追加のアクションを実行します。
宛先サービスが選択された後、バックエンドとエンドポイント間でトラフィックの分散を制御するように、バックエンド サービスを構成します。
トラフィックのルーティングとアクション
Cloud Service Mesh では、トラフィックは Mesh リソースの値、Route リソースの値、バックエンド サービス リソースの値に基づいてルーティングされます。ルーティングとアクションに関連する高度なトラフィック管理機能は、Route オブジェクトを使用して構成されます。
以降のセクションでは、Route オブジェクトで設定できる高度なトラフィック管理機能について説明します。
リクエスト処理
クライアントがリクエストを送信すると、リクエストは次の順序で処理されます。
リクエストは次のようにを特定の
Routeリソースと照合されます。- Envoy を使用している場合:
- HTTP リクエストのホストヘッダーは各
HTTPRouteリソースまたはGRPCRouteリソースのhostnamesフィールドと照合され、リクエストに適したRouteリソースが選択されます。hostnamesフィールドがあるのは、HTTPRouteリソースとGRPCRouteリソースのみです。 TCPPRouteを使用して TCP トラフィックをルーティングするために、IP アドレスが照合されます。TLSRouteを使用した TLS パススルーに SNI と ALPN が使用されます。MeshまたはGatewayに関連付けられるHTTPRouteリソースとGRPCRouteリソースには、一意のホスト名が必要です。ホスト名が競合する複数のルートを接続しようとすると、構成は拒否されます。- 同様に、
TCPRouteのIP:Portフィールドも一意である必要があります。一意でない場合、構成が拒否されます。 - 同様に、SNI と ALPN も
TLSRouteに対して一意である必要があります。 a.example.comと*.example.comのように重複するホスト名がある場合、リクエストはより具体的なルートに一致します。
- HTTP リクエストのホストヘッダーは各
- プロキシレス gRPC を使用している場合:
- プロキシレス gRPC クライアントでは、
xds名前解決スキームが使用されます。Cloud Service Mesh にリクエストを送信して、ターゲット URI のhostname[:port]を解決します。 GRPCRouteリソースのポートのみがターゲット URI のポート（xds:///example.hostname:8080など）と比較されます。ターゲット URI は、GRPCRouteのhostnamesフィールドの文字列と完全に一致する必要があります。
- プロキシレス gRPC クライアントでは、
- Envoy を使用している場合:
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のホスト名と一致する場合:RouteRuleが次に評価されます。RouteRuleが、トラフィックを一致させる方法と、トラフィックが一致した場合にトラフィックをルーティングする方法を指定します。- 各
RouteRuleには、リクエストのパスに対して評価される 1 つ以上のルート マッチが含まれています。 - 一致が見つかった場合、リクエストは
RouteActionで指定されたサービスに転送されます。
HTTPRoute のリソース フィールドとその仕組みについて詳しくは、ネットワーク サービス API のドキュメントをご覧ください。
高度なルーティングとアクション
リクエストのホストとパスに基づいてリクエストをルーティングする場合、高度なルールを設定してリクエストをルーティングし、アクションを実行できます。
高度なルーティングとアクションの仕組みは次のとおりです。
- 単純なルーティングと同様に、リクエストのホストが
HTTPRouteまたはGRPCRouteで構成したホストルールと照合されます。リクエストのホストがホスト名と一致する場合、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 リクエストのヘッダーとして渡されます。 |
アクション
Cloud Service Mesh では、Envoy プロキシまたはプロキシレス gRPC アプリケーションがリクエストを処理するときに実行するアクションを指定できます。Cloud Service Mesh で構成できるアクションは次のとおりです。
| アクション | 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 のページをご覧ください。
ルートの各ルールでは、次のいずれかのルート アクションを指定できます。
- 単一のサービスへのトラフィックのルーティング（
destination.serviceName） - 複数のサービスへのトラフィックの分割（
destination.weight） - リダイレクト URL（
redirect）
また、前述のルート アクションと次のルート アクション（Google Cloud Console ではアドオン アクションと呼ばれます）を組み合わせることもできます。
- リクエスト ヘッダーまたはレスポンス ヘッダーのアクション（
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）十分に正常でトラフィックを再度受信できると見なされる場合に、バックエンドやエンドポイントを追加し直します。バックエンドやエンドポイントが正常かどうかは、サービスに関連付けられたヘルスチェックにより判断します。 |
トラフィック分散のさまざまな手段とその仕組みについて詳しくは、次のドキュメントをご覧ください。
ユースケースの例
高度なトラフィック管理はさまざまなユースケースに対応しています。このセクションでは、その一部について説明します。
サンプルコードなどその他の例については、Envoy で高度なトラフィック管理を構成するとプロキシレス gRPC サービスを使用して高度なトラフィック管理を構成するをご覧ください。
パーソナライズを目的としたきめ細かいトラフィック ルーティング
リクエストのパラメータに従ってトラフィックをサービスにルーティングできます。このサービスを使用すると、Android ユーザー向けにカスタマイズされたエクスペリエンスを提供することなどができます。次の図では、user-agent:Android ヘッダーを含むリクエストを汎用的なサービスに対してではなく Android サービスに送信するサービス メッシュを Cloud Service Mesh を使用して構成しています。
Android に設定された user-agent ヘッダーに基づくルーティング（クリックして拡大）より安全なデプロイを目的とした重み付けベースのトラフィック分割
既存の本番環境サービスの新しいバージョンを安全にデプロイできるとは限りません。テスト環境で問題が見つからなかったとしても、すべてのユーザーをすぐに新しいバージョンにルーティングしないほうがよい場合もあります。
Cloud Service Mesh を使用すると、重み付けに基づくトラフィック分割を定義して複数のサービスにトラフィックを分散できます。たとえば、トラフィックの 1% を新しいバージョンに送信してモニタリングし、すべて正常に機能していることを確認してから、新しいサービスにルーティングするトラフィックの割合を段階的に増やしていくことができます。
デバッグを目的としたトラフィック ミラーリング
問題をデバッグするときに、本番環境のトラフィックのコピーをデバッグ サービスに送信すると便利な場合があります。Cloud Service Mesh では、リクエストを 1 つのサービスに送信し、そのコピーを別のサービスに送信するように、リクエストのミラーリング ポリシーを設定できます。
パフォーマンス向上を目的としたきめ細かい負荷分散
アプリケーションの特性によっては、サービスのバックエンド間でトラフィックを分散する方法をきめ細かく制御することでパフォーマンスと可用性が向上する場合があります。Cloud Service Mesh では、高度なロード バランシング アルゴリズムを適用して、ニーズに合わせてトラフィックが分散できます。
他の図とは異なり、次の図では宛先のバックエンド サービス（本番環境のサービス）とそのサービスのバックエンド（仮想マシン 1、仮想マシン 2、仮想マシン 3）が存在します。高度なトラフィック管理では、宛先バックエンド サービスを選択する仕組みと、その宛先サービスのバックエンド間でトラフィックを分散する仕組みを構成できます。
Cloud Service Mesh でのロード バランシングについて詳しくは、高度なロード バランシングの概要をご覧ください。
次のステップ
- メッシュの外部からメッシュ内部にトラフィックを転送する方法について、メッシュの上り（内向き）トラフィックを確認する