バックエンド サービスベースの外部 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 が変更されていない状態でバックエンド 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 アドレス、パケットのプロトコル、宛先ポートの情報(パケットにポート情報が含まれている場合)を維持しながら、パケットをバックエンド VM に転送します。

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

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

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

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

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

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

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

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

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

インスタンス グループは、スコープ内のリージョンまたはゾーンに設定できます。ネットワーク ロードバランサは可用性が高い設計になっています。高可用性のメカニズムは単一のデバイスや VM インスタンスに依存しないため、ロードバランサの可用性を向上させるための特別な手順はありません。バックエンド 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 ファイアウォール ルールを使用してロードバランサのバックエンドへのアクセスを制御します。ヘルスチェックと負荷分散の対象トラフィックを許可するには、上り(内向き)許可のファイアウォール ルールまたは上り(内向き)階層ファイアウォール ポリシーを作成する必要があります。

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

  • インターネット上の任意の IP アドレスからのトラフィックを許可するには、0.0.0.0/0 の送信元範囲を設定して、関連するプロトコル(プロトコルがポートを使用する場合はポートも含む)に上り(内向き)許可ファイアウォール ルールを作成する必要があります。特定の IP アドレス範囲からのトラフィックのみを許可するには、使用するソース範囲の制限を厳しくします。

  • 転送ルールに L3_DEFAULT プロトコルを使用している場合は、上り(内向き)許可ファイアウォール ルールまたは階層ファイアウォール ポリシーを必要な 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 に送信されます。以前決定されたバックエンドは、ロードバランサの接続トラッキング テーブルに記録されています。

ロードバランサが対応する接続トラッキング エントリを持たないパケットを受信した場合、ロードバランサは以下を実行します。

  • パケットが TCP パケットまたは断片化されていない UDP パケットで、セッション アフィニティが構成されていない場合、ロードバランサは、パケットの送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート、プロトコルの 5 タプルハッシュを作成します。このハッシュを使用して、その時点で正常な状態のバックエンドを選択します。他のプロトコル トラフィック(断片化された UDP パケットを含む)の場合、ロードバランサはパケットの送信元 IP アドレス、宛先 IP アドレス、プロトコルの 3 タプルハッシュを作成し、このハッシュを使用して正常なバックエンドを選択します。
  • セッション アフィニティ オプションを構成した場合、ロードバランサはハッシュを作成しますが、セッション アフィニティで説明されているように、作成元の情報の個数は少なくなる可能性があります。
  • パケットが TCP パケットの場合、またはセッション アフィニティが NONE 以外に設定された UDP または ESP パケットの場合、ロードバランサは選択したバックエンドを接続トラッキング テーブルに記録します。接続トラッキング テーブルのエントリは、使用されない場合、60 秒後に失効します。他のプロトコルの接続はトラッキングできません。詳細な一覧については、次のセクションの表をご覧ください。

永続的な接続動作

  • TCP トラフィック。TCP パケットの場合、バックエンド VM のヘルスチェックの状態によって制御されるのは、新しい接続のパケットの分散のみです。バックエンド VM がインスタンス グループのメンバーであり、そのインスタンス グループがロードバランサのバックエンドとして構成されている限り、同じ接続に含まれるパケットは、その VM のヘルスチェックの状態が正常でなくなっていても、以前選択されていたバックエンド VM に送信されます。正常でないバックエンドがパケットに応答しても、接続は中断されません。正常でないバックエンドがパケットを拒否するか、応答しない場合には、クライアントは新しい接続で再試行でき、再試行接続用に別の正常なバックエンドを選択できます。

    インスタンス グループからバックエンド VM を削除した場合や、バックエンド サービスからインスタンス グループを削除した場合、確立された接続はコネクション ドレインで説明されている形でのみ保持されます。

  • UDP トラフィック。UDP トラフィックにはセッションがないため、デフォルトでは、接続トラッキング テーブルを使用せずにすべての UDP パケットが処理されます。UDP 接続は、問題が発生しているバックエンドでは保持されません。ただし、セッション アフィニティNONE 以外に設定されている場合、UDP 接続は(TCP 接続と同様に)トラッキングされますが、問題が発生しているバックエンドでは UDP 接続は保持されません(TCP 接続とは異なる)。

  • ESP トラフィックと ICMP トラフィック。ESP トラフィックと ICMP トラフィックの場合、問題が発生しているバックエンドでは接続が保持されません。

次の表は、ロードバランサが接続トラッキングを使用する状況と永続的な接続の動作をプロトコルごとにまとめたものです。

負荷分散するトラフィック 接続トラッキング 異常なバックエンドでの接続維持
TCP 常にオン あり
UDP セッション アフィニティNONE 以外に設定されている場合、
接続トラッキングがオンになります。
それ以外の場合、接続トラッキングはオフになります。
×
ESP セッション アフィニティNONE 以外に設定されている場合、
接続トラッキングがオンになります。
それ以外の場合、接続トラッキングはオフになります。
×
ICMP 接続トラッキング不可 ×

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

