内部 HTTP(S) ロードバランサのトラフィック管理の概要

内部 HTTP(S) 負荷分散は高度なトラフィック管理機能をサポートしており、次の機能を使用できます。
  • トラフィック ステアリング。HTTP(S) パラメータ(ホスト、パス、ヘッダー、その他のリクエスト パラメータ)に基づいてトラフィックをインテリジェントにルーティングします。
  • トラフィック アクション。リクエストとレスポンスに基づいてアクションを実行します(リダイレクト、ヘッダー変換など)。
  • トラフィック ポリシー。負荷分散の動作を微調整します。たとえば、高度な負荷分散アルゴリズムを使用します。

これらの機能は、URL マップとバックエンド サービスを使用して設定できます。詳しくは次の記事をご覧ください。

ユースケースの例

トラフィック管理には多くのユースケースがあります。このセクションでは、そのいくつかについて説明します。

トラフィック ステアリング: ヘッダーに基づくルーティング

トラフィック ステアリングを使用すると、リクエスト ヘッダーなどの HTTPS パラメータに基づいてサービス インスタンスにトラフィックを転送できます。たとえば、ユーザーのデバイスがモバイル デバイスで、リクエスト ヘッダーに user-agent:Mobile が含まれている場合、トラフィック ステアリングはモバイル トラフィックを処理するサービス インスタンスにトラフィックを送信します。user-agent:Mobile を含まないトラフィックは、モバイル以外のデバイスからのトラフィックを処理するインスタンスに送信します。

Cloud Load Balancing トラフィック ステアリング(クリックして拡大)
Cloud Load Balancing トラフィック ステアリング

トラフィック アクション: 重み付けに基づくトラフィック分割

一般に、本番環境のサービスの新しいバージョンをデプロイする場合、なんらかのリスクが伴います。ステージング環境のテストに合格しても、すべてのユーザーをすぐに新しいバージョンに移行できるとは限りません。内部 HTTP(S) 負荷分散では、割合を定義して複数のバックエンド サービス間でトラフィックを分割できます。

たとえば、トラフィックの 95% をサービスの前のバージョンに送信し、5% を新しいバージョンに送信できます。新しいバージョンが本番環境で問題なく機能することが確認できたら、サービスの新しいバージョンに送信するトラフィックの量を 100% に到達するまで段階的に増やしていくことができます。トラフィック分割は通常、新しいバージョンのデプロイ、A/B テスト、サービス移行などのプロセスに使用されます。

Cloud Load Balancing トラフィック分割
Cloud Load Balancing トラフィック分割

トラフィック ポリシー: リクエストのミラーリング

組織によっては、すべてのトラフィックを別のサービスにミラーリングし、あとで検証できるようにリクエストの詳細をデータベースに記録することがコンプライアンス要件で義務付けられている場合があります。

トラフィック管理のコンポーネント

内部 HTTP(S) 負荷分散では、リージョン URL マップリージョン バックエンド サービスのリソースを使用してトラフィック管理を行います。

トラフィック ステアリングとトラフィック アクションの設定には、リージョン URL マップを使用します。URL マップに関連する Google Cloud リソースには次のものがあります。

  • ルートルール
  • ルールとの一致
  • ルールのアクション

トラフィック ポリシーの設定には、リージョン バックエンド サービスを使用します。バックエンド サービスに関連する Google Cloud リソースには次のものがあります。

  • 局所的なロードバランサ ポリシー
  • 一貫したハッシュ ロードバランサ設定
  • サーキット ブレーカー
  • 外れ値検出
次の図に、各機能の実装に使用されるリソースを示します。

Cloud Load Balancing トラフィック ステアリング(クリックして拡大)
Cloud Load Balancing データモデル(クリックして拡大)

バックエンドへのリクエストのルーティング

内部 HTTP(S) 負荷分散では、トラフィックのバックエンドは次の 2 段階で決定されます。

  • ロードバランサがバックエンドを含むバックエンド サービスを選択します。バックエンドは、非マネージド インスタンス グループの Compute Engine 仮想マシン(VM)インスタンスかマネージド インスタンス グループ(MIG)の Compute Engine VM です。また、ネットワーク エンドポイント グループ(NEG)の Google Kubernetes Engine(GKE)ノードのコンテナの場合もあります。ロードバランサが、リージョン URL マップで定義されたルールに基づいてバックエンド サービスを選択します。
  • バックエンド サービスが、リージョン バックエンド サービスで定義されたポリシーに基づいてバックエンド インスタンスを選択します。

