内部アプリケーション ロードバランサのトラフィック管理の概要

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

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

ユースケースの例

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

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

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

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

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

一般に、本番環境のサービスの新しいバージョンをデプロイする場合、なんらかのリスクが伴います。ステージング環境のテストに合格したとしても、すべてのユーザーをすぐに新しいバージョンに移行しない方が安全です。トラフィック管理では、複数のバックエンド サービス間で割合に基づいてトラフィック分割を定義できます。

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

Cloud Load Balancing トラフィック分割。
図 2. Cloud Load Balancing トラフィック分割(クリックして拡大)。

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

組織によっては、すべてのトラフィックを追加のサービス(たとえば後で再現できるようにリクエストの詳細をデータベースに記録するサービスなど)にミラーリングすることがコンプライアンス要件で義務付けられている場合があります。

Service Extension による機能拡張

Service Extensions コールアウトを使用すると、ロード バランシング データパスにカスタム ロジックを挿入できます。これらの拡張機能を使用すると、データの処理中にユーザー管理のアプリケーションやサービスに対して gRPC 呼び出しを行うように、サポートされているアプリケーション ロードバランサに指示できます。

詳細については、Service Extensions の概要をご覧ください。

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

簡単に言うと、ロードバランサでは、リージョン URL マップリージョン バックエンド サービス リソースを使用してトラフィックを管理します。

クロスリージョン内部アプリケーション ロードバランサの場合、トラフィック管理では、グローバル URL マップグローバル バックエンド サービス リソースを使用します。

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

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

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

  • サーキット ブレーカー
  • 局所的なロードバランサ ポリシー
  • コンシステント ハッシュ法によるロードバランサ設定
  • 外れ値検出

次の図に、各機能の実装に使用されるリソースを示します。

Cloud Load Balancing データモデル。
図 3. Cloud Load Balancing データモデル(クリックして拡大)

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

リージョン内部アプリケーション ロードバランサでは、トラフィックのバックエンドは次の 2 段階の手法で決定されます。

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

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

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

この 2 つのモードは相互に排他的です。1 つの URL マップに含めることができるのは片方のモードだけです。

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

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

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

単純なホストとパスのルールを使用した URL マップのフロー。
図 4. 単純なホストとパスのルールを使用した URL マップのフロー(クリックして拡大)。

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

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

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

gcloud compute url-maps describe lb-map
defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: lb-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 lb-map
defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: lb-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) リクエストを送信できます。

注: 一致オプションとセマンティクスは、リクエストのどの部分と照合するのかによって異なります。詳細については、リージョン URL マップ API ドキュメントmatchRules[] をご覧ください。