セッション アフィニティは、クライアントからロードバランサのバックエンド VM への新しい接続の分散を制御します。たとえば、接続トラッキングやコンシステント ハッシュのセクションで説明したコンセプトに基づき、新しい接続を同じクライアントから同じバックエンド VM に転送できます。

ネットワーク負荷分散は、バックエンド インスタンス グループではなく、リージョン外部バックエンド サービス全体に指定する次のセッション アフィニティのオプションをサポートします。

セッション アフィニティ コンシステント ハッシュ メソッド 接続トラッキング
なし
NONE
TCP および断片化されていない UDP の場合は 5 タプルハッシュ
他のプロトコルの場合は 3 タプルハッシュ
TCP の 5 タプル トラッキング TCP の場合、これは実質的に、クライアント IP、クライアント ポート、宛先 IP、宛先ポート、プロトコル(5 タプルハッシュ)と同じです。
他のプロトコルの場合、セッション アフィニティに NONE を使用している場合、接続トラッキングは無効になります。
クライアント IP、宛先 IP
CLIENT_IP
次の 2 つのタプルハッシュ:
• パケットの送信元 IP アドレス
• パケットの宛先 IP アドレス
TCP と断片化されていない UDP の場合は 5 タプル トラッキング
ESP と断片化された UDP の場合は 3 タプル トラッキング
他のプロトコルはトラッキングなし
同じ送信元 IP アドレスからの接続をすべて同じバックエンド VM によって処理する必要がある場合は、このオプションを使用します。
クライアント IP、宛先 IP、プロトコル
CLIENT_IP_PROTO
3 タプルハッシュ:
• パケットの送信元 IP アドレス
• パケットの宛先 IP アドレス
• プロトコル
TCP と断片化されていない UDP の場合は 5 タプル トラッキング
ESP と断片化された UDP の場合は 3 タプル トラッキング
他のプロトコルはトラッキングなし
クライアント IP、クライアント ポート、宛先 IP、宛先ポート、プロトコル(5 タプル)
CLIENT_IP_PORT_PROTO
TCP および断片化されていない UDP の場合は 5 タプルハッシュ
他のプロトコルの場合は 3 タプルハッシュ
TCP と断片化されていない UDP の場合は 5 タプル トラッキング
ESP と断片化された UDP の場合は 3 タプル トラッキング
他のプロトコルはトラッキングなし
TCP の場合、これは NONE と同じです。

コネクション ドレイン

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

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

デフォルトでは、コネクション ドレインは無効になっています。無効にすると、確立された接続はできる限り早く終了します。コネクション ドレインを有効にすると、VM が存在しなくなるまで、確立された接続が維持されます。

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

フェイルオーバー

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

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

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

UDP の断片化

UDP パケットを負荷分散している場合は、以下の点に注意してください。

  • 断片化されていないパケットは、すべての構成で通常通り処理されます。
  • UDP パケットは Google Cloud に到達する前に断片化されることがあります。Google Cloud 以外のネットワークでは、すべてのフラグメントが到達するのを待ったり、断片化されたパケットを完全に破棄したりするため、断片化された UDP パケットが遅延する可能性があります。Google Cloud ネットワークは、UDP フラグメントが到達すると転送します。

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

  • 負荷分散された IP アドレスごとに UDP 転送ルールを 1 つだけ使用し、すべてのポートでトラフィックを受信するように転送ルールを構成します。これにより、同じ宛先ポートがない場合でも、すべてのフラグメントが同じ転送ルールに到達するようになります。すべてのポートを構成するには、gcloud を使用して --ports=ALL を設定するか、API を使用して allPortsTrue設定します。
  • セッション アフィニティをなしNONE)に設定します。これはアフィニティの維持が不要であるという意味であり、ロードバランサは断片化されていないパケットの場合は 5 タプルハッシュを使用し、断片化パケットの場合は 3 タプルハッシュを使用してバックエンドを使用するようになります。

これらの設定により、同じパケットからの UDP フラグメントが同じインスタンスに転送されて再構成されます。

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

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

制限事項

  • ネットワーク エンドポイント グループ(NEG)は、ネットワーク ロードバランサのバックエンドとしてサポートされていません。
  • バックエンド サービスベースのネットワーク ロードバランサは、Google Kubernetes Engine ではサポートされていません。
  • Google Cloud Console で次の操作を行うことはできません。
    • 転送ルールで L3_DEFAULT プロトコルを使用するネットワーク ロードバランサを作成または変更する。
    • バックエンド サービス プロトコルが UNSPECIFIED に設定されているネットワーク ロードバランサを作成または変更する。代わりに、gcloud コマンドライン ツールまたは REST API を使用してください。

次のステップ