外部アプリケーション ロードバランサのリクエストの分散

このドキュメントでは、外部アプリケーション ロードバランサが接続を処理し、トラフィックを転送し、セッション アフィニティを維持する方法について詳しく説明します。

接続の仕組み

Google Cloudの外部アプリケーション ロードバランサ（グローバルとリージョン）は、分散プロキシ（GFE）または Envoy 管理のサブネットを使用してルーティングを効率化します。構成可能なタイムアウト、TLS 終端、組み込みのセキュリティにより、世界規模またはリージョン規模で、コンプライアンスに準拠したスケーラブルなアプリケーション配信を実現します。

グローバル外部アプリケーション ロードバランサの接続

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

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

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

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

トラフィックのロード バランシングを均等に行うために、ロードバランサは、Connection: close ヘッダーを含むレスポンスの完了後に FIN ACK パケットを送信して TCP 接続を完全に閉じるか、レスポンスの完了後に HTTP/2 GOAWAY フレームを発行する場合があります。この動作により、アクティブなリクエストやレスポンスが妨げられることはありません。

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

詳細については、ソリューション ガイドの外部アプリケーション ロードバランサの仕組みでグローバル ロード バランシングによるアプリケーション容量の最適化をご覧ください。

リージョン外部アプリケーション ロードバランサの接続

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

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

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

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

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

各モードの外部アプリケーション ロードバランサ転送ルールでサポートされるプロトコルの完全な一覧については、ロードバランサの機能をご覧ください。

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

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

グローバル外部アプリケーション ロードバランサの場合:

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

    • 送信元 IP アドレス: 元のクライアント（クライアントが NAT ゲートウェイまたは転送プロキシの背後にある場合は外部 IP アドレス）。
    • 宛先 IP アドレス: ロードバランサの IP アドレス。

  • 接続 2: ロードバランサ（GFE）からバックエンド VM またはエンドポイントへの接続。

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

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

リージョン外部アプリケーション ロードバランサの場合:

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

    • 送信元 IP アドレス: 元のクライアント（クライアントが NAT ゲートウェイまたは転送プロキシの背後にある場合は外部 IP アドレス）。
    • 宛先 IP アドレス: ロードバランサの IP アドレス。

  • 接続 2: ロードバランサ（プロキシ専用サブネット）からバックエンド VM またはエンドポイントへの接続。

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

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

特別なルーティング パス

Google Cloud は、VPC ネットワークで定義されていない特別なルートを使用して、次のタイプのトラフィックのパケットを転送します。

  • グローバル外部アプリケーション ロードバランサおよび従来のアプリケーション ロードバランサのバックエンドと GFE との間。詳細については、Google Front End とバックエンド間のパスをご覧ください。

Google Cloud は、プロキシ専用サブネットのサブネット ルートを使用して、次の種類のトラフィックのパケットを転送します。

  • 分散 Envoy ヘルスチェックを使用する場合。

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

オープンポート

GFE には、同じアーキテクチャで実行される他の Google サービスをサポートするための複数のオープンポートがあります。ポートスキャンを実行すると、GFE で実行されている他の Google サービスのオープンポートが表示される場合があります。

GFE ベースのロードバランサ（グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサ）は、ポート 80 と 443 を常にオープンポートとして表示します（ロードバランサの転送ルールで構成した他のポートも一緒に表示されます）。ただし、ポート 80 またはポート 443 に転送ルールを構成していない場合、これらのポートに送信された接続は拒否されます。逆に、リージョン外部アプリケーション ロードバランサは Envoy プロキシを使用して実装されているため、スキャン中に余分なオープンポートは表示されません。

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

  • 通常、ポートスキャン（たとえば nmap を使用）では、TCP SYN プローブを実行するときにレスポンス パケットや TCP RST パケットは想定されません。GFE は転送ルールを構成したポートに対してのみ、SYN プローブへのレスポンスとして SYN-ACK パケットを送信します。GFE は、ロードバランサの IP アドレスと、転送ルールで構成されている宛先ポートにパケットが送信された場合にのみ、パケットをバックエンドに送信します。別の IP アドレスまたはポートに送信されたパケットはバックエンドに送信されません。

    GFE は、Google Cloud Armor などのセキュリティ機能を実装しています。Cloud Armor Standard を使用すると、GFE は、ボリューム型およびプロトコル ベースの DDoS 攻撃と SYN フラッドを常に阻止します。この保護は、Cloud Armor を明示的に構成していない場合でも使用できます。セキュリティ ポリシーを構成した場合、または Managed Protection Plus に登録した場合のみ、料金が発生します。

  • ロードバランサの 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 終端

次の表に、外部アプリケーション ロードバランサによる TLS 終端の処理方法を示します。

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

タイムアウトと再試行

外部アプリケーション ロードバランサは、HTTP または HTTPS トラフィックに対して次の種類のタイムアウトをサポートします。

タイムアウトの種類と説明 デフォルト値 カスタムのタイムアウト値をサポート
グローバル クラシック リージョン
バックエンド サービスのタイムアウト1

リクエストとレスポンスのタイムアウトロードバランサがリクエストの最初のバイトをバックエンドに送信してから、バックエンドが HTTP レスポンスの最後のバイトをロードバランサに返すまでの最長時間を表します。バックエンドがこの時間内に HTTP レスポンス全体をロードバランサに返さなかった場合、残りのレスポンス データは破棄されます。
  • バックエンド サービスのサーバーレス NEG の場合: 60 分
  • バックエンド サービスの他のバックエンド タイプの場合: 30 秒
  • バックエンド バケットの場合: 24 時間（86,400 秒）
クライアント HTTP キープアライブ タイムアウト

