バックエンド サービスベースの外部パススルー ネットワーク ロードバランサの概要

外部パススルー ネットワーク ロードバランサは、ロードバランサと同じリージョン内のバックエンド（インスタンス グループまたはネットワーク エンドポイント グループ（NEG））間で外部トラフィックを分散するレイヤ 4 リージョン ロードバランサです。これらのバックエンドは同じリージョンとプロジェクトに存在する必要がありますが、異なる VPC ネットワークに配置できます。これらのロードバランサは、Maglev と Andromeda ネットワークの仮想化スタック上に構築されています。

外部パススルー ネットワーク ロードバランサは、以下のトラフィックを受信できます。

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

外部パススルー ネットワーク ロードバランサはプロキシではありません。ロードバランサ自体はユーザー接続を終端しません。ロードバランスされたパケットは、元の送信元 IP アドレス、宛先 IP アドレス、プロトコル、ポート（該当する場合）のままバックエンド VM に送信されます。その後、バックエンド VM がユーザー接続を終端します。バックエンド VM からのレスポンスは、ロードバランサを経由せず、クライアントに直接送信されます。このプロセスはダイレクト サーバー リターン（DSR）といいます。

バックエンド サービスベースの外部パススルー ネットワーク ロードバランサは、次の機能をサポートしています。

  • マネージド インスタンス グループと非マネージド インスタンス グループのバックエンド。バックエンド サービスベースの外部パススルー ネットワーク ロードバランサは、バックエンドとしてマネージド インスタンス グループと非マネージド インスタンス グループの両方をサポートします。マネージド インスタンス グループはバックエンド管理の特定の側面を自動化し、非マネージド インスタンス グループよりもスケーラビリティと信頼性が向上します。
  • ゾーン NEG バックエンド。バックエンド サービスベースの外部パススルー ネットワーク ロードバランサは、GCE_VM_IP エンドポイントでのゾーン NEG の使用をサポートします。ゾーン NEG GCE_VM_IP エンドポイントを使用すると、次のことができます。
    • nic0 だけでなく、任意のネットワーク インターフェースにパケットを転送します。
    • 異なるバックエンド サービスに接続されている 2 つ以上のゾーン NEG に同じ GCE_VM_IP エンドポイントを配置します。
  • 複数のプロトコルのサポート。バックエンド サービスベースの外部パススルー ネットワーク ロードバランサは、TCP、UDP、ESP、GRE、ICMP、ICMPv6 トラフィックをロードバランスできます。
  • IPv6 接続のサポート。バックエンド サービスベースの外部パススルー ネットワーク ロードバランサは、IPv4 トラフィックと IPv6 トラフィックの両方を処理できます。
  • きめ細かいトラフィック分配の制御。バックエンド サービスを使用すると、構成されたセッション アフィニティ、接続トラッキング ポリシー、重み付きロード バランシング設定に従ってトラフィックを分配できます。コネクション ドレインを有効にして、ロードバランサのフェイルオーバー バックエンドを指定するように、バックエンド サービスを構成することもできます。これらの設定のほとんどにはデフォルト値が用意されているため、直ちに利用を開始できます。詳細については、外部パススルー ネットワーク ロードバランサのトラフィック分配をご覧ください。
  • 非レガシー ヘルスチェックのサポート。バックエンド サービスベースの外部パススルー ネットワーク ロードバランサでは、分散するトラフィックのタイプ（TCP、SSL、HTTP、HTTPS、HTTP/2）に一致するヘルスチェックを使用できます。
  • Google Cloud Armor のインテグレーション。Google Cloud Armor は、外部パススルー ネットワーク ロードバランサの高度なネットワーク DDoS 対策をサポートしています。詳細については、高度なネットワーク DDoS 対策を構成するをご覧ください。

  • GKE のインテグレーション。GKE でアプリケーションを構築する場合は、組み込みの GKE Service コントローラを使用することをおすすめします。このコントローラは GKE ユーザーに代わってGoogle Cloud ロードバランサをデプロイします。これは、このページで説明しているスタンドアロンのロード バランシング アーキテクチャと同じですが、ライフサイクルが GKE によって完全に自動化、制御される点で異なります。

    関連する GKE のドキュメント:

アーキテクチャ

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

