外部 HTTP(S) 負荷分散の概要

このドキュメントでは、Google Cloud 外部 HTTP(S) の負荷分散の構成に必要なコンセプトについて説明します。

HTTP(S) 負荷分散は、プロキシベースのレイヤ 7 ロードバランサであり、単一の外部 IP アドレスの背後でサービスを実行し、スケーリングできます。外部 HTTP(S) 負荷分散は、さまざまな Google Cloud プラットフォーム(Compute Engine、Google Kubernetes Engine(GKE)、Cloud Storage など)でホストされているバックエンドや、インターネットまたはハイブリッド接続を介して接続された外部バックエンドに、HTTP/HTTPS トラフィックを配信します。詳細については、ユースケースをご覧ください。

このページでは、スタンドアロンの外部 HTTP(S) ロードバランサのアーキテクチャについて説明します。GKE のアプリケーションをインターネットに公開する場合は、組み込みの外部 HTTP(S) ロード バランシング用 GKE Ingress を使用することをおすすめします。

外部 HTTP(S) ロードバランサのモード

外部 HTTP(S) ロード バランシングは、次のモードで構成できます。

  • 外部 HTTP/S ロードバランサ。これは、スタンダード ティアではリージョン、プレミアム ティアではグローバルである、外部 HTTP(S) ロードバランサです。外部 HTTP(S) ロードバランサは、Google Front End(GFE)に実装されます。GFE はグローバルに分散し、Google のグローバル ネットワークとコントロール プレーンを使用して連携します。
  • リージョン外部 HTTP(S) ロードバランサ(プレビュー)。これは、オープンソースの Envoy プロキシでマネージド サービスとして実装されるリージョン ロードバランサです。これには、トラフィックのミラーリング、重み付けベースのトラフィック分割、リクエスト/レスポンス ベースのヘッダー変換などの高度なトラフィック管理機能が含まれます。
ロードバランサ・モード おすすめのユースケース 機能
外部 HTTP(S) ロードバランサ

これは、スタンダード ティアではリージョン、プレミアム ティアではグローバルである、外部 HTTP(S) ロードバランサです。

プレミアム Network Service Tiersでは、外部 HTTP(S) ロードバランサがマルチリージョン負荷分散を行い、容量のある最も近い正常なバックエンドにトラフィックを導き、HTTP(S) トラフィックを可能な限りユーザーの近くで終了させます。

スタンダード Network Service Tiersでは、負荷分散はリージョン単位で処理されます。