クライアントとロードバランサのプロキシの間の TCP 接続がアイドル状態である最長時間。（同じ TCP 接続が複数の HTTP リクエストに使用される場合があります）。

  • グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサの場合、ロードバランサのプロキシは第 1 レイヤの GFE です。
  • リージョン外部アプリケーション ロードバランサの場合、ロードバランサのプロキシは Envoy ソフトウェアです。
 610 秒
バックエンド HTTP キープアライブ タイムアウト

ロードバランサのプロキシとバックエンドの間の TCP 接続がアイドル状態である最長時間（同じ TCP 接続が複数の HTTP リクエストに使用される場合があります）。

  • グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサの場合、ロードバランサのプロキシは第 2 レイヤの GFE です。
  • リージョン外部アプリケーション ロードバランサの場合、ロードバランサのプロキシは Envoy ソフトウェアです。
  • バックエンド サービスの場合: 10 分（600 秒）
  • バックエンド バケットの場合: 6 分（360 秒）
QUIC セッションのアイドル タイムアウト

グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサの GFE と（ダウンストリーム）クライアントとの間で QUIC セッションがアイドル状態を継続できる最大時間。

グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサの場合:

QUIC セッションのアイドル タイムアウトは、クライアントのアイドル タイムアウトまたは GFE のアイドル タイムアウト（300 秒）のいずれかの最小値です。

GFE のアイドル タイムアウトは 300 秒に固定されています。クライアントのアイドル タイムアウトは構成できます。

1 サーバーレス NEG バックエンドでは構成できません。バックエンド バケットでは構成できません。

バックエンド サービスのタイムアウト

構成可能なバックエンド サービス タイムアウトは、バックエンドが HTTP リクエストを処理し、対応する HTTP レスポンスを返すまでロードバランサが待機する最長時間を表します。サーバーレス NEG を除き、バックエンド サービスのタイムアウトのデフォルト値は 30 秒です。

たとえば、500 MB のファイルをダウンロードする場合、バックエンド サービスのタイムアウトの値が 90 秒であれば、ロードバランサはバックエンドが 500 MB ファイル全体を 90 秒以内で配信すると想定します。バックエンド サービスのタイムアウトには、バックエンドが完全な HTTP レスポンスを送信するのに十分でない時間を構成することもできます。この状況では、少なくともロードバランサがバックエンドから HTTP レスポンス ヘッダーを受け取った場合、ロードバランサは完全なレスポンス ヘッダーと、バックエンド サービスのタイムアウト内で取得できる可能な限り多くのレスポンス本文を返します。

バックエンド サービスのタイムアウトは、HTTP レスポンスを処理するためにバックエンドが待機する必要のある最長時間に設定することをおすすめします。バックエンドで実行されているソフトウェアが HTTP リクエストを処理し、レスポンス全体を返すためにさらに時間が必要な場合は、バックエンド サービスのタイムアウト値を大きくすることをおすすめします。たとえば、jsonPayload.statusDetail client_timed_out エラーを含む HTTP 408 ステータス コードが返された場合は、タイムアウトを長くすることをおすすめします。

バックエンド サービスのタイムアウトは、1～2,147,483,647 秒の値を受け入れます。ただし、あまりに大きい値は実用的な構成オプションではありません。またGoogle Cloud では、バックエンド サービスがタイムアウトになるまで基盤となる TCP 接続が維持されるとは限りません。 グローバル アプリケーション ロードバランサと従来のアプリケーション ロードバランサの場合、GFE はバックエンド サービスの有効な最大タイムアウトを 86,400 秒（1 日）に設定します。 クライアント システムでは、TCP 接続の持続時間に依存するのではなく、再試行ロジックを実装する必要があります。

バックエンド サービスのタイムアウトを構成するには、次のいずれかの方法を使用します。

コンソール

ロードバランサのバックエンド サービスの [タイムアウト] フィールドを変更します。

gcloud

gcloud compute backend-services update コマンドを使用して、バックエンド サービス リソースの --timeout パラメータを変更します。

API

グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサの場合は、グローバル backendServices リソースの timeoutSec パラメータを変更します。

リージョン外部アプリケーション ロードバランサの場合は、regionBackendServices リソースの timeoutSec パラメータを変更します。

WebSocket 接続のタイムアウトは、バックエンド サービスのタイムアウトと同じとは限りません。WebSocket 接続のタイムアウトは、ロードバランサのタイプによって異なります。

ロードバランサのモード デフォルト値 WebSocket のタイムアウトの説明
グローバル外部アプリケーション ロードバランサ バックエンド サービスのタイムアウト: 30 秒

アクティブな WebSocket 接続は、ロードバランサで構成されたバックエンド サービスのタイムアウトを使用しません。接続は 24 時間（86,400 秒）後に自動的に終了します。この 24 時間の上限は固定されており、24 時間を超えるバックエンド サービスのタイムアウトはオーバーライドされます。

アイドル状態の WebSocket 接続は、バックエンド サービスのタイムアウト後に終了します。

Google Cloud は、ソフトウェアの更新やその他の定期的なメンテナンスのために GFE を定期的に再起動します。このため、バックエンド サービスのタイムアウト値を 24 時間（86,400 秒）より大きくすることはおすすめしません。バックエンド サービスのタイムアウト値によってメンテナンス アクティビティが遅延することはありません。バックエンド サービスのタイムアウト値が長くなるほど、 Google Cloudがメンテナンスで TCP 接続を終了する可能性が高くなります。
従来のアプリケーション ロードバランサ バックエンド サービスのタイムアウト: 30 秒

WebSocket 接続は、アイドル状態かアクティブ状態かにかかわらず、バックエンド サービスがタイムアウトすると自動的に終了します。