リージョン バックエンド サービスを使用した外部パススルー ネットワーク ロードバランサ
リージョン バックエンド サービスを使用した外部パススルー ネットワーク ロードバランサ

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

  • 1 つ以上のリージョン外部 IP アドレス
  • 1 つ以上のリージョン外部転送ルール
  • 1 つのリージョン外部バックエンド サービス
  • 1 つ以上のバックエンド: すべてのインスタンス グループまたはすべてのゾーン NEG バックエンド（GCE_VM_IP エンドポイント）
  • バックエンド サービスに関連付けられたヘルスチェック

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

IP アドレス

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

  • IPv4 トラフィックの場合、転送ルールは単一のリージョン外部 IPv4 アドレスを参照します。リージョン外部 IPv4 アドレスは、各 Google Cloud リージョンに固有のプールから取得されます。IP アドレスには、予約済みの静的アドレスまたはエフェメラル アドレスを使用できます。

  • IPv6 トラフィックの場合、転送ルールはデュアルスタックまたは IPv6 のみ（プレビュー版）のサブネットの IPv6 アドレスの /96 範囲を参照します。サブネットには、VPC ネットワークに割り当てられた外部 IPv6 サブネット範囲が必要です。外部 IPv6 アドレスは、プレミアム ティアでのみ使用できます。

    IPv6 サポートの詳細については、VPC のドキュメントで IPv6 サブネット範囲と IPv6 アドレスに関する説明をご覧ください。

転送ルールを削除した後もプロジェクトに関連付けたアドレスを保持しておく必要がある場合や、同じ IP アドレスを参照する複数の転送ルールが必要な場合は、予約済み IP アドレスを使用します。

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

転送ルール

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

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

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

  • 転送ルールが IPv4 アドレスを参照している場合、転送ルールはサブネットに関連付けられません。その IP アドレスは、Google Cloud のサブネット範囲外にあります。

  • 転送ルールが /96 IPv6 アドレス範囲を参照している場合、転送ルールはサブネットに関連付けられている必要があります。また、このサブネットは（a）デュアルスタックで、（b）外部 IPv6 サブネット範囲（--ipv6-access-type が EXTERNAL に設定されているもの）を持つ必要があります。転送ルールが参照するサブネットは、バックエンド インスタンスで使用されるものと同じサブネットにできます。ただし、バックエンド インスタンスで別のサブネットを使用することもできます。バックエンド インスタンスが別のサブネットを使用する場合、次の条件を満たす必要があります。

外部パススルー ネットワーク ロードバランサには、少なくとも 1 つの転送ルールが必要です。転送ルールは、特定の範囲の送信元 IP アドレスからのトラフィックを特定のバックエンド サービス（またはターゲット インスタンス）に転送するように構成できます。詳細については、トラフィック ステアリングをご覧ください。複数の転送ルールで説明しているように、同じロードバランサに複数の転送ルールを定義できます。

ロードバランサに IPv4 と IPv6 の両方のトラフィックを処理する場合は、IPv4（またはデュアルスタック）バックエンドを指す IPv4 トラフィック用のルールと、デュアルスタック バックエンドのみを指す IPv6 トラフィック用のルールの 2 つの転送ルールを作成します。IPv4 と IPv6 の転送ルールが同じバックエンド サービスを参照できますが、バックエンド サービスがデュアルスタック バックエンドを参照する必要があります。

転送ルール プロトコル

外部パススルー ネットワーク ロードバランサは、転送ルールごとに TCP、UDP、L3_DEFAULT のプロトコル オプションをサポートしています。

TCP または UDP ロード バランシングを構成するには、TCP オプションと UDP オプションを使用します。L3_DEFAULT プロトコル オプションを使用すると、外部パススルー ネットワーク ロードバランサは TCP、UDP、ESP、GRE、ICMP、ICMPv6 のトラフィックをロードバランスできます。

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

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

L3_DEFAULT プロトコルを使用している場合は、すべてのポートでトラフィックを受け入れるように転送ルールを構成する必要があります。すべてのポートを構成するには、Google Cloud CLI を使用して --ports=ALL を設定するか、API を使用して allPorts を True に設定します。

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

ロードバランスされるトラフィック 転送ルール プロトコル バックエンド サービス プロトコル
TCP TCP TCP または UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP または UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP、GRE、ICMP / ICMPv6（echo リクエストのみ） L3_DEFAULT UNSPECIFIED