ルーティングを構成するときに、次のモードを選択できます。

  • 単純なホストとパスのルール
  • 詳細なホスト、パス、ルートのルール

URL マップごとに、単純なホストとパスのルールを使用できます。また、ホスト、パス、ルートの詳細ルールを使用することもできます。この 2 つのモードは相互に排他的です。1 つの URL マップに含めることができるのは片方のモードだけです。

単純なホストとパスのルール

単純なホストとパスのルールの場合、URL マップは URL マップの概要の説明どおりに動作します。

次の図は、単純なホストとパスのルールの論理的なフローを示しています。

単純な URL マップのフロー
単純な URL マップのフロー

リクエストは、最初にホストルールで評価されます。ホストは、リクエストで指定されたドメインです。リクエスト hosthosts フィールドのエントリの 1 つに一致すると、関連するパスマッチャーが使用されます。

次に、パスマッチャーが評価されます。パスルールは最長パス一致基準で評価され、任意の順序で指定できます。最も狭い範囲の一致が見つかると、リクエストは対応するバックエンド サービスに転送されます。リクエストが一致しない場合、デフォルトのバックエンド サービスが使用されます。

単純なホストとパスのルールは次のようになります。この例では、動画トラフィックが video-backend-service に転送され、その他のトラフィックは web-backend-service に転送されます。

$ gcloud compute url-maps describe l7-ilb-map
defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: l7-ilb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: regions/us-west1/backendServices/video-backend-service
region: regions/us-west1

詳細なホスト、パス、ルートのルール

詳細なホスト、パス、ルートのルールでは、単純なルールよりも多くの構成オプションを設定できます。これらのオプションを使用すると、より高度なトラフィック管理パターンを設定できます。また、セマンティクスの一部も変更できます。たとえば、ルートルールに優先度を関連付けている場合、最長一致のセマンティクスではなく、優先度に基づいてルールが解釈されます。

前述の単純なホストとパスのルールの例と同様に、リージョン URL マップを使用して高度なトラフィック管理を構成できます。たとえば、次の URL マップでは、トラフィックの 95% が 1 つのバックエンド サービスにルーティングされ、残りの 5% が別のバックエンド サービスにルーティングされます。

$ gcloud compute url-maps describe l7-ilb-map
defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: l7-ilb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/service-a
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: ''
    routeAction:
      weightedBackendServices:
      - backendService: regions/us-west1/backendServices/service-a
        weight: 95
      - backendService: regions/us-west1/backendServices/service-b
        weight: 5
region: regions/us-west1

ホストルール

リクエストがロードバランサに到達すると、URL マップで定義された hostRules に基づいてリクエストの host フィールドが評価されます。各ホストルールは、1 つ以上のホストと 1 つのパスマッチャー(pathMatcher)のリストで構成されます。hostRules が定義されていない場合、リクエストは defaultService にルーティングされます。

詳細については、リージョン URL マップ API ドキュメントhostRules[]defaultService をご覧ください。

パスマッチャー

リクエストがホストルールに一致すると、ロードバランサはそのホストに対応するパスマッチャーを評価します。

パスマッチャーは次の要素で構成されます。

  • 1 つ以上のパスルール(pathRules)またはルートルール(routeRules)。
  • デフォルト サービス(defaultService)。一致するバックエンド サービスがない場合に使用されるデフォルトのバックエンド サービスです。
詳細については、リージョン URL マップ API ドキュメントpathMatchers[]pathMatchers[].pathRules[]pathMatchers[].routeRules[] をご覧ください。

パスのルール

