このページは Cloud Translation API によって翻訳されました。

従来のアプリケーションロードバランサにおけるトラフィック管理の概要

このページでは、従来のアプリケーションロードバランサで使用できるトラフィック管理機能の概要を説明します。このページは、従来のアプリケーションロードバランサのみを対象としています。トラフィック管理機能の拡張機能をサポートしている別のモードでロードバランサを使用している場合は、次のいずれかのページをご覧ください。

従来のアプリケーションロードバランサはトラフィック管理機能をサポートしており、これにより次の機能を使用できます。

トラフィックステアリング。HTTP(S) パラメータに基づいてトラフィックをインテリジェントに転送します。
- ホストとパス
トラフィックアクション。リクエストベースのアクションを実行します。
トラフィックポリシー。負荷分散の動作を調整します。
- タイムアウト
- 最大レートと最大接続数

これらの機能は、ロードバランサの URL マップで構成します。背景情報については、次のトピックをご覧ください。

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

簡単に言うと、外部アプリケーションロードバランサは、グローバル URL マップを使用してトラフィック管理を行います。

ロードバランサは、次のような相互に排他的なプライマリアクションを実行します。

リクエストをバックエンドサービスにルーティングする
リダイレクトを実行する

ロードバランサを設定すると、ロードバランサがリクエストをバックエンドサービスまたはバックエンドバケットに送信する前に、URL 書き換えアクションを構成できます。

書き換えまたはリダイレクトは、URL マップの次の 3 つのレベルで適用できます。

パスが一致したときにアクションが有効になった pathRule
この pathMatcher に一致するパスがない場合にアクションが有効になった pathMatcher
任意のホストルールで指定されたどのホストにも一致しない場合にアクションが有効になった urlMap

pathMatcher で routeRules を使用すると、pathRules と同じ結果になります。pathRules と routeRules を同じ pathMatcher に含めることはできません。順序を問わない pathRules とは異なり、routeRules は順番に調べられます。routeRule は、URL パス、HTTP ヘッダー、URL クエリパラメータをテストできます。

ユースケースの例

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

書き換え

URL の書き換えによって、サービスで使用する URL とは異なる URL を外部ユーザーに提示できます。

URL の書き換えによって、URL がリソースから分離されます。人間が理解しやすい URL（ユーザーが覚えやすく、簡単に使用できる URL）から、検索エンジンが認識しやすい URL（検索エンジンが容易に検索できる URL）または内部実装固有の URL に変換できます。

URL 書き換え機能では、次の処理を行います。

リクエスト内の受信 URL を読み取ります。
ホスト、パス、またはホストとパスの両方を置き換えて、トラフィックをバックエンドサービスまたはバックエンドバケットに転送する前に URL を変換します。

以下の図で:

日本にいるユーザーが URL www.mydomain.com/static/images/someimage.jpg のリクエストを送信します。
リクエストが外部アプリケーションロードバランサに到達すると、ロードバランサは URL マップの情報を使用して、URL を www.myorigin.com/august_snapshot/images/someimage.jpg に書き換えます。
（省略可）この例の URL マップは、リクエストを外部バックエンドに送信します。

**図 1.** 従来のアプリケーションロードバランサによる URL の書き換え。

構成例については、書き換えをご覧ください。

リダイレクト

URL リダイレクトによって、クライアントリクエストを 1 つの URL から別の URL にリダイレクトできます。

これには次の機能が含まれます。

すべての HTTP リクエストを HTTPS リクエストにリダイレクトします。
URL のホスト、パス、またはホストとパスの両方の部分を変更し、クエリパラメータを削除または保持することによって形成された別の URL にリダイレクトします。
発行するリダイレクトのレスポンスコードを選択します。

次の機能には URL リダイレクトを使用します。

URL を短縮します。クライアント向け URL は大幅に短縮できます。このサービスは、長い URL のウェブページへのリダイレクトを発行します。
ウェブページが移動された場合、または古くなった場合のリンク切れを防止します。
同じ所有者に属する複数のドメイン名が 1 つのウェブサイトを参照することを許可します。
必要なリダイレクトをサポートするためにバックエンドサーバーで回避策を構成する手間と煩雑さを省きます。
レイテンシを短縮します。エッジで作成されたリダイレクトは、バックエンドエンドポイントで作成されたリダイレクトと比べると、レイテンシが低くなる可能性があります。

