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

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

HTTP(S) 負荷分散は、プロキシベースのグローバルなレイヤ 7 ロードバランサであり、単一の外部 IP アドレスの背後でサービスをグローバルに実行し、スケーリングできます。外部 HTTP(S) 負荷分散は、Compute Engine と Google Kubernetes Engine(GKE)でホストされているバックエンドに HTTP および HTTPS トラフィックを分散します。

外部 HTTP(S) 負荷分散は Google Front End(GFE)に実装されます。GFE はグローバルに分散しており、Google のグローバル ネットワークとコントロール プレーンを使用して連携を取ります。プレミアム ティアでは、GFE はマルチリージョンの負荷分散を行い、空き容量のある、最も近い正常なバックエンドにトラフィックを転送して、ユーザーにできるだけ近いところで HTTP(S) トラフィックを終端します。スタンダード ティアでは、負荷分散はリージョン単位で処理されます。

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

アーキテクチャ

外部 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 マップでは、クライアントにリダイレクトを送信するなど、追加のアクションを指定できます。

  • バックエンド サービスまたはバックエンド バケットは、正常なバックエンドにリクエストを分散します。

  • 1 つ以上のバックエンドをバックエンド サービスまたはバックエンド バケットに接続する必要があります。

  • ヘルスチェック。バックエンドの準備状況を定期的に監視します。これにより、処理不能なバックエンドにリクエストが送信されるリスクを軽減できます。

  • バックエンドがヘルスチェック プローブを受け入れるためのファイアウォール

転送ルールとアドレス

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

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

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

外部 HTTP(S) ロードバランサに必要な転送ルールと IP アドレスのタイプは、ロードバランサが含まれるネットワーク サービス階層によって異なります。

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

ターゲット プロキシ

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

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

ターゲット プロキシのタイプ プロキシ追加ヘッダー カスタム ヘッダーをサポート Cloud Trace をサポート
グローバル 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 ヘッダー)(リクエストのみ)

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 を調べることで、トラフィックを分割し、リクエストを各種のバックエンド セットに送信できます。

SSL 証明書

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

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

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

SSL ポリシー

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

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

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

外部 HTTP(S) ロードバランサは、バックエンド サービスおよびバックエンド バケットを持つことができます。

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

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

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

プレミアム ティアを使用する場合

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

ヘルスチェック

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

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

  • 130.211.0.0/22
  • 35.191.0.0/16

外部 HTTP(S) ロードバランサは、グローバル ヘルスチェックを使用します。

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

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

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

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

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

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 の制限をご覧ください。

ファイアウォール ルール

バックエンド インスタンスでは、次のソースからの接続を許可する必要があります。

  • バックエンドに送信されたすべてのリクエストのロードバランサの Google Front End(GFE)
  • ヘルスチェック プローブ

このトラフィックを許可するには、上り(内向き)ファイアウォール ルールを作成する必要があります。これらのファイアウォール ルールのポートでは、次のようにトラフィックを許可する必要があります。

  • 各バックエンド サービスのヘルスチェックの宛先ポート。

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

  • GCE_VM_IP_PORT NEG バックエンドの場合: エンドポイントのポート番号。

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

ヘルスチェック プローブの詳細と、 からのトラフィックを許可する必要がある理由については、プローブ IP 範囲とファイアウォール ルールをご覧ください。

外部 HTTP(S) ロードバランサの場合、ヘルスチェックとリクエストのソース範囲を次の表に示します。

ヘルスチェックのソース範囲 GFE リクエストのソース範囲
  • 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 の本番環境ネットワークがパケット ルーティングを処理します。

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

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

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

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

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

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

リターンパス

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

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 keep-alive は、HTTP 1.1 仕様で指定されているように、デフォルトで有効になっています。GFE は keep-alive タイムアウトを 600 秒に設定しており、構成できません。ですが、バックエンド サービスのタイムアウトを設定することで、リクエスト/レスポンスのタイムアウトを構成できます。詳しくは、タイムアウトと再試行をご覧ください。