機能の完全なリストについては、負荷分散機能のページをご覧ください。
高度なトラフィック管理機能を持つリージョン外部 HTTP(S) ロードバランサ(プレビュー

このロードバランサには、既存の外部 HTTP(S) ロードバランサの機能の多くに加え、追加の高度なトラフィック管理機能が含まれています。

これは、1 つの位置情報のみからコンテンツを配信するために推奨される外部 HTTP(S) ロードバランサです(たとえば、コンプライアンス規制に準拠するため)。

このロードバランサは、リージョン バックエンド サービスのみが必要な場合、またはスタンダード Network Service Tiersが必要な場合に使用します。

詳細については、ロード バランシング機能をご覧ください。

アーキテクチャ

外部 HTTP(S) ロードバランサをデプロイするには、次のリソースが必要です。

  • リージョン外部 HTTP(S) ロードバランサの場合のみ、プロキシ専用サブネットを使用して、ロードバランサをバックエンドに読み込みます。

  • 外部転送ルールで、外部 IP アドレス、ポート、ターゲット HTTP(S) プロキシを指定します。クライアントは、IP アドレスとポートを使用してロードバランサに接続します。

  • ターゲット HTTP(S) プロキシで、クライアントからのリクエストを受信します。HTTP(S) プロキシは、URL マップを使用してリクエストを評価し、トラフィックのルーティングを決定します。プロキシは、SSL 証明書を使用して通信の認証を行うこともできます。

    • HTTPS 負荷分散の場合、ターゲット HTTPS プロキシは SSL 証明書を使用して、クライアントに ID を提供します。ターゲット HTTP(S) プロキシは、ドキュメント番号までの SSL 証明書をサポートします。
  • HTTP(S) プロキシは、URL マップを使用し、HTTP 属性(リクエストパス、Cookie、ヘッダーなど)に基づいてルーティングを決めます。このルーティングの決定に基づいて、プロキシは特定のバックエンド サービスやバックエンド バケットにクライアントのリクエストを転送します。URL マップでは、クライアントにリダイレクトを送信するなど、追加のアクションを指定できます。

  • バックエンド サービスは、正常なバックエンドにリクエストを分散します。外部 HTTP(S) ロードバランサはバックエンド バケットもサポートします。

    • 1 つ以上のバックエンドをバックエンド サービスまたはバックエンド バケットに接続する必要があります。
  • ヘルスチェックで、バックエンドの準備状況を定期的に監視します。これにより、処理不能なバックエンドにリクエストが送信されるリスクを軽減できます。

  • バックエンドがヘルスチェック プローブを受け入れるためのファイアウォール ルール。リージョン外部 HTTP(S) ロードバランサには、プロキシ専用サブネットからのトラフィックがバックエンドに到達できるように追加のファイアウォール ルールが必要です。

グローバル モード

次の図は、外部 HTTP(S) ロードバランサのデプロイのコンポーネントを示しています。

外部 HTTP(S) ロードバランサ コンポーネント
外部 HTTP(S) ロードバランサ コンポーネント

リージョン モード

次の図は、リージョン外部 HTTP(S) ロードバランサのデプロイのコンポーネントを示しています。

リージョン外部 HTTP(S) ロードバランサ コンポーネント
リージョン外部 HTTP(S) ロードバランサ コンポーネント

プロキシ専用サブネット

プロキシ専用サブネットは、リージョン外部 HTTP(S) ロードバランサの場合のみ必要です。

プロキシ専用サブネットには、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。リージョン外部 HTTP(S) ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを 1 つ作成する必要があります。このプロキシ専用サブネットの --purpose フラグは、REGIONAL_MANAGED_PROXY に設定されています。同じリージョンと VPC ネットワーク内のすべてのリージョン外部 HTTP(S) ロードバランサは、同じプロキシ専用サブネットからの Envoy プロキシのプールを共有します。さらに、

  • プロキシ専用サブネットは Envoy プロキシにのみ使用され、バックエンドには使用されません。
  • リージョンと VPC ネットワーク内のすべてのリージョン外部 HTTP(S) ロードバランサのバックエンド VM またはエンドポイントは、プロキシ専用サブネットからの接続を受信します。
  • リージョン外部 HTTP(S) ロードバランサの IP アドレスは、プロキシ専用サブネットにはありません。ロードバランサの IP アドレスは、後述する外部管理転送ルールで定義します。

転送ルールとアドレス

転送ルールは、IP アドレス、ポート、プロトコルに基づいて、ターゲット プロキシ、URL マップ、1 つ以上のバックエンド サービスからなる負荷分散構成にトラフィックをルーティングします。

各転送ルールでは、アプリケーションの DNS レコードで使用できる単一の IP アドレスを指定します。DNS ベースの負荷分散は必要ありません。使用する IP アドレスを自分で指定することも、Cloud Load Balancing で割り当てられる IP アドレスを使用することもできます。

  • HTTP ロードバランサの転送ルールは、TCP ポート 80 と 8080 のみを参照できます。
  • HTTPS ロードバランサの転送ルールは、TCP ポート 443 のみを参照できます。

外部 HTTP(S) ロードバランサが使用する転送ルール、IP アドレス、負荷分散スキームのタイプは、ロードバランサのモードやロードバランサがどの Network Service Tiers に属しているかによって異なります。

ロードバランサ・モード ネットワーク サービス階層 転送ルール、IP アドレス、ロード バランシング スキーム インターネットからロードバランサのフロントエンドへのルーティング
外部 HTTP(S) ロードバランサ プレミアム ティア

グローバル外部転送ルール

グローバル外部 IP アドレス

負荷分散 スキーム:
EXTERNAL

インターネット上のクライアントに最も近い GFE にルーティングされるリクエスト。
スタンダード ティア

リージョン外部転送ルール

リージョン外部 IP アドレス

負荷分散 スキーム:
EXTERNAL

ロードバランサのリージョンの GFE にルーティングされるリクエスト。
リージョン外部 HTTP(S) ロードバランサ スタンダード ティア

リージョン外部転送ルール

リージョン外部 IP アドレス

負荷分散 スキーム
EXTERNAL_MANAGED

ロードバランサと同じリージョンの Envoy プロキシにルーティングされるリクエスト。

各モードの HTTP(S) ロード バランシング転送ルールでサポートされるプロトコルの一覧については、ロードバランサの機能をご覧ください。

ターゲット プロキシ

ターゲット プロキシは、クライアントからの HTTP(S) 接続を終端します。1 つ以上の転送ルールがトラフィックをターゲット プロキシに振り向け、ターゲット プロキシが URL マップを参照してバックエンドにトラフィックを転送する方法を決定します。

プロキシでは、リクエストまたはレスポンスのヘッダー名の大文字と小文字の区別の保持が保証されません。たとえば、Server: Apache/1.0 レスポンス ヘッダーはクライアントで server: Apache/1.0 として表示される場合があります。

次の表に、各モードの外部 HTTP(S) ロードバランサに必要なターゲット プロキシのタイプを示します。

ロードバランサ・モード ターゲット プロキシのタイプ プロキシ追加ヘッダー サポートされるカスタム ヘッダー Cloud Trace のサポート
外部 HTTP(S) ロードバランサ グローバル HTTP
グローバル HTTPS
プロキシは、次のように HTTP リクエスト ヘッダー / レスポンス ヘッダーを設定します。
  • Via: 1.1 google(リクエストとレスポンス)
  • X-Forwarded-Proto: [http | https](リクエストのみ)
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options>(リクエストのみ)
    Cloud Trace のパラメータが含まれます。
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip>(X-Forwarded-For ヘッダー)(リクエストのみ)
バックエンド サービスまたはバックエンド バケットで構成されている
リージョン外部 HTTP(S) ロードバランサ リージョン HTTP
リージョン HTTPS
  • X-Forwarded-Proto: [http | https](リクエストのみ)
  • Via: 1.1 google(リクエストとレスポンス)
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip>(X-Forwarded-For ヘッダー)(リクエストのみ)

Host ヘッダー

ロードバランサが HTTP リクエストを行うと、ロードバランサは元のリクエストの Host ヘッダーを保持します。

X-Forwarded-For ヘッダー

ロードバランサは、1 つのカンマで区切られた 2 つの IP アドレスを次の順序で X-Forwarded-For ヘッダーに追加します。

  • ロードバランサに接続するクライアントの IP アドレス
  • ロードバランサの転送ルールの IP アドレス

受信リクエストに X-Forwarded-For ヘッダーがない場合、ヘッダーの値はこの 2 つの IP アドレスだけです。

X-Forwarded-For: <client-ip>,<load-balancer-ip>

リクエストに X-Forwarded-For ヘッダーが含まれている場合、ロードバランサは、指定された値を <client-ip>,<load-balancer-ip>に保持します。

X-Forwarded-For: <supplied-value>,<client-ip>,<load-balancer-ip>

ロードバランサのバックエンドで HTTP リバース プロキシ ソフトウェアを実行すると、ソフトウェアが X-Forwarded-For ヘッダーの末尾に次の IP アドレスのいずれかまたは両方を追加します。

  • バックエンドに接続されている Google Front End(GFE)の IP アドレス。これらの IP アドレスの範囲は 130.211.0.0/2235.191.0.0/16 です。

  • バックエンド システム自体の IP アドレス

したがって、ロードバランサのバックエンドの後のアップストリーム プロセスは、次の形式の X-Forwarded-For ヘッダーを受け取る可能性があります。

<existing-values>,<client-ip>,<load-balancer-ip><GFE-IP><backend-IP>

HTTP/3 プロトコルと QUIC プロトコルのサポート

HTTP/3 は次世代のインターネット プロトコルです。これは、元の Google QUICgQUIC)プロトコルから開発され、QUIC プロトコル上に構築されます。HTTP/3 は、外部 HTTP(S) ロードバランサ、Cloud CDN、クライアントの間でサポートされます。

特に、以下の点に注意してください。

  • IETF QUIC は、TCP と同様の輻輳制御および SSL / TLS と同等のセキュリティを HTTP/2 に提供するトランスポート レイヤ プロトコルであり、パフォーマンスが向上しています。
  • HTTP/3 は、IETF QUIC の上にビルドされたアプリケーション レイヤであり、多重化、輻輳制御、再試行の処理を QUIC に依存しています。
  • HTTP/3 では、クライアント接続の開始が迅速になり、多重化されたストリームにおけるヘッドオブライン ブロッキングがなくなるとともに、クライアントの IP アドレスが変更されたときの接続の移行がサポートされます。
  • HTTP/3 はクライアントとロードバランサ間の接続に影響を与えるものの、ロードバランサとバックエンド間の接続には影響を与えません。
  • HTTP/3 接続は、BBR 輻輳制御プロトコルを使用します。

外部 HTTP(S) ロードバランサで HTTP/3 を有効にすると、ウェブページの読み込み時間の改善、動画の再バッファリングの低減、レイテンシが高い接続スループットの改善が可能です。

HTTP/3 の構成

quicOverrideENABLE に設定することで、外部 HTTP(S) ロードバランサに HTTP/3 サポートを明示的に有効にできます。将来的には、すべての外部 HTTP(S) ロードバランサ クライアントで HTTP/3 がデフォルトで有効になります。

HTTP/3 または gQUIC をサポートしていないクライアントは、HTTP/3 接続のネゴシエートを行いません。破損または古いクライアント実装が特定されている場合を除き、HTTP/3 を明示的に無効にする必要はありません。

次の表に示すように、外部 HTTP(S) ロードバランサには HTTP/3 を構成するための 3 つのモードが用意されています。

quicOverride 値 動作
NONE

HTTP/3 と Google QUIC はクライアントにアドバタイズされません。

注: これは将来変更される可能性があり、HTTP/3 はデフォルトでクライアントにアドバタイズされます。

ENABLE

HTTP/3 と Google QUIC のサポートは、クライアントにアドバタイズされています。HTTP/3 はより高い優先度でアドバタイズされます。両方のプロトコルをサポートするクライアントは、Google QUIC ではなく HTTP/3 を使用する必要があります。