HTTP から HTTPS へのリダイレクトには、さらに次のような利点があります。

暗号化されたトラフィックのコンプライアンス要件（HIPAA など）を満たします。
HTTP プロトコルで送信されたリクエストを拒否する代わりに、リクエストを HTTPS でリダイレクトします。
バックエンドサーバーでリダイレクトを実装する場合と比べて、レイヤー 7 ロードバランサ自体でトラフィックをリダイレクトすることにより、アプリケーションのセキュリティプロファイルが改善されます。

以下の図で:

日本にいるユーザーが GET http://example.com/img1 リクエストを送信します。
ロードバランサは、URL マップで定義されたリダイレクトに基づいて HTTP/1.1 302 Found Location: https://example.com/img1 リダイレクトを返し、HTTP リクエストを HTTPS リクエストにリダイレクトします。
ユーザーのブラウザが GET https://example.com/img1 リクエストを送信します。

**図 2.** 従来のアプリケーションロードバランサによる URL リダイレクト。

構成例については、リダイレクトをご覧ください。

サポートされているレスポンスコード

次の表に、サポートされているリダイレクトのレスポンスコード示します。

レスポンスコード	番号	注
MOVED_PERMANENTLY_DEFAULT	301
FOUND	302
PERMANENT_REDIRECT	308	この場合、リクエストメソッドは保持されます。
TEMPORARY_REDIRECT	307	この場合、リクエストメソッドは保持されます。
SEE_OTHER	303

ヘッダーベースとパラメータベースのルーティング

ヘッダーベースとパラメータベースのルーティングにより、ロードバランサは HTTP ヘッダーと URL クエリパラメータに基づいてルーティングを決定できます。

この機能を使用すると、ルーティングを行うために追加のプロキシ層（NGINX など）をデプロイすることなく、クラウドアーキテクチャを簡素化できます。

外部アプリケーションロードバランサを使用すると、次のことができます。

A/B テスト
バックエンドで実行されているさまざまなサービスにユーザーを割り当てる
リクエスト元デバイスのカテゴリに合わせてページとエクスペリエンスを提供する

ホスト文字列に基づいて pathMatcher が選択されたら、pathMatcher の routeRules で URL パスを選択します。詳細については、URL マップの概要をご覧ください。

例: クエリパラメータベースのルーティングを使用した A/B テストの構成

次の例は、クエリ文字列を照合してテストと入力を指定することにより、A/B テストを行う方法を示しています。

リクエストが次のように処理されることを確認する必要があるとします。

クエリパラメータ値が A のすべてのリクエストが、BackendServiceForProcessingOptionA というバックエンドサービスに送信される。
クエリパラメータ値が B のすべてのリクエストが、BackendServiceForProcessingOptionB というバックエンドサービスに送信される。

これらの要件を次の表にまとめます。

リクエスト	バックエンドサービス
`http://test.mydomain.com?ABTest=A`	`BackendServiceForProcessingOptionA`
`http://test.mydomain.com?ABTest=B`	`BackendServiceForProcessingOptionB`

これをグローバル URL マップで構成するには、次の設定を作成します。

一致	内容
`pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest` `pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = A`	`pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionA`
`pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest` `pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = B`	`pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionB`

構成例については、ヘッダーベースとパラメータベースのルーティングをご覧ください。

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

トラフィックのバックエンドは次の 2 段階で決定されます。

ロードバランサがバックエンドを含むバックエンドサービスを選択します。次のようなバックエンドを想定できます。
- 非マネージドインスタンスグループの Compute Engine 仮想マシン（VM）インスタンス
- マネージドインスタンスグループ（MIG）の Compute Engine VM
- ゾーンネットワークエンドポイントグループ（NEG）の Google Kubernetes Engine（GKE）ノードによるコンテナ
- インターネット NEG の Google Cloud の外部にある外部バックエンド
- バックエンドバケットの Cloud Storage
- サーバーレス NEG の App Engine、Cloud Run 関数、Cloud Run サービス
ロードバランサは、グローバル URL マップで定義されたルールに基づいてバックエンドサービスを選択します。
バックエンドサービスは、グローバルバックエンドサービスで定義されたポリシーに基づいてバックエンドインスタンスを選択します。

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

