外部パススルー ネットワーク ロードバランサは、ロードバランサと同じリージョン内のバックエンド（インスタンス グループまたはネットワーク エンドポイント グループ（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 の使用をサポートします。ゾーン NEGGCE_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 トラフィックの場合、転送ルールは、VPC ネットワーク内の外部 IPv6 サブネット範囲を持つデュアルスタック サブネットの
/96範囲を参照します。外部 IPv6 アドレスは、プレミアム ティアでのみ使用できます。IPv6 アドレス範囲には、予約済み静的アドレスまたはエフェメラル アドレスを使用できます。
転送ルールを削除した後もプロジェクトに関連付けたアドレスを保持しておく必要がある場合や、同じ IP アドレスを参照する複数の転送ルールが必要な場合は、予約済み IP アドレスを使用します。
外部パススルー ネットワーク ロードバランサは、スタンダード ティアとプレミアム ティアの両方のリージョン外部 IPv4 アドレスに対応しています。IP アドレスと転送ルールはどちらも同じネットワーク階層を使用する必要があります。リージョン外部 IPv6 アドレスは、プレミアム ティアでのみ使用できます。
転送ルール
リージョン外部転送ルールは、ロードバランサがトラフィックを受け入れるプロトコルとポートを指定します。外部パススルー ネットワーク ロードバランサはプロキシではありません。パケットにポート情報が含まれている場合は、同じプロトコルとポートでバックエンドにトラフィックを転送します。転送ルールと IP アドレスの組み合わせにより、ロードバランサのフロントエンドが形成されます。
ロードバランサは受信パケットの送信元 IP アドレスを保持します。受信パケットの宛先 IP アドレスは、ロードバランサの転送ルールに関連付けられた IP アドレスです。
受信トラフィックは転送ルール（特定の IP アドレス（IPv4 アドレスまたは IPv6 アドレス範囲）とプロトコル）と照合されます。プロトコルがポートベースの場合は、ポート、ポート範囲、またはすべてのポートと照合されます。その後、この転送ルールによって、ロードバランサのバックエンド サービスにトラフィックが転送されます。
転送ルールが IPv4 アドレスを参照している場合、転送ルールはサブネットに関連付けられません。その IP アドレスは、Google Cloud のサブネット範囲外にあります。
転送ルールが
/96IPv6 アドレス範囲を参照している場合、転送ルールはサブネットに関連付けられている必要があります。また、このサブネットは（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 パケットなど、他のパケットはすべて最初の転送ルールによって処理されます。
- シナリオ 1. 最初の転送ルールは
転送ルールの選択
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、ソース IPRanges: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 アドレスなし）を指定する場合、NEG に関連付けられたサブネットワーク内に VM のネットワーク インターフェースが存在している必要があります。Google Cloud がエンドポイントに選択する IP アドレスは、サブネットワーク内で NEG に関連付けられた VM のネットワーク インターフェースのプライマリ内部 IPv4 アドレスです。
- エンドポイントを追加するときに VM 名と IP アドレスの両方を指定する場合は、指定する IP アドレスは、VM のネットワーク インターフェースのいずれかのプライマリ内部 IPv4 アドレスにする必要があります。このネットワーク インターフェースは、NEG に関連付けられたサブネットワーク内に存在する必要があります。NEG に関連付けられたサブネットには 1 つのネットワーク インターフェースしか存在しないため、IP アドレスを指定しても冗長になります。
バックエンド サービスと VPC ネットワーク
バックエンド サービスは VPC ネットワークに関連付けられていませんが、前述のように、各バックエンド インスタンス グループまたはゾーン NEG は VPC ネットワークに関連付けられています。すべてのバックエンドが同じリージョンとプロジェクトにあり、すべてのバックエンドが同じタイプ（インスタンス グループまたはゾーン NEG）である限り、同じまたは異なる VPC ネットワークを使用するバックエンドを追加できます。
nic7 を介して nic1 にパケットを配信するには、（GCE_VM_IP エンドポイントを含む）ゾーン NEG バックエンドを使用する必要があります。これは、インスタンス グループに関連付けられた VPC ネットワークは、すべてのメンバー インスタンスの nic0 インターフェースによって使用される VPC ネットワークと常に一致するためです。
デュアルスタック バックエンド（IPv4 と IPv6）
ロードバランサが IPv6 トラフィックをサポートするには、バックエンドが次の要件を満たしている必要があります。
- バックエンドは、ロードバランサの IPv6 転送ルールと同じリージョンにあるデュアルスタックのサブネットで構成する必要があります。バックエンドでは、
ipv6-access-typeがEXTERNALまたはINTERNALに設定されたサブネットを使用できます。ipv6-access-typeがINTERNALに設定されたサブネットを使用するには、ロードバランサの外部転送ルールに、ipv6-access-typeがEXTERNALに設定された個別のデュアルスタック サブネットを使用する必要があります。手順については、デュアルスタックのサブネットを追加するをご覧ください。 - バックエンドは、
--ipv6-network-tierをPREMIUMに設定してデュアルスタックとして構成する必要があります。手順については、IPv6 アドレスを持つインスタンス テンプレートを作成するをご覧ください。
ヘルスチェック
外部パススルー ネットワーク ロードバランサは、リージョン ヘルスチェックを使用して、新しい接続を受け取れるインスタンスを決定します。各外部パススルー ネットワーク ロードバランサのバックエンド サービスは、リージョン ヘルスチェックに関連付ける必要があります。ロードバランサは、ヘルスチェック ステータスを使用して、バックエンド インスタンスに新しい接続を転送する方法を決定します。
Google Cloud ヘルスチェックの仕組みの詳細については、ヘルスチェックの仕組みをご覧ください。
外部パススルー ネットワーク ロードバランサは、次のタイプのヘルスチェックをサポートしています。
- HTTP、HTTPS、HTTP/2。バックエンド VM が HTTP、HTTPS、または HTTP/2 を使用してトラフィックを処理する場合、そのプロトコルと一致するヘルスチェックの使用をおすすめします。詳細については、HTTP、HTTPS、HTTP/2 ヘルスチェックの正常終了の条件をご覧ください。
- SSL または TCP。バックエンド VM が HTTP タイプのトラフィックを処理しない場合は、SSL または TCP のヘルスチェックを使用する必要があります。詳しくは、SSL および TCP ヘルスチェックの正常終了の条件をご覧ください。
他のプロトコルのトラフィックに対するヘルスチェック
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 といいます。
共有 VPC アーキテクチャ
IP アドレスを除き、外部パススルー ネットワーク ロードバランサのすべてのコンポーネントは同じプロジェクト内に存在する必要があります。次の表は、外部パススルー ネットワーク ロードバランサの共有 VPC コンポーネントをまとめたものです。
| IP アドレス | 転送ルール | バックエンド コンポーネント |
|---|---|---|
| リージョン外部 IP アドレスは、ロードバランサまたは共有 VPC ホスト プロジェクトと同じプロジェクトで定義する必要があります。 | リージョンの外部転送ルールは、バックエンド サービスのインスタンスと同じプロジェクトで定義する必要があります。 | リージョン バックエンド サービスは、バックエンド（インスタンス グループまたはゾーン NEG）と同じプロジェクトと同じリージョンで定義する必要があります。 バックエンド サービスに関連するヘルスチェックは、バックエンド サービスと同じプロジェクトとリージョンで定義する必要があります。 |
トラフィック分散
外部パススルー ネットワーク ロードバランサによる新しい接続の分散方法は、フェイルオーバーを構成しているかどうかによって異なります。
- フェイルオーバーを構成していない場合、少なくとも 1 つのバックエンド VM が正常であれば、外部パススルー ネットワーク ロードバランサによって正常なバックエンド VM に新しい接続が分散されます。すべてのバックエンド VM が正常でない場合は、最後の手段としてロードバランサによりすべてのバックエンドの間で新しい接続が分散されます。この場合、ロードバランサにより正常でないバックエンド VM にそれぞれ新しい接続が転送されます。
- フェイルオーバーを構成している場合は、構成したフェイルオーバー ポリシーに従って、外部パススルー ネットワーク ロードバランサによってアクティブ プール内の正常なバックエンド VM 間での新しい接続が分散されます。すべてのバックエンド VM が正常でない場合は、次の動作の中からいずれかを選択できます。
- （デフォルト）ロードバランサは、プライマリ VM にのみトラフィックを分散します。これは最後の手段です。バックアップ VM は、この最後の接続分散から除外されます。
- ロードバランサはトラフィックをドロップします。
接続の分散方法の詳細については、次のセクションのバックエンドの選択と接続トラッキングをご覧ください。
フェイルオーバーの機能の詳細については、フェイルオーバーのセクションをご覧ください。
バックエンドの選択と接続トラッキング
外部パススルー ネットワーク ロードバランサでは、構成可能なバックエンドの選択と接続トラッキング アルゴリズムを使用して、トラフィックをバックエンド VM に分散する方法が決定されます。
外部パススルー ネットワーク ロードバランサでは、次のアルゴリズムを使用して、（フェイルオーバーを構成している場合は、アクティブ プール内の）バックエンド VM 間にパケットが分散されます。
- ロードバランサに、受信パケットの特性と一致する接続トラッキング テーブルがある場合、パケットは接続トラッキング テーブルのエントリで指定されたバックエンドに送信されます。パケットは、以前に確立した接続の一部と見なされるため、ロードバランサによって接続トラッキング テーブルに以前に決定され記録されたバックエンド VM に送信されます。
ロードバランサで対応する接続トラッキング エントリがないパケットを受信した場合、ロードバランサでは次が行われます。
ロードバランサでバックエンドが選択されます。 ロードバランサは、構成されたセッション アフィニティに基づいてハッシュを計算します。ロードバランサは、このハッシュを使用して、正常な状態のバックエンドの中からバックエンドを 1 つ選択します（ただし、すべてのバックエンドが異常な状態である場合を除きます。その場合は、この状況でフェイルオーバー ポリシーがトラフィックをドロップするように構成されていない限り、すべてのバックエンドが考慮されます）。デフォルトのセッション アフィニティ
NONEでは、次のハッシュ アルゴリズムが使用されます。- TCP パケットと断片化されていない UDP パケットの場合、パケットの送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート、プロトコルの 5 タプルハッシュ
- 断片化された UDP パケットと他のすべてのプロトコルの場合、パケットの送信元 IP アドレス、宛先 IP アドレス、プロトコルの 3 タプルハッシュ
バックエンドの選択は、使用する情報が少ないハッシュ アルゴリズムを使用してカスタマイズできます。サポートされているすべてのオプションについては、セッション アフィニティのオプションをご覧ください。
さらに、次の点に留意してください。
重み付き負荷分散を有効にすると、ハッシュベースのバックエンド選択はバックエンド インスタンスから報告された重みに基づいて重み付けされます。次に例を示します。
- セッション アフィニティが
NONEに構成されたバックエンド サービスと、プロトコルUDPの転送ルールについて考えてみましょう。重み 1 と 4 の正常なバックエンド インスタンスが 2 つある場合、バックエンドはそれぞれ UDP パケットの 20% と 80% を受信します。 - 3 タプルのセッション アフィニティと接続トラッキングで構成されているバックエンド サービスについて考えてみましょう。セッション アフィニティは
CLIENT_IP_PROTOで、接続トラッキング モードはPER_SESSIONです。重みが 0、2、6 の正常なバックエンド インスタンスが 3 つある場合、バックエンドはそれぞれ新しいソース IP アドレス (既存の接続トラッキングテーブルエントリがないソース IP アドレス) の 0%、25%、75% のトラフィックを取得します。既存の接続トラフィックは、以前に割り当てられたバックエンドに送信されます。
ロードバランサにより、接続トラッキング テーブルにエントリが追加されます。このエントリによって、パケット接続用に選択されたバックエンドが記録されるため、この接続からの以降のパケットがすべて同じバックエンドに送信されます。接続トラッキングを使用するかどうかは、プロトコルによって異なります。
TCP パケット。接続トラッキングは常に有効になっています。オフにすることはできません。デフォルトでは、接続トラッキングは 5 タプルですが、5 タプル未満に構成することもできます。5 タプルの場合、TCP SYN パケットは異なる方法で処理されます。SYN 以外のパケットとは異なり、一致する接続トラッキング エントリを破棄し、常に新しいバックエンドを選択します。
デフォルトの 5 タプル接続トラッキングは、次の場合に使用されます。- トラッキング モードが
PER_CONNECTION（すべてのセッション アフィニティ）の場合。または、 - トラッキング モードが
PER_SESSIONでセッション アフィニティがNONEの場合。または、 - トラッキング モードが
PER_SESSIONであり、セッション アフィニティがCLIENT_IP_PORT_PROTOの場合。
- トラッキング モードが
UDP、ESP、GRE パケット。接続トラッキングは、セッション アフィニティが
NONE以外に設定されている場合にのみ有効になります。ICMP パケットと ICMPv6 パケット。接続トラッキングは使用できません。
接続トラッキングが有効にされている場合と、接続トラッキングが有効な場合のトラッキング方法の詳細については、接続トラッキング モードをご覧ください。
さらに、次の点に留意してください。
- 接続トラッキング テーブル内のエントリは、ロードバランサがエントリに一致した最後のパケットを処理してから 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、GRE トラフィックで、選択したセッション アフィニティがNONE以外の場合は、接続トラッキングが有効になります。UDP、ESP、GRE パケットは、こちらの表で説明されているトラッキング方法で追跡されます。PER_SESSION。セッション アフィニティがCLIENT_IPまたはCLIENT_IP_PROTOの場合にこのモードを構成すると、（トラッキング可能な接続ではない ICMP と ICMPv6 を除く）すべてのプロトコルに対して、それぞれ 2 タプルと 3 タプルの接続トラッキングが行われます。他のセッション アフィニティの設定の場合、PER_SESSIONモードの動作はPER_CONNECTIONモードとまったく同じです。
プロトコルごとに異なるセッション アフィニティが設定されているこれらのトラッキング モードの動作については、次の表をご覧ください。
| バックエンドの選択 | 接続トラッキング モード | ||
|---|---|---|---|
| セッション アフィニティの設定 | バックエンド選択のハッシュ方法 | PER_CONNECTION（デフォルト） |
PER_SESSION |
| デフォルト: セッション アフィニティなし （ |
TCP と断片化されていない UDP: 5 タプルハッシュ 断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ |
|
|
| クライアント IP、宛先 IP （ |
すべてのプロトコル: 2 タプルハッシュ |
|
|
| クライアント IP、宛先 IP、プロトコル （ |
すべてのプロトコル: 3 タプルハッシュ |
|
|
| クライアント IP、クライアント ポート、宛先 IP、宛先ポート、プロトコル （ |
TCP と断片化されていない UDP: 5 タプルハッシュ 断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ |
|
|
接続トラッキング モードを変更する方法については、接続トラッキング ポリシーの設定をご覧ください。
異常なバックエンドでの接続の永続性
バックエンドが異常な状態になった後も、選択した VM またはバックエンドで既存の接続を維持するかどうかは、バックエンドがロードバランサの構成済みバックエンド インスタンス グループ（インスタンス グループまたは NEG）に残っている限り、接続の永続性の設定で制御します。
このセクションで説明する動作は、インスタンス グループからバックエンド インスタンスを削除する場合、NEG からバックエンド エンドポイントを削除する場合、バックエンド サービスからインスタンス グループまたは NEG を削除する場合には該当しません。このような場合、確立された接続はコネクション ドレインで説明されている内容に基づいてのみ維持されます。
使用できる接続の永続性に関するオプションは次のとおりです。
DEFAULT_FOR_PROTOCOL（デフォルト）NEVER_PERSISTALWAYS_PERSIST
次の表には、接続の永続性のオプションと、さまざまなプロトコル、セッション アフィニティのオプション、トラッキング モードのために接続を維持する方法がまとめられています。
| 異常なバックエンド オプションでの接続の永続性 | 接続トラッキング モード | |
|---|---|---|
PER_CONNECTION |
PER_SESSION |
|
DEFAULT_FOR_PROTOCOL |
TCP: 異常なバックエンドで接続が維持されます（すべてのセッション アフィニティ） 他のすべてのプロトコル: 異常なバックエンドでは接続が維持されることはありません |
TCP: セッション アフィニティが 他のすべてのプロトコル: 異常なバックエンドでは接続が維持されることはありません |
NEVER_PERSIST |
すべてのプロトコル: 異常なバックエンドでは接続が維持されることはありません | |
ALWAYS_PERSIST |
TCP: 異常なバックエンドで接続が維持されます（すべてのセッション アフィニティ） ESP、GRE、UDP: セッション アフィニティが ICMP、ICMPv6: 接続トラッキングできないため、対象外です。 このオプションは、高度なユースケースにのみ使用してください。 |
設定が不可能 |
異常なバックエンドでの TCP 接続の永続性の動作
正常でないバックエンドで 5 タプル トラッキングの TCP 接続が維持される場合は常時:
- 異常なバックエンドがパケットに引き続き応答する場合、接続がリセットされるか、（異常なバックエンドまたはクライアントによって）クローズされるまで、接続は維持されます。
- 正常でないバックエンドが TCP リセット（RST）パケットを送信するか、パケットに応答しない場合、クライアントは新しい接続で再試行するため、ロードバランサは別の正常なバックエンドを選択できます。TCP SYN パケットは常に新しい正常なバックエンドを選択します。
接続の永続性の動作を変更する方法については、接続トラッキング ポリシーを構成するをご覧ください。
アイドル タイムアウト
接続トラッキング テーブル内のエントリは、ロードバランサがエントリに一致した最後のパケットを処理してから 60 秒後に失効します。このアイドル タイムアウト値は変更できません。
重み付きロード バランシング
重み付きロード バランシングを使用して、HTTP ヘルスチェックから報告された重みに基づいてロードバランサのバックエンド インスタンス間でトラフィックを分散するようにネットワーク ロードバランサを構成できます。
重み付き負荷分散では、次の両方を構成する必要があります。
- バックエンド サービスの局所的なロードバランサ ポリシー（
localityLbPolicy）をWEIGHTED_MAGLEVに設定する必要があります。 - バックエンド サービスで HTTP ヘルスチェックを構成する必要があります。HTTP ヘルスチェック レスポンスには、カスタム HTTP レスポンス ヘッダー フィールド
X-Load-Balancing-Endpoint-Weightが含まれている必要があります。これにより、0から1000までの値を使用して、各バックエンド インスタンスの重み付けを指定できます。
重み付きロード バランシングを使用して、バックエンド サービスベースの複数のバックエンド サービスベースの外部パススルー ネットワーク ロードバランサに同じバックエンド（インスタンス グループまたは NEG）を使用する場合は、バックエンド サービスのヘルスチェックごとに一意の request-path を使用することをおすすめします。これにより、エンドポイント インスタンスは異なるバックエンド サービスに異なる重みを割り当てることができます。詳細については、HTTP、HTTPS、HTTP/2 ヘルスチェックの成功基準をご覧ください。
新しい接続のバックエンドを選択する場合、次の表に示すように、バックエンドには重みとヘルス ステータスに基づいて、厳密な優先順位が割り当てられます。
| 重み | 正常 | バックエンド選択の優先度 |
|---|---|---|
| 重みが 0 より大きい | ○ | 4 |
| 重みが 0 より大きい | × | 3 |
| 重みが 0 に等しい | ○ | 2 |
| 重みが 0 に等しい | × | 1 |
優先度が最も高いバックエンドのみがバックエンドの選択対象となります。対象となるすべてのバックエンドの重みが 0 の場合、ロードバランサはすべての適格なバックエンド間で新しい接続を分散し、同等の重みで扱います。重み付き負荷分散の例については、バックエンドの選択と接続トラッキングをご覧ください。
重み付き負荷分散は、次のシナリオで使用できます。
一部の接続が他の接続よりも多くのデータを処理する場合や、一部の接続が他の接続よりも長く存続する場合、バックエンドのロード バランシングが不均等になる可能性があります。インスタンスごとの重みが低いことを通知することで、既存の接続の処理を継続しながら、負荷の高いインスタンスで新しい接続のシェアを下げることができます。
バックエンドが過負荷状態になり、より多くの接続を割り当てると既存の接続が切断される可能性があります。このようなバックエンドは、ゼロの重みを割り当てます。重み 0 を通知することで、バックエンド インスタンスは新しい接続の処理を停止しますが、既存の接続の処理は継続します。
メンテナンスの前にバックエンドで既存の接続がドレインされると、バックエンドには重み 0 が割り当てられます。重みゼロを通知することで、バックエンド インスタンスは新しい接続の処理を停止しますが、既存の接続の処理は継続します。
詳細については、重み付き負荷分散を構成するをご覧ください。
コネクション ドレイン
コネクション ドレインは、次の場合に確立済みの接続に適用されるプロセスです。
- VM またはエンドポイントがバックエンド（インスタンス グループまたは NEG）から削除された場合。
- バックエンドが VM またはエンドポイントを削除する場合（置換、放棄、ローリング アップグレード、スケールダウンにより）。
- バックエンドがバックエンド サービスから削除された場合。
デフォルトでは、コネクション ドレインは無効になっています。無効にすると、確立された接続はできる限り早く終了します。コネクション ドレインを有効にすると、確立された接続は設定可能なタイムアウトまで維持され、その時間が経過するとバックエンド VM インスタンスは終端されます。
コネクション ドレインのトリガーとコネクション ドレインを有効にする方法の詳細については、コネクション ドレインの有効化をご覧ください。
UDP の断片化
バックエンド サービスベースの外部パススルー ネットワーク ロードバランサは、断片化された UDP パケットと断片化されていない UDP パケットの両方を処理できます。断片化された UDP パケットをアプリケーションで使用する場合は、次の点に留意してください。
- UDP パケットは Google Cloud VPC ネットワークに到達する前に断片化される場合があります。
- Google Cloud VPC ネットワークでは、到達した UDP フラグメントが（すべてのフラグメントの到達を待たずに）転送されます。
- Google Cloud 以外のネットワークとオンプレミス ネットワーク機器では、UDP フラグメントが到達すると転送される可能性、すべてのフラグメントが到達するまで断片化された UDP パケットが遅延される可能性、または断片化された UDP パケットが破棄される可能性があります。 詳しくは、ネットワーク プロバイダまたはネットワーク機器のドキュメントをご覧ください。
断片化された UDP パケットを処理する可能性があり、それを同じバックエンドにルーティングする必要がある場合は、次の転送ルールとバックエンド サービスの構成パラメータを使用します。
転送ルールの構成: 負荷分散された IP アドレスごとに
UDPまたはL3_DEFAULT転送ルールを 1 つだけ使用し、すべてのポートでトラフィックを受信するように転送ルールを構成します。これで、すべてのフラグメントが同じ転送ルールに渡されるようになります。断片化されたパケット（最初のフラグメント以外）には宛先ポートがありませんが、すべてのポートのトラフィックを処理する転送ルールを構成すると、ポート情報がない UDP フラグメントも受信するように構成されます。すべてのポートを構成するには、Google Cloud CLI を使用して--ports=ALLを設定するか、API を使用してallPortsをTrueに設定します。バックエンド サービスの構成: バックエンド サービスのセッション アフィニティを
CLIENT_IP（2 タプルハッシュ）またはCLIENT_IP_PROTO（3 タプルハッシュ）に設定し、ポート情報を含む UDP パケットとポート情報がない UDP フラグメント（最初のフラグメント以外）に同じポートが選択されるようにします。バックエンド サービスの接続トラッキング モードをPER_SESSIONに設定して、接続トラッキング テーブルのエントリが同じ 2 タプルハッシュまたは 3 タプルハッシュを使用して構築されるようにします。
ターゲット インスタンスをバックエンドとして使用する
外部パススルー ネットワーク ロードバランサのバックエンドとしてターゲット インスタンスを使用していて、UDP パケットの断片化が想定される場合、IP アドレスごとに UDP または L3_DEFAULT 転送ルールを 1 つだけ使用して、すべてのポートでトラフィックを受け入れるように転送ルールを構成します。これにより、同じ宛先ポートがない場合でも、すべてのフラグメントが同じ転送ルールに到達するようになります。すべてのポートを構成するには、gcloud を使用して --ports=ALL を設定するか、API を使用して allPorts を True に設定します。
フェイルオーバー
プライマリ バックエンド（インスタンス グループまたは NEG）の VM インスタンスまたはエンドポイント間で接続を分散し、必要に応じてフェイルオーバー バックエンドを使用するように、外部パススルー ネットワーク ロードバランサを構成できます。フェイルオーバーにより可用性を向上させるだけでなく、プライマリ バックエンドが正常に動作していない場合にワークロードをより効率的に管理できます。
デフォルトでは、外部パススルー ネットワーク ロードバランサのバックエンド サービスにバックエンドを追加すると、そのバックエンドはプライマリ バックエンドになります。バックエンドは、ロードバランサのバックエンド サービスに追加するときに指定できます。また、後でバックエンド サービスを編集して、フェイルオーバー バックエンドに指定することもできます。
フェイルオーバーの詳細については、外部パススルー ネットワーク ロードバランサのフェイルオーバーの概要をご覧ください。
バックエンドからのアウトバウンド インターネット接続
外部パススルー ネットワーク ロードバランサのバックエンド エンドポイントとして構成された 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 の暗黙的なファイアウォール ルールに従って、デフォルトの動作となります。ただし、このパスを開いたままにしておくことによるセキュリティ上の懸念がある場合は、ターゲットを絞った下り（外向き）ファイアウォール ルールを使用して、インターネットへの不要なアウトバウンド トラフィックをブロックできます。
制限事項
Google Cloud コンソールを使用して次のタスクを行うことはできません。
- 転送ルールで
L3_DEFAULTプロトコルを使用する外部パススルー ネットワーク ロードバランサを作成または変更する。 - バックエンド サービス プロトコルが
UNSPECIFIEDに設定されている外部パススルー ネットワーク ロードバランサを作成または変更する。 - 接続トラッキング ポリシーを構成する外部パススルー ネットワーク ロードバランサを作成または変更する。
- 転送ルールの送信元 IP ベースのトラフィック ステアリングを作成または変更する。
代わりに、Google Cloud CLI または REST API を使用してください。
- 転送ルールで
外部パススルー ネットワーク ロードバランサは、VPC ネットワーク ピアリングをサポートしていません。
料金
料金については、こちらをご覧ください。
次のステップ
- TCP または UDP トラフィックのみを対象とするバックエンド サービスを使用して外部パススルー ネットワーク ロードバランサを構成する（IPv4 および IPv6 トラフィックをサポート）。バックエンド サービスを使用して外部パススルー ネットワーク ロードバランサを設定するをご覧ください。
- 複数の IP プロトコルに外部パススルー ネットワーク ロードバランサを構成する（IPv4 と IPv6 のトラフィックをサポート）。複数の IP プロトコルへの外部パススルー ネットワーク ロードバランサを設定するをご覧ください。
- ゾーン NEG バックエンドを使用して外部パススルー ネットワーク ロードバランサを構成する。ゾーン NEG を使用して外部パススルー ネットワーク ロードバランサを設定するをご覧ください。
- ターゲット プールを使用して外部パススルー ネットワーク ロードバランサを構成する。ターゲット プールを使用して外部パススルー ネットワーク ロードバランサを設定するをご覧ください。
- 外部パススルー ネットワーク ロードバランサをターゲット プール バックエンドからリージョン バックエンド サービスに移行する。外部パススルー ネットワーク ロードバランサをターゲット プールからバックエンド サービスに移行するをご覧ください。