注: TLS 0-RTT(別名 TLS 早期データ)は、クライアントが Google QUIC によってネゴシエートされた場合に暗黙的にサポートされますが、HTTP/3 が使用されている場合は現在サポートされません。

DISABLE クライアントへの HTTP/3 と Google QUIC のアドバタイジングを明示的に無効にします。

HTTP/3 を明示的に有効または無効にする手順は次のとおりです。

Console: HTTPS

  1. Google Cloud Console で、[負荷分散] ページに移動します。

    [負荷分散] に移動

  2. 編集する外部 HTTP(S) ロードバランサを選択します。

  3. [フロントエンドの構成] をクリックします。

  4. 編集するフロントエンドの IP アドレスとポートを選択します。HTTP/3 の構成を編集するには、IP アドレスとポートが HTTPS(ポート 443)である必要があります。

HTTP/3 を有効にする

  1. [QUIC ネゴシエーション] プルダウンを選択します。
  2. このフロントエンドで HTTP/3 を明示的に有効にするには、[有効] を選択します。
  3. IPv4 と IPv6 を表す複数のフロントエンド ルールが存在する場合は、各ルールで HTTP/3 を有効にします。

HTTP/3 を無効にする

  1. [QUIC ネゴシエーション] プルダウンを選択します。
  2. このフロントエンドの HTTP/3 を明示的に無効にするには、[無効] を選択します。
  3. IPv4 と IPv6 を表す複数のフロントエンド ルールが存在する場合は、ルールごとに HTTP/3 を無効にします。

gcloud: HTTPS

次のコマンドを実行する前に、SSL 証明書ごとにそのリソースを作成する必要があります。

 gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
     --global \
     --quic-override=QUIC_SETTING

QUIC_SETTING を次のいずれかに置き換えます。

  • NONE(デフォルト): QUIC がネゴシエートされる際に、Google が制御できるようにします。

    現在、NONE を選択すると QUIC は無効になります。このオプションを選択することで、今後このロードバランサの QUIC ネゴシエーションと HTTP/3 は自動的に有効になります。Cloud Console で、このオプションは自動(デフォルト)と呼ばれます。

  • ENABLE: HTTP/3 と Google QUIC をクライアントにアドバタイズします

  • DISABLE: HTTP/3 または Google QUIC をクライアントにアドバタイズしません

API: HTTPS

POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride

{
  "quicOverride": QUIC_SETTING
}

QUIC_SETTING を次のいずれかに置き換えます。

  • NONE(デフォルト): QUIC がネゴシエートされる際に、Google が制御できるようにします。

    現在、NONE を選択すると QUIC は無効になります。このオプションを選択することで、今後このロードバランサの QUIC ネゴシエーションと HTTP/3 は自動的に有効になります。Cloud Console で、このオプションは自動(デフォルト)と呼ばれます。

  • ENABLE: HTTP/3 と Google QUIC をクライアントにアドバタイズします

  • DISABLE: HTTP/3 または Google QUIC をクライアントにアドバタイズしません

HTTP/3 のネゴシエート方法

HTTP/3 が有効になっている場合、ロードバランサはこのサポートをクライアントにアドバタイズし、HTTP/3 をサポートするクライアントは HTTPS ロードバランサとの HTTP/3 接続の確立を試行できるようにします。

  • 適切に実装されたクライアントは、QUIC 接続を確立できない場合は常に HTTPS または HTTP/2 にフォールバックします。
  • HTTP/3 をサポートするクライアントは、HTTP/3 サポートのキャッシュに保存された以前の情報を使用して、将来的に不要なラウンドトリップを節約します。
  • このフォールバックにより、ロードバランサで QUIC を有効または無効にしても、ロードバランサのクライアントへの接続機能は中断されません。

サポートは Alt-Svc HTTP レスポンス ヘッダーでアドバタイズされます。外部 HTTP(S) ロードバランサの targetHttpsProxy リソースで HTTP/3 が ENABLE として構成されている場合、外部 HTTP(S) ロードバランサからのレスポンスには次の alt-svc ヘッダー値が含まれます。

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,
h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,
quic=":443"; ma=2592000; v="46,43"

HTTP/3 が明示的に DISABLE に設定されている場合、レスポンスに alt-svc レスポンス ヘッダーは含まれません。

HTTPS ロードバランサで QUIC が有効になっているときに、クライアントが QUIC をネゴシエートせずに HTTPS または HTTP/2 にフォールバックすることがあります。次のような場合です。

  • HTTPS ロードバランサによってサポートされている HTTP/3 バージョンと互換性のないバージョンの HTTP/3 をクライアントがサポートしている場合
  • HTTP/3(QUIC)が機能できない方法で、UDP トラフィックがブロックされているかレート制限されていると、ロードバランサで検出された場合
  • クライアントは HTTP/3 をまったくサポートしていないため、HTTP/3 接続のネゴシエーションを試行しません。

このような状況のために接続が HTTPS または HTTP/2 にフォールバックした場合は、ロードバランサの障害としてカウントされません。

HTTP/3 を有効にする前に、前述の動作がワークロードに対して許容できることを確認してください。

URL マップ

URL マップは、URL に基づいてリクエストが適切なバックエンド サービスにルーティングされる際に使用される一致パターンを定義します。デフォルトのバックエンド サービスは、指定されたホストまたはパスのマッチング ルールに一致しないリクエストを処理するように定義されています。マルチリージョン負荷分散の例など、URL ルールを定義せず、デフォルトのサービスのみに依存する状況もあります。リクエストのルーティングでは、URL マップを使用して URL を調べることで、トラフィックを分割し、リクエストを各種のバックエンド セットに送信できます。

次の表に、各モードの外部 HTTP(S) ロードバランサに必要な URL マップのタイプを示します。

ロードバランサ・モード URL マップのタイプ
外部 HTTP(S) ロードバランサ グローバルサポートされている機能のサブセットのみ)
リージョン外部 HTTP(S) ロードバランサ リージョン

SSL 証明書

Transport Layer Security(TLS)は、ネットワーク通信を保護するために SSL 証明書で使用される暗号化プロトコルです。

Google Cloud は SSL 証明書を使用して、クライアントからロードバランサに転送されるデータのプライバシーとセキュリティを保護します。HTTPS ベースの負荷分散を使用している場合は、ターゲット HTTPS プロキシに 1 つ以上の SSL 証明書をインストールする必要があります。

次の表に、各モードの外部 HTTP(S) ロードバランサに必要な SSL 証明書のスコープを示します。

ロードバランサ・モード SSL 証明書のスコープ
外部 HTTP(S) ロードバランサ グローバル
リージョン外部 HTTP(S) ロードバランサ リージョン

SSL 証明書の詳細については、次をご覧ください。

SSL ポリシー

SSL ポリシーを使用すると、HTTPS ロードバランサが HTTPS クライアントとネゴシエートする際に使用する SSL の機能を制御できます。

デフォルトでは、HTTPS 負荷分散は、優れたセキュリティと幅広い互換性を提供する一連の SSL 機能を使用します。アプリケーションの中には、HTTPS または SSL 接続に使用される SSL のバージョンおよび暗号をより詳細に管理しなければならないものがあります。ロードバランサがネゴシエートに使用する SSL 機能を制御する SSL ポリシーを定義し、ターゲット HTTPS プロキシに SSL ポリシーを関連付けることができます。

