バックエンド サービスベースの外部 TCP / UDP ネットワーク負荷分散の概要

Google Cloud の外部 TCP / UDP ネットワーク負荷分散(以降はネットワーク負荷分散と呼びます)は、リージョンのパススルー ロードバランサです。ネットワーク ロードバランサは、同じリージョン内の仮想マシン(VM)インスタンス間で外部トラフィックを分散します。

ネットワーク ロードバランサは、TCP、UDP、ESP、ICMP トラフィック向けに構成できます。ESP と ICMP のサポートは、プレビュー版です。

ネットワーク ロードバランサは、以下からのトラフィックを受信できます。

  • インターネット上のすべてのクライアント
  • 外部 IP を持つ Google Cloud VM
  • Cloud NAT またはインスタンス ベースの NAT 経由でインターネットにアクセスできる Google Cloud VM

ネットワーク負荷分散には次の特長があります。

  • ネットワーク負荷分散はマネージド サービスです。
  • ネットワーク負荷分散は、Andromeda 仮想ネットワーキングGoogle Maglev で実装されます。
  • ネットワーク ロードバランサはプロキシではありません。
    • 負荷分散されたパケットは、パケットの送信元 IP アドレス、宛先 IP アドレス、プロトコル(プロトコルがポートベースの場合は、送信元ポートと宛先ポートは変更されていません)を持つバックエンド VM によって受信されます。
    • 負荷分散接続はバックエンド VM によって終端されます。
    • バックエンド VM からのレスポンスは、ロードバランサを経由せず、クライアントに直接送信されます。これを業界用語で Direct Server Return といいます。

バックエンド サービスベースのネットワーク ロードバランサには次の特長があります。

  • マネージド インスタンス グループのバックエンド。バックエンド サービスベースのネットワーク ロードバランサでは、バックエンドとしてマネージド インスタンス グループの使用がサポートされます。マネージド インスタンス グループはバックエンド管理の特定の側面を自動化し、非マネージド インスタンス グループよりもスケーラビリティと信頼性が向上します。
  • きめ細かいトラフィック分散の制御。バックエンド サービスの構成には、ヘルスチェックセッション アフィニティ接続トラッキングコネクション ドレインフェイルオーバー ポリシーなどの一連の値が含まれます。これらの設定のほとんどにはデフォルト値が用意されているため、直ちに利用を開始できます。
  • ヘルスチェック。バックエンド サービスベースのネットワーク ロードバランサは、分散するトラフィックのタイプ(TCP、SSL、HTTP、HTTPS、HTTP/2)に一致するヘルスチェックを使用します。

アーキテクチャ

次の図は、ネットワーク ロードバランサのコンポーネントを示しています。

リージョン バックエンド サービスを使用した外部 TCP / UDP ネットワーク ロードバランサ
リージョン バックエンド サービスを使用するネットワーク負荷分散

ロードバランサは、いくつかの構成コンポーネントで構成されています。単一のロードバランサには、次のものを含めることができます。

  • 1 つ以上のリージョン外部 IP アドレス
  • 1 つ以上のリージョン外部転送ルール
  • 1 つのリージョン外部バックエンド サービス
  • 1 つ以上のバックエンド インスタンス グループ
  • バックエンド サービスに関連付けられたヘルスチェック

さらに、負荷分散トラフィックとヘルスチェック プローブがバックエンド VM に到達することを許可するファイアウォール ルールを作成する必要があります。

IP アドレス

1 つのネットワーク ロードバランサには、少なくとも 1 つの転送ルールが必要です。転送ルールは、単一のリージョン外部 IP アドレスを参照します。リージョン外部 IP アドレスは、インターネット上のどこからでもアクセスできますが、各 Google Cloud リージョンに固有のプールからのものです。

転送ルールを作成するときは、既存の予約済みリージョン外部 IP アドレスの名前または IP アドレスを指定できます。IP アドレスを指定しない場合、転送ルールはエフェメラル リージョン外部 IP アドレスを参照します。転送ルールを削除した後もプロジェクトに関連付けたアドレスを保持しておく必要がある場合、または同じ IP アドレスを参照する複数の転送ルールが必要な場合は、予約済み IP アドレスを使用します。

ネットワーク負荷分散は、スタンダード ティアとプレミアム ティアの両方のリージョン外部 IP アドレスに対応しています。IP アドレスと転送ルールはどちらも同じネットワーク階層を使用する必要があります。

IP アドレスを予約する手順については、外部 IP アドレスをご覧ください。

転送ルール

リージョン外部転送ルールは、ロードバランサがトラフィックを受け入れるプロトコルとポートを指定します。ネットワーク ロードバランサはプロキシではありません。パケットにポート情報が含まれている場合は、同じプロトコルとポートでバックエンドにトラフィックを転送します。転送ルールと IP アドレスの組み合わせにより、ロードバランサのフロントエンドが形成されます。

