このページでは、グローバル外部アプリケーション ロードバランサで使用できる高度なトラフィック管理機能の概要を説明します。このページは、グローバル外部アプリケーション ロードバランサのみを対象としています。これらのロードバランサは常にグローバルで、常にプレミアム ティアにあります。ロードバランサを別のモードで使用する場合は、次のいずれかのページをご覧ください。
グローバル外部アプリケーション ロードバランサは、次の高度なトラフィック管理機能をサポートしています。- トラフィック ステアリング。HTTP(S) パラメータ（ホスト、パス、ヘッダー、その他のリクエスト パラメータ）に基づいてトラフィックをインテリジェントにルーティングします。
- トラフィック アクション。リクエストとレスポンスに基づいてアクションを実行します（リダイレクト、ヘッダー変換など）。
- トラフィック ポリシー。ロード バランシングの動作を微調整します。たとえば、高度なロード バランシング アルゴリズムを使用します。
これらの機能は、URL マップとバックエンド サービスを使用して設定できます。詳細については次のトピックをご覧ください。
ユースケースの例
トラフィック管理には多くのユースケースがあります。このセクションでは、そのいくつかについて説明します。
トラフィック ステアリング: ヘッダーに基づくルーティング
トラフィック ステアリングを使用すると、リクエスト ヘッダーなどの HTTP パラメータに基づいてサービス インスタンスにトラフィックを転送できます。たとえば、ユーザーのデバイスがモバイル デバイスで、リクエスト ヘッダーに user-agent:Mobile が含まれている場合、トラフィック ステアリングはモバイル トラフィックを処理するサービス インスタンスにトラフィックを送信します。user-agent:Mobile を含まないトラフィックは、モバイル以外のデバイスからのトラフィックを処理するインスタンスに送信します。
トラフィック アクション: 重み付けに基づくトラフィック分割
一般に、本番環境のサービスの新しいバージョンをデプロイする場合、なんらかのリスクが伴います。ステージング環境のテストに合格したとしても、すべてのユーザーをすぐに新しいバージョンに移行しない方が安全です。トラフィック管理では、複数のバックエンド サービス間で割合に基づいてトラフィック分割を定義できます。
たとえば、トラフィックの 95% をサービスの前のバージョンに送信し、5% を新しいバージョンに送信できます。新しいバージョンが本番環境で問題なく機能することが確認できたら、サービスの新しいバージョンに送信するトラフィックの量を 100% に到達するまで段階的に増やしていくことができます。トラフィック分割は通常、新しいバージョンのデプロイ、A/B テスト、サービス移行などのプロセスに使用されます。
トラフィック ポリシー: リクエストのミラーリング
組織によっては、すべてのトラフィックを追加のサービス（たとえば後で再現できるようにリクエストの詳細をデータベースに記録するサービスなど）にミラーリングすることがコンプライアンス要件で義務付けられている場合があります。
Service Extension による機能拡張
Service Extensions とのインテグレーションにより、コールアウトとプラグインを使用して、サポートされているアプリケーション ロードバランサのロード バランシング データパスにカスタム ロジックを挿入できます。
こうした拡張機能は、処理パスのさまざまなポイント（認証、エッジ、ルート、トラフィック）で構成できます。
Service Extensions を使用して、動的転送などの上級者向け機能を構成することもできます。
詳細については、Service Extensions の概要をご覧ください。
トラフィック管理のコンポーネント
簡単に言うと、ロードバランサでは、グローバル URL マップとグローバル バックエンド サービスのリソースを使用してトラフィック管理を行います。トラフィック ステアリングとトラフィック アクションの設定には URL マップを使用します。URL マップに関連付けられているGoogle Cloud リソースには次のものがあります。
- ルートルール
- ルールとの一致
- ルールのアクション
トラフィック ポリシーの設定には、バックエンド サービスを使用します。バックエンド サービスに関連付けられているGoogle Cloud リソースには次のものがあります。
- 局所的なロードバランサ ポリシー
- コンシステント ハッシュ法によるロードバランサ設定
- 外れ値検出
次の図に、各機能の実装に使用されるリソースを示します。
バックエンドへのリクエストのルーティング
グローバル外部アプリケーション ロードバランサでは、トラフィックのバックエンドは次の 2 段階の手法で決定されます。- ロードバランサは、グローバル URL マップで定義されたルールに基づいて、バックエンド サービスまたはバックエンド バケットを選択します。
- バックエンド サービスは、グローバル バックエンド サービスで定義されたポリシーに基づいてバックエンド インスタンスを選択します。
ルーティングを構成するときに、次のモードを選択できます。
# disableFinding("simple") #
単純なホストとパスのルール- 詳細なホスト、パス、ルートのルール
この 2 つのモードは相互に排他的です。1 つの URL マップに含めることができるのは片方のモードだけです。
単純なホストとパスのルール
単純なホストとパスのルールの場合、URL マップは URL マップの概要の説明どおりに動作します。
次の図は、単純なホストとパスのルールの論理的なフローを示しています。
リクエストは、最初にホストルールで評価されます。ホストは、リクエストで指定されたドメインです。リクエスト host が hosts フィールドのエントリの 1 つに一致すると、関連するパスマッチャーが使用されます。
次に、パスマッチャーが評価されます。パスルールは最長パス一致基準で評価され、任意の順序で指定できます。最も狭い範囲の一致が見つかると、リクエストは対応するバックエンド サービスに転送されます。リクエストが一致しない場合、デフォルトのバックエンド サービスが使用されます。
単純なホストとパスのルールは次のようになります。この例では、動画トラフィックが video-backend-service に転送され、その他のトラフィックは web-backend-service に転送されます。
defaultService と service は、バックエンド サービスまたはバックエンド バケットを指し示すことができます。この例は、バックエンド サービスの場合を示しています。
gcloud compute url-maps describe lb-map
defaultService: global/backendServices/web-backend-service
hostRules:
- hosts:
- '*'
pathMatcher: pathmap
name: lb-map
pathMatchers:
- defaultService: global/backendServices/web-backend-service
name: pathmap
pathRules:
- paths:
- /video
- /video/*
service: global/backendServices/video-backend-service
詳細なホスト、パス、ルートのルール
詳細なホスト、パス、ルートのルールでは、単純なルールよりも多くの構成オプションを設定できます。これらのオプションを使用すると、より高度なトラフィック管理パターンを設定できます。また、セマンティクスの一部も変更できます。たとえば、ルートルールに優先度を関連付けている場合、最長一致のセマンティクスではなく、優先度に基づいてルールが解釈されます。
前述の単純なホストとパスのルールの例と同様に、URL マップを使用して高度なトラフィック管理を構成できます。たとえば、次の URL マップでは、トラフィックの 95% が 1 つのバックエンド サービスにルーティングされ、残りの 5% が別のバックエンド サービスにルーティングされます。
defaultService と service は、バックエンド サービスまたはバックエンド バケットを指し示すことができます。この例は、バックエンド サービスの場合を示しています。
gcloud compute url-maps describe lb-map
defaultService: global/backendServices/service-a
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: lb-map
pathMatchers:
- defaultService: global/backendServices/service-a
name: matcher1
routeRules:
- matchRules:
- prefixMatch: ''
routeAction:
weightedBackendServices:
- backendService: global/backendServices/service-a
weight: 95
- backendService: global/backendServices/service-b
weight: 5
ホストルール
リクエストがロードバランサに到達すると、URL マップで定義された hostRules に基づいてリクエストの host フィールドが評価されます。各ホストルールは、1 つ以上のホストと 1 つのパスマッチャー（pathMatcher）のリストで構成されます。hostRules が定義されていない場合、リクエストは defaultService にルーティングされます。
hostRules[] と defaultService をご覧ください。パスマッチャー
リクエストがホストルールに一致すると、ロードバランサはそのホストに対応するパスマッチャーを評価します。
パスマッチャーは次の要素で構成されます。
- 1 つ以上のパスルール（
pathRules）またはルートルール（routeRules）。 - デフォルト サービス（
defaultService）。一致するバックエンド サービスまたはバックエンド バケットがない場合に使用される、デフォルトのバックエンド サービスまたはバックエンド バケット。
pathMatchers[]、pathMatchers[].pathRules[]、pathMatchers[].routeRules[] をご覧ください。パスのルール
パスのルール（pathRules）には 1 つ以上の URL パスを指定します（たとえば、/、/video など）。パスルールは通常、前述の単純なホストとパスベースのルーティングに使用します。
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 内の条件を満たしたときに適用されるリクエストとレスポンスのヘッダー変換ルールを構成できます。 |
routeRules[]routeRules[].priorityrouteRules[].descriptionrouteRules[].servicerouteRules[].matchRules[]routeRules[].routeActionrouteRules[].urlRedirectrouteRules[].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 変数）に基づく照合を行うことができます。
pathMatchers[].routeRules[].matchRules[] をご覧ください。ルート アクション
ルート アクションは、ルートルールがリクエストの属性と一致した場合に実行される特定のアクションです。
ルート アクション（API field name） |
説明 |
|---|---|
リダイレクト（urlRedirect） |
構成可能な 3xx レスポンス コードが返されます。また、Location レスポンス ヘッダーに適切な URI を設定し、リダイレクト アクションの指定に従ってホストとパスを置き換えます。
|
URL の書き換え（urlRewrite） |
選択したバックエンド サービスにリクエストを送信する前に、URL のホスト名部分、URL のパス部分、またはその両方を書き換えます。パス部分の書き換えでは、pathTemplateRewrite にワイルドカードを使用できます。 |
ヘッダー変換（headerAction） |
リクエスト ヘッダーを追加または削除してから、バックエンド サービスにリクエストを送信します。バックエンド サービスからレスポンスを受信した後にレスポンス ヘッダーを追加または削除することもできます。同じヘッダーを追加して削除しようとすると、requestHeadersToAdd オペレーションで replace: True フラグが使用されていない限り、ヘッダーは削除されます。 |
トラフィックのミラーリング（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）。
urlRedirecturlRewriteheaderActionrequestMirrorPolicyweightedBackendServicesretryPolicytimeoutfaultInjectionPolicycorsPolicy
HTTP から HTTPS へのリダイレクト
HTTP トラフィックを HTTPS にリダイレクトする必要がある場合は、共通の IP アドレスを持つ 2 つの転送ルールを作成できます。
詳細な例については、グローバル外部アプリケーション ロードバランサの HTTP から HTTPS へのリダイレクトを設定するをご覧ください。トラフィック ポリシー
バックエンド サービス リソースを使用すると、トラフィック グループ ポリシーを構成し、インスタンス グループまたはネットワーク エンドポイント グループ（NEG）内のロード バランシングを細かく調整できます。これらのポリシーは、前述の URL マップでバックエンド サービスが選択された場合にのみ適用されます。
トラフィック ポリシーを使用すると、次のことができます。
- バックエンド サービス内のインスタンス間でロード バランシング アルゴリズムを制御する。
- アップストリーム サービスへの接続量を制御する。
- バックエンド サービスからの異常なホストのエビクションを制御する。
トラフィック ポリシー（API field name） |
説明 |
|---|---|
ロード バランシングの局所性ポリシー（LocalityLbPolicy） |
バックエンド サービスまたはバケットの場合、トラフィック分散はロード バランシング モードとロード バランシング局所性ポリシーに基づいて行われます。 分散モードでは、各バックエンド（インスタンス グループまたは サポートされている分散モードについては、分散モードをご覧ください。 サポートされているロード バランシング ポリシー アルゴリズムについては、グローバル バックエンド サービス API ドキュメントの |
セッション アフィニティ（consistentHash） |
HTTP Cookie ベースのアフィニティ、HTTP ヘッダーベースのアフィニティ、クライアント IP アドレス アフィニティ、ステートフル Cookie ベースのセッション アフィニティ、生成された Cookie アフィニティなどがあります。セッション アフィニティにより、バックエンドが良好な状態で処理能力があれば、特定のクライアントからのリクエストが可能な限り同じバックエンドに送信されます。 セッション アフィニティの設定は、ロード バランシングの局所性ポリシーが セッション アフィニティの詳細については、グローバル バックエンド サービス API ドキュメントの |
外れ値検出（outlierDetection） |
NEG の正常でないバックエンド VM またはエンドポイントのエビクションの基準、バックエンドまたはエンドポイントでトラフィックを再度受信するのに正常だと考えられるタイミングを定義する基準を指定するためのポリシーのセットです。 外れ値検出の詳細については、グローバル バックエンド サービス API ドキュメントの |
次のステップ
- グローバル外部アプリケーション ロードバランサのトラフィック管理を構成する。グローバル外部アプリケーション ロードバランサのトラフィック管理の設定をご覧ください。