バックエンド サービスとバケット

外部 HTTP(S) ロードバランサに、バックエンド サービスとバックエンド バケットが設定されている場合があります。リージョン外部 HTTP(S) ロードバランサは、バックエンド バケットに対応していません。

バックエンド サービスは、ロードバランサに構成情報を提供します。ロードバランサは、バックエンド サービスからの情報を使用して、受信トラフィックを接続されている 1 つまたは複数のバックエンドに振り向けます。バックエンド サービスと Compute Engine バックエンドを使用してロードバランサを設定する方法の例については、Compute Engine バックエンドを使用した外部 HTTP(S) ロードバランサの設定をご覧ください。

バックエンド バケットは、Cloud Storage バケットに着信トラフィックを振り向けます。バケットを外部 HTTP(S) ロードバランサに追加する方法を示す例については、バックエンド バケットを使用したロードバランサの設定をご覧ください。

Google Kubernetes Engine Ingress で HTTP/2 を使用するか、Ingress で gRPC と HTTP/2 を使用して、外部 HTTP(S) ロードバランサを構成する場合は、Ingress による HTTP/2 を使用した負荷分散をご覧ください。

次の表に、HTTP(S) ロード バランシングでサポートされるバックエンド機能を示します。


ロードバランサ モード
バックエンド サービスでサポートされるバックエンド バックエンド バケットのサポート Google Cloud Armor のサポート Cloud CDN のサポート IAP のサポート
インスタンス グループ ゾーン NEG インターネット NEG サーバーレス NEG ハイブリッド NEG
外部 HTTP(S) ロードバランサ
プレミアム ティアを使用する場合

リージョン外部 HTTP(S) ロードバランサ

詳しくは以下をご覧ください。

バックエンドへのプロトコル

外部 HTTP(S) ロードバランサのバックエンド サービスを構成する際には、バックエンド サービスがバックエンドと通信するために使用するプロトコルを設定します。HTTP、HTTPS、HTTP/2 を選択できます。指定したプロトコルのみがロードバランサで使用されます。指定されたプロトコルでバックエンドへの接続をネゴシエートできない場合、ロードバランサは他のプロトコルへのフォールバックを行いません。

HTTP/2 を使用する場合は、TLS を使用する必要があります。暗号化されていない HTTP/2 はサポートされません。

サポートされているプロトコルの一覧については、ロード バランシング機能: ロードバランサからバックエンドへのプロトコルをご覧ください。

WebSocket のサポート

Google Cloud の HTTP(S) ベースのロードバランサは、HTTP または HTTPS をバックエンドへのプロトコルとして使用する場合、WebSocket プロトコルをネイティブにサポートします。ロードバランサに、WebSocket 接続のプロキシを構成する必要はありません。

WebSocket プロトコルは、クライアントとサーバー間で全二重の通信チャネルを提供します。HTTP(S) リクエストによってチャネルが開始されます。プロトコルの詳細については、RFC 6455 をご覧ください。

ロードバランサで HTTP(S) クライアントからの WebSocket Upgrade リクエストが認識され、続いてバックエンド インスタンスから Upgrade の正常終了のレスポンスが送られた場合、現在の接続の存続期間の間、ロードバランサによって双方向トラフィックがプロキシされます。バックエンド インスタンスから Upgrade の正常終了のレスポンスが返されない場合、ロードバランサによって接続が閉じられます。

WebSocket 接続のタイムアウトは、ロードバランサの構成可能なバックエンド サービス タイムアウトによって異なります。デフォルトは 30 秒です。このタイムアウトは、WebSocket 接続が使用中かどうかに関係なく WebSocket 接続に適用されます。

WebSocket のセッション アフィニティは、他のリクエストの場合と同じように機能します。詳細については、セッション アフィニティをご覧ください。

Google Cloud アプリケーションで gRPC を使用する

gRPC は、リモート プロシージャ コール用のオープンソース フレームワークです。これは HTTP/2 標準に基づいています。gRPC のユースケースには次のものがあります。

  • 低レイテンシでスケーラビリティの高い分散システム
  • クラウド サーバーと通信するモバイル クライアントの開発
  • 正確かつ効率的で言語に依存しない新しいプロトコルの設計
  • 拡張、認証、ロギングを可能にする階層型の設計

Google Cloud アプリケーションで gRPC を使用するには、HTTP/2 経由でエンドツーエンドでリクエストをプロキシする必要があります。外部 HTTP(S) ロードバランサでこれを行うには:

  1. HTTPS ロードバランサを構成します。
  2. ロードバランサからバックエンドへのプロトコルとして HTTP/2 を有効にします。

ロードバランサは、ALPN TLS 拡張を使用して SSL handshake の一部としてクライアントと HTTP/2 をネゴシエートします。

ロードバランサとバックエンド インスタンス間で HTTP/2 を使用するように構成された外部 HTTP(S) ロードバランサでは、一部のクライアントとの HTTPS のネゴシエーションや、セキュアでない HTTP リクエストの受け入れが可能です。これらの HTTP または HTTPS リクエストはロードバランサによって変換され、リクエストは HTTP/2 経由でバックエンド インスタンスにプロキシされます。

バックエンドで TLS を有効にする必要があります。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。

Google Kubernetes Engine Ingress で HTTP/2 を使用するか、Ingress で gRPC と HTTP/2 を使用して、外部 HTTP(S) ロードバランサを構成する場合は、Ingress による HTTP/2 を使用したロード バランシングをご覧ください。

HTTP/2 の問題のトラブルシューティングについては、バックエンドへの HTTP/2 の問題のトラブルシューティングをご覧ください。

HTTP/2 の制限の詳細については、HTTP/2 の制限をご覧ください。

ヘルスチェック

各バックエンド サービスは、バックエンド インスタンスのヘルスチェックを指定します。

ヘルスチェック プローブでは、トラフィックがバックエンド インスタンスに到達できるように上り(内向き)許可ファイアウォール ルールを作成する必要があります。ファイアウォール ルールでは、次のソース範囲を許可する必要があります。

  • 130.211.0.0/22
  • 35.191.0.0/16

必須ではありませんが、バックエンド サービスのプロトコルと一致するプロトコルでのヘルスチェックを使用することをおすすめします。たとえば、バックエンドに対する HTTP/2 の接続性を最も正確にテストできるのは HTTP/2 ヘルスチェックです。サポートされているヘルスチェック プロトコルの一覧については、ロード バランシング機能をご覧ください。

次の表に、各モードの外部 HTTP(S) ロードバランサでサポートされるヘルスチェックのスコープを示します。

ロードバランサ・モード ヘルスチェックのタイプ
外部 HTTP(S) ロードバランサ グローバル
リージョン外部 HTTP(S) ロードバランサ リージョン

ヘルスチェックの詳細については、以下をご覧ください。

ファイアウォール ルール