ロードバランサは受信パケットの送信元 IP アドレスを保持します。受信パケットの宛先 IP アドレスは、ロードバランサの転送ルールに関連付けられた IP アドレスです。

受信トラフィックは転送ルール(特定の IP アドレスとプロトコル)と照合されます。プロトコルがポートベースの場合は、ポート、ポート範囲、またはすべてのポートと照合されます。その後、この転送ルールによって、ロードバランサのバックエンド サービスにトラフィックが転送されます。

1 つのネットワーク ロードバランサには、少なくとも 1 つの転送ルールが必要です。複数の転送ルールで説明しているように、同じロードバランサに複数の転送ルールを定義できます。

転送ルール プロトコル

ネットワーク負荷分散は、転送ルールごとにプロトコル オプション TCPUDPL3_DEFAULTプレビュー版)をサポートしています。

TCP または UDP 負荷分散を構成するには、TCP オプションと UDP オプションを使用します。L3_DEFAULT プロトコル オプションを使用すると、ネットワーク ロードバランサは TCP、UDP、ESP、ICMP のトラフィックを負荷分散できます。

TCP と UDP 以外のプロトコルがサポートされるだけでなく、L3_DEFAULT では 1 つの転送ルールで複数のプロトコルを処理できます。たとえば、IPSec サービスは通常、ESP と UDP ベースの IKE、NAT-T のトラフィックの組み合わせを処理します。L3_DEFAULT オプションを使用すると、これらのプロトコルをすべて処理する単一の転送ルールを構成できます。

TCP または UDP プロトコルを使用した転送ルールでは、転送ルールと同じプロトコルか、プロトコルが UNSPECIFIEDプレビュー)のバックエンド サービスのいずれかを使用して、バックエンド サービスを参照できます。L3_DEFAULT 転送ルールは、プロトコル UNSPECIFIED のバックエンド サービスのみを参照できます。

次の表に、それぞれのプロトコルでこれらの設定を使用する方法を示します。

負荷分散するトラフィック 転送ルール プロトコル バックエンド サービス プロトコル
TCP TCP TCP または UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP または UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP L3_DEFAULT UNSPECIFIED
ICMP(Echo リクエストのみ) L3_DEFAULT UNSPECIFIED

複数の転送ルール

同じネットワーク ロードバランサに複数のリージョンの外部転送ルールを構成できます。必要に応じて、各転送ルールで異なるリージョン外部 IP アドレスを指定できます。また、複数の転送ルールで同じリージョン外部 IP アドレスを指定することもできます。

複数のリージョン外部転送ルールを構成すると、次のような場合に便利です。

  • 同じバックエンド サービスに複数の外部 IP アドレスを構成する必要がある。
  • 同じ外部 IP アドレスに対して異なるプロトコルを使用し、重複しないポートまたはポート範囲を構成する必要があります。

特定の IP アドレスに対して、L3_DEFAULT 転送ルールと他のプロトコル(TCP または UDP)の転送ルールを共存できますが、別の L3_DEFAULT 転送ルールとは共存できません。

限定された転送ルールが利用できない場合(たとえば、TCP トラフィックや UDP トラフィックの場合)、ロードバランサの IP アドレスに到達するパケットは L3_DEFAULT 転送ルールで処理されます。IP アドレス、プロトコル、ポートに到着したパケットが L3_DEFAULT 転送ルールで処理されるのは、その IP アドレスに対して、パケットのプロトコルと宛先ポートに一致する転送ルールが他にない場合に限ります。

複数の転送ルールを使用する場合は、バックエンド VM で実行されるソフトウェアを、ロードバランサの転送ルールのすべての外部 IP アドレスにバインドされるように構成します。

リージョン バックエンド サービス

各ネットワーク ロードバランサには、ロードバランサの動作とバックエンドへのトラフィックの分散を定義する 1 つのリージョン バックエンド サービスがあります。バックエンド サービスの名前は、Google Cloud Console に表示されるネットワーク ロードバランサの名前です。