複数の転送ルール

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

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

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

Google Cloud では、受信パケットが複数の転送ルールに一致しないことが条件となります。次のセクションで説明するステアリング ルールを除き、同じリージョン外部 IP アドレスを使用する 2 つ以上の転送ルールには、制約に応じて一意のプロトコルとポートの組み合わせを設定する必要があります。

  • 1 つのプロトコルのすべてのポートに構成された転送ルールは、同じプロトコルと IP アドレスを使用する他の転送ルールが作成されないようにします。TCP プロトコルまたは UDP プロトコルを使用した転送ルールは、すべてのポートを使用するように構成することも、特定のポートに対して構成することもできます。たとえば、IP アドレス 198.51.100.1、TCP プロトコル、すべてのポートを使用して転送ルールを作成する場合、IP アドレス 198.51.100.1 と TCP プロトコルを使用して、他の転送ルールを作成することはできません。それぞれ一意のポートがあるか、重複しないポート範囲がある場合は、IP アドレス 198.51.100.1 と TCP プロトコルを使用して 2 つの転送ルールを作成できます。たとえば、IP アドレス 198.51.100.1 と TCP プロトコルを使用して 2 つの転送ルールを作成できますが、1 つの転送ルールのポートは 80,443 を使用し、もう 1 つはポート範囲 81-442 を使用します。
  • IP アドレスごとに作成可能な L3_DEFAULT 転送ルールは 1 つだけです。これは、L3_DEFAULT プロトコルが定義上すべてのポートを使用するためです。ここで、「すべてのポート」という用語にはポート情報のないプロトコルも含まれます。

  • 1 つの L3_DEFAULT 転送ルールは、特定のプロトコル（TCP または UDP）を使用する他の転送ルールと共存できます。L3_DEFAULT 転送ルールは、同じ IP アドレスを使用する転送ルールが存在するが、より具体的なプロトコルが存在する場合に、最後の手段として使用できます。L3_DEFAULT 転送ルールは、パケットの宛先 IP アドレス、プロトコル、宛先ポートがプロトコル固有の転送ルールと一致しない場合にのみ、宛先 IP アドレスに送信されるパケットを処理します。

    次の 2 つのシナリオについて考えてみましょう。どちらのシナリオでも、転送ルールは同じ IP アドレス 198.51.100.1 を使用します。

    • シナリオ 1. 最初の転送ルールは L3_DEFAULT プロトコルを使用します。2 つ目の転送ルールは、TCP プロトコルとすべてのポートを使用します。198.51.100.1 の宛先ポートに送信された TCP パケットは 2 番目の転送ルールによって処理されます。異なるプロトコルを使用するパケットは最初の転送ルールによって処理されます。
    • シナリオ 2. 最初の転送ルールは L3_DEFAULT プロトコルを使用します。2 つ目の転送ルールは、TCP プロトコルとポート 8080 を使用します。198.51.100.1:8080 に送信された TCP パケットは 2 番目の転送ルールによって処理されます。別の宛先ポートに送信された TCP パケットなど、他のパケットはすべて最初の転送ルールによって処理されます。

転送ルールの選択

Google Cloud は、次の除外プロセスを使用して、パケットの宛先 IP アドレスに一致する転送ルールの候補の中から、受信パケットを処理する 1 つまたは 0 個の転送ルールを選択します

  • L3_DEFAULT 転送ルールを除き、プロトコルがパケットのプロトコルと一致しない転送ルールを除外します。L3_DEFAULT プロトコルを使用した転送ルールは、L3_DEFAULT がすべてのプロトコルと一致するため、このステップで除外されることはありません。たとえば、パケットのプロトコルが TCP の場合、UDP プロトコルを使用する転送ルールのみが除外されます。

  • ポートがパケットのポートと一致しない転送ルールを除外します。すべてのポート転送ルールは任意のポートと一致するため、このステップですべてのポートに構成された転送ルールが除外されることはありません。

  • 残りの転送ルールの候補に L3_DEFAULT とプロトコル固有の転送ルールの両方が含まれている場合は、L3_DEFAULT 転送ルールを除外します。残りの転送ルールの候補がすべて L3_DEFAULT 転送ルールの場合、このステップでは何も除外されません。

  • この時点で、残りの転送ルールの候補は次のいずれかに分類されます。

    • パケットの宛先 IP アドレス、プロトコル、ポートに一致する単一の転送ルールが残り、パケットのルーティングに使用されます。
    • パケットの宛先 IP アドレス、プロトコル、ポートに一致する 2 つ以上の転送ルールの候補が残ります。残りの転送ルールの候補にはステアリング転送ルール（次のセクションで説明）が含まれています。パケットの送信元 IP アドレスを含む最も限定的な（最長のプレフィックス一致の）CIDR がソース範囲に含まれているステアリング転送ルールを選択します。パケットの送信元 IP アドレスを含むソース範囲を持つステアリング転送ルールがない場合、親転送ルールを選択します。
    • 転送ルールの候補は残り、パケットは破棄されます。

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

トラフィック ステアリング

外部パススルー ネットワーク ロードバランサの転送ルールは、特定の範囲の送信元 IP アドレスからのトラフィックを特定のバックエンド サービス（またはターゲット インスタンス）に転送するように構成できます。

トラフィック ステアリングは、トラブルシューティングや高度な構成に役立ちます。トラフィック ステアリングによって、特定のクライアントを異なるバックエンド セット、異なるバックエンド サービス構成、またはその両方に転送できます。例:

  • トラフィック ステアリングでは、2 つのバックエンド サービスを介して同じバックエンド（インスタンス グループまたは NEG）にトラフィックを転送する 2 つの転送ルールを作成できます。2 つのバックエンド サービスは、異なるヘルスチェック、異なるセッション アフィニティ、異なるトラフィック分散制御ポリシー（接続トラッキング、コネクション ドレイン、フェイルオーバー）を使用して構成できます。
  • トラフィック ステアリングを使用すると、低帯域幅のバックエンド サービスから高帯域幅のバックエンド サービスにトラフィックをリダイレクトする転送ルールを作成できます。両方のバックエンド サービスに同じバックエンド VM またはエンドポイントのセットが含まれていますが、重み付きロード バランシングで使用される重みが異なります。
  • トラフィック ステアリングを使用すると、異なるバックエンド（インスタンス グループまたは NEG）で異なるバックエンド サービスにトラフィックを転送する 2 つの転送ルールを作成できます。たとえば、特定の送信元 IP アドレスからのトラフィックを適切に処理するために、1 つのバックエンドを異なるマシンタイプで構成できます。

トラフィック ステアリングは、sourceIPRanges という転送ルール API パラメータを使用して構成します。1 つ以上のソース IP 範囲が構成された転送ルールは、ステアリング転送ルールと呼ばれます。

ステアリング転送ルールには、最大 64 個のソース IP 範囲を含むリストを指定できます。ステアリング転送ルール用に構成されたソース IP 範囲のリストはいつでも更新できます。

各ステアリング転送ルールでは、まず親転送ルールを作成する必要があります。親転送ルールとステアリング転送ルールは、同じリージョン外部 IP アドレス、IP プロトコル、ポート情報を共有します。ただし、親転送ルールには送信元 IP アドレスの情報はありません。例:

  • 親転送ルール: IP アドレス: 198.51.100.1、IP プロトコル: TCP、ポート: 80
  • ステアリング転送ルール: IP アドレス: 198.51.100.1、IP プロトコル: TCP、ポート: 80、sourceIPRanges: 203.0.113.0/24

バックエンド サービスを参照する親転送ルールは、バックエンド サービスまたはターゲット インスタンスを指すステアリング転送ルールに関連付けることができます。

特定の親転送ルールに対して、2 つ以上のステアリング転送ルールのソース IP 範囲が重複していますが、これらは同一ではありません。たとえば、1 つのステアリング転送ルールのソース IP 範囲を 203.0.113.0/24 に指定し、同じ親の別のステアリング転送ルールのソース IP 範囲を 203.0.113.0 に指定できます。

ステアリング転送ルールをすべて削除してから、それらに依存する親転送ルールを削除する必要があります。

転送ルールの使用時に受信パケットを処理する方法については、転送ルールの選択をご覧ください。

ステアリングの変更におけるセッション アフィニティの動作

