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

このドキュメントは、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 を使用するメッシュで使用できます。プロキシレス gRPC サービスまたは Cloud Service Mesh でアプリケーションを使用する場合は、このドキュメントで説明している機能の一部が使用できません。
  • バックエンド サービスRoute リソースが関連付けられています。

構成

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

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

  1. サービス メッシュを識別する Mesh リソースを構成します。
  2. 送信リクエストの特性に基づいて、次の処理を行うように Route リソースを構成します。

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

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

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

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

Cloud Service Mesh では、Mesh リソース、Route リソース、バックエンド サービス リソースの値に基づいてトラフィックがルーティングされます。ルーティングとアクションに関連する高度なトラフィック管理機能は、Route オブジェクトを使用して構成します。

以降のセクションでは、Route オブジェクトで設定できる高度なトラフィック管理機能について説明します。

リクエスト処理

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

  1. 次のように、リクエストを特定の Route リソースと照合します。

    • Envoy を使用している場合:
      • HTTP リクエストのホストヘッダーは、各 HTTPRoute リソースまたは GRPCRoute リソースの hostnames フィールドと照合され、リクエストに正しい Route リソースが選択されます。hostnames フィールドがあるのは、HTTPRoute リソースと GRPCRoute リソースのみです。
      • この IP アドレスは、TCPPRoute を使用して TCP トラフィックをルーティングするために照合されます。
      • SNI と ALPN は TLSRoute を使用した TLS パススルーに使用されます。
      • Mesh または Gateway に関連付けられる HTTPRoute リソースと GRPCRoute リソースには、一意であるホスト名が必要です。競合するホスト名を持つ複数のルートを接続しようとすると、構成は拒否されます。
      • 同様に、TCPRouteIP: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 は、GRPCRoutehostnames フィールド内の文字列と完全に一致する必要があります。
  2. Route リソースには、さらにルーティング情報とルールを含めることができます。

  3. 宛先のバックエンド サービスが選択されると、トラフィックは、バックエンド サービス リソースの構成に基づいて、そのバックエンド サービスの複数のバックエンドやエンドポイントに分散されます。

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 のドキュメントをご覧ください。

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

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

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

  1. 単純なルーティングと同様に、リクエストのホストが HTTPRouteGRPCRoute の URL マップで構成したホストルールと照合されます。リクエストのホストがホスト名と一致する場合は、HTTPRoute または GRPCRoute が評価されます。
  2. ルートが選択された後に、アクションを適用できます。

高度なルーティング

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

headerMatchesqueryParameterMatches のその他の一致条件と詳細については、network services REST API ページをご覧ください。

ホスト、パス、ヘッダー、クエリ パラメータを一致条件と組み合わせることで、トラフィック管理を完全に満たす、きめ細かいルールを作成できます。詳しくは、次の表をご覧ください。

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 リクエストのヘッダーとして渡されます。

アクション

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

アクション API フィールド名 説明
リダイレクト redirect [pathredirect?] 構成可能な 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 1Backend 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 ユーザー向けにカスタマイズされたエクスペリエンスを提供できます。次の図では、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)があります。高度なトラフィック管理では、宛先バックエンド サービスを選択する仕組みと、その宛先サービスのバックエンド間でトラフィックを分散する仕組みを構成できます。

Cloud Service Mesh の負荷分散。
Cloud Service Mesh による負荷分散(クリックして拡大)

Cloud Service Mesh による負荷分散の詳細については、高度な負荷分散の概要をご覧ください。

次のステップ