各バックエンド サービスは、次のバックエンド パラメータを定義します。

  • プロトコル。バックエンド サービスは、1 つ以上のリージョン外部転送ルールで指定された IP アドレスとポート(構成されている場合)のトラフィックを受け入れます。バックエンド サービスは、パケットの送信元 IP アドレス、宛先 IP アドレス、プロトコル(プロトコルがポートベースの場合は、送信元ポートと宛先ポート)を保持しながら、パケットをバックエンド VM に渡します。

    ネットワーク ロードバランサで使用されるバックエンド サービスは、TCPUDP または UNSPECIFIEDプレビュー版)のプロトコル オプションをサポートします。

    UNSPECIFIED プロトコルのバックエンド サービスは、転送ルール プロトコルに関係なく、どの転送ルールでも使用できます。特定のプロトコル(TCP または UDP)のバックエンド サービスを参照できるのは、同じプロトコル(TCP または UDP)の転送ルールだけです。L3_DEFAULT プロトコルの転送ルールを参照できるのは、UNSPECIFIED プロトコルのバックエンド サービスだけです。

    使用可能な転送ルールとバックエンド サービス プロトコルの組み合わせについては、転送ルール プロトコルの仕様の表をご覧ください。

  • トラフィック分散。バックエンド サービスでは、構成可能なセッション アフィニティ ポリシーと接続トラッキング ポリシーに沿って、トラフィックの分散ができます。バックエンド サービスは、コネクション ドレインを有効にして、ロードバランサのフェイルオーバー バックエンドを指定するように構成することもできます。

  • ヘルスチェック。バックエンド サービスには、関連付けられたリージョン ヘルスチェックが必要です。

各バックエンド サービスは単一のリージョンで動作し、バックエンド VM の最初のネットワーク インターフェース(nic0)にトラフィックを分散します。バックエンドは、バックエンド サービス(および転送ルール)と同じリージョン内のインスタンス グループである必要があります。バックエンドは、ゾーン非マネージド インスタンス グループ、ゾーン マネージド インスタンス グループ、またはリージョン マネージド インスタンス グループです。

バックエンド サービスベースのネットワーク ロードバランサは、VPC ネットワークがバックエンド サービスと同じプロジェクトにある限り、メンバー インスタンスが同じリージョン内の VPC ネットワークを使用するインスタンス グループをサポートします(特定のインスタンス グループ内のすべての VM は同じ VPC ネットワークを使用する必要があります)。

バックエンド インスタンス グループ

ネットワーク ロードバランサは、マネージド インスタンス グループまたは非マネージド インスタンス グループに含まれるバックエンド VM 間で接続を分散します。インスタンス グループは、スコープ内のリージョンまたはゾーンに設定できます。

  • リージョン マネージド インスタンス グループ インスタンス テンプレートを使用してソフトウェアをデプロイできる場合は、リージョン マネージド インスタンス グループを使用してください。リージョン マネージド インスタンス グループは、複数のゾーン間にトラフィックを自動的に分散して、ゾーン内の潜在的な問題の回避に最適な手段を提供します。

    リージョン マネージド インスタンス グループを使用したデプロイ例を以下に示します。インスタンス グループには、インスタンスをプロビジョニングする方法を定義するインスタンス テンプレートがあり、各グループは us-central1 リージョンの 3 つのゾーンにインスタンスをデプロイします。

    リージョン マネージド インスタンス グループを使用したネットワーク ロードバランサ
    リージョン マネージド インスタンス グループを使用するネットワーク負荷分散
  • ゾーン マネージド インスタンス グループまたは非マネージド インスタンス グループ。(同じリージョン内の)異なるゾーンのゾーン インスタンス グループを使用することで、特定のゾーンの潜在的な問題から保護します。

    ゾーン インスタンス グループを使用したデプロイ例を以下に示します。このロードバランサは 2 つのゾーンにわたって可用性を提供します。

    ゾーン インスタンス グループを使用したネットワーク ロードバランサ
    ゾーン インスタンス グループを使用したネットワーク負荷分散

ヘルスチェック

ネットワーク負荷分散は、リージョン ヘルスチェックを使用して、新しい接続を受け取れるインスタンスを決定します。各ネットワーク ロードバランサのバックエンド サービスは、リージョン ヘルスチェックに関連付ける必要があります。ロードバランサは、ヘルスチェック ステータスを使用して、バックエンド インスタンスに新しい接続を転送する方法を決定します。

Google Cloud ヘルスチェックの仕組みの詳細については、ヘルスチェックの仕組みをご覧ください。

ネットワーク負荷分散は次のタイプのヘルスチェックをサポートします。

他のプロトコルのトラフィックに対するヘルスチェック

Google Cloud では、こちらに掲載されていないプロトコルに対して固有のヘルスチェックを提供していません。ネットワーク負荷分散を使用して TCP 以外のプロトコルを負荷分散する場合、必要なヘルスチェック情報を提供するには、バックエンド VM で TCP ベースのサービスを実行する必要があります。

たとえば、UDP トラフィックの負荷分散を行う場合、クライアント リクエストは UDP プロトコルを使用して負荷分散されますが、Google Cloud ヘルスチェック プローバーに情報を提供するには、TCP サービスを実行する必要があります。この処理を行うには、ヘルスチェック プローバーに HTTP 200 レスポンスを返す各バックエンド VM でシンプルな HTTP サーバーを実行します。バックエンド VM 上で実行する独自のロジックを使用して、UDP サービスが適切に構成および実行されている場合にのみ、HTTP サーバーが 200 を返すようにする必要があります。