Google Cloud は、ソフトウェアの更新やその他の定期的なメンテナンスのために GFE を定期的に再起動します。このため、バックエンド サービスのタイムアウト値を 24 時間（86,400 秒）より大きくすることはおすすめしません。バックエンド サービスのタイムアウト値によってメンテナンス アクティビティが遅延することはありません。バックエンド サービスのタイムアウト値が長くなるほど、 Google Cloudがメンテナンスで TCP 接続を終了する可能性が高くなります。
リージョン外部アプリケーション ロードバランサ バックエンド サービスのタイムアウト: 30 秒

アクティブな WebSocket 接続は、ロードバランサのバックエンド サービスのタイムアウトを使用しません。

アイドル状態の WebSocket 接続は、バックエンド サービスのタイムアウト後に終了します。

Google Cloud は、サービスを提供する Envoy ソフトウェア タスクの定期的な再起動、またはその数の変更を行います。バックエンド サービスのタイムアウト値が長いほど、Envoy タスクが TCP 接続を再開または終了する可能性が高くなります。

リージョン外部アプリケーション ロードバランサは、URL マップの構成済みの routeActions.timeout パラメータを使用し、バックエンド サービスのタイムアウトを無視します。routeActions.timeout が構成されていない場合、バックエンド サービスのタイムアウト値が使用されます。routeActions.timeout が指定されている場合、バックエンド サービスのタイムアウトは無視され、代わりに、リクエストとレスポンスのタイムアウトとして routeActions.timeout が使用されます。

クライアント HTTP キープアライブ タイムアウト

クライアント HTTP キープアライブ タイムアウトは、TCP 接続が（ダウンストリーム）クライアントと次のいずれかのタイプのプロキシ間でアイドル状態になる最長時間を表します。

  • グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサの場合: 最初のレイヤの Google Front End
  • リージョン外部アプリケーション ロードバランサの場合: Envoy プロキシ

クライアント HTTP キープアライブ タイムアウトは、基盤となる TCP 接続の TCP アイドル タイムアウトを表します。クライアント HTTP キープアライブ タイムアウトは WebSocket に適用されません。

クライアント HTTP キープアライブ タイムアウトのデフォルト値は 610 秒です。グローバル外部アプリケーション ロードバランサとリージョン外部アプリケーション ロードバランサの場合、クライアント HTTP キープアライブ タイムアウトは 5～1,200 秒で構成できます。

クライアントの HTTP キープアライブ タイムアウトを構成するには、次のいずれかの方法を使用します。

コンソール

ロードバランサのフロントエンド構成の HTTP キープアライブ タイムアウト フィールドを変更します。

gcloud

グローバル外部アプリケーション ロードバランサの場合は、gcloud compute target-http-proxies update コマンドまたは gcloud compute target-https-proxies update コマンドを使用して、ターゲット HTTP プロキシまたはターゲット HTTPS プロキシ リソースの --http-keep-alive-timeout-sec パラメータを変更します。

リージョン外部アプリケーション ロードバランサの場合、リージョン ターゲット HTTP(S) プロキシのキープアライブ タイムアウト パラメータを直接更新することはできません。リージョン ターゲット プロキシのキープアライブ タイムアウト パラメータを更新するには、次の操作を行う必要があります。

  1. 適切なタイムアウト設定で新しいターゲット プロキシを作成します。
  2. 現在のターゲット プロキシの他のすべての設定を新しいプロキシにミラーリングします。ターゲット HTTPS プロキシの場合、SSL 証明書または証明書マップを新しいターゲット プロキシにリンクします。
  3. 新しいターゲット プロキシを指すように転送ルールを更新します。
  4. 以前のターゲット プロキシを削除します。

API

グローバル外部アプリケーション ロードバランサの場合は、targetHttpProxies リソースまたは targetHttpsProxies リソースの httpKeepAliveTimeoutSec パラメータを変更します。

リージョン外部アプリケーション ロードバランサの場合、リージョン ターゲット HTTP(S) プロキシのキープアライブ タイムアウト パラメータを直接更新することはできません。リージョン ターゲット プロキシのキープアライブ タイムアウト パラメータを更新するには、次の操作を行う必要があります。

  1. 適切なタイムアウト設定で新しいターゲット プロキシを作成します。
  2. 現在のターゲット プロキシの他のすべての設定を新しいプロキシにミラーリングします。ターゲット HTTPS プロキシの場合、SSL 証明書または証明書マップを新しいターゲット プロキシにリンクします。
  3. 新しいターゲット プロキシを指すように転送ルールを更新します。
  4. 以前のターゲット プロキシを削除します。

ロードバランサのクライアント HTTP キープアライブ タイムアウトは、ダウンストリーム クライアントまたはプロキシで使用される HTTP キープアライブ（TCP アイドル）タイムアウトよりも大きくする必要があります。ダウンストリーム クライアントの HTTP キープアライブ（TCP アイドル）タイムアウトがロードバランサのクライアント HTTP キープアライブ タイムアウトよりも大きい場合、競合状態が発生する可能性があります。ダウンストリーム クライアントから見ると、確立済みの TCP 接続が、ロードバランサで許可されている時間よりも長くアイドル状態になる可能性があります。ロードバランサが TCP 接続が終了したとみなすと、ダウンストリーム クライアントはパケットを送信することができます。その場合、ロードバランサは TCP reset（RST）パケットで応答します。

クライアントの HTTP キープアライブ タイムアウトが切れると、GFE または Envoy プロキシがクライアントに TCP FIN を送信して、接続を正常に終了します。

バックエンド HTTP キープアライブ タイムアウト

外部アプリケーション ロードバランサは、少なくとも 2 つの TCP 接続を使用するプロキシです。

  • グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサの場合、（ダウンストリームの）クライアントと最初のレイヤの GFE の間に最初の TCP 接続が存在します。最初のレイヤの GFE が 2 番目のレイヤの GFE に接続し、次に 2 番目のレイヤの GFE がバックエンドへの 2 番目の TCP 接続を開きます。
  • リージョン外部アプリケーション ロードバランサの場合、最初の TCP 接続は（ダウンストリーム）クライアントと Envoy プロキシの間に存在します。次に、Envoy プロキシがバックエンドへの 2 番目の TCP 接続を開きます。

