このページでは、従来のアプリケーション ロードバランサで使用できるトラフィック管理機能の概要を説明します。このページは、従来のアプリケーション ロードバランサのみを対象としています。トラフィック管理機能の拡張機能をサポートしている別のモードでロードバランサを使用している場合は、次のいずれかのページをご覧ください。
従来のアプリケーション ロードバランサはトラフィック管理機能をサポートしており、これにより次の機能を使用できます。
- トラフィック ステアリング。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 マップは、リクエストを外部バックエンドに送信します。
構成例については、書き換えをご覧ください。
リダイレクト
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リクエストを送信します。
構成例については、リダイレクトをご覧ください。
サポートされているレスポンス コード
次の表に、サポートされているリダイレクトのレスポンス コード示します。
| レスポンス コード | 番号 | 注 |
|---|---|---|
| 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 = ABTestpathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = A |
pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionA |
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTestpathMatchers[].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 functions、Cloud Run サービス
ロードバランサは、グローバル URL マップで定義されたルールに基づいてバックエンド サービスを選択します。
バックエンド サービスは、グローバル バックエンド サービスで定義されたポリシーに基づいてバックエンド インスタンスを選択します。
ルーティングを構成するときに、次のモードを選択できます。
pathRulesを使用した簡単なホストとパスのテストrouteRulesを使用した高度なリクエストのテスト
URL マップごとに、単純なホストとパスのルールを使用できます。また、ホスト、パス、ルートの詳細ルールを使用することもできます。この 2 つのモードは相互に排他的です。1 つの URL マップに含めることができるのは片方のモードだけです。
単純なホストとパスのルール
単純なホストとパスのルールの場合、URL マップは 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[].priorityrouteRules[].descriptionrouteRules[].servicerouteRules[].matchRules[]routeRules[].routeActionrouteRules[].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 ファイルの作成方法については、次のリソースをご覧ください。
-
フィールドの完全なリストを提供します。関係、制限、カーディナリティに関するセマンティクスなども確認できます。
トラフィック管理設定ページの例: