このページは Cloud Translation API によって翻訳されました。

内部パススルーネットワークロードバランサの概要

内部パススルーネットワークロードバランサは、Andromeda ネットワークの仮想化スタック上に構築されたリージョンロードバランサです。

内部パススルーネットワークロードバランサは、Virtual Private Cloud（VPC）ネットワークの同じリージョンに存在する内部仮想マシン（VM）インスタンス間でトラフィックを分散します。これにより、同じ VPC ネットワークのシステムまたは VPC ネットワークに接続しているシステムのみがアクセス可能な内部 IP アドレスの背後でサービスを実行し、スケーリングできます。

内部パススルーネットワークロードバランサは、次のような状況で使用します。

TCP、UDP、ICMP、ICMPv6、SCTP、ESP、AH、GRE プロトコル用に高パフォーマンスのパススルーレイヤ 4 ロードバランサが必要な場合。
TLS（SSL）を介してトラフィックを処理する場合は、ロードバランサの代わりにバックエンドによって SSL トラフィックを終端させることもできます。内部パススルーネットワークロードバランサは、SSL トラフィックを終端できません。
プロキシを経由せずに元のパケットを転送する必要がある場合。たとえば、クライアントの送信元 IP アドレスを保持する必要がある場合が該当します。
既存の環境でパススルーロードバランサを使用していて、これを変更せずに移行する場合。

内部パススルーネットワークロードバランサは、多くのユースケースに対応しています。大まかな例については、パススルーネットワークロードバランサの概要をご覧ください。

内部パススルーネットワークロードバランサの仕組み

内部パススルーネットワークロードバランサには、フロントエンド（転送ルール）とバックエンド（バックエンドサービス）があります。バックエンドサービスのバックエンドとしてインスタンスグループまたは GCE_VM_IP ゾーン NEG を使用できます。この例は、インスタンスグループのバックエンドを示しています。

内部パススルーネットワークロードバランサの概要。 — 内部パススルーネットワークロードバランサの概要（クリックして拡大）

プロキシロードバランサとは異なり、内部パススルーネットワークロードバランサは、クライアントからの接続を終了せずに、バックエンドへの新しい接続を開きます。代わりに、内部パススルーネットワークロードバランサは、接続をクライアントから正常なバックエンドに中断されることなく直接転送します。正常なバックエンド VM からのレスポンスは、ロードバランサを経由せず、クライアントに直接送られます。TCP レスポンスは、ダイレクトサーバーリターンを使用します。詳細については、TCP と UDP のリクエストとリターンパケットをご覧ください。

ロードバランサは、ヘルスチェックプローブを使用してバックエンドの状態を監視します。詳細については、ヘルスチェックをご覧ください。

Google Cloud Linux ゲスト環境、Windows ゲスト環境、またはそれと同様のプロセスは、各バックエンド VM をロードバランサの IP アドレスで構成します。Google Cloud イメージから作成された VM では、ゲストエージェント（旧称 Windows ゲスト環境または Linux ゲスト環境）によって、ロードバランサの IP アドレスのローカルルートがインストールされます。Container-Optimized OS をベースとした Google Kubernetes Engine インスタンスは、代わりに iptables を使用してこれを実装します。

Google Cloud の仮想ネットワーキングが、トラフィック配信とスケーリングを適切に管理します。

プロトコル、スキーム、スコープ

各内部パススルーネットワークロードバランサは、以下をサポートします。

ロードバランシングスキーム INTERNAL とサポートされているプロトコルを使用する 1 つのバックエンドサービス。詳細については、バックエンドサービスをご覧ください。
次のいずれかとして指定されたバックエンド VM。
- 1 つのリージョンと VPC ネットワークにあるマネージドインスタンスグループと非マネージドインスタンスグループ
- 同じリージョンと VPC ネットワークにある GCE_VM_IP タイプエンドポイントを持つバックエンドゾーンネットワークエンドポイントグループ（NEG）NEG 内のエンドポイントは、NEG に使用されるものと同じサブネットとゾーン内のプライマリ内部 IP アドレスである必要があります。
インスタンスグループのバックエンドを使用する場合の IPv4 トラフィックと IPv6 トラフィックのサポート。GCE_VM_IP エンドポイントを使用するゾーンネットワークエンドポイントグループ（NEG）は、IPv4 トラフィックのみをサポートします。
バックエンドサービスのプロトコルに一致する TCP、UDP、または L3_DEFAULT プロトコルのいずれかを使用する 1 つ以上の転送ルール。
独自の一意の IP アドレスを持つ各転送ルール、または共通の IP アドレスを共有する複数の転送ルール。
最大 5 つのポートまたはすべてのポートを持つ各転送ルール。
グローバルアクセスが有効になっている場合、任意のリージョンのクライアント。
グローバルアクセスが無効になっている場合、ロードバランサと同じリージョンのクライアント。

内部パススルーネットワークロードバランサでは、次はサポートされていません。

複数リージョンのバックエンド VM。
インターネットからのトラフィックの分散（外部ロードバランサで使用する場合は不可）。
ヘッダーが断片化された IPv6 パケット。

クライアントアクセス

デフォルトでは、ロードバランサはロードバランサと同じリージョンにあるクライアントのみをサポートします。クライアントは、ロードバランサと同じネットワークに配置することも、VPC ネットワークピアリングを使用して接続された VPC ネットワークに配置することもできます。グローバルアクセスを有効にして、任意のリージョンのクライアントが内部パススルーネットワークロードバランサにアクセスできるようにします。

グローバルアクセスを使用した内部パススルーネットワークロードバランサ。 — グローバルアクセスを構成した内部パススルーネットワークロードバランサ（クリックして拡大）

次の表にクライアントアクセスの概要を示します。

グローバルアクセスが無効な場合	グローバルアクセスが有効な場合
クライアントはロードバランサと同じリージョンになければなりません。また、ロードバランサと同じ VPC ネットワーク、または VPC ネットワークピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。	クライアントはどのリージョンにでも配置できます。ただし、ロードバランサと同じ VPC ネットワーク、または VPC ネットワークピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。
オンプレミスクライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを介してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、ロードバランサと同じリージョンになければなりません。	オンプレミスクライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを使用してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、どのリージョンにでも配置できます。

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

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

送信元: クライアントの内部 IPv4、IPv6、またはクライアントのエイリアス IPv4 範囲の IPv4 アドレス。
宛先: ロードバランサの転送ルールの IP アドレス。転送ルールでは、単一の内部 IPv4 アドレスまたは内部 IPv6 範囲を使用します。

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

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

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

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

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

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

^† レスポンスパケットの送信元を VM NIC のプライマリ内部 IPv4 アドレスまたはエイリアス IP アドレス範囲に設定できます。VM で IP 転送が有効になっている場合は、任意の IP アドレスの送信元を使用できます。クライアントは、リクエストパケットの宛先 IP アドレスと一致しない内部 IP アドレスからレスポンスパケットを受信します。このため、転送ルールの IP アドレスを送信元として使用しないのは高度なシナリオです。

アーキテクチャ

複数のバックエンドを使用する内部パススルーネットワークロードバランサは、それらのすべてのバックエンド間で接続を分散します。分散の方法と構成オプションの詳細は、トラフィックの分散をご覧ください。

内部パススルーネットワークロードバランサのバックエンドとして、インスタンスグループまたはゾーン NEG を使用できますが、両方を組み合わせることはできません。

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

高可用性では、単一のゾーンに依存しない内部ロードバランサを設計する方法について説明しています。

内部 TCP / UDP ロードバランサのバックエンド VM として参加するインスタンスでは、適切な Linux または Windows のゲスト環境、あるいは同等の機能を提供する他のプロセスが実行されている必要があります。これらのゲスト環境では、メタデータサーバー（metadata.google.internal、169.254.169.254）に接続し、インスタンスのメタデータを読み取ることが可能である必要があります。これによって、ロードバランサの内部 IP アドレスに送信されるトラフィックを受け入れるローカルルートを生成できます。

この図は、2 つの個別のインスタンスグループに存在する VM 間のトラフィック分散を示しています。クライアントインスタンスからロードバランサの IP アドレス（10.10.10.9）に送信されたトラフィックが、いずれかのインスタンスグループのバックエンド VM 間で分散されます。サービスを提供するいずれかのバックエンド VM から送信されたレスポンスがクライアント VM に直接配信されます。

内部パススルーネットワークロードバランサは、カスタムモードまたは自動モードの VPC ネットワークで使用できます。既存のレガシーネットワークを使用して内部パススルーネットワークロードバランサを作成することもできます。

内部パススルーネットワークロードバランサは、次の Google Cloud コンポーネントで構成されています。

コンポーネント	目的	要件
内部 IP アドレス	ロードバランサのアドレスです。	内部 IP アドレスは、内部転送ルールと同じサブネット内に存在する必要があります。サブネットは、バックエンドサービスと同じリージョンと VPC ネットワークに存在する必要があります。
内部転送ルール	内部転送ルールを内部 IP アドレスと組み合わせると、ロードバランサのフロントエンドになります。ロードバランサが受け入れるプロトコルとポートを定義し、トラフィックをリージョンの内部バックエンドサービスにルーティングします。	内部パススルーネットワークロードバランサの転送ルールは、次のことを行う必要があります。 `load-balancing-scheme` が `INTERNAL` である。 • バックエンドサービスの `protocol` に一致する `TCP` または `UDP` の `ip-protocol` を使用する。 • バックエンドサービスと同じ VPC ネットワークとリージョン内の `subnet` を参照する。
リージョンの内部バックエンドサービス	リージョンの内部バックエンドサービスは、バックエンドとの通信に使用するプロトコルを定義し、ヘルスチェックを指定します。バックエンドには、非マネージドインスタンスグループ、マネージドゾーンインスタンスグループ、マネージドリージョンインスタンスグループ、`GCE_VM_IP` エンドポイントを使用したゾーン NEG があります。	バックエンドサービスは、次の条件を満たす必要があります。 • `load-balancing-scheme` が `INTERNAL` と指定されている。 • 転送ルールの `ip-protocol` に一致する `TCP` または `UDP` の `protocol` を使用する。 • 関連付けられたヘルスチェックを含む。 • 関連付けられたリージョンを含む。転送ルールとすべてのバックエンドは、バックエンドサービスと同じリージョンに存在する必要があります • 単一の VPC ネットワークに関連付けられている必要があります。指定されていない場合、各バックエンド VM のデフォルトのネットワークインターフェース（`nic0`）で使用されるネットワークに基づいてネットワークが推定されます。バックエンドサービスは特定のサブネットには接続されませんが、転送ルールのサブネットは、バックエンドサービスと同じ VPC ネットワークにある必要があります。
ヘルスチェック	バックエンドサービスはいずれもヘルスチェックが関連付けられている必要があります。ヘルスチェックでは、Google Cloud が管理しているバックエンドについて、トラフィックの受信に適格であるかどうかを検討する際に使用するパラメータを定義します。正常なバックエンド VM のみが、クライアント VM からロードバランサの IP アドレスに送信されたトラフィックを受信します。	転送ルールとバックエンドサービスでは `TCP` か `UDP` のいずれかを使用できます。ただし、Google Cloud では UDP トラフィックに対するヘルスチェックが行われません。詳細は、ヘルスチェックと UDP トラフィックをご覧ください。

内部パススルーネットワークロードバランサでは、次はサポートされていません。

複数リージョンのバックエンド VM。
インターネットからのトラフィックの分散（外部ロードバランサで使用する場合は不可）。
ヘッダーが断片化された IPv6 パケット。

内部 IP アドレス

内部パススルーネットワークロードバランサは、IPv4 のみ（シングルスタック）のサブネット、IPv4 と IPv6（デュアルスタック）のサブネットをサポートしています。詳細については、サブネットの種類をご覧ください。

内部パススルーネットワークロードバランサには、少なくとも 1 つの転送ルールが必要です。転送ルールは内部 IP アドレスを参照します。

IPv4 トラフィックの場合、転送ルールはプライマリ IPv4 サブネット範囲の IPv4 アドレスを参照します。
IPv6 トラフィックの場合、転送ルールはサブネットの /64 内部 IPv6 アドレス範囲から内部 IPv6 アドレスの /96 範囲を参照します。サブネットは、内部 IPv6 アドレス範囲（ipv6-access-type を INTERNAL に設定）を持つデュアルスタックサブネットである必要があります。

ファイアウォール構成

内部パススルーネットワークロードバランサには、階層型ファイアウォールポリシーと VPC ファイアウォールルールに対して次の構成が必要です。

IPv4 または IPv6 ヘルスチェックのソース範囲からの上り（内向き）を許可する。
クライアントの IPv4 または IPv6 アドレスのソース範囲からの上り（内向き）を許可する。

詳細については、ファイアウォールルールの構成をご覧ください。

転送ルール

転送ルールでは、ロードバランサがトラフィックを受け入れるポートとプロトコルを指定します。内部パススルーネットワークロードバランサはプロキシではないため、同じプロトコルとポートでバックエンドにトラフィックを渡します。

内部パススルーネットワークロードバランサには、少なくとも 1 つの内部転送ルールが必要です。同じロードバランサに対して複数の転送ルールを定義できます。

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

転送ルールは、ロードバランサのバックエンドコンポーネントと同じ VPC ネットワークとリージョン内の特定のサブネットを参照する必要があります。この要件に関しては、次の点に注意してください。

転送ルールに指定するサブネットは、バックエンド VM で使用されるどのサブネットとも同じである必要はありません。ただし、サブネットは転送ルールと同じリージョンにある必要があります。
IPv4 トラフィックの場合、内部転送ルールは、選択したサブネットのプライマリ IPv4 アドレス範囲からリージョン内部 IPv4 アドレスを参照します。この IPv4 アドレスは自動的に選択することも、静的（予約済み）IPv4 アドレスを使用することもできます。
IPv6 トラフィックの場合、転送ルールはサブネットの内部 IPv6 アドレス範囲から IPv6 アドレスの /96 範囲を参照します。サブネットは、ipv6-access-type が INTERNAL に設定されたデュアルスタックのサブネットである必要があります。/96 IPv6 アドレス範囲は自動的に割り振られます。また、予約済み内部 IP アドレスを使用することもできます。

転送ルールプロトコル

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

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

L3_DEFAULT オプションを使用すると、TCP、UDP、ICMP、ICMPv6、SCTP、ESP、AH、GRE プロトコルをロードバランスできます。

TCP と UDP 以外のプロトコルがサポートされるだけでなく、L3_DEFAULT オプションを使用すると、1 つの転送ルールで複数のプロトコルのトラフィックを同時に転送できます。たとえば、HTTP リクエストを発行するだけでなく、ロードバランサの IP アドレスに ping することもできます。

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

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

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

負荷分散するトラフィック	転送ルールプロトコル	バックエンドサービスプロトコル
TCP（IPv4 または IPv6）	`TCP`	`TCP or UNSPECIFIED`
UDP（IPv4 または IPv6）	`UDP`	`UDP or UNSPECIFIED`
TCP、UDP、ICMP、ICMPv6、SCTP、ESP、AH、GRE	`L3_DEFAULT`	`UNSPECIFIED`

転送ルールとグローバルアクセス

内部パススルーネットワークロードバランサの転送ルールは、グローバルアクセスが有効になっている場合でもリージョンルールになります。グローバルアクセスを有効にすると、リージョンの内部転送ルールの allowGlobalAccess フラグが true に設定されます。

転送ルールとポートの仕様

内部転送ルールを作成する場合は、次のいずれかのポート指定を選択する必要があります。

1 個から 5 個までのポートを番号で指定する。
すべてのポートにトラフィックを転送するには ALL を指定する。

すべての TCP ポートまたはすべての UDP ポートのいずれかをサポートする内部転送ルールでは、バックエンド VM がそれぞれ別のポートで複数のアプリケーションを実行できます。特定のポートに送信されたトラフィックは、対応するアプリケーションに配信され、すべてのアプリケーションで同じ IP アドレスが使用されます。

5 つより多い特定のポートでトラフィックを転送する必要がある場合は、ファイアウォールルールを転送ルールと組み合わせます。転送ルールを作成するときは、すべてのポートを指定してから、必要なポートへのトラフィックのみを許可する上り（内向き）allow ファイアウォールルールを作成します。ファイアウォールルールをバックエンド VM に適用します。

転送ルールは作成後に変更できません。指定したポートまたは内部転送ルールの内部 IP アドレスを変更する必要がある場合は、削除してから再度作成する必要があります。

単一のバックエンドサービスの複数の転送ルール

すべてが同じ内部バックエンドサービスを参照する複数の内部転送ルールを構成できます。内部パススルーネットワークロードバランサには、少なくとも 1 つの内部転送ルールが必要です。

同じバックエンドサービスに複数の転送ルールを構成すると、次のことが可能になります。

ロードバランサに複数の IP アドレスを割り当てる。それぞれに一意の IP アドレスを使用した、複数の転送ルールを作成できます。各転送ルールでは、すべてのポートまたは最大 5 つのポートを指定できます。
同じ IP アドレスを使用する特定のポートセットをロードバランサに割り当てる。同じ IP アドレスを共有する複数の転送ルールを作成し、各転送ルールで特定の最大 5 つのポートを使用するように設定できます。単一の転送ルールですべてのポートを指定する代わりに、この方法を使用できます。

共通の内部 IP アドレスを共有する 2 つ以上の内部転送ルールに関するシナリオについては、同じ IP アドレスを持つ複数の転送ルールをご覧ください。

複数の内部転送ルールを使用する場合は、バックエンド VM で実行されるソフトウェアを、すべての転送ルール IP アドレスまたは任意のアドレス（IPv4 の場合は 0.0.0.0/0、IPv6 の場合は ::/0）にバインドするように構成します。ロードバランサを介して配信されるパケットの宛先 IP アドレスは、対応する内部転送ルールが関連付けられている内部 IP アドレスです。詳細については、TCP と UDP のリクエストと返信パケットをご覧ください。

バックエンドサービス

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

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

プロトコル。バックエンドサービスは IPv4 トラフィックと IPv6 トラフィックをサポートします。プロトコルにポートのコンセプト（TCP や UDP など）がある場合、バックエンドサービスは、トラフィックの送信先と同じ宛先ポートのバックエンド VM にパケットを配信します。

バックエンドサービスは、TCP、UDP、UNSPECIFIED の IPv4 プロトコルオプションをサポートしています。

バックエンドサービスは、TCP または UDP の IPv6 プロトコルオプションをサポートしています。バックエンドサービスプロトコルは、転送ルールプロトコルと一致させる必要があります。

転送ルールとバックエンドサービスプロトコルの可能な組み合わせについては、転送ルールプロトコルの仕様をご覧ください。
トラフィック分散。バックエンドサービスは、構成可能なセッションアフィニティに従ってトラフィックの分散を許可します。
ヘルスチェック。バックエンドサービスには、関連付けられたヘルスチェックが必要です。

各バックエンドサービスは単一のリージョンで動作し、1 つの VPC ネットワーク内でバックエンド VM のトラフィックを分散します。

1 つのバックエンドタイプ、1 つのリージョン。バックエンドは、インスタンスグループ、またはバックエンドサービスおよび転送ルールと同じリージョンにある GCE_VM_IP エンドポイントを持つゾーン NEGです。インスタンスグループのバックエンドは、非マネージドインスタンスグループ、ゾーンマネージドインスタンスグループ、またはリージョンマネージドインスタンスグループです。ゾーン NEG バックエンドでは GCE_VM_IP エンドポイントを使用する必要があります。
1 つの VPC ネットワーク。各インスタンスグループまたは NEG バックエンドは、まだバックエンドサービスに接続されていない場合でも、関連付けられた VPC ネットワークが存在します。ネットワークが各タイプのバックエンドにどのように関連付けられているかについて詳しくは、インスタンスグループのバックエンドとネットワークインターフェースおよびゾーン NEG バックエンドとネットワークインターフェースをご覧ください。バックエンドサービスリソース自体にも関連付けられた VPC ネットワークがあり、このネットワークは、明示的または暗黙的に定義できます。バックエンドサービスのネットワークについて詳しくは、バックエンドサービスのネットワーク仕様とバックエンドサービスのネットワークルールをご覧ください。

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

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

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

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

ゾーン 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 アドレスを指定しても冗長になります。

バックエンドサービスのネットワーク仕様

バックエンドサービスの作成時に、--network フラグを使用して VPC ネットワークを明示的にバックエンドサービスに関連付けることができます。バックエンドサービスのネットワークルールは即座に有効になります。

バックエンドサービスを作成するときに --network フラグを省略すると、Google Cloud は次のいずれかの適格なイベントを使用して、バックエンドサービスの関連 VPC ネットワークを暗黙的に設定します。設定後は、バックエンドサービスの関連 VPC ネットワークは変更できません。

バックエンドサービスにまだ関連付けられたバックエンドがなく、バックエンドサービスを参照するように最初の転送ルールを構成する場合、Google Cloud はバックエンドサービスの関連 VPC ネットワークを、この転送ルールで使用されるサブネットを含む VPC ネットワークに設定します。
バックエンドサービスにまだ参照している転送ルールがなく、最初のインスタンスグループのバックエンドをバックエンドサービスに追加すると、Google Cloud はバックエンドサービスの VPC ネットワークを、その最初のインスタンスグループのバックエンドに関連付けられた VPC ネットワークに設定します。つまり、バックエンドサービスの関連 VPC ネットワークは、最初のインスタンスグループのバックエンド内の各 VM の nic0 ネットワークインターフェースで使用されるネットワークです。
バックエンドサービスにまだ参照している転送ルールがなく、最初のゾーン NEG バックエンド（GCE_VM_IP エンドポイントを含む）をバックエンドサービスに追加すると、Google Cloud はバックエンドサービスの VPC ネットワークを、その最初の NEG バックエンドに関連付けられた VPC ネットワークに設定します。

バックエンドサービスの VPC ネットワークが適格なイベントによって設定されたら、追加の転送ルール、バックエンドインスタンスグループ、または追加するバックエンドゾーン NEG はすべてバックエンドサービスのネットワークルールに従う必要があります。

バックエンドサービスのネットワークルール

バックエンドサービスが特定の VPC ネットワークに関連付けられた後は、次のルールが適用されます。