ロードバランサの 2 番目の TCP 接続は、リクエストごとに終了せず、複数の HTTP リクエストとレスポンスを処理できるように、開いている状態を維持する場合があります。バックエンド HTTP キープアライブ タイムアウトは、ロードバランサとバックエンド間の TCP アイドル タイムアウトを定義します。バックエンド HTTP キープアライブ タイムアウトは WebSocket には適用されません。

バックエンド キープアライブ タイムアウトは 10 分（600 秒）に固定されており、変更できません。これにより、ロードバランサはアイドル状態の接続を少なくとも 10 分間維持します。この期間が経過すると、ロードバランサはいつでもバックエンドに終了パケットを送信できます。

ロードバランサのバックエンド キープアライブ タイムアウトは、バックエンドで実行されているソフトウェアで使用されるキープアライブ タイムアウトよりも短くする必要があります。これにより、バックエンドのオペレーティング システムが TCP reset（RST）で TCP 接続を終了する可能性のある競合状態を回避できます。ロードバランサのバックエンド キープアライブ タイムアウトは構成できないため、HTTP キープアライブ（TCP アイドル）タイムアウト値が 600 秒を超えるように、バックエンド ソフトウェアを構成する必要があります。

バックエンド HTTP キープアライブ タイムアウトが切れると、GFE または Envoy プロキシがバックエンド VM に TCP FIN を送信して、接続を正常に終了します。

次の表は、一般的なウェブサーバー ソフトウェアのキープアライブ タイムアウト値を変更するために必要な変更を示したものです。

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

QUIC セッションのアイドル タイムアウト

QUIC セッションのアイドル タイムアウトは、グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサの GFE とクライアントとの間で QUIC セッションがアイドル状態を継続できる最大時間を表します。

QUIC セッションのアイドル タイムアウト値は、クライアントのアイドル タイムアウトまたは GFE アイドル タイムアウト（300 秒）のいずれかの最小値として定義されます。GFE のアイドル タイムアウトは 300 秒に固定されています。クライアントのアイドル タイムアウトは構成できます。

再試行数

再試行ロジックのサポートは、外部アプリケーション ロードバランサのモードによって異なります。

ロードバランサのモード 再試行ロジック
グローバル外部アプリケーション ロードバランサ

URL マップの再試行ポリシーを使用して構成できます。再試行ポリシーを使用して構成できる再試行の最大数（numRetries）は 25 です。構成可能な perTryTimeout の最大値は 24 時間です。

再試行を無効にする場合は、numRetries を明示的に 1 に設定する必要があります。

再試行ポリシーがない場合、HTTP 本文のないリクエスト（GET リクエストなど）が HTTP 502、503、または 504 のレスポンス（retryConditions=["gateway-error"]）を返したときに 1 回再試行されます。

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

再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。
従来のアプリケーション ロードバランサ

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

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

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

ロードバランサは、最初のリクエストが失敗した後にバックエンド インスタンスからレスポンス ヘッダーを受け取ると、失敗した GET リクエストを再試行します。

再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。詳細については、外部アプリケーション ロードバランサのロギングとモニタリングをご覧ください。

リクエストが失敗すると、ロードバランサは HTTP 502 レスポンスを合成します。
リージョン外部アプリケーション ロードバランサ

URL マップの再試行ポリシーを使用して構成できます。デフォルトの再試行回数（numRetries）は 1 回です。再試行ポリシーを使用して構成できる再試行の最大数は 25 です。構成可能な perTryTimeout の最大値は 24 時間です。

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

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

再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。

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

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

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

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

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

リクエスト処理

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

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

レスポンス処理

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

  • レスポンス ヘッダーの合計サイズが、外部アプリケーション ロードバランサの最大レスポンス ヘッダーのサイズの上限を超えている。
  • HTTP のバージョンが不明。

リクエストとレスポンスの両方を処理するときに、ロードバランサは HTTP/1.1 のホップバイホップ ヘッダーを削除または上書きしてから、目的の宛先に転送することがあります。

トラフィック分散

バックエンド インスタンス グループまたは NEG をバックエンド サービスに追加する場合は、バックエンドの負荷とターゲット容量を測定する方法を定義するバランシング モードを指定します。外部アプリケーション ロードバランサは、次の 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 ロード バランシングは、リクエストごとにバックエンド インスタンスの選択を最適化します。

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

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

リクエストの分散方法