このセクションでは、ステアリング転送ルールのソース IP 範囲が更新されたときに、セッション アフィニティが失われる可能性がある条件について説明します。

  • ステアリング転送ルールのソース IP 範囲を変更した後も、既存の接続が同じ転送ルールに一致し続けている場合、セッション アフィニティは失われません。変更により、既存の接続が異なる転送ルールと一致する場合は、次のようになります。
  • 次のような状況では、セッション アフィニティが失われます。
    • 新しく一致した転送ルールは、前に選択したバックエンド VM を参照しないバックエンド サービス（またはターゲット インスタンス）に確立された接続を転送します。
    • 新しく一致した転送ルールは、以前に選択したバックエンド VM を参照するバックエンド サービスに確立された接続を転送しますが、バックエンド サービスはバックエンドが異常なときに接続を継続するようには構成されておらず、バックエンド VM がバックエンド サービスのヘルスチェックに失敗します。
  • 新しく一致した転送ルールが、確立された接続をバックエンド サービスに転送したときに、バックエンド サービスが以前に選択した VM を参照していても、バックエンド サービスのセッション アフィニティと接続トラッキング モードの組み合わせによって別の接続トラッキング ハッシュが生成されると、セッション アフィニティが失われる可能性があります。

ステアリング変更時のセッション アフィニティの維持

このセクションでは、ステアリング転送ルールのソース IP 範囲が更新されたときに、セッション アフィニティの中断を回避する方法について説明します。

  • バックエンド サービスを参照するステアリング転送ルール親転送ルールとステアリング転送ルールの両方がバックエンド サービスを参照している場合、セッション アフィニティと接続トラッキング ポリシーの設定が一致するように手動で操作する必要があります。Google Cloud で、一致しない構成が自動的に拒否されることはありません。
  • ターゲット インスタンスを指す転送ルール。バックエンド サービスを参照する親転送ルールは、ターゲット インスタンスを参照するステアリング転送ルールに関連付けることができます。この場合、ステアリング転送ルールは親転送ルールからセッション アフィニティと接続トラッキング ポリシーの設定を継承します。

トラフィック ステアリングを構成する方法については、トラフィック ステアリングを構成するをご覧ください。

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

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

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

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

    外部パススルー ネットワーク ロードバランサで使用されるバックエンド サービスは、TCP、UDP、UNSPECIFIED のプロトコル オプションをサポートします。

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

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

  • トラフィック分散。バックエンド サービスを使用すると、構成されたセッション アフィニティ、接続トラッキング ポリシー、重み付きロード バランシング設定に従ってトラフィックを分配できます。コネクション ドレインを有効にして、ロードバランサのフェイルオーバー バックエンドを指定するように、バックエンド サービスを構成することもできます。これらの設定のほとんどにはデフォルト値が用意されているため、直ちに利用を開始できます。詳細については、外部パススルー ネットワーク ロードバランサのトラフィック分配をご覧ください。

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

  • バックエンド: 各バックエンド サービスは単一のリージョンで動作し、同じリージョン内のインスタンス グループまたはゾーン NEG にトラフィックを分散します。外部パススルー ネットワーク ロードバランサのバックエンドとして、インスタンス グループまたはゾーン NEG を使用できますが、両方を組み合わせることはできません。

    • インスタンス グループを選択した場合は、非マネージド インスタンス グループ、ゾーン マネージド インスタンス グループ、リージョン マネージド インスタンス グループ、またはインスタンス グループ タイプの組み合わせを使用できます。
    • ゾーン NEG を選択する場合は、GCE_VM_IP ゾーン NEG を使用する必要があります。

    各インスタンス グループまたは NEG バックエンドは、まだバックエンド サービスに接続されていない場合でも、関連付けられた VPC ネットワークが存在します。ネットワークが各タイプのバックエンドにどのように関連付けられているかについては、インスタンス グループのバックエンドとネットワーク インターフェースとゾーン NEG バックエンドとネットワーク インターフェースをご覧ください。

インスタンス グループ

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

外部パススルー ネットワーク ロードバランサは、バックエンド VM の最初のネットワーク インターフェース（nic0）にのみトラフィックを配信します。ロードバランサは、VPC ネットワークがバックエンド サービスと同じプロジェクトにある限り、メンバー インスタンスが同じリージョン内の VPC ネットワークを使用するインスタンス グループをサポートします（特定のインスタンス グループ内のすべての VM は同じ VPC ネットワークを使用する必要があります）。