バックエンドサービスを参照するように転送ルールを構成する場合、転送ルールはバックエンドサービスの VPC ネットワークのサブネットを使用する必要があります。ネットワークが VPC ネットワークピアリングで接続されていても、転送ルールとバックエンドサービスが異なる VPC ネットワークを使用することはできません。
インスタンスグループのバックエンドを追加するときは、次のいずれかを満たしている必要があります。
- インスタンスグループに関連付けられた VPC ネットワーク（インスタンスグループ内の各 VM の nic0 ネットワークインターフェースによって使用される VPC ネットワーク）は、バックエンドサービスに関連付けられた VPC ネットワークと一致する必要があります。
- 各バックエンド VM は、バックエンドサービスに関連付けられた VPC ネットワークに nic0 以外のインターフェース（nic1～nic7）を持っている必要があります。
GCE_VM_IP エンドポイントを使用してゾーン NEG バックエンドを追加する場合、NEG に関連付けられた VPC ネットワークは、バックエンドサービスに関連付けられた VPC ネットワークと一致する必要があります。

バックエンドのサブセット化

バックエンドのサブセット化は、トラフィックを分散するバックエンドの数を制限してパフォーマンスを向上させるオプションの機能です。

1 つのロードバランサで 250 台を超えるバックエンド VM をサポートする必要がある場合にのみ、サブセット化を有効にしてください。詳細については、内部パススルーネットワークロードバランサのバックエンドのサブセット化をご覧ください。

ヘルスチェック

ロードバランサのバックエンドサービスは、グローバルまたはリージョンのヘルスチェックに関連付けられている必要があります。VPC ネットワークの外側の特殊ルートを使用することで、ヘルスチェックシステムとバックエンドとの間で容易に通信できます。

既存のヘルスチェックを使用することも、新たに定義することもできます。トラフィック分散での説明のとおり、内部パススルーネットワークロードバランサは、ヘルスチェックのステータスを使用して、新しい接続をルーティングする方法を決定します。

次の任意のヘルスチェックプロトコルを使用できます。ヘルスチェックのプロトコルがロードバランサのプロトコルと一致する必要はありません。

HTTP、HTTPS、HTTP/2。バックエンド VM が HTTP、HTTPS、または HTTP/2 を使用してトラフィックを処理する場合、HTTP ベースのヘルスチェックではそのプロトコルに適したオプションが提供されるため、それぞれのプロトコルと一致するヘルスチェックの使用をおすすめします。内部パススルーネットワークロードバランサを介して HTTP タイプのトラフィックを処理すると、ロードバランサのプロトコルが TCP になります。
SSL または TCP。バックエンド VM が HTTP タイプのトラフィックを処理しない場合は、SSL または TCP のヘルスチェックを使用する必要があります。

作成するヘルスチェックの種類に関係なく、Google Cloud は、ロードバランサのバックエンドサービスによって選択された VPC ネットワーク内のネットワークインターフェースへの内部パススルーネットワークロードバランサの転送ルールの IP アドレスに、ヘルスチェックプローブを送信します。これにより、ロードバランスされたトラフィックの配信方法がシミュレートされます。バックエンド VM 上で動作するソフトウェアは、各転送ルールの IP アドレスに送信される負荷分散トラフィックとヘルスチェックプローブの両方に応答する必要があります（ソフトウェアはネットワークインターフェースに割り当てられている特定の IP アドレスではなく 0.0.0.0:<port> をリッスンする必要があります）詳細については、プローブパケットの宛先をご覧ください。

ヘルスチェックと UDP トラフィック

Google Cloud では、UDP プロトコルを使用するヘルスチェックを提供していません。UDP トラフィックを処理する内部パススルーネットワークロードバランサを使用する場合、ヘルスチェック情報を提供する TCP ベースのサービスをバックエンド VM で実行する必要があります。

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

高可用性アーキテクチャ

内部パススルーネットワークロードバランサは、設計により高可用性を備えています。高可用性のメカニズムは単一のデバイスや VM インスタンスに依存しないため、ロードバランサの可用性を高くするための特別な手順はありません。

バックエンド VM インスタンスが複数のゾーンにデプロイされるようにするには、次のデプロイに関する推奨事項に従ってください。

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

共有 VPC アーキテクチャ

次の表は、共有 VPC ネットワークで使用される内部パススルーネットワークロードバランサのコンポーネント要件をまとめたものです。例については、プロビジョニングする共有 VPC での内部パススルーネットワークロードバランサの作成のページをご覧ください。

IP アドレス	転送ルール	バックエンドコンポーネント
内部 IP アドレスは、バックエンド VM と同じプロジェクトで定義する必要があります。共有 VPC ネットワークでロードバランサを使用できるようにするには、Google Cloud 内部 IP アドレスは、バックエンド VM が配置されている同じサービスプロジェクト内で定義する必要があります。さらに、ホストプロジェクト内の目的の共有 VPC ネットワーク内のサブネットを参照する必要があります。アドレス自体は、参照先サブネットのプライマリ IP 範囲から取得します。サービスプロジェクトで内部 IP アドレスを作成し、その IP アドレスのサブネットがサービスプロジェクトの VPC ネットワークにある場合、内部パススルーネットワークロードバランサは、サービスプロジェクトに対しローカルです。共有 VPC ホストプロジェクトに対してローカルではありません。	内部転送ルールは、バックエンド VM と同じプロジェクトで定義する必要があります。共有 VPC ネットワークでロードバランサを使用できるようにするには、内部転送ルールは、バックエンド VM が配置されている同じサービスプロジェクト内で定義する必要があります。さらに、関連付けられている内部 IP アドレスが参照する同じサブネット（共有 VPC ネットワーク内）を参照する必要があります。サービスプロジェクトで内部転送ルールを作成し、転送ルールのサブネットがサービスプロジェクトの VPC ネットワーク内にある場合、内部パススルーネットワークロードバランサは、サービスプロジェクトに対してローカルです。共有 VPC ホストプロジェクトに対してローカルではありません。	共有 VPC のシナリオでは、バックエンド VM はサービスプロジェクト内にあります。そのサービスプロジェクトでは、リージョン内部のバックエンドサービスとヘルスチェックを定義する必要があります。

トラフィック分散

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

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

新しい接続の分散方法は、ロードバランサのセッションアフィニティの設定によって異なります。