外部 HTTP(S) ロードバランサには、次のファイアウォール ルールが必要です。

  • 外部 HTTP(S) ロードバランサの場合、上り(内向き)許可ルールによって、Google Front End(GFE)からのトラフィックがバックエンドに到達できます。
    リージョン外部 HTTP(S) ロードバランサの場合、上り(内向き)許可ルールによって、プロキシ専用サブネットからのトラフィックが許可されます。
  • ヘルスチェック プローブ範囲からのトラフィックを許可する上り(内向き)許可ルール。ヘルスチェック プローブの詳細と、プローブからのトラフィックを許可する必要がある理由については、プローブ IP 範囲とファイアウォール ルールをご覧ください。

これらのファイアウォール ルールのポートは、次のように構成する必要があります。

  • 各バックエンド サービスのヘルスチェックのための宛先ポートへのトラフィックを許可する。

  • インスタンス グループのバックエンドの場合: バックエンド サービスの名前付きポートと、各インスタンス グループの名前付きポートに関連付けられたポート番号とのマッピングによって、構成するポートを決定します。同じバックエンド サービスに割り当てられたインスタンス グループ間でポート番号が異なる可能性があります。

  • GCE_VM_IP_PORT NEG バックエンドの場合: エンドポイントのポート番号へのトラフィックを許可します。

ファイアウォール ルールは GFE プロキシではなく、VM インスタンス レベルで実装されます。Google Cloud ファイアウォール ルールを使用して、トラフィックがロードバランサに到達しないようにすることはできません。外部 HTTP(S) ロードバランサの場合、Google Cloud Armor を使用してこれを実現できます。

次の表は、外部 HTTP(S) ロードバランサの場合、ファイアウォール ルールに必要な IP アドレス範囲をまとめたものです。

ロードバランサ・モード ヘルスチェックのソース範囲 ソース範囲をリクエストする
外部 HTTP(S) ロードバランサ
  • 130.211.0.0/22
  • 35.191.0.0/16
GFE トラフィックのソースはバックエンド タイプによって異なります。
  • インスタンス グループ、ゾーン NEG(GCE_VM_IP_PORT)、ハイブリッド接続 NEG(NON_GCP_PRIVATE_IP_PORT):
    • 130.211.0.0/22
    • 35.191.0.0/16
  • インターネット NEG(INTERNET_FQDN_PORTINTERNET_IP_PORT):
    • 34.96.0.0/20
    • 34.127.192.0/18
  • SERVERLESS NEG とバックエンド バケット: Google の本番環境ネットワークがパケット ルーティングを処理します。
リージョン外部 HTTP(S) ロードバランサ
  • 130.211.0.0/22
  • 35.191.0.0/16
構成するプロキシ専用サブネット

HTTP(S) 負荷分散での接続の仕組み

外部 HTTP(S) ロードバランサ接続

外部 HTTP(S) ロードバランサは、Google Front End(GFE)と呼ばれる多数のプロキシによって実装されるサービスです。プロキシは 1 つではありません。プレミアム ティアでは、同じグローバル外部 IP アドレスがさまざまな拠点からアドバタイズされ、クライアント リクエストはクライアントの最も近い GFE に送信されます。

クライアントがいる場所に応じて、複数の GFE がバックエンドへの HTTP(S) 接続を開始できます。GFE から送信されたパケットには、ヘルスチェック プローバーが使用するものと同じ範囲(35.191.0.0/16130.211.0.0/22)の送信元 IP アドレスがあります。

バックエンド サービスの構成に応じて、各 GFE がバックエンドに接続するために使用するプロトコルは HTTP、HTTPS、HTTP/2 のいずれかになります。HTTP 接続または HTTPS 接続の場合、使用される HTTP バージョンは HTTP 1.1 です。

HTTP キープアライブ は、HTTP 1.1 仕様で指定されているように、デフォルトで有効になっています。HTTP キープアライブ は、同じ TCP セッションを効率的に使用しようとしますが、保証はありません。GFE は キープアライブ タイムアウトを 600 秒に設定しており、構成できません。ですが、バックエンド サービスのタイムアウトを設定することで、リクエスト/レスポンスのタイムアウトを構成できます。密接に関連していますが、HTTP キープアライブ と TCP アイドル タイムアウトは同じではありません。詳しくは、タイムアウトと再試行をご覧ください。

HTTP 接続と TCP セッションの数は、GFE の接続数、GFE に接続するクライアントの数、バックエンドへのプロトコル、バックエンドのデプロイ場所によって異なります。

詳細については、ソリューション ガイドの HTTP(S) 負荷分散の仕組み: グローバル負荷分散によるアプリケーション容量の最適化をご覧ください。

リージョン外部 HTTP(S) ロードバランサ接続

リージョン外部 HTTP(S) ロードバランサは、Envoy プロキシに実装されるマネージド サービスです。リージョン外部 HTTP(S) ロードバランサは、プロキシ専用サブネットと呼ばれる共有サブネットを使用して、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスをプロビジョニングします。このプロキシ専用サブネットの --purpose フラグは、REGIONAL_MANAGED_PROXY に設定されています。特定のネットワークとリージョンにあるすべてのリージョン外部 HTTP(S) ロードバランサは、このサブネットを共有します。

クライアントは、ロードバランサの IP アドレスとポートを使用してロードバランサに接続します。クライアント リクエストは、クライアントと同じリージョンのプロキシ専用サブネットに転送されます。ロードバランサはクライアント リクエストを終了し、プロキシ専用サブネットからバックエンドへの新しい接続を開きます。したがって、ロードバランサから送信されたパケットには、プロキシ専用サブネットからの送信元 IP アドレスが含まれます。

バックエンド サービスの構成に応じて、Envoy プロキシがバックエンドに接続するために使用するプロトコルは HTTP、HTTPS、HTTP/2 のいずれかになります。HTTP または HTTPS の場合の HTTP バージョンは HTTP 1.1 です。HTTP キープアライブ は、HTTP 1.1 仕様で指定されているように、デフォルトで有効になっています。Envoy プロキシは、キープアライブ タイムアウトを 600 秒に設定しており、構成できません。ですが、バックエンド サービスのタイムアウトを設定することで、リクエスト/レスポンスのタイムアウトを構成できます。詳しくは、タイムアウトと再試行をご覧ください。

ロードバランサとのクライアント通信

  • クライアントは HTTP 1.1 または HTTP/2 プロトコルを使用してロードバランサと通信できます。
  • 最近のクライアントは、HTTPS を使用するとデフォルトで HTTP/2 になります。この制御は HTTPS ロードバランサではなくクライアント上で行われます。
  • ロードバランサで構成を変更することで、HTTP/2 を無効にすることはできません。ただし、一部のクライアントは、HTTP/2 ではなく HTTP 1.1 を使用するように構成できます。たとえば、curl では、--http1.1 パラメータを使用します。
  • HTTP(S) 負荷分散は、HTTP/1.1 100 Continue レスポンスをサポートしています。

各モードの HTTP(S) ロード バランシング転送ルールでサポートされるプロトコルの一覧については、ロードバランサの機能をご覧ください。

クライアント パケットの送信元 IP アドレス

バックエンドから見たパケットの送信元 IP アドレスは、ロードバランサの Google Cloud の外部 IP アドレスではありません。つまり、2 つの TCP 接続があります。