ファイアウォール ルール

ネットワーク負荷分散はパススルー ロードバランサであるため、Google Cloud ファイアウォール ルールを使用してロードバランサのバックエンドへのアクセスを制御します。ヘルスチェックと負荷分散するトラフィックを許可するには、上り(内向き)許可のファイアウォール ルールまたは上り(内向き)許可の階層型ファイアウォール ポリシーを作成する必要があります。

転送ルールと上り(内向き)許可のファイアウォール ルールまたは階層型ファイアウォール ポリシーは、次のように連携します。転送ルールでは、バックエンド VM に転送するために、プロトコルと(定義されている場合)パケットが適合する必要があるポート要件が定義されます。上り(内向き)許可のファイアウォール ルールでは、転送されたパケットを VM に配信するか、ドロップするかを制御します。すべての VPC ネットワークには、任意のソースからの受信パケットをブロックする暗黙の上り(内向き)拒否のファイアウォール ルールがあります。Google Cloud のデフォルト VPC ネットワークには、事前入力された上り(内向き)許可のファイアウォール ルールが一部含まれています。

  • インターネット上の任意の IP アドレスからのトラフィックを受信するには、0.0.0.0/0 ソース範囲を使用して上り(内向き)許可ファイアウォール ルールを作成する必要があります。特定の IP アドレス範囲からのトラフィックのみを許可するには、使用するソース範囲の制限を厳格にします。

  • セキュリティのベスト プラクティスとして、上り(内向き)許可のファイアウォール ルールでは、必要な IP プロトコルとポートのみを許可してください。プロトコルが L3_DEFAULT に設定されている転送ルールを使用する場合は、プロトコル(および可能であればポート)の構成を制限することが特に重要です。L3_DEFAULT 転送ルールによって、サポートされているすべての IP プロトコルのパケットが転送されます(プロトコルとパケットにポート情報が存在する場合は、すべてのポート上で転送されます)。

  • ネットワーク負荷分散は、Google Cloud ヘルスチェックを使用します。したがって、ヘルスチェックの IP アドレス範囲からのトラフィックは常に許可する必要があります。上り(内向き)のファイアウォール許可ルールは、ロードバランサのヘルスチェックのプロトコルとポートに特化して作成できます。

リクエスト パケットと返信パケットの IP アドレス

バックエンド VM がクライアントからロード バランシングされたパケットを受信すると、パケットの送信元と宛先は次のようになります。

  • 送信元: Google Cloud VM に関連付けられている外部 IP アドレス、またはロードバランサに接続するシステムのインターネット ルーティング可能な IP アドレス。
  • 宛先: ロードバランサの転送ルールの IP アドレス。

ロードバランサはプロキシではなくパススルー ロードバランサであるため、パケットはロードバランサの転送ルールの宛先 IP アドレスに送信されます。バックエンド VM で実行されるソフトウェアは、次のように構成する必要があります。

  • ロードバランサの転送ルールの IP アドレスまたは任意の IP アドレス(0.0.0.0 または ::)をリッスン(バインド)する
  • ロードバランサの転送ルールのプロトコルがポートをサポートしている場合: ロードバランサの転送ルールのポートをリッスン(バインド)する

戻りパケットは、ロードバランサのバックエンド VM からクライアントに直接送信されます。戻りパケットの送信元アドレスと宛先 IP アドレスはプロトコルによって異なります。

  • TCP は接続指向のため、バックエンド VM は、送信元 IP アドレスが転送ルールの IP アドレスと一致するパケットで応答する必要があります。これにより、クライアントがレスポンス パケットを適切な TCP 接続に関連付けることができます。
  • UDP、ESP、ICMP はコネクションレスです。バックエンド VM は、送信元 IP アドレスが転送ルールの IP アドレスまたは VM に割り当てられた IP アドレスと一致するレスポンス パケットを送信できます。ほとんどのクライアントは、パケットの送信元と同じ IP アドレスからのレスポンスを想定しています。

次の表は、レスポンス パケットの送信元と宛先をまとめたものです。

トラフィックの種類 送信元 宛先
TCP ロードバランサの転送ルールの IP アドレス リクエスト パケットの送信元
UDP、ESP、ICMP ほとんどの場合、ロードバランサの転送ルールの IP アドレス リクエスト パケットの送信元。