ヘルスチェックの状態によって、新しい接続の分散が制御されます。デフォルトでは、TCP 接続は異常なバックエンドで維持されます。詳細とこの動作を変更する方法については、異常なバックエンドでの接続の永続性をご覧ください。

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

内部パススルーネットワークロードバランサでは、構成可能なバックエンドの選択と接続トラッキングアルゴリズムを使用して、トラフィックをバックエンド VM に分散する方法が決定されます。内部パススルーネットワークロードバランサでは、次のアルゴリズムを使用して、（フェイルオーバーを構成している場合は、アクティブプール内の）バックエンド VM 間にパケットが分散されます。

ロードバランサに、受信パケットの特性と一致する接続トラッキングテーブルがある場合、パケットは接続トラッキングテーブルのエントリで指定されたバックエンドに送信されます。パケットは、以前に確立した接続の一部と見なされるため、ロードバランサによって接続トラッキングテーブルに以前に決定され記録されたバックエンド VM に送信されます。
ロードバランサで対応する接続トラッキングエントリがないパケットを受信した場合、ロードバランサでは次が行われます。
1. ロードバランサでバックエンドが選択されます。 ロードバランサは、構成されたセッションアフィニティに基づいてハッシュを計算します。このハッシュを使用してバックエンドを選択します。
  - 少なくとも 1 つのバックエンドが正常な場合、ハッシュは正常なバックエンドのいずれかを選択します。
  - すべてのバックエンドが異常な状態の場合で、フェイルオーバーポリシーが設定されていない場合、ハッシュはいずれかのバックエンドを選択します。
  - すべてのバックエンドが異常な状態の場合で、フェイルオーバーポリシーが構成されており、この状況でフェイルオーバーポリシーがトラフィックをドロップするように構成されていない場合、ハッシュはプライマリ VM バックエンドの 1 つを選択します。
  デフォルトのセッションアフィニティ NONE は、パケットの送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート、プロトコルの 5 タプルハッシュを使用します。
  
  バックエンドの選択は、使用する情報が少ないハッシュアルゴリズムを使用してカスタマイズできます。サポートされているすべてのオプションについては、セッションアフィニティのオプションをご覧ください。
2. ロードバランサにより、接続トラッキングテーブルにエントリが追加されます。このエントリによって、パケット接続用に選択されたバックエンドが記録されるため、この接続からの以降のパケットがすべて同じバックエンドに送信されます。接続トラッキングを使用するかどうかは、プロトコルによって異なります。
  
  TCP パケットと UDP パケットの場合、接続トラッキングは常に有効になっています。オフにすることはできません。デフォルトでは、接続トラッキングは 5 タプルですが、5 タプル未満に構成することもできます。
  
  接続トラッキングハッシュが 5 タプルの場合、TCP SYN パケットは常に接続トラッキングテーブルに新しいエントリを作成します。
  
  デフォルトの 5 タプル接続トラッキングは、次の場合に使用されます。
  - トラッキングモードが PER_CONNECTION（すべてのセッションアフィニティ）の場合。または、
  - トラッキングモードが PER_SESSIONでセッションアフィニティが NONEの場合。または、
  - トラッキングモードが PER_SESSION であり、セッションアフィニティが CLIENT_IP_PORT_PROTO の場合。
  接続トラッキングが有効にされている場合と、接続トラッキングが有効な場合のトラッキング方法の詳細については、接続トラッキングモードをご覧ください。
  
  さらに、次の点に留意してください。
  - デフォルトでは、接続トラッキングテーブル内のエントリは、ロードバランサがエントリに一致した最後のパケットを処理してから 600 秒後に失効します。アイドルタイムアウトをカスタマイズする方法については、アイドルタイムアウトをご覧ください。
  - プロトコルによっては、バックエンドが正常な状態ではなくなると、ロードバランサによって接続トラッキングテーブルのエントリが削除される場合があります。この動作の詳細とカスタマイズ方法については、異常なバックエンドでの接続の永続性をご覧ください。

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

セッションアフィニティは、クライアントからロードバランサのバックエンド VM への新しい接続の分散を制御します。バックエンド VM がクライアントの状態情報を追跡する必要がある場合は、セッションアフィニティを設定します。これは、ウェブアプリケーションの一般的な要件です。

セッションアフィニティはベストエフォートベースで機能します。

内部パススルーネットワークロードバランサは、バックエンドインスタンスグループではなく、内部バックエンドサービス全体に指定する次に示すセッションアフィニティのオプションをサポートします。

なし（NONE）。送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートの 5 タプルハッシュ
クライアント IP、宛先なし（CLIENT_IP_NO_DESTINATION）。送信元 IP アドレスからのみ作成された 1 タプルハッシュ
クライアント IP（CLIENT_IP）。送信元 IP アドレスと宛先 IP アドレスの 2 タプルハッシュです。外部パススルーネットワークロードバランサは、このセッションアフィニティのクライアント IP、宛先 IP　オプションを呼び出します。
クライアント IP、宛先 IP、プロトコル（CLIENT_IP_PROTO）。送信元 IP アドレス、宛先 IP アドレス、プロトコルの 3 タプルハッシュ
クライアント IP、クライアントポート、宛先 IP、宛先ポート、プロトコル（CLIENT_IP_PORT_PROTO）。送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートの 5 タプルハッシュ

ロードバランサをカスタム静的ルートのネクストホップとして使用しない限り、パケットの宛先 IP アドレスは、パケットをロードバランサに配信するためのロードバランサ転送ルールの IP アドレスと一致する必要があります。ロードバランサをカスタム静的ルートのネクストホップとして使用する場合の考慮事項については、セッションアフィニティとネクストホップの内部パススルーネットワークロードバランサをご覧ください。

セッションアフィニティとネクストホップの内部パススルーネットワークロードバランサ

