- トラフィック ステアリング。HTTP(S) パラメータ(ホスト、パス、ヘッダー、その他のリクエスト パラメータ)に基づいてトラフィックをインテリジェントにルーティングします。
- トラフィック アクション。リクエストとレスポンスに基づいてアクションを実行します(リダイレクト、ヘッダー変換など)。
- トラフィック ポリシー。ロード バランシングの動作を微調整します。たとえば、高度なロード バランシング アルゴリズムを使用します。
これらの機能は、URL マップとバックエンド サービスを使用して設定できます。詳細については次のトピックをご覧ください。
ユースケースの例
トラフィック管理には多くのユースケースがあります。このセクションでは、そのいくつかについて説明します。
トラフィック ステアリング: ヘッダーに基づくルーティング
トラフィック ステアリングを使用すると、リクエスト ヘッダーなどの HTTP パラメータに基づいてサービス インスタンスにトラフィックを転送できます。たとえば、ユーザーのデバイスがモバイル デバイスで、リクエスト ヘッダーに user-agent:Mobile
が含まれている場合、トラフィック ステアリングはモバイル トラフィックを処理するサービス インスタンスにトラフィックを送信します。user-agent:Mobile
を含まないトラフィックは、モバイル以外のデバイスからのトラフィックを処理するインスタンスに送信します。
トラフィック アクション: 重み付けに基づくトラフィック分割
一般に、本番環境のサービスの新しいバージョンをデプロイする場合、なんらかのリスクが伴います。ステージング環境のテストに合格したとしても、すべてのユーザーをすぐに新しいバージョンに移行しない方が安全です。トラフィック管理では、複数のバックエンド サービス間で割合に基づいてトラフィック分割を定義できます。
たとえば、トラフィックの 95% をサービスの前のバージョンに送信し、5% を新しいバージョンに送信できます。新しいバージョンが本番環境で問題なく機能することが確認できたら、サービスの新しいバージョンに送信するトラフィックの量を 100% に到達するまで段階的に増やしていくことができます。トラフィック分割は通常、新しいバージョンのデプロイ、A/B テスト、サービス移行などのプロセスに使用されます。
トラフィック ポリシー: リクエストのミラーリング
組織によっては、すべてのトラフィックを追加のサービス(たとえば後で再現できるようにリクエストの詳細をデータベースに記録するサービスなど)にミラーリングすることがコンプライアンス要件で義務付けられている場合があります。
Service Extension による機能拡張
Service Extensions とのインテグレーションにより、サポートされているアプリケーション ロードバランサのロード バランシング データパスにカスタム ロジックを挿入できます。
詳細については、Service Extensions の概要をご覧ください。
トラフィック管理のコンポーネント
簡単に言うと、ロードバランサでは、リージョン URL マップとリージョン バックエンド サービス リソースを使用してトラフィックを管理します。クロスリージョン内部アプリケーション ロードバランサの場合、トラフィック管理では、グローバル URL マップとグローバル バックエンド サービス リソースを使用します。
トラフィック ステアリングとトラフィック アクションの設定には URL マップを使用します。URL マップに関連する Google Cloud リソースには次のものがあります。
- ルートルール
- ルールとの一致
- ルールのアクション
トラフィック ポリシーの設定には、バックエンド サービスを使用します。バックエンド サービスに関連する Google Cloud リソースには次のものがあります。
- サーキット ブレーカー
- 局所的なロードバランサ ポリシー
- コンシステント ハッシュ法によるロードバランサ設定
- 外れ値検出
次の図に、各機能の実装に使用されるリソースを示します。
バックエンドへのリクエストのルーティング
リージョン内部アプリケーション ロードバランサでは、トラフィックのバックエンドは次の 2 段階の手法で決定されます。- ロードバランサがバックエンドを含むバックエンド サービスを選択します。バックエンドは、非マネージド インスタンス グループの 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
にルーティングされます。
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[].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 変数)に基づく照合を行うことができます。
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
)
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 ) |
バックエンド サービスの場合、トラフィック分散はロード バランシング モードとロード バランシングの局所性ポリシーに基づいて行われます。 分散モードでは、各バックエンド(インスタンス グループまたは サポートされている分散モードについては、分散モードをご覧ください。 サポートされているロード バランシング ポリシー アルゴリズムについては、リージョン バックエンド サービス API ドキュメントの |
セッション アフィニティ(consistentHash ) |
HTTP Cookie ベースのアフィニティ、HTTP ヘッダーベースのアフィニティ、クライアント IP アドレス アフィニティ、ステートフル Cookie ベースのセッション アフィニティ、生成された Cookie アフィニティなどがあります。セッション アフィニティにより、バックエンドが良好な状態で処理能力があれば、特定のクライアントからのリクエストが可能な限り同じバックエンドに送信されます。 セッション アフィニティの詳細については、リージョン バックエンド サービス API ドキュメントの |
外れ値検出(outlierDetection ) |
NEG の正常でないバックエンド VM またはエンドポイントのエビクションの基準、バックエンドまたはエンドポイントでトラフィックを再度受信するのに正常だと考えられるタイミングを定義する基準を指定するためのポリシーのセットです。 外れ値検出の詳細については、リージョン バックエンド サービス API ドキュメントの |
サーキット ブレーク(circuitBreakers ) |
バックエンド サービスへの接続量と接続あたりのリクエスト数の上限を設定します。 サーキット ブレークの詳細については、リージョン バックエンド サービス API ドキュメントの |
次のステップ
- 内部アプリケーション ロードバランサのトラフィック管理を構成する。内部アプリケーション ロードバランサのトラフィック管理を設定するをご覧ください。