外部 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) ロード バランシングは、次のモードで構成できます。

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

このロードバランサは、プレミアム ティアでグローバル、スタンダード ティアではリージョンとして構成できます。

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

スタンダード ネットワーク サービス ティアでは、ロード バランシングはリージョン単位で処理されます。

  • GKE に対応。
  • Google Cloud Armor(bot 管理を含む)に対応。
  • トラフィック ルーティング機能は限定されます。
機能の完全なリストについては、ロード バランシング機能のページをご覧ください。
リージョン外部 HTTP(S) ロードバランサ(プレビュー

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

このロードバランサは、1 つの位置情報のみからコンテンツを配信する場合(コンプライアンスで規制されている場合など)や、スタンダード ネットワーク サービス ティアが必要な場合に使用します。

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

モードの識別

Cloud Console

  1. Cloud Console で [ロード バランシング] ページに移動します。
    [ロード バランシング] に移動
  2. [ロードバランサ] タブに、ロードバランサのタイプ、プロトコル、リージョンが表示されます。リージョンが空の場合、ロードバランサはグローバルです。次の表に、ロードバランサのモードを識別する方法を示します。
    ロードバランサ モード ロード バランシングのタイプ リージョン ネットワーク ティア
    グローバル外部 HTTP(S) ロードバランサ(プレビュー)。 HTTP(S) PREMIUM
    グローバル外部 HTTP(S) ロードバランサ(従来) HTTP(S)(従来) STANDARD または PREMIUM
    リージョン外部 HTTP(S) ロードバランサ(プレビュー HTTP(S) リージョンを指定 STANDARD

gcloud

  1. ロードバランサのモードを確認するには、次のコマンドを実行します。

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
    

    コマンド出力で、ロード バランシング スキーム、リージョン、ネットワーク ティアを確認します。次の表に、ロードバランサのモードを識別する方法を示します。

    ロードバランサ モード ロード バランシング スキーム 転送ルール ネットワーク ティア
    グローバル外部 HTTP(S) ロードバランサ(プレビュー)。 EXTERNAL_MANAGED グローバル PREMIUM
    グローバル外部 HTTP(S) ロードバランサ(従来) EXTERNAL グローバル STANDARD または PREMIUM
    リージョン外部 HTTP(S) ロードバランサ(プレビュー EXTERNAL_MANAGED リージョンを指定 STANDARD

アーキテクチャ

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) ロードバランサ コンポーネント
リージョン外部 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 に属しているかによって異なります。

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

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

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

ロード バランシング スキーム:
EXTERNAL_MANAGED

インターネット上のクライアントに最も近い GFE にルーティングされるリクエスト。
グローバル外部 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 ヘッダーを参照)(リクエストのみ)
バックエンド サービスまたはバックエンド バケットで構成されている

Cloud CDN ではサポートされていない

グローバル外部 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/3 を有効にすると、ウェブページの読み込み時間の改善、動画の再バッファリングの低減、レイテンシが高い接続スループットの改善が可能です。

次の表に、各モードでの HTTP(S) ロード バランシングの HTTP/3 サポートを示します。

ロードバランサ モード HTTP/3 サポート
グローバル外部 HTTP(S) ロードバランサ(プレビュー
グローバル外部 HTTP(S) ロードバランサ(従来)
リージョン外部 HTTP(S) ロードバランサ(プレビュー)

HTTP/3 の構成

quicOverrideENABLE に設定することで、ロードバランサに HTTP/3 サポートを明示的に有効にできます。

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

HTTP(S) ロード バランシングには、次の表に示すように HTTP/3 を構成する方法が 3 つあります。

quicOverride 値 動作
NONE

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

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. 編集するロードバランサを選択します。

  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 として構成されている場合、ロードバランサからのレスポンスには、次の alt-svc ヘッダー値が含まれます。

alt-svc: h3=":443"; ma=2592000,h3-29=":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) ロードバランサとリージョン外部 HTTP(S) ロードバランサで使用する URL マップは、ヘッダーに基づくトラフィック ステアリング、重み付けに基づくトラフィック分割、リクエスト ミラーリングなどの高度なトラフィック管理機能をサポートしています。詳しくは以下をご覧ください。

次の表に、各モードで HTTP(S) ロード バランシングに必要な URL マップの種類を示します。

ロードバランサ モード URL マップのタイプ
グローバル外部 HTTP(S) ロードバランサ(プレビュー グローバル
グローバル外部 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) ロードバランサ(従来) グローバル
リージョン外部 HTTP(S) ロードバランサ(プレビュー) リージョン

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

Certificate Manager

プレミアム ネットワーク サービス ティアでグローバル外部 HTTP(S) ロードバランサ(従来型)を使用している場合は、Certificate Manager のプレビュー リリースを使用して、グローバル外部 HTTP(S) ロードバランサ(従来)の複数インスタンスにわたって大規模に SSL 証明書のプロビジョニングと管理を行うことができます。詳細については、Certificate Manager の概要をご覧ください。

SSL ポリシー

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

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

次の表に、各モードでのロードバランサに対する SSL ポリシーのサポートを示します。

ロードバランサ モード サポートされる SSL ポリシー
グローバル外部 HTTP(S) ロードバランサ(プレビュー
グローバル外部 HTTP(S) ロードバランサ(従来)
リージョン外部 HTTP(S) ロードバランサ(プレビュー)

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

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

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

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


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

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

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

バックエンドと VPC ネットワーク

バックエンドを配置するロケーションの制限は、ロードバランサの種類によって異なります。

  • グローバル外部 HTTP(S) ロードバランサとグローバル外部 HTTP(S) ロードバランサ(従来)の場合、すべてのバックエンドは同じプロジェクトに配置する必要がありますが、異なる VPC ネットワークに配置できます。GFE プロキシ システムはそれぞれの VPC ネットワーク内のバックエンドと直接通信するため、異なる VPC ネットワークを VPC ネットワーク ピアリングで接続する必要はありません。
  • リージョン外部 HTTP(S) ロードバランサの場合、すべてのバックエンドを同じ VPC ネットワークとリージョンに配置する必要があります。

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

ロードバランサのバックエンド サービスを構成する際には、バックエンド サービスがバックエンドと通信するために使用するプロトコルを設定します。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 経由でエンドツーエンドでリクエストをプロキシする必要があります。手順は次のとおりです。

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

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

ロードバランサは、ロードバランサとバックエンド インスタンスの間で HTTP/2 を使用するように構成されたロードバランサで、一部のクライアントと 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) ロード バランシングには、次のファイアウォール ルールが必要です。

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

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

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

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

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

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

次の表は、ファイアウォール ルールに必要な送信元 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
  • SERVERLESS NEG とバックエンド バケット: Google の本番環境ネットワークがパケット ルーティングを処理します。
グローバル外部 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 を使用するロードバランサの場合、接続を QUIC(HTTP/3)にアップグレードすると、UDP ポート 443 が使用されます。

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

TLS 終端

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

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

タイムアウトと再試行

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

    たとえば、バックエンド サービスのタイムアウトの値がデフォルト値の 30 秒である場合、バックエンドにはリクエストに応答するための時間が 30 秒あります。ロードバランサは、バックエンドが接続を閉じるか、レスポンス ヘッダーをロードバランサに送信する前にタイムアウトになると、HTTP GET リクエストを 1 回再試行します。バックエンドがレスポンス ヘッダーを送信する場合、またはバックエンドに送信されるリクエストが HTTP GET リクエストでない場合、ロードバランサは再試行しません。バックエンドがまったく応答しない場合、ロードバランサは HTTP 5xx レスポンスをクライアントに返します。これらのロードバランサでは、バックエンドがリクエストに応答するまでの時間を増減する場合は、タイムアウト値を変更します。

    バックエンド サービスのタイムアウトは、GFE とバックエンド間の処理のため、リクエストの最初のバイトからレスポンスの最後のバイトまでの最大時間に設定する必要があります。WebSocket を使用している場合は、バックエンド サービスのタイムアウトを WebSocket の最大時間(アイドルまたはアクティブ)に設定する必要があります。

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

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

    設定するバックエンド サービスのタイムアウトはベスト エフォート型の目標です。ただし、基礎となる TCP 接続が、タイムアウトの間にオープン状態になっているとは限りません。

    バックエンド サービスのタイムアウトは任意の値に設定できますが、1 日(86,400 秒)を超える値に設定しても、ロードバランサはその期間 TCP 接続を継続するわけではありません。継続する場合もあれば、そうでない場合もあります。Google は、ソフトウェアの更新と定期的なメンテナンスで GFE を定期的に再起動しますが、バックエンド サービスのタイムアウトはそれをオーバーライドしません。バックエンド サービスのタイムアウトを長くするほど、Google が GFE のメンテナンスで TCP 接続を終了する可能性が高くなります。このようなイベントの影響を減らすため、再試行ロジックの実装をおすすめします。

    詳細については、バックエンド サービスの設定をご覧ください。

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

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

  • HTTP キープアライブ タイムアウト。この値は 10 分(600 秒)に固定されています。この値は、バックエンド サービスを変更しても構成できません。バックエンドによって接続が早期に閉じられないようにするには、バックエンドによって使用されているウェブサーバー ソフトウェアでキープアライブ タイムアウトを 600 秒より長い時間に構成する必要があります。このタイムアウトは WebSocket には適用されません。次の表は、一般的なウェブサーバー ソフトウェアのキープアライブ タイムアウトを変更するために必要な変更を示します。
    ウェブサーバー ソフトウェア パラメータ デフォルト設定 推奨される設定
    Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
    nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

再試行数

再試行ロジックのための HTTP(S) ロード バランシングのサポートは、外部 HTTP(S) ロードバランサのモードによって異なります。

ロードバランサ モード 再試行ロジック
グローバル外部 HTTP(S) ロードバランサ(プレビュー)。

URL マップの再試行ポリシーを使用して構成できます。デフォルトの再試行回数(numRetries)は 1 回です。再試行ポリシーを使用して構成できる再試行の最大数は 25 です。デフォルトのタイムアウト(perTryTimeout)は 30 秒です。perTryTimeout は最大 24 時間で構成できます。

再試行ポリシーがない場合、HTTP 本文のないリクエスト(GET リクエストなど)が HTTP 502、503、または 504 レスポンスを返すと、1 回再試行されます。HTTP POST リクエストは再試行されません。

グローバル外部 HTTP(S) ロードバランサ(従来)

接続の再試行に関する再試行ポリシーは変更できません。

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

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

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

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

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

URL マップで URL マップ(numRetriesを使用して構成できます。

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

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

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

ロードバランサは、いくつかの理由により、クライアント リクエストとバックエンド レスポンスのいずれについても、相手方のバックエンドまたはクライアントに到達しないようにブロックすることがあります。厳密に 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) ロードバランサ

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

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

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

グローバル外部 HTTP(S) ロードバランサ(従来)の場合、ロード バランシング モードを使用して、最も優先するバックエンド(インスタンス グループまたは NEG)を選択します。トラフィックは、ラウンドロビン方式によりバックエンド内のインスタンスまたはエンドポイント間で分散されます。

グローバル外部 HTTP(S) ロードバランサの場合、ロード バランシングは 2 層になります。分散モードでは、各バックエンド(インスタンス グループまたは NEG)に送信するトラフィックの重みまたは割合を決定します。さらに、ロード バランシング ポリシー(LocalityLbPolicy)により、グループ内のインスタンスまたはエンドポイントにトラフィックを分散する方法が決まります。詳細については、ロード バランシングの局所性ポリシー(リージョン バックエンド サービスの API ドキュメント)をご覧ください。

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

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

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

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

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

リクエストの分散方法

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

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

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

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

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

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

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

分散モードとターゲットの選択により、各ゾーン GCE_VM_IP_PORT NEG、ゾーン インスタンス グループ、またはリージョン インスタンス グループのゾーンの観点からバックエンドの完全性が定義されます。ゾーン内の分散はグローバル外部 HTTP(S) ロードバランサ(従来)のコンシステント ハッシュで行われます。これは、グローバル外部 HTTP(S) ロードバランサとリージョン外部 HTTP(S) ロードバランサのロード バランシング局所性ポリシーを使用して構成できます。

GFE ベースのグローバル外部 HTTP(S) ロードバランサは、受信リクエストを分散するために次のプロセスを使用します。

  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)に設定されている場合に最も機能を発揮します。

HTTP(S) ロード バランシングには、次のタイプのセッション アフィニティがあります。

次の表に、HTTP(S) ロード バランシングの各モードでサポートされるセッション アフィニティのオプションを示します。

ロードバランサ モード セッション アフィニティのオプション
  なし クライアント IP 生成された Cookie ヘッダー フィールド HTTP Cookie
グローバル外部 HTTP(S) ロードバランサ(プレビュー)。
グローバル外部 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/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 レスポンス コードが記録されます。

制限事項

  • HTTPS ロードバランサは、クライアント証明書ベースの認証(別名: 相互 TLS 認証)をサポートしていません。
  • HTTPS ロードバランサは、SSL 接続を終了する際に close_notify 終了アラートを送信しません。つまり、ロードバランサは SSL シャットダウンを実行する代わりに、TCP 接続を閉じます。
  • HTTPS ロードバランサでは、証明書の共通名(CN)属性またはサブジェクト代替名(SAN)属性に含まれるドメインで小文字のみがサポートされます。ドメイン名に大文字を含む証明書は、ターゲット プロキシでプライマリ証明書として設定されている場合にのみ返されます。
  • HTTPS ロードバランサは、インターネット NEG バックエンド対応のロードバランサを除き、バックエンドへの接続時に Server Name Indication(SNI)拡張機能を使用しません。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。
  • 高度なトラフィック管理機能を備えたグローバル外部 HTTP(S) ロードバランサで Google Cloud Armor を使用する場合、Google Cloud Armor ルールと EXTERNAL_MANAGED バックエンド サービス間の特定のやり取りにより、HTTP 408 タイムアウトが発生することがあります(特に、リクエストに POST 本文が含まれている場合)。

次のステップ