pathRules を使用した簡単なホストとパスのテスト
routeRules を使用した高度なリクエストのテスト

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

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

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

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

**図 3.** 単純なホストとパスのルールを使用した URL マップのフロー。

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

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

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

$ gcloud compute url-maps describe ext-https-map

defaultService: global/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: ext-https-map
pathMatchers:
- defaultService: global/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: global/backendServices/video-backend-service

構成例については、ホストとパスをご覧ください。

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

詳細なホスト、パス、ルートのルールでは、単純なルールよりも多くの構成オプションを設定できます。これらのオプションを使用すると、より高度なトラフィック管理パターンを設定できます。また、セマンティクスの一部も変更できます。たとえば、ルートルールは最長一致のセマンティクスではなく、順番に実行されます。

前述の単純なホストとパスのルールの例と同様に、グローバル URL マップを使用して高度なトラフィック管理を構成できますが、その場合は pathMatchers[].pathRules[] を使用する代わりに pathMatchers[].routeRules[] を使用します。

以降のセクションでは、高度なホスト、パス、ルートのルールのコンポーネントについて説明します。

ホストルール

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

詳細については、グローバル URL マップ API のドキュメントの hostRules[] と defaultService をご覧ください。

パスマッチャー

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

パスマッチャーは次のコンポーネントから構成されます。

1 つ以上のパスルール（pathRules）またはルートルール（routeRules）。
他にバックエンドサービスが一致しない場合に実行されるデフォルトのルール。ルールには、次のような相互に排他的なオプションがあります。
- デフォルトのサービスでは、他のバックエンドサービスが一致しない場合にルーティング対象とするデフォルトのバックエンドサービスを指定します。
- デフォルトのリダイレクトでは、他のバックエンドサービスが一致しない場合にリダイレクト先とする URL を指定します。

ロードバランサがデフォルトサービス用に構成されている場合は、リクエストをデフォルトサービスに送信する前に URL を書き換えるように追加の構成を行うことができます。

詳細については、グローバル URL マップ API のドキュメントの pathMatchers[]、pathMatchers[].pathRules[]、pathMatchers[].routeRules[] をご覧ください。

パスのルール

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

詳細については、グローバル URL マップ API のドキュメントの pathRules[] をご覧ください。

ルートルール

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

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

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

matchRules でサポートされているオプションの詳細なリストについては、グローバル URL マップ API のドキュメントの matchRules[] をご覧ください。

複数のルートルールがある場合、ロードバランサはそれらを順番に実行します。これにより、マッチング、ルーティング、その他のアクションのカスタムロジックを指定できます。

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

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

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

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

ルートルールのコンポーネント（`API field name`）	説明
優先度（`priority`）	特定のパスマッチャーのルートルールに割り当てられる 0～2,147,483,647 の数値。つまり、(2^31)-1。優先度が最も高いのは `0` です。最も低い優先度は `2147483647` です。たとえば、優先度 `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 書き換えアクションを指定できます。
リダイレクトアクション（`urlRedirect`）	一致ルールの条件を満たしたときに、HTTP リダイレクトで応答するアクションを構成できます。このフィールドは、ルートアクションと一緒に使用することはできません。

詳細については、グローバル URL マップ API のドキュメントの次のフィールドをご覧ください。

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

一致ルール

一致ルール（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[] をご覧ください。

トラフィック管理の構成

トラフィック管理の構成には、Google Cloud コンソール、gcloud、Cloud Load Balancing API のいずれかを使用できます。選択した構成環境で、YAML 構成を使用してトラフィック管理を設定します。

これらの YAML ファイルの作成方法については、次のリソースをご覧ください。

グローバル URL マップ API のドキュメント

フィールドの完全なリストを提供します。関係、制限、カーディナリティに関するセマンティクスなども確認できます。
トラフィック管理設定ページの例:

従来のアプリケーション ロードバランサにおけるトラフィック管理の概要