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

内部パススルー ネットワーク ロードバランサは、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。
  • インスタンス グループのバックエンドを使用する場合の 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 を使用する必要があります。

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

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

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

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

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

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

内部 IP アドレス

内部パススルー ネットワーク ロードバランサは、IPv4 のみ、デュアルスタック、IPv6 のみのサブネットをサポートしています。それぞれの詳細については、サブネットのタイプをご覧ください。

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

  • IPv4 トラフィックの場合、転送ルールはプライマリ IPv4 サブネット範囲の IPv4 アドレスを参照します。

  • IPv6 トラフィックの場合、転送ルールはサブネットの /64 内部 IPv6 アドレス範囲から内部 IPv6 アドレスの /96 範囲を参照します。サブネットは、内部 IPv6 アドレス範囲（ipv6-access-type を INTERNAL に設定）を持つデュアルスタックまたはシングルスタック IPv6 のみ（プレビュー版）のサブネットである必要があります。IPv6 アドレス範囲は、予約済み静的アドレスまたはエフェメラル アドレスにできます。

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

ファイアウォール構成

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

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

転送ルール

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

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

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

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

  • 転送ルールに指定するサブネットは、バックエンド VM で使用されるどのサブネットとも同じである必要はありません。ただし、サブネットは転送ルールと同じリージョンにある必要があります。
  • IPv4 トラフィックの場合、内部転送ルールは、選択したサブネットのプライマリ IPv4 アドレス範囲からリージョン内部 IPv4 アドレスを参照します。この IPv4 アドレスは自動的に選択することも、静的（予約済み）IPv4 アドレスを使用することもできます。
  • IPv6 トラフィックの場合、転送ルールはサブネットの /64 内部 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 のトラフィックを分散します。

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

インスタンス グループに関連付けられた 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 アドレスなし）を指定する場合、 Google Cloud では 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 ネットワークと一致する必要があります。

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

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

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

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

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

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

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 はサービス プロジェクト内にあります。そのサービス プロジェクトでは、リージョン内部のバックエンド サービスとヘルスチェックを定義する必要があります。

トラフィック分配

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

割り当てと上限

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

制限事項

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

次のステップ