VM に外部 IP アドレスがある場合、または Cloud NAT を使用している場合は、レスポンス パケットの送信元 IP アドレスを VM NIC のプライマリ内部 IPv4 アドレスに設定することもできます。Google Cloud または Cloud NAT は、レスポンス パケットの送信元 IP アドレスを NIC の外部 IPv4 アドレスまたは Cloud NAT 外部 IPv4 アドレスに変更して、レスポンス パケットをクライアントの外部 IP アドレスに送信します。クライアントは、リクエスト パケットの宛先 IP アドレスと一致しない外部 IP アドレスからレスポンス パケットを受信します。このため、転送ルールの IP アドレスを送信元として使用しないのは高度なシナリオです。

リターンパス

ネットワーク負荷分散は、VPC ネットワーク外にある特別なルートを使用して、受信リクエストとヘルスチェック プローブを各バックエンド VM に転送します。

ロードバランサはパケットの送信元 IP アドレスを保持します。バックエンド VM からのレスポンスは、ロードバランサを経由せず、クライアントに直接送信されます。これを業界用語で Direct Server Return といいます。

共有 VPC アーキテクチャ

IP アドレスを除き、ネットワーク ロードバランサのすべてのコンポーネントは同じプロジェクト内に存在する必要があります。次の表は、ネットワーク負荷分散の共有 VPC コンポーネントをまとめたものです。

IP アドレス 転送ルール バックエンド コンポーネント
リージョン外部 IP アドレスは、ロードバランサまたは共有 VPC ホスト プロジェクトと同じプロジェクトで定義する必要があります。 リージョンの外部転送ルールは、バックエンド サービスのインスタンスと同じプロジェクトで定義する必要があります。

リージョン バックエンド サービスは、バックエンド インスタンス グループ内のインスタンスと同じプロジェクトおよび同じリージョンで定義する必要があります。

バックエンド サービスに関連するヘルスチェックは、バックエンド サービスと同じプロジェクトとリージョンで定義する必要があります。

トラフィック分散

ネットワーク ロードバランサがどのように新しい接続を分散するかは、フェイルオーバーが構成されているかどうかによって異なります。

  • フェイルオーバーを構成していない場合、少なくとも 1 つのバックエンド VM が正常であれば、ネットワーク ロードバランサは正常なバックエンド VM に新しい接続を分散します。すべてのバックエンド VM が正常でない場合は、最後の手段としてロードバランサによりすべてのバックエンドの間で新しい接続が分散されます。この場合、ロードバランサにより正常でないバックエンド VM にそれぞれ新しい接続が転送されます。
  • フェイルオーバーを構成している場合は、構成したフェイルオーバー ポリシーに従って、ネットワーク ロードバランサによってアクティブ プール内の正常なバックエンド VM 間での新しい接続が分散されます。すべてのバックエンド VM が正常でない場合は、次の動作の中からいずれかを選択できます。
    • (デフォルト)ロードバランサは、プライマリ VM にのみトラフィックを分散します。これは最後の手段です。バックアップ VM は、この最後の接続分散から除外されます。
    • ロードバランサはトラフィックをドロップします。

接続の分散方法の詳細については、次のセクションのバックエンドの選択と接続トラッキングをご覧ください。

フェイルオーバーの機能の詳細については、フェイルオーバーのセクションをご覧ください。

バックエンドの選択と接続トラッキング

ネットワーク負荷分散では、構成可能なバックエンドの選択と接続トラッキング アルゴリズムを使用して、トラフィックをバックエンド VM に分散する方法が決定されます。