パスのルール(pathRules)には 1 つ以上の URL パスを指定します(たとえば、//video など)。パスルールは通常、前述の単純なホストとパスベースのルーティングに使用します。

詳細については、リージョン URL マップ API ドキュメントpathRules[] をご覧ください。

ルートルール

ルートルール(routeRules)では、受信したリクエストの中から一致するものを見つけて、その一致に基づいてルーティングを行います。

ルートルールには、異なる一致ルール(matchRules)とルート アクション(routeAction)を含めることができます。

一致ルールは、HTTP(S) リクエストのパス、ヘッダー、クエリ パラメータに基づいて受信リクエストを評価します。一致ルールでは、さまざまなタイプの一致(プレフィックス一致など)と修飾子(大文字と小文字の区別など)を使用できます。たとえば、カスタム定義の HTTP ヘッダーの有無に応じて、一連のバックエンドに HTTP(S) リクエストを送信できます。

複数のルートルールがある場合、ロードバランサは優先度(priority フィールド)に基づいてルールを処理します。この場合、一致、ルーティングなどのアクションにカスタム ロジックを指定できます。

特定のルートルールで最初の一致が見つかると、ロードバランサは一致ルールの評価を停止し、残りの一致ルールはすべて無視されます。

Google Cloud は次のアクションを実行します。

  1. リクエストに一致する最初の一致ルールを検索します。
  2. 他の一致ルールの検索を停止します。
  3. 対応するルート アクションのアクションを適用します。

次の表に示すように、ルートルールには複数のコンポーネントがあります。

ルートルールのコンポーネント(API field name 説明
優先度(priority 特定のパスマッチャーのルートルールに割り当てられる 0~2,147,483,647(つまり (2^31)-1)の数値。

優先度により、ルートルールの評価順序が決まります。ルールの優先度は、その数が大きくなるほど低くなります。優先度が 4 のルールは、優先度が 25 のルールより先に評価されます。最初にリクエストに一致したルールが適用されます。

優先度の番号にはギャップがあります。複数のルールに同じ優先度を設定することはできません。
説明(description 任意の説明で、1,024 文字まで使用できます。
サービス(service このルールが一致した場合にトラフィックが転送されるバックエンド サービス リソースの URL(完全な URL または URL の一部)。
一致ルール(matchRules リクエストの評価で使用される 1 つ以上のルール。これらの matchRules は、パス、HTTP ヘッダー、クエリ(GET)パラメータなどのリクエストの HTTP 属性の一部またはすべてに一致します。

routeRulerouteActions が有効になるには、matchRule ですべての一致条件を満たす必要があります。routeRule に複数の matchRules がある場合、リクエストが routeRulematchRules のすべてに一致すると、routeRulerouteActions が有効になります。
ルート アクション(routeAction 一致ルールの条件を満たしたときに実行するアクションを指定できます。トラフィック分割、URL 書き換え、再試行とミラーリング、フォールト インジェクション、CORS ポリシーなどがあります。
リダイレクト アクション(urlRedirect 一致ルールの条件を満たしたときに、HTTP リダイレクトで応答するアクションを構成できます。このフィールドは、ルート アクションと一緒に使用することはできません。
ヘッダー アクション(headerAction matchRules 内の条件を満たしたときに適用されるリクエストとレスポンスのヘッダー変換ルールを構成できます。

詳細については、リージョン URL マップ API ドキュメントの以下のフィールドをご覧ください。

  • routeRules[]
  • routeRules[].priority
  • routeRules[].description
  • routeRules[].service
  • routeRules[].matchRules[]
  • routeRules[].routeAction
  • routeRules[].urlRedirect
  • routeRules[].headerAction

一致ルール

一致ルール(matchRules)はリクエストの 1 つ以上の属性と照合され、ルートルールで指定されたアクションを実行します。以下では、一致ルールを使用して照合できるリクエスト属性の例を示します。

  • ホスト: ホスト名は URL のドメイン名の部分です。たとえば、http://example.net/video/hd という URL では example.net がホスト名になります。この curl コマンドの例のように、リクエストではホスト名は Host から取得されます。10.1.2.9 は負荷分散された IP アドレスです。

    curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
    
  • パスの後にホスト名が続きます(例: /images)。このルールは、パス全体またはパスの先頭部分のみの一致を照合できます。

  • HTTP ヘッダーなど、他の HTTP リクエスト パラメータ。これにより、Cookie の照合やクエリ パラメータ(GET 変数)に基づく照合を行うことができます。

サポートされている一致ルールの一覧については、リージョン URL マップ API ドキュメントpathMatchers[].routeRules[].matchRules[] をご覧ください。

ルート アクション

ルート アクションは、ルートルールがリクエストの属性と一致した場合に実行される特定のアクションです。

ルート アクション(API field name 説明
リダイレクト(urlRedirect 構成可能な 3xx レスポンス コードを返します。また、Location レスポンス ヘッダーに適切な URI を設定し、リダイレクト アクションの指定に従ってホストとパスを置き換えます。
URL の書き換え(urlRewrite 選択したバックエンド サービスにリクエストを送信する前に、URL のホスト名部分、パス部分、またはその両方を書き換えます。
ヘッダー変換(headerAction リクエスト ヘッダーを追加または削除してから、バックエンド サービスにリクエストを送信します。バックエンド サービスからレスポンスを受信した後にレスポンス ヘッダーを追加または削除することもできます。
トラフィックのミラーリング(requestMirrorPolicy 選択したバックエンド サービスにリクエストを転送するだけでなく、構成済みのミラー バックエンド サービスに「ファイア アンド フォーゲット」方式で同じリクエストを送信します。ロードバランサは、ミラーリングされたリクエストを送信するバックエンドからのレスポンスを待機しません。

ミラーリングは、バックエンド サービスの新しいバージョンをテストする際に利用できます。また、本番環境バージョンではなくバックエンド サービスのデバッグ環境バージョンで本番環境のエラーをデバッグすることもできます。
重み付けによるトラフィック分割(weightedBackendServices 個々のバックエンド サービスに割り当てられたユーザー定義の重み付けに応じて、一致したルールのトラフィックを複数のバックエンド サービスに分散できます。

この機能は、段階的なデプロイや A/B テストの構成に利用できます。たとえば、トラフィックの 99% をアプリケーションの安定バージョンを実行しているサービスに送信し、残りの 1% を同じアプリケーションの新しいバージョンを実行している別のサービスに送信するようにルート アクションを構成できます。
再試行回数(retryPolicy ロードバランサが失敗したリクエストを再試行する条件、再試行までのロードバランサの待機時間、再試行の最大回数を構成します。
タイムアウト(timeout 選択したルートのタイムアウトを指定します。タイムアウトは、リクエストが完全に処理されてからレスポンスが完全に処理されるまでの時間です。タイムアウトにはすべての再試行が含まれます。
フォールト インジェクション(faultInjectionPolicy 高レイテンシ、サービス過負荷、サービス障害、ネットワーク パーティショニングなどの障害をシミュレートするリクエストを処理する際にエラーを発生させます。この機能は、サービスの復元力を疑似的にテストするために利用できます。
遅延インジェクション(faultInjectionPolicy リクエストのユーザー定義部分に遅延が発生し、選択したバックエンド サービスにリクエストが送信されます。
中断インジェクション(faultInjectionPolicy ユーザー定義の HTTP ステータス コードを含むリクエストをバックエンド サービスに転送せず、そうしたリクエストの一部に直接応答します。
セキュリティ ポリシー(corsPolicy クロスオリジン リソース シェアリング(CORS)ポリシーが、CORS リクエストを適用するため内部 HTTP(S) 負荷分散設定を処理します。

次のいずれかのルート アクションを指定できます(Google Cloud Console では、プライマリ アクションと表示されます)。

  • トラフィックを 1 つのサービス(service)にルーティングします。
  • 複数のサービス間でトラフィックを分割します(weightedBackendServices weight:x、x <100)。
  • リダイレクト URL(urlRedirect

また、前述のルート アクションと次のルート アクション(Cloud Console ではアドオン アクションと表示されます)を組み合わせることもできます。

  • トラフィックのミラーリング(requestMirrorPolicy
  • URL ホスト / パスの書き換え(urlRewrite
  • 失敗したリクエストの再試行(retryPolicy
  • タイムアウトの設定(timeout
  • フォールトを挿入するトラフィックの割合(faultInjectionPolicy
  • CORS ポリシーの追加(corsPolicy
  • リクエスト / レスポンス ヘッダーの処理(headerAction

ルート アクションの構成とセマンティクスの詳細については、リージョン URL マップ API ドキュメントで以下の項目をご覧ください。

  • urlRedirect
  • urlRewrite
  • headerAction
  • requestMirrorPolicy
  • weightedBackendServices
  • retryPolicy
  • timeout
  • faultInjectionPolicy
  • corsPolicy

トラフィック ポリシー

バックエンド サービス リソースを使用すると、トラフィック グループ ポリシーを構成し、インスタンス グループまたはネットワーク エンドポイント グループ(NEG)内の負荷分散を細かく調整できます。これらのポリシーは、前述のリージョン URL マップでバックエンド サービスが選択された場合にのみ適用されます。

トラフィック ポリシーを使用すると、次のことができます。

  • バックエンド サービス内のインスタンス間で負荷分散アルゴリズムを制御する。
  • アップストリーム サービスへの接続量を制御する。
  • バックエンド サービスからの異常なホストのエビクションを制御する。

以下のトラフィック ポリシー機能は、リージョン バックエンド サービスで構成されます。

トラフィック ポリシー(API field name 説明
負荷分散ポリシー(LocalityLbPolicy バックエンド サービスの場合、トラフィック分散は負荷分散モードと負荷分散ポリシーに基づいて行われます。

まず、バックエンド サービスがバックエンドの分散モードに従ってバックエンド(インスタンス グループまたは NEG)にトラフィックを転送します。バックエンドが選択されると、負荷分散ポリシーに従ってバックエンド サービス内のインスタンス間でトラフィックが分散されます。

負荷分散モードの場合、ロードバランサは最初に Google Cloud ゾーンなどの範囲を選択します。負荷分散ポリシーにより、NEG 内の特定のバックエンド VM またはエンドポイントが選択されます。

さまざまな負荷分散アルゴリズム(ラウンドロビン、最小リクエストなど)がサポートされています。アルゴリズムの一覧については、リージョン バックエンド サービス API ドキュメントlocalityLbPolicy をご覧ください。
セッション アフィニティ(consistentHash HTTP Cookie ベースのアフィニティ、HTTP ヘッダーベースのアフィニティ、クライアント IP アドレス アフィニティ、生成された Cookie アフィニティなどがあります。セッション アフィニティにより、バックエンドが良好な状態で処理能力があれば、特定のクライアントからのリクエストが可能な限り同じバックエンドに送信されます。

セッション アフィニティの詳細については、リージョン サービス API ドキュメントconsistentHash をご覧ください。
外れ値検出(outlierDetection NEG の正常でないバックエンド VM またはエンドポイントのエビクションの基準を指定する一連のポリシーです。バックエンドまたはエンドポイントがトラフィックを再度受信するのに十分な状態とみなす条件も指定します。

セッション アフィニティの詳細については、リージョン バックエンド サービス API ドキュメントoutlierDetection をご覧ください。
サーキット ブレーク(circuitBreakers バックエンド サービスへの接続量と接続あたりのリクエスト数の上限を設定します。

セッション アフィニティの詳細については、リージョン バックエンド サービス API ドキュメントcircuitBreakers をご覧ください。

制限事項

  • RouteRule.service は、現在は機能していません。この問題を回避するには、RouteRule.weightedBackendServices を単一の WeightedBackendService と一緒に使用します。
  • 内部 HTTP(S) 負荷分散ではパスの正規表現 pathMatchers.routeRules.matchRules.regexMatch はサポートされません。
  • UrlMap.defaultRouteActionUrlMap.defaultUrlRedirect は、現在は機能していません。この UrlMapUrlMap.hostRules[] のいずれのホストにも一致しないトラフィックを処理するため、UrlMap.defaultService を指定する必要があります。
  • UrlMap.pathMatchers[].defaultRouteActionUrlMap.pathMatchers[].defaultUrlRedirect は現在は機能していません。この pathMatcherrouteRules のいずれにも一致しないトラフィックを処理するため、UrlMap.pathMatchers[].defaultService を指定する必要があります。
  • BackendService.SessionAffinity の値が NONE でない場合、BackendService.localityLbPolicyMAGLEV または RING_HASH 以外の負荷分散ポリシーに設定され、セッション アフィニティの設定は適用されません。
  • gcloud compute backend-services import コマンドは、バックエンド サービスや URL マップなど、リソースの最上位フィールドを削除しません。たとえば、バックエンド サービスを作成し、circuitBreakers を設定する場合、これらの設定を後続の gcloud compute backend-services import コマンドで更新できます。ただし、これらの設定をバックエンド サービスから削除することはできません。リソースを削除して、circuitBreakers の設定なしで再作成できます。

次のステップ