GFE ベースの外部アプリケーション ロードバランサは、受信リクエストを分散するために次のプロセスを使用します。

  1. クライアントから第 1 レイヤの GFE へ。エッジルーターは、Google ネットワークの境界にある転送ルールの外部 IP アドレスをアドバタイズします。各アドバタイズは、レイヤ 3 とレイヤ 4 のロード バランシング システム（Maglev）へのネクストホップの一覧を示します。Maglev システムは、最初のレイヤの Google Front End（GFE）にトラフィックを転送します。
    • プレミアム ティアを使用する場合、Google は、全世界のあらゆるポイント オブ プレゼンスからロードバランサの IP アドレスをアドバタイズします。各ロードバランサの IP アドレスはグローバル エニーキャストです。
    • スタンダード ティアを使用する場合、Google は転送ルールのリージョンに関連付けられたポイント オブ プレゼンスからロードバランサの IP アドレスをアドバタイズします。ロードバランサは、リージョン外部 IP アドレスを使用します。スタンダード ティアの転送ルールを使用する場合、インスタンス グループとゾーン NEG バックエンドはロードバランサの転送ルールと同じリージョンに制限されます。
  2. 第 1 レイヤの GFE から第 2 レイヤの GFE へ。第 1 レイヤの GFE は、必要に応じて TLS を終端し、以下のプロセスでトラフィックを 2 番目のレイヤの GFE にルーティングします。
    • 第 1 レイヤの GFE が URL マップを解析し、バックエンド サービスまたはバックエンド バケットを選択します。
    • インターネット NEG を使用するバックエンド サービスの場合、第 1 レイヤの GFE は、第 1 レイヤの GFE と同じ場所に配置された第 2 レイヤの外部転送ゲートウェイを選択します。転送ゲートウェイは、インターネット NEG エンドポイントにリクエストを送信します。これで、インターネット NEG のリクエスト分散プロセスは完了です。
    • サーバーレス NEG、Private Service Connect（PSC）NEG、シングル リージョンのバックエンド バケットを使用するバックエンド サービスの場合、第 1 レイヤの GFE は NEG またはバケットと一致するリージョン内にある第 2 レイヤの GFE を選択します。マルチリージョンの Cloud Storage バケットの場合、第 1 レイヤの GFE は、バケットのリージョン内、またはマルチリージョン バケットに可能な限り近いリージョンにある第 2 レイヤの GFE を選択します（ネットワーク ラウンド トリップ時間により定義されます）。
    • インスタンス グループ、GCE_VM_IP_PORT エンドポイントを含むゾーン NEG、ハイブリッド NEG を使用するバックエンド サービスの場合、Google の容量管理システムは、各バックエンドで使用および構成した容量を第 1 レイヤの GFE に通知します。バックエンドに構成された容量は、バランシング モード、バランシング モードのターゲット容量、容量スケーラーにより定義されます。
      • スタンダード ティア: 第 1 レイヤの GFE は、バックエンドを含むリージョンにある第 2 レイヤの GFE を選択します。
      • プレミアム ティア: 第 1 レイヤの GFE は、該当リージョンのセットから第 2 レイヤの GFE を選択します。該当リージョンは、バックエンドが構成されているすべてのリージョンです。ただし、バックエンド容量がゼロで構成されるリージョンは除きます。第 1 レイヤの GFE は、該当リージョンで最も近い第 2 レイヤの GFE を選択します（ネットワーク ラウンド トリップ時間により定義されます）。バックエンドが 2 つ以上のリージョンで構成されている場合、第 1 レイヤの GFE は、最初に選択したリージョンがフルになると、他の該当リージョンにリクエストをスピルできます。最初に選択したリージョン内にあるすべてのバックエンドが容量の上限に達した場合、他のリージョンにスピルオーバーできます。
  3. 第 2 レイヤの GFE がバックエンドを選択します。第 2 レイヤの GFE はリージョンのゾーンに配置されます。次のプロセスを使用してバックエンドを選択します。
    • サーバーレス NEG、Private Service Connect NEG、バックエンド バケットを使用するバックエンド サービスの場合、第 2 レイヤの GFE が Google の本番環境システムにリクエストを転送します。これで、これらのバックエンドのリクエスト分散プロセスは完了です。

    • インスタンス グループ、GCE_VM_IP_PORT エンドポイントを含むゾーン NEG、ハイブリッド NEG を使用するバックエンド サービスの場合、Google のヘルスチェック プローブ システムは、バックエンド インスタンスまたはエンドポイントのヘルスチェック ステータスを第 2 レイヤの GFE に通知します。

      プレミアム ティアのみ: 第 2 レイヤの GFE がリージョンに正常なバックエンド インスタンスまたはエンドポイントを持たない場合、バックエンドが構成された別の該当リージョン内にあるもう 1 つの第 2 レイヤの GFE にリクエストを送信することがあります。別のリージョンにある第 2 レイヤの GFE 間におけるスピルオーバーは、リージョン間で可能なすべての組み合わせを使い切るわけではありません。特定のリージョンでバックエンドからトラフィックを転送する必要がある場合は、ヘルスチェックに失敗するようバックエンドを構成するのではなく、バックエンドの容量スケーラーをゼロに設定して、第 1 レイヤの GFE が、前のステップでリージョンを除外するようにします。

    第 2 レイヤの GFE は、次のステップで説明するように、リージョン内のゾーンにあるバックエンド インスタンスまたはエンドポイントにリクエストを転送します。

  4. 第 2 レイヤの GFE がゾーンを選択します。デフォルトでは、第 2 レイヤの GFE は WATERFALL_BY_REGION アルゴリズムを使用します。第 2 レイヤの各 GFE は、第 2 レイヤの GFE を含むゾーンと同じゾーン内のバックエンド インスタンスまたはエンドポイントを選択します。WATERFALL_BY_REGION ではゾーン間のトラフィックが最小限になるため、リクエスト率が低い場合は第 2 レイヤの各 GFE が第 2 レイヤの GFE と同じゾーンにあるバックエンドにのみリクエストを送信する可能性があります。

    グローバル外部アプリケーション ロードバランサの場合のみ、serviceLbPolicy を使用して次のいずれかの代替アルゴリズムを使用するように第 2 レイヤの GFE を構成できます。

    • SPRAY_TO_REGION: 第 2 レイヤの GFE は、第 2 レイヤの GFE と同じゾーンのバックエンド インスタンスまたはエンドポイントを選択しません。第 2 レイヤの GFE は、リージョン内のすべてのゾーンにある全バックエンド インスタンスまたはエンドポイントにトラフィックを分散しようとします。これにより、ゾーン間のトラフィックが増加すると負荷が均等に分散されます。
    • WATERFALL_BY_ZONE: 第 2 レイヤの GFE には、第 2 レイヤの GFE と同じゾーンのバックエンド インスタンスまたはエンドポイントを選択することを強くおすすめします。第 2 レイヤの GFE は、現在のゾーン内のすべてのバックエンドが構成済みの容量に達した後にのみ、別のゾーンのバックエンドにリクエストを転送します。
  5. 第 2 レイヤの GFE がゾーン内のインスタンスまたはエンドポイントを選択します。デフォルトでは、第 2 レイヤの GFE はラウンドロビン方式によりバックエンド間でリクエストを分散します。グローバル外部アプリケーション ロードバランサの場合のみ、ロード バランシングの局所性ポリシー（localityLbPolicy）を使用してこの設定を変更できます。ロード バランシングの局所性ポリシーは、前の手順で説明した選択済みゾーン内のバックエンドにのみ適用されます。