各インスタンス グループは、まだバックエンド サービスに接続されていない場合でも、関連付けられた VPC ネットワークが存在します。ネットワークをインスタンス グループに関連付ける方法については、インスタンス グループのバックエンドとネットワーク インターフェースをご覧ください。

外部パススルー ネットワーク ロードバランサは、設計により高可用性を備えています。高可用性のメカニズムは単一のデバイスまたは VM インスタンスに依存しないため、ロードバランサの可用性を改善するために必要な特別な手順は存在しません。バックエンド VM インスタンスが複数のゾーンにデプロイされるようにすることのみによって、ロードバランサが任意のゾーンで潜在的な問題を回避できます。

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

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

    リージョン マネージド インスタンス グループを使用した外部パススルー ネットワーク ロードバランサ
    リージョン マネージド インスタンス グループを使用した外部パススルー ネットワーク ロードバランサ

  • ゾーン マネージド インスタンス グループまたは非マネージド インスタンス グループ。（同じリージョン内の）異なるゾーンのゾーン インスタンス グループを使用することで、特定のゾーンの潜在的な問題から保護します。

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

    ゾーン インスタンス グループを使用した外部パススルー ネットワーク ロードバランサ
    ゾーン インスタンス グループを使用した外部パススルー ネットワーク ロードバランサ

ゾーン NEG

外部パススルー ネットワーク ロードバランサは、ゾーン ネットワーク エンドポイント グループに含まれる GCE_VM_IP エンドポイント間で接続を分散します。これらのエンドポイントは、ロードバランサと同じリージョンに配置する必要があります。ゾーン NEG に推奨されるユースケースについては、ゾーン ネットワーク エンドポイント グループの概要をご覧ください。

NEG 内のエンドポイントは、ゾーン NEG と同じサブネットとゾーン内にある VM ネットワーク インターフェースのプライマリ内部 IPv4 アドレスである必要があります。マルチ NIC VM インスタンスのネットワーク インターフェースのプライマリ内部 IPv4 アドレスは、NEG のサブネット内であれば NEG に追加できます。

ゾーン NEG は、IPv4 とデュアルスタック（IPv4 と IPv6）の両方の VM をサポートします。IPv4 とデュアルスタック VM の場合、エンドポイントを NEG に接続するときに VM インスタンスのみを指定するだけで十分です。エンドポイントの IP アドレスを指定する必要はありません。VM インスタンスは、常に NEG と同じゾーンに配置する必要があります。

各ゾーン NEG には、まだバックエンド サービスに接続されていない場合でも、関連付けられた VPC ネットワークとサブネットがあります。ネットワークをゾーン NEG に関連付ける方法については、ゾーン NEG バックエンドとネットワーク インターフェースをご覧ください。

インスタンス グループのバックエンドとネットワーク インターフェース

インスタンス グループに関連付けられた VPC ネットワークは、すべてのメンバー VM の nic0 ネットワーク インターフェースで使用される VPC ネットワークです。

  • マネージド インスタンス グループ（MIG）の場合、インスタンス グループの VPC ネットワークがインスタンス テンプレートで定義されています。
  • 非マネージド インスタンス グループの場合、インスタンス グループの VPC ネットワークは、非マネージド インスタンス グループに追加する最初の VM インスタンスの nic0 ネットワーク インターフェースで使用される VPC ネットワークとして定義されます。

特定の（マネージドまたは非マネージド）インスタンス グループ内で、すべての VM インスタンスの nic0 ネットワーク インターフェースが同じ VPC ネットワークに存在している必要があります。各メンバー VM は、追加のネットワーク インターフェース（nic1～nic7）を持つこともできますが、各ネットワーク インターフェースは異なる VPC ネットワークに接続する必要があります。これらのネットワークは、インスタンス グループに関連付けられた VPC ネットワークとは異なる必要があります。

バックエンド サービスは、nic0 以外のインターフェースのインスタンス グループ メンバーの VM にトラフィックを分散できません。デフォルト以外のネットワーク インターフェース（nic1～nic7）を定義するには、GCE_VM_IP エンドポイントを含むゾーン NEG を使用する必要があります。

ゾーン NEG バックエンドとネットワーク インターフェース

GCE_VM_IP エンドポイントを含む新しいゾーン NEG を作成する場合は、NEG にエンドポイントを追加する前に、NEG を VPC ネットワークのサブネットワークに明示的に関連付ける必要があります。NEG の作成後にサブネットと VPC ネットワークを変更することはできません。