外部 HTTP(S) ロードバランサの場合:
  • 接続 1: 元のクライアントからロードバランサ(GFE)への接続。

    • 送信元 IP アドレス: オリジナルのクライアント(クライアントが NAT の背後にある場合や外部プロキシの場合は外部 IP アドレス)。
    • 宛先 IP アドレス: ロードバランサの IP アドレス。
  • 接続 2: ロードバランサ(GFE)からバックエンド VM またはエンドポイントへの接続。

    • 送信元 IP アドレス: ファイアウォール ルールで指定された範囲の IP アドレス。

    • 宛先 IP アドレス: VPC ネットワーク内のバックエンド VM またはコンテナの内部 IP アドレス。

リージョン外部 HTTP(S) ロードバランサの場合:

  • 接続 1: 元のクライアントからロードバランサ(プロキシ専用サブネット)への接続。

    • 送信元 IP アドレス: オリジナルのクライアント(クライアントが NAT の背後にある場合や外部プロキシの場合は外部 IP アドレス)。
    • 宛先 IP アドレス: ロードバランサの IP アドレス。
  • 接続 2: ロードバランサ(プロキシ専用サブネット)からバックエンド VM またはエンドポイントへの接続。

    • 送信元 IP アドレス: ロードバランサと同じリージョン、同じネットワークにデプロイされたすべての Envoy ベースのロードバランサ間で共有されるプロキシ専用サブネットのIPアドレス。

    • 宛先 IP アドレス: VPC ネットワーク内のバックエンド VM またはコンテナの内部 IP アドレス。

リターンパス

外部 HTTP(S) ロードバランサの場合、Google Cloud は VPC ネットワークで定義されていない特殊なルートをヘルスチェックに使用します。詳細については、ロードバランサのリターンパスをご覧ください。

リージョン外部 HTTP(S) ロードバランサの場合、Google Cloud はオープンソースの Envoy プロキシを使用してロードバランサへのクライアント リクエストを終了します。ロードバランサが TCP セッションを終了し、リージョンのプロキシ専用サブネットからバックエンドへの新しい TCP セッションを開きます。VPC ネットワーク内で定義されたルートにより、Envoy プロキシからバックエンドへの通信と、バックエンドから Envoy プロキシへの通信が可能になります。

オープンポート

このセクションは、GFE を使用して実装された外部 HTTP(S) ロードバランサにのみ適用されます。

GFE には、同じアーキテクチャで実行される他の Google サービスをサポートするための複数のオープンポートがあります。GFE で開かれる可能性のあるポートの一覧を確認するには、転送ルール: ポートの仕様をご覧ください。GFE で実行されている他の Google サービス用に他のオープンポートが存在する可能性もあります。

GFE ベースのロードバランサの IP アドレスに対してポートスキャンを実行することは、次の理由により、監査の観点からは役立ちません。

  • 通常、ポートスキャン(たとえば nmap を使用)では、TCP SYN プローブを実行するときにレスポンス パケットや TCP RST パケットは想定されません。ロードバランサがプレミアム ティアの IP アドレスを使用する場合、GFE はさまざまなポートに対する SYN プローブへのレスポンスとして SYN-ACK パケットを送信します。ただし、GFE は、ロードバランサの IP アドレスと、転送ルールで構成されている宛先ポートにパケットが送信された場合にのみ、パケットをバックエンドに送信します。別のロードバランサの IP アドレスや、転送ルールに構成されていないポートのロードバランサの IP アドレスに送信されたパケットは、ロードバランサのバックエンドに送信されません。GFE は、Google Cloud Armor などのセキュリティ機能を実装しています。Google Cloud Armor の構成がなくても、Google のインフラストラクチャと GFE は DDoS 攻撃と SYN フラッドに対して多層防御を提供します。

  • ロードバランサの IP アドレスに送信されたパケットには Google のフリートの任意の GFE が応答可能ですが、ロードバランサの IP アドレスと宛先ポートの組み合わせをスキャンすると、TCP 接続ごとに 1 つの GFE のみが検査されます。ロードバランサの IP アドレスは、単一のデバイスまたはシステムに割り当てられていません。したがって、GFE ベースのロードバランサの IP アドレスをスキャンしても、Google のフリート内のすべての GFE がスキャンされるわけではありません。

以下では、この点を考慮し、バックエンド インスタンスのセキュリティをより効果的に監査する方法を説明します。

  • セキュリティ監査担当者は、ロードバランサの構成で転送ルールの構成を検査する必要があります。転送ルールは、ロードバランサがパケットを受け入れてバックエンドに転送する宛先ポートを定義しています。GFE ベースのロードバランサの場合、1 つの外部転送ルールで参照できる宛先 TCP ポートは 1 つだけです。TCP ポート 443 を使用する外部 HTTP(S) ロードバランサの場合、接続が QUIC(HTTP/3)にアップグレードされると、UDP ポート 443 が使用されます。

  • セキュリティ監査担当者は、バックエンド VM に適用されるファイアウォール ルールの構成を検査する必要があります。ファイアウォール ルールの設定では、GFE からバックエンド VM へのトラフィックをブロックしますが、GFE への受信トラフィックはブロックしません。ベスト プラクティスについては、ファイアウォール ルールのセクションをご覧ください。

TLS 終端

次の表は、TLS 終端が各モードの外部 HTTP(S) ロードバランサでどのように処理されるかをまとめたものです。

ロードバランサ・モード TLS 終端
外部 HTTP(S) ロードバランサ TLS は、世界中のあらゆる場所にある GFE で終端されます。
リージョン外部 HTTP(S) ロードバランサ ユーザーが選択したリージョンのプロキシ専用サブネットにある Envoy プロキシで TLS が終端されます。このロードバランサ モードは、TLS が終端されるリージョンを地理的に制御する必要がある場合に使用します。

タイムアウトと再試行

HTTP(S) 負荷分散には次の 2 種類のタイムアウトがあります。
  • 構成可能な HTTP バックエンド サービス タイムアウト。ロードバランサがバックエンドから完全な HTTP レスポンスが返されるまで待機する時間です。バックエンド サービス タイムアウトのデフォルト値は 30 秒です。指定できるタイムアウト値の範囲は 1~2,147,483,647 秒です。

    HTTP トラフィックの場合、このタイムアウトは HTTP リクエストとレスポンスの最大時間です。

    WebSocket トラフィックの場合、このタイムアウトはアイドル状態かアクティブかにかかわらず、WebSocket 接続をオープン状態に保てる最長時間です。

    次のいずれかの状況では、タイムアウトを長くすることを検討してください。

    • バックエンドが HTTP レスポンスを返すのに時間がかかることが予想される場合。
    • jsonPayload.statusDetail client_timed_out の HTTP 408 レスポンスが返された場合。
    • 接続が WebSocket にアップグレードされた場合。

    1 日(86,400 秒)などが、外部 HTTP(S) ロードバランサの現実的なタイムアウト値になります。GFE の再起動などのイベントにより、このタイムアウトよりも早くセッションが終了する可能性があるので注意してください。

    バックエンド サービス タイムアウトは、HTTP のアイドル(キープアライブ)タイムアウトではありません。バックエンドからの入出力(IO)は、クライアントの速度が遅い場合(ブラウザの接続が遅い場合など)にブロックされる可能性があります。この待機時間は、バックエンド サービス タイムアウトにはカウントされません。

    リージョン外部 HTTP(S) ロードバランサの場合、URL マップの routeActions.timeout パラメータがバックエンド サービスのタイムアウトをオーバーライドします。バックエンド サービス タイムアウトは、routeActions.timeout のデフォルト値として使用されます。

  • HTTP キープアライブ タイムアウト。この値は 10 分(600 秒)に固定されています。この値は、バックエンド サービスを変更しても構成できません。バックエンドによって接続が早期に閉じられないようにするには、バックエンドによって使用されているウェブサーバー ソフトウェアでキープアライブ タイムアウトを 600 秒より長い時間に設定する必要があります。このタイムアウトは WebSocket には適用されません

    次の表は、一般的なウェブサーバー ソフトウェアの、keep-alive タイムアウトを変更するために必要な変更を示します。

    ウェブサーバー ソフトウェア パラメータ デフォルト設定 推奨される設定
    Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
    nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;