リージョン外部アプリケーション ロードバランサ

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

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

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

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

セッション アフィニティ

アプリケーション ロードバランサのバックエンド サービスで構成されたセッション アフィニティは、正常なバックエンド インスタンスまたはエンドポイントの数が一定であり、以前に選択したバックエンド インスタンスまたはエンドポイントの容量が上限に達していない限り、特定のクライアントからのリクエストを同じバックエンドに送信するためのベスト エフォート型の試行を行います。バランシング モードのターゲット容量により、バックエンドの容量が上限に達するタイミングが判断されます。

次の表に、さまざまなアプリケーション ロードバランサでサポートされているさまざまなタイプのセッション アフィニティ オプションの概要を示します。次のセクションのセッション アフィニティのタイプでは、各セッション アフィニティ タイプについて詳しく説明します。

表: サポートされているセッション アフィニティの設定
プロダクト セッション アフィニティのオプション
  • なし（NONE）
  • クライアント IP（CLIENT_IP）
  • 生成した Cookie（GENERATED_COOKIE）
  • ヘッダー フィールド（HEADER_FIELD）
  • HTTP Cookie（HTTP_COOKIE）
  • ステートフル Cookie ベース アフィニティ（STRONG_COOKIE_AFFINITY）

また、次の点にもご注意ください。

  • ロード バランシングの局所性ポリシー（localityLbPolicy）の有効なデフォルト値は、セッション アフィニティの設定に応じて変わります。セッション アフィニティが構成されていない場合（セッション アフィニティがデフォルト値の NONE のままの場合）、localityLbPolicy のデフォルト値は ROUND_ROBIN です。セッション アフィニティが NONE 以外の値に設定されている場合、localityLbPolicy のデフォルト値は MAGLEV です。
  • グローバル外部アプリケーション ロードバランサの場合、重み付けによるトラフィック分割を使用する場合は、セッション アフィニティを構成しないでください。セッション アフィニティを構成した場合、重み付けトラフィック分割構成が優先されます。
従来のアプリケーション ロードバランサ
  • なし（NONE）
  • クライアント IP（CLIENT_IP）
  • 生成した Cookie（GENERATED_COOKIE）

セッション アフィニティを構成する際は、次の点に留意してください。

  • 認証やセキュリティを目的としてセッション アフィニティに依存しないでください。ステートフル Cookie ベースのセッション アフィニティを除き、セッション アフィニティは、サービスの数と正常なバックエンドの数が変わるたびに失われる可能性があります。詳細については、セッション アフィニティの喪失をご覧ください。

  • --session-affinity フラグと --subsetting-policy フラグのデフォルト値はどちらも NONE です。異なる値を設定できるのは一度に 1 つだけです。

セッション アフィニティのタイプ

外部アプリケーション ロードバランサのセッション アフィニティは、次のいずれかのカテゴリに分類できます。
  • ハッシュベースのセッション アフィニティ（NONE、CLIENT_IP）
  • HTTP ヘッダーベースのセッション アフィニティ（HEADER_FIELD）
  • Cookie ベースのセッション アフィニティ（GENERATED_COOKIE、HTTP_COOKIE、STRONG_COOKIE_AFFINITY）

ハッシュベースのセッション アフィニティ

ハッシュベースのセッション アフィニティの場合、ロードバランサはコンシステント ハッシュ法のアルゴリズムを使用して、適格なバックエンドを選択します。セッション アフィニティの設定により、ハッシュの計算に使用される IP ヘッダーのフィールドが決まります。

ハッシュベースのセッション アフィニティには、次のタイプがあります。

なし

セッション アフィニティの設定 NONE は、セッション アフィニティがないことを意味するわけではありません。これは、セッション アフィニティ オプションが明示的に構成されていないことを意味します。

ハッシュは、バックエンドを選択するために常に実行されます。セッション アフィニティの設定が NONE の場合、ロードバランサは 5 タプルハッシュを使用してバックエンドを選択します。5 タプルハッシュは、送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートで構成されます。

セッション アフィニティのデフォルト値は NONE です。

クライアント IP アフィニティ

「クライアント IP セッション アフィニティ（CLIENT_IP）」は、パケットの送信元 IP アドレスと宛先 IP アドレスから作成された 2 タプルハッシュです。クライアント IP アフィニティは、バックエンドに容量があり、正常な状態を維持している限り、同じクライアント IP アドレスからのすべてのリクエストを同じバックエンドに転送します。

クライアント IP アフィニティを使用する場合は、次の点に留意してください。

  • パケットがロードバランサに直接送信される場合、パケットの宛先 IP アドレスはロードバランサの転送ルールの IP アドレスと同じになります。
  • パケットが Google Cloud ロードバランサに配信される前に中間 NAT またはプロキシ システムによって処理されると、パケットの送信元 IP アドレスが元のクライアントに関連付けられた IP アドレスと一致しないことがあります。多くのクライアントが同じ有効な送信元 IP アドレスを共有する場合、一部のバックエンド VM は他の VM よりも多くの接続またはリクエストを受信する可能性があります。

HTTP ヘッダーベースのセッション アフィニティ