ネットワーク負荷分散では、次のアルゴリズムを使用して、(フェイルオーバーを構成している場合は、アクティブ プール内の)バックエンド VM 間にパケットが分散されます。

  1. ロードバランサに、受信パケットの特性と一致する接続トラッキング テーブルがある場合、パケットは接続トラッキング テーブルのエントリで指定されたバックエンドに送信されます。パケットは、以前に確立した接続の一部とみなされるため、ロードバランサによって接続トラッキング テーブルに以前に決定され記録されたバックエンド VM に送信されます。
  2. ロードバランサが対応する接続トラッキング エントリを持たないパケットを受信した場合、ロードバランサは以下のことを行います。

    1. ロードバランサがバックエンドを選択します。ロードバランサは、構成されたセッション アフィニティに基づいてハッシュを計算します。ロードバランサは、このハッシュを使用して、その時点で正常な状態のバックエンドの中からバックエンドを 1 つ選択します(ただし、すべてのバックエンドが異常な状態である場合を除きます。その場合は、この状況でフェイルオーバー ポリシーがトラフィックをドロップするように構成されていない限り、すべてのバックエンドが考慮されます)。デフォルトのセッション アフィニティ NONE では、次のハッシュ アルゴリズムが使用されます。

      • TCP パケットと断片化されていない UDP パケットの場合、パケットの送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート、プロトコルの 5 タプルハッシュ
      • 断片化された UDP パケットと他のすべてのプロトコルの場合、パケットの送信元 IP アドレス、宛先 IP アドレス、プロトコルの 3 タプルハッシュ

      バックエンドの選択は、使用する情報が少ないハッシュ アルゴリズムを使用してカスタマイズできます。サポートされているすべてのオプションについては、セッション アフィニティのオプションをご覧ください。

    2. ロードバランサにより、接続トラッキング テーブルにエントリが追加されます。このエントリによって、パケット接続用に選択されたバックエンドが記録されるため、この接続からの以降のパケットがすべて同じバックエンドに送信されます。接続トラッキングを使用するかどうかは、プロトコルによって異なります。

      • TCP パケット。接続トラッキングは常に有効になっています。オフにすることはできません。デフォルトでは、接続トラッキングは 5 タプルですが、5 タプル未満に構成することもできます。5 タプルの場合、TCP SYN パケットは異なる方法で処理されます。SYN 以外のパケットとは異なり、一致する接続トラッキング エントリを破棄し、常に新しいバックエンドを選択します。

        デフォルトの 5 タプル接続トラッキングは、次の場合に使用されます。

        • トラッキング モードが PER_CONNECTION(すべてのセッション アフィニティ)の場合。または
        • トラッキング モードが PER_SESSION であり、セッション アフィニティが NONE の場合。または
        • トラッキング モードが PER_SESSION であり、セッション アフィニティが CLIENT_IP_PORT_PROTO の場合。
      • UDP パケットと ESP パケット。接続トラッキングは、セッション アフィニティが NONE 以外に設定されている場合にのみ有効になります。

      • ICMP パケット。接続トラッキングは使用できません。

      接続トラッキングが有効にされている場合と、接続トラッキングが有効な場合のトラッキング方法の詳細については、接続トラッキング モードをご覧ください。

      さらに、次の点に留意してください。

      • 接続トラッキング テーブル内のエントリは、ロードバランサがエントリに一致した最後のパケットを処理してから 60 秒後に失効します。この 60 秒のアイドル タイムアウト値は構成できません。
      • プロトコルによっては、バックエンドが正常な状態ではなくなると、ロードバランサによって接続トラッキング テーブルのエントリが削除される場合があります。この動作の詳細とカスタマイズ方法については、異常なバックエンドでの接続の永続性をご覧ください。

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

セッション アフィニティは、クライアントからロードバランサのバックエンド VM への新しい接続の分散を制御します。セッション アフィニティは、バックエンド インスタンス グループごとではなく、リージョンの外部バックエンド サービス全体に対して指定されます。

ネットワーク負荷分散では、次のセッション アフィニティのオプションがサポートされます。

  • なし(NONE)。送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートの 5 タプルハッシュ
  • クライアント IP、宛先 IP(CLIENT_IP)。送信元 IP アドレスと宛先 IP アドレスの 2 タプルハッシュ
  • クライアント IP、宛先 IP、プロトコル(CLIENT_IP_PROTO)。送信元 IP アドレス、宛先 IP アドレス、プロトコルの 3 タプルハッシュ
  • クライアント IP、クライアント ポート、宛先 IP、宛先ポート、プロトコル(CLIENT_IP_PORT_PROTO)。送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートの 5 タプルハッシュ

これらのセッション アフィニティのオプションがバックエンドの選択と接続トラッキング方法に与える影響については、こちらの表をご覧ください。

接続トラッキング モード

接続トラッキングを有効にするかどうかは、負荷分散されたトラフィックのプロトコルとセッション アフィニティの設定のみによって決定されます。トラッキング モードでは、接続トラッキングが有効な場合に使用される接続トラッキング アルゴリズムを指定します。トラッキング モードには、PER_CONNECTION(デフォルト)と PER_SESSION の 2 つがあります。

  • PER_CONNECTION(デフォルト)。これはデフォルトのトラッキング モードです。この接続トラッキング モードでは、セッション アフィニティの設定に関係なく、TCP トラフィックが常に 5 タプルごとに追跡されます。UDP トラフィックと ESP トラフィックについては、選択したセッション アフィニティが NONE 以外の場合に、接続トラッキングが有効になります。UDP パケットと ESP パケットは、こちらので説明されている追跡方法で追跡されます。

  • PER_SESSIONセッション アフィニティが CLIENT_IP または CLIENT_IP_PROTO の場合にこのモードを構成すると、(トラッキング可能な接続ではない ICMP を除く)すべてのプロトコルに対して、それぞれ 2 タプルと 3 タプルの接続トラッキングが行われます。他のセッション アフィニティの設定の場合、PER_SESSION モードの動作は PER_CONNECTION モードとまったく同じです。

プロトコルごとに異なるセッション アフィニティが設定されているこれらのトラッキング モードの動作については、次の表をご覧ください。