再試行ロジックのための HTTP(S) ロード バランシングのサポートは、外部 HTTP(S) ロードバランサのモードによって異なります。

ロードバランサ・モード 再試行ロジック
外部 HTTP(S) ロードバランサ

再試行ポリシーは変更できません。

HTTP POST リクエストは再試行されません。

HTTP GET リクエストは、バックエンドの 80% 以上が正常である限り、常に 1 回再試行されます。グループ内に存在するバックエンド インスタンスが 1 つだけで、そのバックエンド インスタンスへの接続が失敗した場合、正常でないバックエンド インスタンスの割合が 100% になるため、GFE はリクエストを再試行しません。

ロードバランサは、バックエンド サービス タイムアウトに達したときなど、特定の状況で失敗した GET リクエストを再試行します。再試行回数は 2 回に制限されています。再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。詳細については、HTTP(S) ロード バランシングのロギングとモニタリングをご覧ください。

リクエストが失敗すると、ロードバランサは HTTP 502 レスポンスを合成します。

リージョン外部 HTTP(S) ロードバランサ

URL マップの再試行ポリシーを使用して構成できます。

再試行ポリシーがない場合、HTTP 本文がないリクエスト(GET リクエストなど)が 1 回再試行されます。

WebSocket プロトコルは Ingress でもサポートされています。

不正なリクエストとレスポンスの処理

外部 HTTP(S) ロードバランサは、いくつかの理由により、クライアント リクエストとバックエンド レスポンスのいずれについても、相手方のバックエンドまたはクライアントに到達しないようにブロックすることがあります。厳密に HTTP/1.1 を遵守するためという理由もあれば、バックエンド間での予期しないデータのやり取りを避けるという理由もあります。無効にできるチェックはありません。

ロードバランサは、HTTP/1.1 への適合のために以下をブロックします。

  • 要求の最初の行を解析できない。
  • ヘッダーに : 区切り文字がない。
  • ヘッダーまたは最初の行に無効な文字が含まれている。
  • コンテンツの長さが有効な数値でない、または、複数のコンテンツ長ヘッダーがある。
  • 複数の転送エンコーディング キーがある、または、認識されない転送エンコーティング値がある。
  • チャンク化されていない本文があり、コンテンツの長さが指定されていない。
  • 本文のチャンクが解析できない。なんらかのデータがバックエンドに到達するのはこの場合のみです。ロードバランサは、解析不能なチャンクを受信すると、クライアントとバックエンドへの接続を閉じます。

次のいずれかが該当する場合、ロードバランサはリクエストをブロックします。

  • リクエスト ヘッダーとリクエスト URL の合計サイズが、外部 HTTP(S) 負荷分散のリクエストのヘッダーサイズの上限を超えている。
  • リクエスト メソッドが本文を許可していないにもかかわらず、リクエストに本文がある。
  • リクエストに Upgrade ヘッダーが含まれており、WebSocket 接続の有効化に Upgrade ヘッダーが使用されない。
  • HTTP のバージョンが不明。

ロードバランサは、次のいずれかに該当する場合、バックエンドからのレスポンスをブロックします。

  • レスポンス ヘッダーの合計サイズが、外部 HTTP(S) 負荷分散の最大レスポンス ヘッダーのサイズの上限を超えている。
  • HTTP のバージョンが不明。

トラフィック分散

バックエンド インスタンス グループまたは NEG をバックエンド サービスに追加する場合は、バックエンドの負荷とターゲット容量を測定する方法を定義する分散モードを指定します。外部 HTTP(S) 負荷分散は、以下の 2 つの分散モードをサポートします。

  • インスタンス グループまたは NEG の場合、RATE は 1 秒あたりのリクエスト(クエリ)の最大数(RPS、QPS)の目標です。すべてのバックエンドが容量を超えると、目標最大 RPS / QPS を超過する場合があります。

  • UTILIZATION はインスタンス グループ内の VM のバックエンド使用率です。

バックエンド間でのトラフィック分散方法は、外部 HTTP(S) ロードバランサのモードによって異なります。

外部 HTTP(S) ロードバランサのトラフィック分配

Google Front End(GFE)はバックエンド インスタンスにリクエストを送信する前に、どのバックエンド インスタンスがリクエストを受信できるかを推定します。この容量の見積もりは、リクエストの到着と同時に行われるのではなく、事前に行われます。GFE は、利用可能な容量に関する情報を定期的に受け取り、それに応じて受信リクエストを分散します。

容量の意味は、分散モードによって異なります。RATE モードの場合は比較的単純です。GFE は 1 秒あたりに割り当てることができるリクエスト数を正確に決定します。UTILIZATION ベースの負荷分散はより複雑です。ロードバランサはインスタンスの現在の使用率をチェックし、各インスタンスが処理できるクエリ負荷を見積もります。この推定値は、インスタンスの使用率とトラフィック パターンの変化に応じて変化します。

容量の見積もりと事前の割り当ての両方の要素が、インスタンス間の分散に影響します。そのため、Cloud Load Balancing の動作は、2 つのインスタンス間でリクエストを正確に 50:50 に分散する単純なラウンドロビン ロードバランサとは異なります。Google Cloud 負荷分散は、リクエストごとにバックエンド インスタンスの選択を最適化します。

詳細については、トラフィック分散をご覧ください。

リージョン外部 HTTP(S) ロードバランサのトラフィック分配

リージョン外部 HTTP(S) ロードバランサの場合、トラフィック分散はロード バランシング モードとロード バランシングのロケーション ポリシーに基づきます。

分散モードでは、各グループ(インスタンス グループまたは NEG)に送信するトラフィックの重みと割合を決定します。ロード バランシングの地域区分ポリシー(LocalityLbPolicy)により、グループ内のバックエンドのロード バランシング方法が決まります。

トラフィックを受信すると、バックエンド サービスはバックエンドの分散モードに従ってバックエンド(インスタンス グループまたは NEG)にトラフィックを転送します。バックエンドが選択されると、ロード バランシングの局所性ポリシーに従って、バックエンド グループ内のインスタンスまたはエンドポイント間でトラフィックが分散されます。

詳細情報

リクエストの分散方法

トラフィックがリージョン単位で分散されるかグローバルに分散されるかは、ロードバランサ モードと Network Service Tiers がどのように使用されているかによって異なります。