ヘッダー フィールド アフィニティ（HEADER_FIELD）では、バックエンド サービスの consistentHash.httpHeaderName フィールドの HTTP ヘッダーの値に基づいて、リクエストがバックエンドにルーティングされます。使用可能なすべてのバックエンドにリクエストを分散するには、各クライアントで異なる HTTP ヘッダー値を使用する必要があります。

ヘッダー フィールド アフィニティは、次の条件を満たす場合にサポートされます。

  • ロード バランシングの局所性ポリシーが RING_HASH または MAGLEV である。
  • バックエンド サービスの consistentHash が、HTTP ヘッダーの名前（httpHeaderName）を指定する。

Cookie ベースのセッション アフィニティには次のタイプがあります。

生成された Cookie ベースのアフィニティ（GENERATED_COOKIE）を使用する場合、ロードバランサは最初の HTTP リクエストに応答して Set-Cookie ヘッダーに HTTP Cookie を含めます。

生成される Cookie の名前は、ロードバランサのタイプによって異なります。

プロダクト Cookie 名
グローバル外部アプリケーション ロードバランサ GCLB
従来のアプリケーション ロードバランサ GCLB
リージョン外部アプリケーション ロードバランサ GCILB

生成された Cookie のパス属性は常にスラッシュ（/）になります。他のバックエンド サービスも生成された Cookie アフィニティを使用している場合、同じ URL マップ上のすべてのバックエンド サービスに適用されます。

affinityCookieTtlSec バックエンド サービス パラメータを使用して、Cookie の有効期間（TTL）値を 0～1,209,600 秒の範囲（両端を含む）で構成できます。affinityCookieTtlSec が指定されていない場合、デフォルトの TTL 値は 0 です。

クライアントが、HTTP リクエストの Cookie リクエスト ヘッダーに生成されたセッション アフィニティ Cookie を含めると、ロードバランサは、セッション アフィニティ Cookie が有効である限り、それらのリクエストを同じバックエンド インスタンスまたはエンドポイントに転送します。これを行うには、Cookie 値を、特定のバックエンド インスタンスまたはエンドポイントを参照するインデックスにマッピングし、生成された Cookie のセッション アフィニティ要件を満たすようにします。

生成された Cookie アフィニティを使用するには、次のバランシング モードと localityLbPolicy 設定を構成します。

  • バックエンド インスタンス グループの場合は、RATE バランシング モードを使用します。
  • バックエンド サービスの localityLbPolicy には、RING_HASH または MAGLEV を使用します。localityLbPolicy を明示的に設定しない場合、ロードバランサは暗黙のデフォルトとして MAGLEV を使用します。

詳細については、セッション アフィニティの喪失をご覧ください。

HTTP Cookie ベースのアフィニティ（HTTP_COOKIE）を使用する場合、ロードバランサは最初の HTTP リクエストに応答して Set-Cookie ヘッダーに HTTP Cookie を含めます。Cookie の名前、パス、有効期間（TTL）を指定します。

すべてのアプリケーション ロードバランサは、HTTP Cookie ベースのアフィニティをサポートしています。

Cookie の TTL 値は、次のバックエンド サービス パラメータと有効な値を使用して、秒、秒未満（ナノ秒単位）、秒と秒未満（ナノ秒単位）のいずれかで構成できます。

  • consistentHash.httpCookie.ttl.seconds は、0～315576000000 の値に設定できます（両端を含む）。
  • consistentHash.httpCookie.ttl.nanos は、0～999999999 の値に設定できます（両端を含む）。単位はナノ秒であるため、999999999 は .999999999 秒を意味します。

consistentHash.httpCookie.ttl.seconds と consistentHash.httpCookie.ttl.nanos の両方が指定されていない場合は、代わりに affinityCookieTtlSec バックエンド サービス パラメータの値が使用されます。affinityCookieTtlSec が指定されていない場合、デフォルトの TTL 値は 0 です。

クライアントが、HTTP リクエストの Cookie リクエスト ヘッダーに HTTP セッション アフィニティ Cookie を含めると、ロードバランサは、セッション アフィニティ Cookie が有効である限り、それらのリクエストを同じバックエンド インスタンスまたはエンドポイントに転送します。これを行うには、Cookie 値を、特定のバックエンド インスタンスまたはエンドポイントを参照するインデックスにマッピングし、生成された Cookie のセッション アフィニティ要件を満たすようにします。

HTTP Cookie アフィニティを使用するには、次のバランシング モードと localityLbPolicy 設定を構成します。

  • バックエンド インスタンス グループの場合は、RATE バランシング モードを使用します。
  • バックエンド サービスの localityLbPolicy には、RING_HASH または MAGLEV を使用します。localityLbPolicy を明示的に設定しない場合、ロードバランサは暗黙のデフォルトとして MAGLEV を使用します。

詳細については、セッション アフィニティの喪失をご覧ください。

ステートフル Cookie ベース セッション アフィニティ

ステートフル Cookie ベースのアフィニティ（STRONG_COOKIE_AFFINITY）を使用する場合、ロードバランサは最初の HTTP リクエストに応答して Set-Cookie ヘッダーに HTTP Cookie を含めます。Cookie の名前、パス、有効期間（TTL）を指定します。

従来のアプリケーション ロードバランサを除くすべてのアプリケーション ロードバランサは、ステートフル Cookie ベースのアフィニティをサポートしています。

Cookie の TTL 値は、秒、秒未満（ナノ秒単位）、秒と秒未満（ナノ秒単位）のいずれかで構成できます。strongSessionAffinityCookie.ttl で表される期間は、2 週間を超える値（1,209,600 秒）には設定できません。