複数のルートルールがある場合、ロードバランサは優先度(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 が有効になるには、1 つの matchRule 内のすべての一致条件を満たす必要があります。routeRule に複数の matchRules がある場合、リクエストが routeRule のいずれかの matchRules に一致すると、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 のホスト名部分、URL のパス部分、またはその両方を書き換えます。
ヘッダー変換(headerAction リクエスト ヘッダーを追加または削除してから、バックエンド サービスにリクエストを送信します。バックエンド サービスからレスポンスを受信した後にレスポンス ヘッダーを追加または削除することもできます。
トラフィックのミラーリング(requestMirrorPolicy

選択したバックエンド サービスにリクエストを転送するだけでなく、構成済みのミラー バックエンド サービスに「ファイア アンド フォーゲット」方式で同じリクエストを送信します。ロードバランサは、ミラーリングされたリクエストを送信するバックエンドからのレスポンスを待機しません。

ミラーリングは、バックエンド サービスの新しいバージョンをテストする際に利用できます。また、本番環境バージョンではなくバックエンド サービスのデバッグ環境バージョンで本番環境のエラーをデバッグすることもできます。

重み付けによるトラフィック分割(weightedBackendServices 個々のバックエンド サービスに割り当てられたユーザー定義の重み付けに応じて、一致したルールのトラフィックを複数のバックエンド サービスに分散できます。

この機能は、段階的なデプロイや A/B テストの構成に利用できます。たとえば、トラフィックの 99% をアプリケーションの安定版を実行しているサービスに送信し、残りの 1% を同じアプリケーションの新しいバージョンを実行している別のサービスに送信するようにルート アクションを構成できます。
再試行回数(retryPolicy

ロードバランサが失敗したリクエストを再試行する条件、再試行までのロードバランサの待機時間、再試行の最大回数を構成します。

タイムアウト(timeout 選択したルートのタイムアウトを指定します。タイムアウトは、リクエストが完全に処理されてからレスポンスが完全に処理されるまでの時間です。タイムアウトにはすべての再試行が含まれます。
フォールト インジェクション(faultInjectionPolicy 高レイテンシ、サービス過負荷、サービス障害、ネットワーク パーティショニングなどの障害をシミュレートするリクエストを処理する際にエラーを発生させます。この機能は、サービスの復元力を疑似的にテストするために利用できます。
遅延インジェクション(faultInjectionPolicy リクエストのユーザー定義部分に遅延が発生し、選択したバックエンド サービスにリクエストが送信されます。
中断インジェクション(faultInjectionPolicy ユーザー定義の HTTP ステータス コードを含むリクエストをバックエンド サービスに転送せず、そうしたリクエストの一部に直接応答します。
セキュリティ ポリシー(corsPolicy クロスオリジン リソース シェアリング(CORS)ポリシーが、CORS リクエストを適用するために設定を処理します。

次のいずれかのルート アクションを指定できます。

  • 1 つのサービスへのトラフィックの転送(service
  • 複数のサービス間でのトラフィックの分割(weightedBackendServices weight:x、X は 0~1,000)
  • リダイレクト URL(urlRedirect

また、前述のルート アクションと次のルート アクションを組み合わせることもできます。

  • トラフィックのミラーリング(requestMirrorPolicy
  • URL ホストとパスの書き換え(urlRewrite
  • 失敗したリクエストの再試行(retryPolicy
  • タイムアウトの設定(timeout
  • フォールトを挿入するトラフィックの割合(faultInjectionPolicy
  • CORS ポリシーの追加(corsPolicy
  • リクエスト ヘッダーまたはレスポンス ヘッダーの操作(headerAction
ルート アクションの構成とセマンティクスの詳細については、リージョン URL マップ API ドキュメントで以下の項目をご覧ください。
  • urlRedirect
  • urlRewrite
  • headerAction
  • requestMirrorPolicy
  • weightedBackendServices
  • retryPolicy
  • timeout
  • faultInjectionPolicy
  • corsPolicy

HTTP から HTTPS へのリダイレクト

HTTP トラフィックを HTTPS にリダイレクトする必要がある場合は、共通の IP アドレスを持つ 2 つの転送ルールを作成できます。

共通の内部 IP アドレスを共有する 2 つの転送ルールには、IP アドレスを予約して --purpose=SHARED_LOADBALANCER_VIP フラグを指定する必要があります。

gcloud compute addresses create NAME \
    --region=us-west1 \
    --subnet=backend-subnet \
    --purpose=SHARED_LOADBALANCER_VIP

詳細な例については、内部アプリケーション ロードバランサの HTTP から HTTPS へのリダイレクトを設定するをご覧ください。

トラフィック ポリシー

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

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

  • バックエンド サービス内のインスタンス間でロード バランシング アルゴリズムを制御する。
  • アップストリーム サービスへの接続量を制御する。
  • バックエンド サービスからの異常なホストのエビクションを制御する。
以下のトラフィック ポリシー機能は、リージョン バックエンド サービスで構成されます。
トラフィック ポリシー(API field name 説明
ロード バランシングの局所性ポリシー(LocalityLbPolicy

バックエンド サービスの場合、トラフィック分散はロード バランシング モードとロード バランシングの局所性ポリシーに基づいて行われます。

分散モードでは、各バックエンド(インスタンス グループまたは GCE_VM_IP_PORT NEG)に送信するトラフィックの重みと割合を決定します。ロード バランシング ポリシー(LocalityLbPolicy)により、ゾーン内またはグループ内のバックエンドのロード バランシング方法が決まります。トラフィックを受信すると、バックエンド サービスはバックエンドの分散モードに従ってバックエンド(インスタンス グループまたは GCE_VM_IP_PORT NEG)にトラフィックを転送します。バックエンドが選択されると、局所性ポリシーに従って各ゾーン内のインスタンスまたはエンドポイント間でトラフィックが分散されます。リージョン マネージド インスタンス グループの場合、局所性ポリシーは各構成ゾーンに適用されます。

サポートされている分散モードについては、分散モードをご覧ください。

サポートされているロード バランシング ポリシー アルゴリズムについては、リージョン バックエンド サービス API ドキュメントlocalityLbPolicy をご覧ください。

セッション アフィニティ(consistentHash

HTTP Cookie ベースのアフィニティ、HTTP ヘッダーベースのアフィニティ、クライアント IP アドレス アフィニティ、生成された Cookie アフィニティなどがあります。セッション アフィニティにより、バックエンドが良好な状態で処理能力があれば、特定のクライアントからのリクエストが可能な限り同じバックエンドに送信されます。

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

外れ値検出(outlierDetection

NEG の正常でないバックエンド VM またはエンドポイントのエビクションの基準、バックエンドまたはエンドポイントでトラフィックを再度受信するのに正常だと考えられるタイミングを定義する基準を指定するためのポリシーのセットです。

外れ値検出の詳細については、リージョン バックエンド サービス API ドキュメントoutlierDetection をご覧ください。

サーキット ブレーク(circuitBreakers

バックエンド サービスへの接続量と接続あたりのリクエスト数の上限を設定します。

サーキット ブレークの詳細については、リージョン バックエンド サービス API ドキュメントcircuitBreakers をご覧ください。

次のステップ