プレミアム ティアの場合(外部 HTTP(S) ロードバランサにのみ適用):

  • Google は、全世界のあらゆる拠点からロードバランサの IP アドレスをアドバタイズします。各ロードバランサの IP アドレスはグローバル エニーキャストです。
  • 複数のリージョンにバックエンドを持つバックエンド サービスを構成した場合、Google Front End(GFE)は、ユーザーに最も近いリージョンの正常なバックエンド インスタンス グループまたは NEG にリクエストを転送しようとします。このプロセスについては、このページで詳しく説明します。

スタンダード ティアの場合:

  • Google は、転送ルールのリージョンに関連付けられた接続拠点からロードバランサの IP アドレスをアドバタイズします。ロードバランサは、リージョン外部 IP アドレスを使用します。

  • バックエンドは、転送ルールと同じリージョンに構成できます。ここで説明するプロセスは引き続き適用されますが、GFE は対象の 1 つのリージョン内に存在する正常なバックエンドにのみリクエストを転送します。

リクエストの分散プロセス:

分散モードとターゲットの選択により、各ゾーン GCE_VM_IP_PORT NEG、ゾーン インスタンス グループ、またはリージョン インスタンス グループのゾーンの観点からバックエンドの完全性が定義されます。その後、ゾーン内での分散が一貫したハッシュを使用して行われます。

ロードバランサは、次のプロセスを使用します。

  1. 転送ルールの外部 IP アドレスは、Google ネットワークの境界にあるエッジルーターによってアドバタイズされます。各アドバタイズでは、可能な限りユーザーに近いレイヤ 3/4 のロード バランシング システム(Maglev)へのネクストホップの一覧が取得されます。
  2. Maglev システムが受信パケットの送信元 IP アドレスを検査します。受信したリクエストは、Google の geo-IP システムが可能な限りユーザーの近くに存在すると判断した Maglev システムに送信されます。
  3. Maglev システムは、最初のレイヤの Google Front End(GFE)にトラフィックを転送します。最初のレイヤの GFE は、必要に応じて TLS を終了し、このプロセスに従ってトラフィックを 2 番目のレイヤの GFE にルーティングします。
    1. URL マップでバックエンド サービスが選択されます。
    2. バックエンド サービスがインスタンス グループまたは GCE_VM_IP_PORT NEG バックエンドを使用する場合、最初のレイヤの GFE は、インスタンス グループまたは NEG を含むリージョン内か、またはその近くに配置された 2 番目のレイヤの GFE を優先します。
    3. ハイブリッド NEG、サーバーレス NEG、インターネット NEG のバックエンド バケットとバックエンド サービスの場合、最初のレイヤの GFE は 2 番目の GFE をリージョンのサブセットで選択します。これにより、2 つの GFE 間のラウンドトリップ時間が最小化されます。

      2 番目のレイヤの GFE の優先は保証されず、Google のネットワーク条件とメンテナンスに基づいて動的に変更される可能性があります。

      2 番目のレイヤの GFE は、ヘルスチェックのステータスと実際のバックエンド容量の使用率を認識します。

  4. 2 番目のレイヤの GFE は、リージョン内のゾーンのバックエンドにリクエストを転送します。
  5. プレミアム ティアの場合は、2 番目のレイヤの GFE が、異なるリージョンのゾーンにあるバックエンドにリクエストを送信する可能性があります。この動作はスピルオーバーと呼ばれます。
  6. スピルオーバーには次の 2 つの原則が適用されます。

    • スピルオーバーは、2 番目のレイヤの GFE に認識されるすべてのバックエンドが容量の上限に達した場合か、正常ではない場合に可能です。
    • 2 番目のレイヤの GFE には、別のリージョンのゾーンに存在する利用可能な正常なバックエンドに関する情報があります。

    通常、2 番目のレイヤの GFE は、バックエンドのロケーションのサブセットを提供するように構成されています。

    スピルオーバー動作は、使用可能なすべての Google Cloud ゾーンを使い切るわけではありません。特定のゾーンまたはリージョン全体のバックエンドからトラフィックを転送する必要がある場合は、容量スケーラーをゼロに設定する必要があります。ヘルスチェックに失敗するようにバックエンドを構成しても、2 番目のレイヤの GFE が別のリージョンのゾーンにバックエンドをスピルオーバーする保証はありません。

  7. バックエンドにリクエストを分散する場合、GFE はゾーンレベルで動作します。

    1 秒あたりのリクエスト数が少ない場合は、2 番目のレイヤの GFE がリージョン内で 1 つのゾーンを他のゾーンよりも優先する場合があります。これは、想定されている正常な設定です。ロードバランサが秒単位でより多くのリクエストを受信するまで、リージョン内のゾーン間での分散は行われません。

セッション アフィニティ

セッション アフィニティでは、構成した分散モードに基づいてバックエンドが良好な状態で容量があれば、特定のクライアントから同じバックエンドにリクエストを送信するための、ベストエフォート型の試行を行います。

セッション アフィニティを使用する場合は、UTILIZATION よりも RATE 分散モードを推奨します。セッション アフィニティは、分散モードが [リクエスト数/秒](RPS)に設定されている場合に最も機能を発揮します。

Google Cloud HTTP(S) ロード バランシングでは、次のタイプのセッション アフィニティを使用できます。

次の表は、外部 HTTP(S) ロードバランサの各モードでサポートされるセッション アフィニティのオプションをまとめたものです。

ロードバランサ・モード セッション アフィニティのオプション
  なし クライアント IP 生成した Cookie ヘッダー フィールド HTTP Cookie
外部 HTTP(S) ロードバランサ
リージョン外部 HTTP(S) ロードバランサ

HTTP/2 サポート

HTTP/2 最大同時ストリーム数

HTTP/2 の SETTINGS_MAX_CONCURRENT_STREAMS 設定は、ピアが開始し、エンドポイントが受け入れるストリームの最大数を表します。Google Cloud ロードバランサはクライアントへのストリームを開始しないため、HTTP/2 クライアントにより Google Cloud ロードバランサにアドバタイズされた値は、事実上無意味になります。

ロードバランサが HTTP/2 を使用して、VM で実行されているサーバーと通信する場合、ロードバランサはサーバーによってアドバタイズされる SETTINGS_MAX_CONCURRENT_STREAMS 値を受け入れます。値ゼロがアドバタイズされると、ロードバランサはリクエストをサーバーに転送できないため、エラーが発生する可能性があります。

HTTP/2 の制限事項

  • 外部 HTTP(S) ロードバランサの場合、ロードバランサとインスタンスの間の接続に HTTP/2 を使用する場合は、HTTP(S) の場合よりもインスタンスへの TCP 接続数を大幅に増やす必要があります。HTTP/2 では、HTTP(S) などでの接続数を減らすための最適化を提供する接続プールは現在のところ使用できません。
  • ロードバランサとバックエンドの間の HTTP/2 では、HTTP/2 接続の単一ストリームを介した WebSocket プロトコルの実行(RFC 8441)はサポートされていません。
  • ロードバランサとバックエンドの間の HTTP/2 では、サーバー push がサポートされていません。
  • gRPC エラー率とリクエスト数は Google Cloud API または Cloud Console で確認できません。gRPC エンドポイントがエラーを返した場合、ロードバランサ ログとモニタリング データに「OK 200」という HTTP レスポンス コードが記録されます。

次のステップ