バックエンドの選択 接続トラッキング モード
セッション アフィニティの設定 バックエンド選択のハッシュ方法 PER_CONNECTION(デフォルト) PER_SESSION
デフォルト: セッション アフィニティなし

NONE

TCP と断片化されていない UDP: 5 タプルハッシュ

断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ

  • TCP: 5 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ
  • TCP: 5 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ
クライアント IP、宛先 IP

CLIENT_IP

すべてのプロトコル: 2 タプルハッシュ
  • TCP と断片化されていない UDP: 5 タプル接続トラッキング
  • 断片化された UDP と ESP: 3 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ
  • TCP、UDP、ESP: 2 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ
クライアント IP、宛先 IP、プロトコル

CLIENT_IP_PROTO

すべてのプロトコル: 3 タプルハッシュ
  • TCP と断片化されていない UDP: 5 タプル接続トラッキング
  • 断片化された UDP と ESP: 3 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ
  • TCP、UDP、ESP: 3 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ
クライアント IP、クライアント ポート、宛先 IP、宛先ポート、プロトコル

CLIENT_IP_PORT_PROTO

TCP と断片化されていない UDP: 5 タプルハッシュ

断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ

  • TCP と断片化されていない UDP: 5 タプル接続トラッキング
  • 断片化された UDP と ESP: 3 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ
  • TCP と断片化されていない UDP: 5 タプル接続トラッキング
  • 断片化された UDP と ESP: 3 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ

接続トラッキング モードを変更する方法については、接続トラッキング ポリシーを構成するをご覧ください。

異常なバックエンドでの接続の永続性

バックエンドが異常な状態になった後も、選択したバックエンドで既存の接続を維持するかどうかは、接続の永続性の設定で制御します(ただしバックエンドがロードバランサの構成済みバックエンド インスタンス グループに保持されている場合に限ります)。

このセクションで説明する動作は、バックエンド VM をインスタンス グループから削除する場合、またはインスタンス グループをバックエンド サービスから削除する場合には適用されません。このような場合、確立された接続はコネクション ドレインで説明されている内容に基づいてのみ維持されます。

使用できる接続の永続性に関するオプションは次のとおりです。

  • DEFAULT_FOR_PROTOCOL(デフォルト)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

次の表には、接続の永続性に関するオプションと、さまざまなプロトコル、セッション アフィニティのオプション、トラッキング モードに対して接続を維持する方法をまとめています。

異常なバックエンド オプションでの接続の永続性 接続トラッキング モード
PER_CONNECTION PER_SESSION
DEFAULT_FOR_PROTOCOL

TCP: 異常なバックエンドで接続が維持されます(すべてのセッション アフィニティ)

他のすべてのプロトコル: 異常なバックエンドで接続が維持されることはありません

TCP: セッション アフィニティが NONE または CLIENT_IP_PORT_PROTO の場合に、異常なバックエンドで接続が維持されます

他のすべてのプロトコル: 異常なバックエンドで接続が維持されることはありません

NEVER_PERSIST すべてのプロトコル: 異常なバックエンドで接続が維持されることはありません
ALWAYS_PERSIST

TCP: 異常なバックエンドで接続が維持されます(すべてのセッション アフィニティ)

ESP、UDP: セッション アフィニティが NONE でない場合に、異常なバックエンドで接続が維持されます。

ICMP: ICMP はトラッキングできない接続であるため適用できません

このオプションは、高度なユースケースにのみ使用してください。

構成が不可能

異常なバックエンドでの TCP 接続の永続性の動作

正常でないバックエンドで 5 タプル トラッキングの TCP 接続が維持される場合は常時:

  • 異常なバックエンドがパケットに引き続き応答する場合、接続がリセットされるか、(異常なバックエンドまたはクライアントによって)クローズされるまで、接続は維持されます。
  • 正常でないバックエンドが TCP リセット(RST)パケットを送信するか、パケットに応答しない場合、クライアントは新しい接続で再試行するため、ロードバランサは別の正常なバックエンドを選択できます。TCP SYN パケットは常に新しい正常なバックエンドを選択します。

接続の永続性の動作を変更する方法については、接続トラッキング ポリシーを構成するをご覧ください。

コネクション ドレイン

次の場合に、確立されたセッションにコネクション ドレインがプロセスとして適用されます。

  • バックエンド VM がインスタンス グループから削除された場合、または
  • マネージド インスタンス グループがバックエンド VM を削除した場合(置換、放棄、ローリング アップグレード、またはスケールダウン)、または
  • インスタンス グループがバックエンド サービスから削除された場合。

デフォルトでは、コネクション ドレインは無効になっています。無効にすると、確立された接続はできる限り早く終了します。コネクション ドレインを有効にすると、確立された接続は構成可能なタイムアウトまで維持され、その時間が経過するとバックエンド VM インスタンスは終端されます。