ネクストホップの内部パススルーネットワークロードバランサを使用するように静的ルートを構成すると、ロードバランサは前述のバックエンドの選択と接続のトラッキング方法を使用します。バックエンドの選択は、構成されたセッションアフィニティに従ってハッシュを計算することで引き続き行われます。CLIENT_IP_NO_DESTINATION セッションアフィニティを除き、バックエンド選択ハッシュは、パケットの宛先 IP アドレスに部分的に依存します。

内部パススルーネットワークロードバランサロードバランサが静的ルートのネクストホップの場合、宛先 IP アドレスはロードバランサの転送ルールの IP アドレスに限定されません。代わりに、パケットの宛先 IP アドレスは、静的ルートの宛先範囲内に収まる任意の IP アドレスにできます。

構成済みで正常なバックエンド VM の数が一定の場合（フェイルオーバーが構成されていない場合、またはフェイルオーバーが構成されていてもフェイルオーバーイベントまたはフェイルバックイベントが発生しない場合）、ロードバランサは次のように動作します。

構成済みで正常なバックエンド VM が 1 つだけある場合（フェイルオーバーが構成されている場合はアクティブプール内）、すべてのハッシュが 1 つのバックエンド VM にマッピングされるため、使用するセッションアフィニティは重要ではありません。
構成済みで正常なバックエンド VM が 2 つ以上ある場合（フェイルオーバーが構成されている場合はアクティブプール内）、セッションアフィニティの選択が重要になります。
- パケットの宛先 IP アドレスに関係なく、パケットの送信元 IP アドレスのみに基づいて、クライアントからのすべてのパケットを同じバックエンド VM で処理する必要がある場合は、CLIENT_IP_NO_DESTINATION セッションアフィニティを使用します。トラフィックパターンによっては、一部のバックエンド VM が他のバックエンド VM よりも多くのパケットまたは接続を受信する場合があります。
- CLIENT_IP_NO_DESTINATION 以外のセッションアフィニティオプションを使用する場合、ロードバランサは、少なくともパケットの送信元 IP アドレスと宛先 IP アドレスの両方を含む情報に基づいてバックエンド VM を選択します。同じ送信元 IP アドレスを使用して異なる宛先 IP アドレスを使用して同じクライアントから送信されたパケットは、異なるバックエンド VM にルーティングできます。

接続トラッキングモード

トラッキングモードでは、使用する接続トラッキングアルゴリズムを指定します。トラッキングモードには、PER_CONNECTION（デフォルト）と PER_SESSION の 2 つがあります。

PER_CONNECTION（デフォルト）。このモードでは、TCP トラフィックと UDP トラフィックはセッションアフィニティの設定に関係なく、常に 5 タプルごとにトラッキングされます。これは、接続トラッキングのキー（5 タプル）が、構成されたセッションアフィニティの設定（たとえば、CLIENT_IP_PROTO 設定の 3 タプル）と異なることを意味します。その結果、セッションアフィニティが分割され、バックエンドのセットや状態が変更されたときに、セッションの新しい接続が別のバックエンドを選択する場合があります。
PER_SESSION。このモードでは、構成されたセッションアフィニティに従って TCP と UDP のトラフィックを追跡します。つまり、セッションアフィニティが CLIENT_IP または CLIENT_IP_PROTO の場合、このモードを構成すると、それぞれ 2 タプルと 3 タプルの接続トラッキングが行われます。これは、アフィニティの消失が高コストで、バックエンドの追加後も回避すべきシナリオでは望ましい場合があります。

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

バックエンドの選択		接続トラッキングモード
セッションアフィニティの設定	バックエンド選択のハッシュ方法	`PER_CONNECTION`（デフォルト）	`PER_SESSION`
デフォルト: セッションアフィニティなし `NONE`	5 タプルハッシュ	5 タプル接続トラッキング	5 タプル接続トラッキング
クライアント IP、宛先なし `CLIENT_IP_NO_DESTINATION`	1 タプルハッシュ	5 タプル接続トラッキング	1 タプル接続トラッキング
クライアント IP `CLIENT_IP` （外部パススルーネットワークロードバランサのクライアント IP、宛先 IP と同じ）	2 タプルハッシュ	5 タプル接続トラッキング	2 タプル接続トラッキング
クライアント IP、宛先 IP、プロトコル `CLIENT_IP_PROTO`	3 タプルハッシュ	5 タプル接続トラッキング	3 タプル接続トラッキング
クライアント IP、クライアントポート、宛先 IP、宛先ポート、プロトコル `CLIENT_IP_PORT_PROTO`	5 タプルハッシュ	5 タプル接続トラッキング	5 タプル接続トラッキング

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

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

正常でないバックエンドでの接続の永続性の設定は、バックエンドが異常になった後（バックエンドがロードバランサの構成済みバックエンドインスタンスグループに残っている限り）、選択したバックエンドで既存の接続を持続するかどうかを制御します。

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

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

DEFAULT_FOR_PROTOCOL（デフォルト）
NEVER_PERSIST
ALWAYS_PERSIST

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

異常なバックエンドオプションでの接続の永続性	接続トラッキングモード
異常なバックエンドオプションでの接続の永続性	`PER_CONNECTION`	`PER_SESSION`
`DEFAULT_FOR_PROTOCOL`	TCP: 異常なバックエンドで接続が維持されます（すべてのセッションアフィニティ） UDP: 異常なバックエンドで接続が持続することはありません	TCP: セッションアフィニティが `NONE` または `CLIENT_IP_PORT_PROTO` の場合に、異常なバックエンドで接続が維持されます UDP: 異常なバックエンドで接続が持続することはありません
`NEVER_PERSIST`	TCP、UDP: 異常なバックエンドで接続が持続することはありません
`ALWAYS_PERSIST`	TCP、UDP: 異常なバックエンドで接続が維持されます（すべてのセッションアフィニティ）このオプションは、高度なユースケースにのみ使用してください。	構成が不可能

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