Cookie の値は、選択したバックエンド インスタンスまたはエンドポイントを値自体にエンコードすることで識別します。Cookie が有効である限り、クライアントが後続の HTTP リクエストの Cookie リクエスト ヘッダーにセッション アフィニティ Cookie を含めると、ロードバランサは、選択したバックエンド インスタンスまたはエンドポイントにリクエストを転送します。

他のセッション アフィニティ方法とは異なり、

  • ステートフル Cookie ベース アフィニティには、バランシング モードやロード バランシング局所性ポリシー（localityLbPolicy）に関する特定の要件はありません。

  • 自動スケーリングによってマネージド インスタンス グループに新しいインスタンスが追加されても、ステートフル Cookie ベース アフィニティは影響を受けません。

  • 選択したインスタンスが削除されない限り、自動スケーリングによってマネージド インスタンス グループからインスタンスが削除されても、ステートフル Cookie ベース アフィニティは影響を受けません。

  • 選択したインスタンスが削除されない限り、自動修復によってマネージド インスタンス グループからインスタンスが削除されても、ステートフル Cookie ベース アフィニティは影響を受けません。

詳細については、セッション アフィニティの喪失をご覧ください。

Cookie ベースのアフィニティの TTL がゼロの場合の意味

生成された Cookie アフィニティ、HTTP Cookie アフィニティ、ステートフル Cookie ベースのアフィニティなど、すべての Cookie ベースのセッション アフィニティには TTL 属性があります。

TTL が 0 秒の場合、ロードバランサは Cookie に Expires 属性を割り当てません。この場合、クライアントは Cookie をセッション Cookie として扱います。セッションの定義は、クライアントによって異なります。

  • ウェブブラウザなどの一部のクライアントは、ブラウジング セッション全体で Cookie を保持します。つまり、Cookie はアプリケーションが閉じられるまで複数のリクエストにわたって保持されます。

  • 他のクライアントは、セッションを単一の HTTP リクエストとして扱い、直後に Cookie を破棄します。

セッション アフィニティの喪失

すべてのセッション アフィニティ オプションには、次の要件があります。

  • 選択したバックエンド インスタンスまたはエンドポイントは、バックエンドとして構成されたままにする必要があります。セッション アフィニティは、次のいずれかのイベントが発生すると破棄される可能性があります。
    • 選択したインスタンスをインスタンス グループから削除します。
    • マネージド インスタンス グループの自動スケーリングまたは自動修復により、選択したインスタンスがマネージド インスタンス グループから削除されます。
    • 選択したエンドポイントを NEG から削除します。
    • 選択したインスタンスまたはエンドポイントを含むインスタンス グループまたは NEG をバックエンド サービスから削除します。
  • 選択したバックエンド インスタンスまたはエンドポイントは正常な状態を維持する必要があります。選択したインスタンスまたはエンドポイントでヘルスチェックが失敗すると、セッション アフィニティが破棄される可能性があります。
  • グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサの場合、ルーティング パスの変更後に後続のリクエストまたは接続に別の第 1 レイヤの Google Front End（GFE）が使用されると、セッション アフィニティが中断される可能性があります。インターネット上のクライアントから Google へのルーティング パスがリクエストまたは接続によって異なる場合は、別の第 1 レイヤの GFE が選択される可能性があります。
ステートフル Cookie ベースのセッション アフィニティを除き、すべてのセッション アフィニティ オプションには次の追加要件があります。

  • 選択したインスタンスまたはエンドポイントを含むインスタンス グループまたは NEG は、ターゲット容量で定義されている容量を満たしてはなりません。（リージョン マネージド インスタンス グループの場合、選択したインスタンスを含むインスタンス グループのゾーン コンポーネントがいっぱいになっていないこと）。インスタンス グループまたは NEG がいっぱいで、他のインスタンス グループまたは NEG がいっぱいでない場合は、セッション アフィニティが破棄される可能性があります。UTILIZATION バランシング モードを使用すると、満杯状態が予測できない方法で変化する可能性があるため、RATE バランシング モードまたは CONNECTION バランシング モードを使用して、セッション アフィニティが破損する可能性のある状況を最小限に抑える必要があります。

  • 構成されたバックエンド インスタンスまたはエンドポイントの合計数は一定にする必要があります。次のいずれかのイベントが 1 つ以上発生すると、構成されたバックエンド インスタンスまたはエンドポイントの数が変わり、セッション アフィニティが破損する可能性があります。

    • 新しいインスタンスまたはエンドポイントを追加する:

      • バックエンド サービスで、既存のインスタンス グループにインスタンスを追加します。
      • マネージド インスタンス グループの自動スケーリングでは、バックエンド サービスのマネージド インスタンス グループにインスタンスが追加されます。
      • バックエンド サービスで、既存の NEG にエンドポイントを追加します。
      • 空ではないインスタンス グループまたは NEG をバックエンド サービスに追加します。

    • 選択したインスタンスまたはエンドポイントだけでなく、インスタンスまたはエンドポイントを削除する:

      • インスタンス グループのバックエンドからインスタンスを削除した場合。
      • マネージド インスタンス グループの自動スケーリングまたは自動修復により、マネージド インスタンス グループのバックエンドからインスタンスが削除されます。
      • NEG バックエンドからエンドポイントを削除します。
      • 空ではない既存のバックエンド インスタンス グループまたは NEG をバックエンド サービスから削除します。

  • 正常なバックエンド インスタンスまたはエンドポイントの合計数は一定にする必要があります。次のいずれかのイベントが 1 つ以上発生すると、正常なバックエンド インスタンスまたはエンドポイントの数が変わり、セッション アフィニティが破損する可能性があります。

    • インスタンスまたはエンドポイントがヘルスチェックに合格し、異常な状態から正常な状態に変わります。
    • インスタンスまたはエンドポイントがヘルスチェックに失敗し、正常な状態から異常な状態に移行するか、タイムアウトします。