このドキュメントでは、外部アプリケーション ロードバランサが接続を処理し、トラフィックを転送し、セッション アフィニティを維持する方法について詳しく説明します。
接続の仕組み
Trusted Cloudの外部アプリケーション ロードバランサ（グローバルとリージョン）は、分散プロキシ（GFE）または Envoy 管理のサブネットを使用してルーティングを効率化します。構成可能なタイムアウト、TLS 終端、組み込みのセキュリティにより、世界規模またはリージョン規模で、コンプライアンスに準拠したスケーラブルなアプリケーション配信を実現します。
リージョン外部アプリケーション ロードバランサの接続
リージョン外部アプリケーション ロードバランサは、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 アドレスは、ロードバランサのTrusted Cloud 外部 IP アドレスではありません。つまり、2 つの TCP 接続があります。
リージョン外部アプリケーション ロードバランサの場合:接続 1: 元のクライアントからロードバランサ（プロキシ専用サブネット）への接続。
- 送信元 IP アドレス: 元のクライアント（クライアントが NAT ゲートウェイまたは転送プロキシの背後にある場合は外部 IP アドレス）。
- 宛先 IP アドレス: ロードバランサの IP アドレス。
接続 2: ロードバランサ（プロキシ専用サブネット）からバックエンド VM またはエンドポイントへの接続。
送信元 IP アドレス: ロードバランサと同じリージョン、同じネットワークにデプロイされたすべての Envoy ベースのロードバランサ間で共有されるプロキシ専用サブネットの IP アドレス。
宛先 IP アドレス: VPC ネットワーク内のバックエンド VM またはコンテナの内部 IP アドレス。
特別なルーティング パス
Trusted Cloud は、VPC ネットワークで定義されていない特別なルートを使用して、次のタイプのトラフィックのパケットを転送します。
- ヘルスチェックの場合（分散 Envoy ヘルスチェックを除く）。詳細については、ヘルスチェックのパスをご覧ください。
Trusted Cloud は、プロキシ専用サブネットのサブネット ルートを使用して、次の種類のトラフィックのパケットを転送します。
- 分散 Envoy ヘルスチェックを使用する場合。
リージョン外部アプリケーション ロードバランサの場合、 Trusted Cloud はオープンソースの Envoy プロキシを使用してロードバランサへのクライアント リクエストを終了します。ロードバランサは TCP セッションを終了し、リージョンのプロキシ専用サブネットからバックエンドへの新しい TCP セッションを開きます。VPC ネットワーク内で定義されたルートによって、Envoy プロキシからバックエンドへの通信と、バックエンドから Envoy プロキシへの通信が容易になります。
TLS 終端
次の表に、外部アプリケーション ロードバランサによる TLS 終端の処理方法を示します。
| ロードバランサのモード | TLS 終端 |
|---|---|
| リージョン外部アプリケーション ロードバランサ | TLS は、ユーザーが選択したリージョンのプロキシ専用サブネットにある Envoy プロキシで終端されます。TLS を終端するリージョンを地理的に制御する必要がある場合は、このロードバランサ モードを使用してください。 |
タイムアウトと再試行
外部アプリケーション ロードバランサは、HTTP または HTTPS トラフィックに対して次の種類のタイムアウトをサポートします。
| タイムアウトの種類と説明 | デフォルト値 | カスタムのタイムアウト値をサポート | ||
|---|---|---|---|---|
| バックエンド サービスのタイムアウト1
リクエストとレスポンスのタイムアウトロードバランサがリクエストの最初のバイトをバックエンドに送信してから、バックエンドが HTTP レスポンスの最後のバイトをロードバランサに返すまでの最長時間を表します。バックエンドがこの時間内に HTTP レスポンス全体をロードバランサに返さなかった場合、残りのレスポンス データは破棄されます。 |
|
|||
| クライアント HTTP キープアライブ タイムアウト
クライアントとロードバランサのプロキシの間の TCP 接続がアイドル状態である最長時間。（同じ TCP 接続が複数の HTTP リクエストに使用される場合があります）。
|
610 秒 | |||
| バックエンド HTTP キープアライブ タイムアウト
ロードバランサのプロキシとバックエンドの間の TCP 接続がアイドル状態である最長時間（同じ TCP 接続が複数の HTTP リクエストに使用される場合があります）。
|
|
|||
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 秒の値を受け入れます。ただし、あまりに大きい値は実用的な構成オプションではありません。またTrusted Cloud では、バックエンド サービスがタイムアウトになるまで基盤となる TCP 接続が維持されるとは限りません。
クライアント システムでは、TCP 接続の持続時間に依存するのではなく、再試行ロジックを実装する必要があります。
バックエンド サービスのタイムアウトを構成するには、次のいずれかの方法を使用します。
コンソール
ロードバランサのバックエンド サービスの [タイムアウト] フィールドを変更します。
gcloud
gcloud compute backend-services update コマンドを使用して、バックエンド サービス リソースの --timeout パラメータを変更します。
API
リージョン外部アプリケーション ロードバランサの場合は、regionBackendServices リソースの timeoutSec パラメータを変更します。
| ロードバランサのモード | デフォルト値 | WebSocket のタイムアウトの説明 |
|---|---|---|
| リージョン外部アプリケーション ロードバランサ | バックエンド サービスのタイムアウト: 30 秒 | アクティブな WebSocket 接続は、ロードバランサのバックエンド サービスのタイムアウトを使用しません。 アイドル状態の WebSocket 接続は、バックエンド サービスのタイムアウト後に終了します。 Trusted Cloud は、サービスを提供する Envoy ソフトウェア タスクの定期的な再起動、またはその数の変更を行います。バックエンド サービスのタイムアウト値が長いほど、Envoy タスクが TCP 接続を再開または終了する可能性が高くなります。 |
リージョン外部アプリケーション ロードバランサは、URL マップの構成済みの routeActions.timeout パラメータを使用し、バックエンド サービスのタイムアウトを無視します。routeActions.timeout が構成されていない場合、バックエンド サービスのタイムアウト値が使用されます。routeActions.timeout が指定されている場合、バックエンド サービスのタイムアウトは無視され、代わりに、リクエストとレスポンスのタイムアウトとして routeActions.timeout が使用されます。
クライアント HTTP キープアライブ タイムアウト
クライアント HTTP キープアライブ タイムアウトは、TCP 接続が（ダウンストリーム）クライアントと次のいずれかのタイプのプロキシ間でアイドル状態になる最長時間を表します。
- リージョン外部アプリケーション ロードバランサの場合: 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) プロキシのキープアライブ タイムアウト パラメータを直接更新することはできません。リージョン ターゲット プロキシのキープアライブ タイムアウト パラメータを更新するには、次の操作を行う必要があります。
- 適切なタイムアウト設定で新しいターゲット プロキシを作成します。
- 現在のターゲット プロキシの他のすべての設定を新しいプロキシにミラーリングします。ターゲット HTTPS プロキシの場合、SSL 証明書または証明書マップを新しいターゲット プロキシにリンクします。
- 新しいターゲット プロキシを指すように転送ルールを更新します。
- 以前のターゲット プロキシを削除します。
API
グローバル外部アプリケーション ロードバランサの場合は、targetHttpProxies リソースまたは targetHttpsProxies リソースの httpKeepAliveTimeoutSec パラメータを変更します。
リージョン外部アプリケーション ロードバランサの場合、リージョン ターゲット HTTP(S) プロキシのキープアライブ タイムアウト パラメータを直接更新することはできません。リージョン ターゲット プロキシのキープアライブ タイムアウト パラメータを更新するには、次の操作を行う必要があります。
- 適切なタイムアウト設定で新しいターゲット プロキシを作成します。
- 現在のターゲット プロキシの他のすべての設定を新しいプロキシにミラーリングします。ターゲット HTTPS プロキシの場合、SSL 証明書または証明書マップを新しいターゲット プロキシにリンクします。
- 新しいターゲット プロキシを指すように転送ルールを更新します。
- 以前のターゲット プロキシを削除します。
ロードバランサのクライアント HTTP キープアライブ タイムアウトは、ダウンストリーム クライアントまたはプロキシで使用される HTTP キープアライブ（TCP アイドル）タイムアウトよりも大きくする必要があります。ダウンストリーム クライアントの HTTP キープアライブ（TCP アイドル）タイムアウトがロードバランサのクライアント HTTP キープアライブ タイムアウトよりも大きい場合、競合状態が発生する可能性があります。ダウンストリーム クライアントから見ると、確立済みの TCP 接続が、ロードバランサで許可されている時間よりも長くアイドル状態になる可能性があります。ロードバランサが TCP 接続が終了したとみなすと、ダウンストリーム クライアントはパケットを送信することができます。その場合、ロードバランサは TCP reset（RST）パケットで応答します。
クライアントの HTTP キープアライブ タイムアウトが切れると、GFE または Envoy プロキシがクライアントに TCP FIN を送信して、接続を正常に終了します。
バックエンド HTTP キープアライブ タイムアウト
外部アプリケーション ロードバランサは、少なくとも 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; |
再試行数
再試行ロジックのサポートは、外部アプリケーション ロードバランサのモードによって異なります。
| ロードバランサのモード | 再試行ロジック |
|---|---|
| リージョン外部アプリケーション ロードバランサ |
URL マップの再試行ポリシーを使用して構成できます。デフォルトの再試行回数（ 再試行ポリシーがない場合、HTTP 本文のないリクエスト（ HTTP 再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 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 のバックエンド使用率です。
バックエンド間でのトラフィックの分散方法は、ロードバランサのモードによって異なります。
リージョン外部アプリケーション ロードバランサ
リージョン外部アプリケーション ロードバランサの場合、トラフィック分散はロード バランシング モードとロード バランシングの局所性ポリシーに基づきます。
バランシング モードでは、各グループ（インスタンス グループまたは NEG）に送信するトラフィックの重みと割合を決定します。ロード バランシングの局所性ポリシー（LocalityLbPolicy）により、グループ内のバックエンドのロード バランシング方法が決まります。
トラフィックを受信すると、バックエンド サービスはバックエンドの分散モードに従ってバックエンド（インスタンス グループまたは NEG）にトラフィックを転送します。バックエンドが選択されると、ロード バランシングの局所性ポリシーに従って、バックエンド グループ内のインスタンスまたはエンドポイント間でトラフィックが分散されます。
詳しくは以下をご覧ください。
セッション アフィニティ
アプリケーション ロードバランサのバックエンド サービスで構成されたセッション アフィニティは、正常なバックエンド インスタンスまたはエンドポイントの数が一定であり、以前に選択したバックエンド インスタンスまたはエンドポイントの容量が上限に達していない限り、特定のクライアントからのリクエストを同じバックエンドに送信するためのベスト エフォート型の試行を行います。バランシング モードのターゲット容量により、バックエンドの容量が上限に達するタイミングが判断されます。
次の表に、さまざまなアプリケーション ロードバランサでサポートされているさまざまなタイプのセッション アフィニティ オプションの概要を示します。次のセクションのセッション アフィニティのタイプでは、各セッション アフィニティ タイプについて詳しく説明します。
| プロダクト | セッション アフィニティのオプション |
|---|---|
また、次の点にもご注意ください。
|
セッション アフィニティを構成する際は、次の点に留意してください。
認証やセキュリティを目的としてセッション アフィニティに依存しないでください。ステートフル 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 アドレスと同じになります。
- パケットが Trusted Cloud ロードバランサに配信される前に中間 NAT またはプロキシ システムによって処理されると、パケットの送信元 IP アドレスが元のクライアントに関連付けられた IP アドレスと一致しないことがあります。多くのクライアントが同じ有効な送信元 IP アドレスを共有する場合、一部のバックエンド VM は他の VM よりも多くの接続またはリクエストを受信する可能性があります。
HTTP ヘッダーベースのセッション アフィニティ
ヘッダー フィールド アフィニティ（HEADER_FIELD）では、バックエンド サービスの consistentHash.httpHeaderName フィールドの HTTP ヘッダーの値に基づいて、リクエストがバックエンドにルーティングされます。使用可能なすべてのバックエンドにリクエストを分散するには、各クライアントで異なる HTTP ヘッダー値を使用する必要があります。
ヘッダー フィールド アフィニティは、次の条件を満たす場合にサポートされます。
- ロード バランシングの局所性ポリシーが
RING_HASHまたはMAGLEVである。 - バックエンド サービスの
consistentHashが、HTTP ヘッダーの名前（httpHeaderName）を指定する。
Cookie ベースのセッション アフィニティ
Cookie ベースのセッション アフィニティには次のタイプがあります。
生成された 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_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 が選択される可能性があります。
選択したインスタンスまたはエンドポイントを含むインスタンス グループまたは NEG は、ターゲット容量で定義されている容量を満たしてはなりません。（リージョン マネージド インスタンス グループの場合、選択したインスタンスを含むインスタンス グループのゾーン コンポーネントがいっぱいになっていないこと）。インスタンス グループまたは NEG がいっぱいで、他のインスタンス グループまたは NEG がいっぱいでない場合は、セッション アフィニティが破棄される可能性があります。
UTILIZATIONバランシング モードを使用すると、満杯状態が予測できない方法で変化する可能性があるため、RATEバランシング モードまたはCONNECTIONバランシング モードを使用して、セッション アフィニティが破損する可能性のある状況を最小限に抑える必要があります。構成されたバックエンド インスタンスまたはエンドポイントの合計数は一定にする必要があります。次のいずれかのイベントが 1 つ以上発生すると、構成されたバックエンド インスタンスまたはエンドポイントの数が変わり、セッション アフィニティが破損する可能性があります。
新しいインスタンスまたはエンドポイントを追加する:
- バックエンド サービスで、既存のインスタンス グループにインスタンスを追加します。
- マネージド インスタンス グループの自動スケーリングでは、バックエンド サービスのマネージド インスタンス グループにインスタンスが追加されます。
- バックエンド サービスで、既存の NEG にエンドポイントを追加します。
- 空ではないインスタンス グループまたは NEG をバックエンド サービスに追加します。
選択したインスタンスまたはエンドポイントだけでなく、インスタンスまたはエンドポイントを削除する:
- インスタンス グループのバックエンドからインスタンスを削除した場合。
- マネージド インスタンス グループの自動スケーリングまたは自動修復により、マネージド インスタンス グループのバックエンドからインスタンスが削除されます。
- NEG バックエンドからエンドポイントを削除します。
- 空ではない既存のバックエンド インスタンス グループまたは NEG をバックエンド サービスから削除します。
正常なバックエンド インスタンスまたはエンドポイントの合計数は一定にする必要があります。次のいずれかのイベントが 1 つ以上発生すると、正常なバックエンド インスタンスまたはエンドポイントの数が変わり、セッション アフィニティが破損する可能性があります。
- インスタンスまたはエンドポイントがヘルスチェックに合格し、異常な状態から正常な状態に変わります。
- インスタンスまたはエンドポイントがヘルスチェックに失敗し、正常な状態から異常な状態に移行するか、タイムアウトします。