注: ロードバランサが異常なバックエンドから接続を移動すると、ロードバランサによって新しいトラッキングテーブルエントリが作成されます。新しいエントリは、設定したセッションアフィニティに基づいて別のバックエンドに接続をマッピングします。新しいエントリは、他のエントリと同様に有効な状態を保持します。異常なバックエンドが正常な状態に戻っても、それだけでは接続トラッキングテーブルのエントリは削除されません。（ただし、フェイルバックがトリガーされ、フェイルオーバー時のコネクションドレインとフェイルバックが無効になっている場合は除きます）。

アイドルタイムアウト

デフォルトでは、接続トラッキングテーブル内のエントリは、ロードバランサがエントリに一致した最後のパケットを処理してから 600 秒後に失効します。このデフォルトのアイドルタイムアウト値は、接続トラッキングが 5 タプル未満の場合（つまり、セッションアフィニティが CLIENT_IP または CLIENT_IP_PROTO に構成されている場合）にのみ変更できます。トラッキングモードは PER_SESSION です）。

構成可能なアイドルタイムアウトの最大値は 57,600 秒（16 時間）です。

アイドルタイムアウト値を変更する方法については、接続トラッキングポリシーの構成をご覧ください。

1 つのクライアントから接続をテストする

単一のクライアントシステムから内部パススルーネットワークロードバランサの IP アドレスへの接続をテストする場合、次の点に注意します。

クライアントシステムが負荷分散対象外の VM、つまりバックエンド VM でない場合、新しい接続がロードバランサの正常なバックエンド VM に配信されます。ただし、すべてのセッションアフィニティのオプションが、少なくともクライアントシステムの IP アドレスに依存するため、同じクライアントからの接続は、予測より頻繁に同じバックエンド VM に分散されることがあります。

実地面では、単一クライアントから内部パススルーネットワークロードバランサに接続した場合、これを介したトラフィック分散を正確にモニタリングできないことになります。トラフィック分散のモニタリングに必要なクライアント数は、ロードバランサの種類、トラフィックの種類、正常なバックエンドの数によって異なります。
クライアント VM がロードバランサのバックエンド VM の場合、ロードバランサの転送ルールの IP アドレスに送信される接続には、常にクライアント / バックエンド VM 自体が応答することになります。この現象は、バックエンド VM が正常であるかどうかにかかわらず、ロードバランサの内部転送ルールで指定されたプロトコルとポート上のトラフィックだけではなく、ロードバランサの IP アドレスに送信されたすべてのトラフィックで発生します。

詳細については、負荷分散された VM からのリクエストの送信をご覧ください。

UDP の断片化

内部パススルーネットワークロードバランサは、断片化された UDP パケットと断片化されていない UDP パケットの両方を処理できます。断片化された UDP パケットをアプリケーションで使用する場合は、次の点に留意してください。

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

断片化された UDP パケットを処理する可能性があり、それを同じバックエンドにルーティングする必要がある場合は、次の転送ルールとバックエンドサービスの構成パラメータを使用します。

転送ルールの構成: ロードバランシングされた IP アドレスごとに UDP 転送ルールを 1 つだけ使用し、すべてのポートでトラフィックを受信するように転送ルールを構成します。これで、すべてのフラグメントが同じ転送ルールに渡されるようになります。断片化されたパケット（最初のフラグメント以外）には宛先ポートがありませんが、すべてのポートのトラフィックを処理する転送ルールを構成すると、ポート情報がない UDP フラグメントも受信するように構成されます。すべてのポートを構成するには、Google Cloud CLI を使用して --ports=ALL を設定するか、API を使用して allPorts を True に設定します。
バックエンドサービスの構成: バックエンドサービスのセッションアフィニティを CLIENT_IP（2 タプルハッシュ）または CLIENT_IP_PROTO（3 タプルハッシュ）に設定し、ポート情報を含む UDP パケットとポート情報がない UDP フラグメント（最初のフラグメント以外）に同じポートが選択されるようにします。バックエンドサービスの接続トラッキングモードを PER_SESSION に設定して、接続トラッキングテーブルのエントリが同じ 2 タプルハッシュまたは 3 タプルハッシュを使用して構築されるようにします。

フェイルオーバー

内部パススルーネットワークロードバランサを使用すると、一部のバックエンドをフェイルオーバーバックエンドとして指定できます。これらのバックエンドは、プライマリバックエンドインスタンスグループの正常な VM の数が、構成可能なしきい値を下回る場合にのみ使用されます。デフォルトでは、すべてのプライマリ VM とフェイルオーバー VM が異常な状態になると、最後の手段として、Google Cloud はすべてのプライマリ VM 間でのみ新しい接続トラフィックを分散します。

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

内部パススルーネットワークロードバランサのフェイルオーバーのコンセプトの概要については、内部パススルーネットワークロードバランサのフェイルオーバーをご覧ください。

割り当てと上限

割り当てと上限について詳しくは、ロードバランシングのリソースの割り当てをご覧ください。

制限事項

Google Cloud コンソールを使用して、ゾーン NEG バックエンドを持つ内部パススルーネットワークロードバランサを作成することはできません。

次のステップ

内部パススルーネットワークロードバランサを構成してテストする。内部パススルーネットワークロードバランサを設定するをご覧ください。
内部パススルーネットワークロードバランサに Cloud Monitoring を構成する。内部パススルーネットワークロードバランサのロギングとモニタリングをご覧ください。
内部パススルーネットワークロードバランサの問題をトラブルシューティングするには、内部パススルーネットワークロードバランサをトラブルシューティングするをご覧ください。

内部パススルー ネットワーク ロードバランサの概要

内部パススルー ネットワーク ロードバランサの仕組み