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

リージョン内部アプリケーションロードバランサとクロスリージョン内部アプリケーションロードバランサは、高度なトラフィック管理機能をサポートしています。これにより、次の機能を使用できます。

トラフィックステアリング。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 マップのフロー（クリックして拡大）。

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

詳細については、リージョン 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 は次のアクションを実行します。

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

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

ルートルールのコンポーネント（`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 属性の一部またはすべてに一致します。 `routeRule` の `routeActions` が有効になるには、1 つの `matchRule` 内のすべての一致条件を満たす必要があります。`routeRule` に複数の `matchRules` がある場合、リクエストが `routeRule` のいずれかの `matchRules` に一致すると、`routeRule` の `routeActions` が有効になります。
ルートアクション（`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` をご覧ください。

次のステップ

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