HTTP keep-alive は、同じ TCP セッションを効率的に使用しようとしますが、保証はありません。密接に関連していますが、HTTP keep-alive と TCP アイドル タイムアウトは同じではありません。

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

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

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

  • クライアントは 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) 負荷分散転送ルールでサポートされるプロトコルの一覧については、ロードバランサの機能をご覧ください。

オープンポート

外部 HTTP(S) ロードバランサはリバース プロキシのロードバランサです。ロードバランサによって受信接続が終端され、ロードバランサからバックエンドへの新しい接続が開かれます。これらのロードバランサは、世界中の Google Front End(GFE)プロキシを使用して実装されています。

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 終端

HTTPS ロードバランサは、クライアントとロードバランサ間のレイテンシを最小にするため、グローバルに分散されているロケーションで TLS を終端します。TLS を終端する場所を地理的に制御する必要がある場合は、Google Cloud ネットワーク負荷分散を代わりに使用し、ニーズに適したリージョンにあるバックエンドで TLS を終端する必要があります。

タイムアウトと再試行

HTTP(S) 負荷分散には次の 2 種類のタイムアウトがあります。

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

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

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

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

ロードバランサ経由で送信される WebSocket トラフィックのバックエンド サービスのタイムアウトは、アイドル状態かどうかにかかわらず、WebSocket 接続をオープン状態に保てる最長時間として解釈されます。詳細については、バックエンド サービスの設定をご覧ください。

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

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

ウェブサーバー ソフトウェア パラメータ デフォルト設定 推奨される設定
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

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

GFE は、80% を超えるバックエンド インスタンスが正常でない場合は、再試行を行いません。グループ内に存在するバックエンド インスタンスが 1 つだけで、そのバックエンド インスタンスへの接続が失敗した場合、正常でないバックエンド インスタンスの割合が 100% になるため、GFE はリクエストを再試行しません。詳細については、HTTP(S) 負荷分散のロギングとモニタリングをご覧ください。

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 のバックエンド使用率です。

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

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

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

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

分散モードの詳細については、分散モードをご覧ください。

リクエストの分散方法

トラフィックがリージョン単位で分散されるかグローバルに分散されるかは、使用されているネットワーク サービス層により異なります。

プレミアム ティアの場合:

  • 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)に転送します。第 1 レイヤの GFE は、必要に応じて TLS を終了し、このプロセスに従ってトラフィックを第 2 レイヤの GFE にルーティングします。
    1. URL マップでバックエンド サービスが選択されます。
    2. バックエンド サービスがインスタンス グループまたは GCE_VM_IP_PORT NEG バックエンドを使用する場合、最初のレイヤの GFE は、インスタンス グループまたは NEG を含むリージョン内またはその近くに配置された第 2 レイヤの GFE を優先します。
    3. ハイブリッド NEG、サーバーレス NEG、インターネット NEG のバックエンド バケットとバックエンド サービスの場合、第 1 レイヤの 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 つのゾーンを他のゾーンよりも優先する場合があります。これは正常な、想定されている設定です。ロードバランサが秒単位でより多くのリクエストを受信するまで、リージョン内のゾーン間の分散は起こりません。

セッション アフィニティ

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

Google Cloud HTTP(S) 負荷分散には、次の 3 種類のセッション アフィニティがあります。

  • なし。ロードバランサにセッション アフィニティが設定されていません。
  • クライアント IP アフィニティは、同じクライアント IP アドレスからのリクエストを同じバックエンドに送信します。
  • Cookie アフィニティは、最初のリクエストが行われたときにクライアント Cookie を設定し、その Cookie を含むリクエストを同じバックエンドに送信します。

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

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

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

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

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

HTTP/2 の制限事項

  • ロードバランサとインスタンスの間の接続に 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 レスポンス コードが記録されます。

次のステップ