特定の NEG 内では、各 GCE_VM_IP エンドポイントは実際にはネットワーク インターフェースを表します。ネットワーク インターフェースは、NEG に関連付けられたサブネットワークに存在する必要があります。Compute Engine インスタンスの観点から、ネットワーク インターフェースは任意の識別子（nic0 から nic7）を使用できます。NEG のエンドポイントであるという観点から、ネットワーク インターフェースはプライマリ IPv4 アドレスを使用することで識別されます。

GCE_VM_IP エンドポイントを NEG に追加するには、次の 2 つの方法があります。

  • エンドポイントを追加するときに VM 名のみ（IP アドレスなし）を指定する場合、 Google Cloud では NEG に関連付けられたサブネットワーク内に VM のネットワーク インターフェースが存在している必要があります。 Google Cloudがエンドポイントに選択する IP アドレスは、サブネットワーク内で NEG に関連付けられた VM のネットワーク インターフェースのプライマリ内部 IPv4 アドレスです
  • エンドポイントを追加するときに VM 名と IP アドレスの両方を指定する場合は、指定する IP アドレスは、VM のネットワーク インターフェースのいずれかのプライマリ内部 IPv4 アドレスにする必要があります。このネットワーク インターフェースは、NEG に関連付けられたサブネットワーク内に存在する必要があります。NEG に関連付けられたサブネットには 1 つのネットワーク インターフェースしか存在しないため、IP アドレスを指定しても冗長になります。

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

バックエンド サービスは VPC ネットワークに関連付けられていませんが、前述のように、各バックエンド インスタンス グループまたはゾーン NEG は VPC ネットワークに関連付けられています。すべてのバックエンドが同じリージョンとプロジェクトにあり、すべてのバックエンドが同じタイプ（インスタンス グループまたはゾーン NEG）である限り、同じまたは異なる VPC ネットワークを使用するバックエンドを追加できます。

nic0 以外のインターフェースにパケットを配信するには、ゾーン NEG バックエンド（GCE_VM_IP エンドポイントを使用）を使用する必要があります。

デュアルスタック バックエンド（IPv4 と IPv6）

ロードバランサが IPv4 トラフィックと IPv6 トラフィックの両方を処理するデュアルスタック バックエンドを使用する場合は、次の要件に注意してください。

  • バックエンドは、ロードバランサの IPv6 転送ルールと同じリージョンにあるデュアルスタックのサブネットで構成する必要があります。バックエンドでは、ipv6-access-type が EXTERNAL または INTERNAL に設定されたサブネットを使用できます。バックエンド サブネットの ipv6-access-type が INTERNAL に設定されている場合は、ロードバランサの外部転送ルールに、ipv6-access-type が EXTERNAL に設定された異なる IPv6 のみのサブネットを使用する必要があります。
  • バックエンドは、stack-type を IPv4_IPv6 に設定してデュアルスタックとして構成する必要があります。バックエンド サブネットの ipv6-access-type が EXTERNAL に設定されている場合は、--ipv6-network-tier も PREMIUM に設定する必要があります。手順については、IPv6 アドレスを持つインスタンス テンプレートを作成するをご覧ください。

IPv6 のみのバックエンド

ロードバランサで IPv6 のみのバックエンドを使用する場合は、次の要件に注意してください。

  • IPv6 のみのインスタンスは、非マネージド インスタンス グループでのみサポートされます。他のバックエンド タイプはサポートされていません。
  • バックエンドは、ロードバランサの IPv6 転送ルールと同じリージョンにあるデュアルスタックまたは IPv6 のみのサブネットで構成する必要があります。バックエンドでは、ipv6-access-type が INTERNAL または EXTERNAL に設定されたサブネットを使用できます。バックエンド サブネットの ipv6-access-type が INTERNAL に設定されている場合は、ロードバランサの外部転送ルールに、ipv6-access-type が EXTERNAL に設定された異なる IPv6 のみのサブネットを使用する必要があります。
  • バックエンドは、VM stack-type を IPv6_ONLY に設定して IPv6 のみとして構成する必要があります。バックエンド サブネットの ipv6-access-type が EXTERNAL に設定されている場合は、--ipv6-network-tier も PREMIUM に設定する必要があります。手順については、IPv6 アドレスを持つインスタンス テンプレートを作成するをご覧ください。