コネクション ドレインのトリガーとコネクション ドレインを有効にする方法の詳細については、コネクション ドレインの有効化をご覧ください。

UDP の断片化

ネットワーク負荷分散は、断片化された UDP パケットと断片化されていない UDP パケットの両方を処理します。断片化されていないパケットは、すべての構成で通常通り処理されます。断片化された UDP パケットをアプリケーションで使用する場合は、次の点に留意してください。

  • UDP パケットは Google Cloud VPC ネットワークに到達する前に断片化される場合があります。
  • Google Cloud VPC ネットワークでは、到達した UDP フラグメントが(すべてのフラグメントの到達を待たずに)転送されます。
  • Google Cloud 以外のネットワークとオンプレミス ネットワーク機器では、UDP フラグメントが到達すると転送される可能性、すべてのフラグメントが到達するまで断片化された UDP パケットが遅延される可能性、または断片化された UDP パケットが破棄される可能性があります。詳細については、他のネットワーク プロバイダまたはネットワーク機器のドキュメントをご覧ください。

断片化された UDP パケットを処理する可能性がある場合は、次の手順を行います。

  • 負荷分散された IP アドレスごとに UDP 転送ルールを 1 つだけ使用し、すべてのポートでトラフィックを受信するように転送ルールを構成します。これにより、同じ宛先ポートがない場合でも、すべてのフラグメントが同じ転送ルールに到達するようになります。すべてのポートを構成するには、gcloud コマンドライン ツールを使用して --ports=ALL を設定するか、API を使用して allPortsTrue に設定します。

  • 次のいずれかの方法を使用してバックエンド サービスを構成します。

    • セッション アフィニティと接続トラッキングを無効にします。セッション アフィニティを NONE に設定します。ロードバランサは、バックエンドを選択する際に断片化されたパケット(ポート情報を含む)に対しては 5 タプルハッシュを使用し、断片化されたパケット(ポート情報が欠落)に対しては 3 タプルハッシュを使用します。この設定では、同じクライアントからの断片化された UDP パケットと断片化されていない UDP パケットが別のバックエンドに転送される可能性があります。
    • 2 タプルまたは 3 タプルのセッション アフィニティと接続トラッキングを有効にします。セッション アフィニティを CLIENT_IP または CLIENT_IP_PROTO に設定し、接続トラッキング モードを PER_SESSION に設定します。この設定では、同じクライアントからの断片化された UDP パケットと断片化されていない UDP パケットが同じポートに転送されます(ポート情報は使用されません)。

ターゲット インスタンスをバックエンドとして使用する

ネットワーク ロードバランサのバックエンドとしてターゲット インスタンスを使用していて、UDP パケットの断片化が想定される場合、負荷分散された IP アドレスごとに UDP 転送ルールを 1 つだけ使用して、すべてのポートでトラフィックを受け入れるように転送ルールを構成します。これにより、同じ宛先ポートがない場合でも、すべてのフラグメントが同じ転送ルールに到達するようになります。すべてのポートを構成するには、gcloud を使用して --ports=ALL を設定するか、API を使用して allPortsTrue設定します。

フェイルオーバー

ネットワーク ロードバランサを構成して、プライマリ バックエンド インスタンス グループ内の仮想マシン(VM)インスタンス間で接続を分散し、必要に応じてフェイルオーバー バックエンド インスタンス グループを使用するように切り替えることができます。フェイルオーバーにより可用性を向上させることができる一方、メインのバックエンド VM が正常に動作していない場合にワークロードをより効率的に管理できます。

デフォルトでは、ネットワーク ロードバランサのバックエンド サービスにバックエンドを追加すると、そのバックエンドがプライマリ バックエンドになります。バックエンドは、ロードバランサのバックエンド サービスに追加するときに指定できます。また、後でバックエンド サービスを編集して、フェイルオーバー バックエンドに指定することもできます。

フェイルオーバー機能の詳細については、ネットワーク負荷分散のフェイルオーバーの概要をご覧ください。

制限事項

  • ネットワーク エンドポイント グループ(NEG)は、ネットワーク ロードバランサのバックエンドとしてサポートされていません。
  • バックエンド サービスベースのネットワーク ロードバランサは、Google Kubernetes Engine ではサポートされていません。
  • Google Cloud Console を使用して次のタスクを行うことはできません。

    • 転送ルールで L3_DEFAULT プロトコルを使用するネットワーク ロードバランサを作成または変更する。
    • バックエンド サービス プロトコルが UNSPECIFIED に設定されているネットワーク ロードバランサを作成または変更する。
    • バックエンド サービスの接続トラッキング ポリシーを構成する。

    代わりに、gcloud コマンドライン ツールまたは REST API を使用してください。

  • ネットワーク ロードバランサは、VPC ネットワーク ピアリングをサポートしていません。

次のステップ