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

• トラフィック ステアリング。HTTP(S) パラメータ（ホスト、パス、ヘッダー、その他のリクエスト パラメータ）に基づいてトラフィックをインテリジェントにルーティングします。
• トラフィック アクション。リクエストとレスポンスに基づいてアクションを実行します（リダイレクト、ヘッダー変換など）。
• トラフィック ポリシー。ロード バランシングの動作を微調整します。たとえば、高度なロード バランシング アルゴリズムを使用します。

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

• URL マップの概要
• URL マップの使用
• バックエンド サービスについて

ユースケースの例

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

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

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

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

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

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

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

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

Service Extension による機能拡張

Service Extensions と統合すると、サポートされているアプリケーション ロードバランサのロード バランシング データパスにカスタム ロジックを挿入できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

リクエストは、最初にホストルールで評価されます。ホストは、リクエストで指定されたドメインです。リクエスト host が hosts フィールドのエントリの 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 にルーティングされます。

パスマッチャー

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

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

• 1 つ以上のパスルール（pathRules）またはルートルール（routeRules）。
• デフォルト サービス（defaultService）。一致するバックエンド サービスがない場合に使用されるデフォルトのバックエンド サービスです。

パスのルール

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

ルートルール

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

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

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

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

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

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

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

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

• 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 変数）に基づく照合を行うことができます。

ルート アクション

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

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

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

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

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

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

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

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

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

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

トラフィック ポリシー

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

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

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

次のステップ

• 内部アプリケーション ロードバランサのトラフィック管理を構成する。内部アプリケーション ロードバランサのトラフィック管理を設定するをご覧ください。