IPv6 のみの VM は、デュアルスタック サブネットと IPv6 のみのサブネットの両方で作成できますが、デュアルスタック VM は IPv6 のみのサブネットで作成できません。

ヘルスチェック

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

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、GRE、ICMP はコネクションレスです。バックエンド VM は、送信元 IP アドレスが転送ルールの IP アドレスまたは VM に割り当てられた外部 IP アドレスと一致するレスポンス パケットを送信できます。ほとんどのクライアントは、パケットの送信元と同じ IP アドレスからのレスポンスを想定しています。

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

トラフィックの種類 送信元 宛先
TCP ロードバランサの転送ルールの IP アドレス リクエスト パケットの送信元
UDP、ESP、GRE、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 といいます。

バックエンドからのアウトバウンド インターネット接続

外部パススルー ネットワーク ロードバランサのバックエンド エンドポイントとして構成された VM インスタンスは、ロードバランサの転送ルールの IP アドレスをアウトバウンド接続の送信元 IP アドレスとして使用して、インターネットへの接続を開始できます。

通常、VM インスタンスは常に独自の外部 IP アドレスまたは Cloud NAT を使用して接続を開始します。転送ルールの IP アドレスは、VM インスタンスが同じ外部 IP アドレスで接続を開始して受信する必要がある場合や、外部パススルー ネットワーク ロードバランサによって提供されるバックエンド冗長性が必要なインバウンド接続の場合などの特別なシナリオでのみ、バックエンド エンドポイントから接続を開始するために使用します。

バックエンド VM からインターネットに直接送信されるアウトバウンド パケットには、トラフィック プロトコルとポートの制限はありません。アウトバウンド パケットが転送ルールの IP アドレスを送信元として使用している場合でも、パケットのプロトコルと送信元ポートが、転送ルールのプロトコルとポートの仕様に一致する必要はありません。ただし、インバウンド レスポンス パケットは、転送ルールの転送ルール IP アドレス、プロトコル、宛先ポートと一致する必要があります。詳細については、外部パススルー ネットワーク ロードバランサと外部プロトコル転送のためのパスをご覧ください。

また、ロードバランサ宛ての他のすべての受信パケットと同様に、VM のアウトバウンド接続へのレスポンスもロード バランシングの影響を受けます。つまり、インターネットへの接続を開始したバックエンド VM にレスポンスが届かない可能性があります。アウトバウンド接続とロードバランスされたインバウンド接続が共通のプロトコルとポートを共有している場合は、次のいずれかをお試しください。

  • バックエンド VM 間でアウトバウンド接続状態を同期します。これにより、接続を開始したバックエンド VM 以外のバックエンド VM にレスポンスが到着した場合でも、接続を処理できます。

  • 1 つのプライマリ VM と 1 つのバックアップ VM を使用して、フェイルオーバーを構成します。これにより、アウトバウンド接続を開始するアクティブなバックエンド VM が常にレスポンス パケットを受信します。

外部パススルー ネットワーク ロードバランサのバックエンドからインターネット接続へのこのパスは、 Google Cloudの暗黙的なファイアウォール ルールに従って、デフォルトの動作となります。ただし、このパスを開いたままにしておくことによるセキュリティ上の懸念がある場合は、ターゲットを絞った下り（外向き）ファイアウォール ルールを使用して、インターネットへの不要なアウトバウンド トラフィックをブロックできます。

共有 VPC アーキテクチャ

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

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

リージョン バックエンド サービスは、バックエンド（インスタンス グループまたはゾーン NEG）と同じプロジェクトと同じリージョンで定義する必要があります。

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

トラフィック分配

外部パススルー ネットワーク ロードバランサは、セッション アフィニティ、接続トラッキング、重み付きロード バランシング、フェイルオーバーなど、さまざまなトラフィック分配カスタマイズ オプションをサポートしています。外部パススルー ネットワーク ロードバランサがトラフィックを分散する方法と、これらのオプションが相互にどのように作用するかについては、外部パススルー ネットワーク ロードバランサのトラフィック分配をご覧ください。

制限事項

  • Google Cloud コンソールを使用して次のタスクを行うことはできません。

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

    代わりに、Google Cloud CLI または REST API を使用してください。

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

料金

料金については、こちらをご覧ください。

次のステップ