外部パススルー ネットワーク ロードバランサは、リージョン レイヤ 4 ロードバランサです。外部パススルー ネットワーク ロードバランサは、Virtual Private Cloud（VPC）ネットワークの同じリージョン内のバックエンド仮想マシン（VM）インスタンス間で TCP トラフィックと UDP トラフィックを分散します。外部パススルー ネットワーク ロードバランサは、次のいずれかからトラフィックを受信できます。
- インターネット上のすべてのクライアント
- 外部 IP を持つ Google Cloud VM
- Cloud NAT またはインスタンス ベースの NAT 経由でインターネットにアクセスできる Google Cloud VM
転送ルールの構成に応じて、ターゲット プールベースの各ロードバランサは、次のいずれかのタイプのプロトコル トラフィックをサポートします。
- TCP
- UDP
- TCP と UDP
ロードバランサのスコープは、グローバルではなくリージョンです。外部パススルー ネットワーク ロードバランサのすべてのバックエンド インスタンスは同じリージョンに配置する必要があります。バックエンドはリージョンの任意のゾーンに配置できます。
外部パススルー ネットワーク ロードバランサは、すべてのポートをサポートします。外部パススルー ネットワーク ロードバランサを使用して、TCP または UDP トラフィックをロード バランシングできます。ロードバランサはパススルー ロードバランサであるため、バックエンドはロードバランスされた TCP 接続または UDP パケット自体を終端します。たとえば、バックエンドで HTTPS ウェブサーバーを実行し、外部パススルー ネットワーク ロードバランサを使用してリクエストを転送することで、バックエンド自体で TLS を終端できます。
GKE でアプリケーションを構築する場合は、組み込みの GKE Service コントローラを使用することをおすすめします。このコントローラは GKE ユーザーに代わって Google Cloud ロードバランサをデプロイします。これは、スタンドアロンのロード バランシング アーキテクチャと同じですが、ライフサイクルが GKE によって完全に自動化、制御される点で異なります。詳細については、サービスを使用したアプリの公開をご覧ください。
アーキテクチャ
ロードバランサは、いくつかの構成コンポーネントで構成されています。単一のロードバランサには、次のものを含めることができます。
外部パススルー ネットワーク ロードバランサには、常に 1 つのターゲット プールがあります。複数の転送ルールからターゲット プールを参照できます。
ターゲット プールは、ロードバランサのバックエンドです。負荷分散されるトラフィック間のバックエンド インスタンスを指定します。各転送ルールは、ロードバランサのフロントエンドです。プロジェクトあたりの転送ルールとターゲット プールの数には制限がある点にご注意ください。
外部パススルー ネットワーク ロードバランサは、アドレス、ポート、プロトコル タイプなどの受信 IP プロトコル データに基づいてシステムの負荷を分散します。
外部パススルー ネットワーク ロードバランサはパススルー ロードバランサであるため、バックエンドは元のクライアント リクエストを受け取ります。外部パススルー ネットワーク ロードバランサは、Transport Layer Security（TLS）のオフロードやプロキシを行いません。トラフィックは VM に直接ルーティングされます。
ロードバランサの転送ルールを作成するときに、エフェメラル仮想 IP アドレス（VIP）を受信するか、リージョン ネットワーク ブロックから派生する VIP を予約します。
次に、その転送ルールをターゲット プールに関連付けます。VIP は、世界的に展開されている Google の拠点からエニーキャストされますが、バックエンドはリージョンです。ロードバランサに複数のリージョンにまたがるバックエンドを指定することはできません。
Google Cloud ファイアウォールを使用して、バックエンド VM へのアクセスを制御またはフィルタできます。
外部パススルー ネットワーク ロードバランサは、送信元ポート、宛先ポート、IP アドレス、プロトコルを調べて、パケットの転送方法を決定します。TCP トラフィックの場合は、セッション アフィニティを構成することで、ロードバランサの転送動作を変更できます。外部パススルー ネットワーク ロードバランサは、ターゲット プール内のインスタンスの最初のネットワーク インターフェース（nic0）にパケットを転送します。
ロードバランサは受信パケットの送信元 IP アドレスを保持します。受信パケットの宛先 IP アドレスは、ロードバランサの転送ルールに関連付けられたリージョン外部 IP アドレスです。
負荷分散アルゴリズム
デフォルトでは、トラフィックを複数のインスタンスに分散するため、セッション アフィニティ値が NONE に設定されています。Cloud Load Balancing は、送信元 IP とポート、宛先 IP とポート、プロトコルのハッシュに基づいてインスタンスを選択します。これは、受信 TCP 接続トラフィックが複数のインスタンスにまたがっており、新しい接続トラフィックがそれぞれ別のインスタンスに送信される可能性があることを意味します。接続が閉じられるまで、接続のパケットはすべて、同じインスタンスに振り向けられます。確立済みの接続はロード バランシング時に考慮されません。
セッション アフィニティの設定に関係なく、接続が閉じられるまで、接続のすべてのパケットは選択されたインスタンスに送信されます。既存の接続は、新しい受信接続に対するロード バランシングの決定に影響を受けません。その結果、長期的な TCP 接続が使用されている場合、バックエンド間で不均衡が生じる可能性があります。
単一クライアントからの複数の接続トラフィックのパケットを同じインスタンスに送信する場合は、異なるセッション アフィニティ値を設定できます。
ターゲット プール
ターゲット プールリソースは、転送ルールから受信トラフィックを受け取るインスタンスのグループを定義します。転送ルールがトラフィックをターゲット プールに送信する際は、Cloud Load Balancing が送信元 IP とポート、宛先 IP とポートのハッシュに基づいて、そのターゲット プールからインスタンスを選択します。各ターゲット プールは単一のリージョンで動作し、バックエンド インスタンスの最初のネットワーク インターフェース（nic0）にトラフィックを分散します。インスタンスにトラフィックを分散する方法の詳細については、負荷分散アルゴリズムのセクションをご覧ください。
外部パススルー ネットワーク ロードバランサはプロキシではありません。バックエンド VM からのレスポンスは、ロードバランサを経由せず、クライアントに直接送信されます。ロードバランサはパケットの送信元 IP アドレスを保持します。受信パケットの宛先 IP アドレスは、ロードバランサの転送ルールに関連付けられたリージョン外部 IP アドレスです。したがって、次のことが必要になります。
外部パススルー ネットワーク ロードバランサのバックエンド VM として参加するインスタンスでは、適切な Linux ゲスト環境、Windows ゲスト環境、または同等の機能を提供する他のプロセスが実行されている必要があります。
ゲスト OS 環境（または同等のプロセス）ではバックエンド VM ごとにローカルルートを構成します。このルートにより、宛先がロードバランサの転送ルールの IP アドレスと一致するパケットを VM で受信できるようになります。
ロードバランスされたトラフィックを受け入れるバックエンド インスタンスでは、ロードバランサの転送ルールに関連付けられた IP アドレス（または任意の IP アドレス
0.0.0.0/0）にバインドするようにソフトウェアを構成する必要があります。
外部パススルー ネットワーク ロードバランサは Compute Engine オートスケーラーをサポートしています。これにより、ユーザーはバックエンドの使用状況に基づいて、ターゲット プールのインスタンス グループで自動スケーリングを実行できます。詳細については、CPU 使用率に基づくスケーリングをご覧ください。
ターゲット プールに単一の VM インスタンスを含めるようにする場合、プロトコル転送機能の使用を検討する必要があります。
ターゲット プールは、TCP と UDP トラフィックを処理する転送ルールと組み合わせた場合のみ使用できます。その他のすべてのプロトコルには、ターゲット インスタンスを作成する必要があります。ターゲット プールを転送ルールと組み合わせて使用するには、その前にターゲット プールを新たに作成する必要があります。各プロジェクトには、最大 50 個のターゲット プールを設定できます。
転送ルール
転送ルールは、ターゲット プールと連携して機能し、ロード バランシングをサポートします。ロード バランシングを使用するには、特定のターゲット プールにトラフィックを転送する転送ルールを作成する必要があります。転送ルールを設定することなくトラフィックを負荷分散することはできません。
各転送ルールでは、特定の IP アドレス、プロトコル、ポート範囲（オプション）が、単一のターゲット プールと照合されます。転送ルールから提供される外部 IP アドレスにトラフィックが送信されると、そのトラフィックは転送ルールによって、対応するターゲット プールに送信されます。
Google Cloud VPC ネットワークに到達する前に断片化されたと考えられる UDP パケットを負荷分散する場合は、負荷分散と断片化された UDP パケットをご覧ください。
ターゲット プール ベースの外部パススルー ネットワーク ロードバランサは、転送ルールごとに TCP または UDP のプロトコルをサポートします。ロードバランサがすべての IP プロトコル トラフィックを転送する場合は、バックエンド サービスベースの外部パススルー ネットワーク ロードバランサを使用する必要があります。
複数の転送ルール
同じ外部パススルー ネットワーク ロードバランサに複数のリージョン外部転送ルールを構成できます。必要に応じて、各転送ルールで異なるリージョン外部 IP アドレスを指定できます。また、複数の転送ルールで同じリージョン外部 IP アドレスを指定することもできます。
複数のリージョン外部転送ルールを構成すると、次のような場合に便利です。
- 同じターゲット プールに複数の外部 IP アドレスを構成する必要がある。
- 同じターゲット プールに同じ外部 IP アドレスを使用して、異なるポート範囲または異なるプロトコルを構成する必要がある。
複数の転送ルールを使用する場合は、必要なすべての IP アドレスにバインドするように、バックエンド VM で実行されるソフトウェアを構成します。これは、ロードバランサを介して配信されるパケットの宛先 IP アドレスが、それぞれのリージョン外部転送ルールに関連付けられているリージョン外部 IP アドレスであるためです。
ヘルスチェック
ヘルスチェックにより、Compute Engine は、稼働中で接続の受信準備ができたインスタンスに対してのみ、新しい接続を転送するようになります。Compute Engine は指定された頻度で各インスタンスにヘルスチェック リクエストを送信します。インスタンスでヘルスチェックの条件を満たさない回数が許容回数を超えると、そのインスタンスは新しいトラフィックの受信対象とみなされなくなります。
TCP 接続の正常なシャットダウンと終了を可能にするために、既存の接続がアクティブに終了されることはありません。ただし、異常なバックエンドへの既存の接続は、長期間使用可能であるとは限りません。可能であれば、できるだけ早く正常ではないバックエンドのシャットダウン プロセスを開始してください。
ヘルスチェックでは異常なインスタンスへのクエリが継続的に行われ、チェックの適合が指定された回数を超えると、インスタンスがプールに戻されます。すべてのインスタンスが UNHEALTHY とマークされている場合、ロードバランサは既存のすべてのインスタンスに新しいトラフィックを転送します。
外部パススルー ネットワーク ロードバランサは、以前の HTTP ヘルスチェックを使用してインスタンスの状態を判断します。HTTP を使用しないサービスでも、ヘルスチェック システムが照会できるインスタンスごとに基本的なウェブサーバーを実行する必要があります。
以前の HTTPS ヘルスチェックはネットワーク ロードバランサに対応しておらず、他の種類のロードバランサでもほとんど使用できません。
ファイアウォール ルール
外部パススルー ネットワーク ロードバランサのヘルスチェックは、これらの IP 範囲から送信されます。これらの範囲からのトラフィックを許可する、上り（内向き）許可ファイアウォール ルールを作成する必要があります。
外部パススルー ネットワーク ロードバランサはパススルー ロードバランサです。これは、ファイアウォール ルールでクライアントの送信元 IP アドレスからのトラフィックを許可する必要があるということです。サービスがインターネットに公開されているのであれば、すべての IP 範囲からのトラフィックを許可するのが最も簡単です。特定の送信元 IP アドレスのみが許可されるようにアクセスを制限する場合は、ヘルスチェック 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 はコネクションレスのため、バックエンド VM は、送信元 IP アドレスが転送ルールの IP アドレスまたは VM に割り当てられた IP アドレスと一致するレスポンス パケットを送信できます。ほとんどのクライアントは、パケットの送信元と同じ IP アドレスからのレスポンスを想定しています。
次の表は、レスポンス パケットの送信元と宛先をまとめたものです。
| トラフィックの種類 | 送信元 | 宛先 |
|---|---|---|
| TCP | ロードバランサの転送ルールの IP アドレス | リクエスト パケットの送信元 |
| UDP | ほとんどの場合、ロードバランサの転送ルールの IP アドレス† | リクエスト パケットの送信元 |
† VM に外部 IP アドレスがある場合、または Cloud NAT を使用している場合は、レスポンス パケットの送信元 IP アドレスを VM NIC のプライマリ内部 IPv4 アドレスに設定することもできます。Google Cloud または Cloud NAT は、レスポンス パケットの送信元 IP アドレスを NIC の外部 IPv4 アドレスまたは Cloud NAT 外部 IPv4 アドレスに変更して、レスポンス パケットをクライアントの外部 IP アドレスに送信します。クライアントは、リクエスト パケットの宛先 IP アドレスと一致しない外部 IP アドレスからレスポンス パケットを受信します。このため、転送ルールの IP アドレスを送信元として使用しないのは高度なシナリオです。
特別なルーティング パス
Google Cloud では、VPC ネットワークで定義されていない特殊なルートがヘルスチェックに使用されます。詳細については、ヘルスチェックのパスをご覧ください。
共有 VPC アーキテクチャ
次の表は、外部パススルー ネットワーク ロードバランサの共有 VPC コンポーネントをまとめたものです。
| IP アドレス | 転送ルール | バックエンド コンポーネント |
|---|---|---|
| リージョン外部 IP は、負荷分散されているインスタンスと同じプロジェクトで定義する必要があります。 | リージョン転送ルールは、ターゲット プールのインスタンスと同じプロジェクト（サービス プロジェクト）で定義する必要があります。 | ターゲット プールは、ターゲット プールのインスタンスと同じリージョンの同じプロジェクトで定義する必要があります。ターゲット プールに関連するヘルスチェックも同じプロジェクトで定義する必要があります。 |
トラフィック分散
ターゲット プールベースの外部パススルー ネットワーク ロードバランサによる新しい接続の分散方法は、セッション アフィニティの構成方法によって異なります。
セッション アフィニティ
セッション アフィニティは、クライアントからロードバランサのバックエンド VM に新しい接続を分散するために使用されるハッシュ方法を制御します。ターゲット プールベースのロードバランサでは、sessionAffinity パラメータを使用してセッション アフィニティを構成します。
詳細については、ターゲット プールの使用をご覧ください。
負荷分散および断片化された UDP パケット
UDP パケットをロードバランスしている場合は、以下の点に注意してください。
- 断片化されていないパケットは、すべての構成で通常通り処理されます。
- UDP パケットは、Google Cloud に到達する前に断片化されることがあります。介在するネットワークは、すべてのフラグメントが到達してから転送するため遅延を引き起こすか、フラグメントをドロップすることがあります。Google Cloud はすべてのフラグメントの到着を待つことなく、個々のフラグメントを到達と同時に転送します。
後から到達する UDP フラグメントには宛先ポートが含まれないため、次のような場合に問題が発生します。
- ターゲット プールのセッション アフィニティが
NONE（5 タプル アフィニティ）に設定されている場合、ロードバランサでは 5 タプルハッシュを計算できないため、後から到達するフラグメントがドロップされることがあります。 - 負荷分散された 1 つの IP アドレスに複数の UDP 転送ルールが設定されていると、後から到達するフラグメントが間違った転送ルールに到達することがあります。
- ターゲット プールのセッション アフィニティが
断片化された UDP パケットを処理する可能性がある場合は、次の手順を行います。
- セッション アフィニティを
NONE、CLIENT_IP_PROTO、CLIENT_IPのいずれかに設定します。- セッション アフィニティを
NONEに設定すると、アフィニティを維持する必要がなくなります。このため、ロードバランサは 5 タプルハッシュを使用して断片化されていないパケット用のバックエンドを選択しますが、断片化されたパケットについては 3 タプルハッシュを使用します。 - セッション アフィニティを
CLIENT_IP_PROTOまたはCLIENT_IPに設定した場合は、送信元ポートと宛先ポートがハッシュに使用されないことになるため、断片化されたパケットとされていないパケットの両方に対して同じハッシュが算出されます。
- セッション アフィニティを
- ロードバランスされた IP アドレスごとに、UDP 転送ルールを 1 つだけ使用します。これで、すべてのフラグメントが同じ転送ルールに渡されるようになります。
これらの設定により、同じパケットからの UDP フラグメントが同じインスタンスに転送されて再構成されます。
ターゲット インスタンスをバックエンドとして使用する
外部パススルー ネットワーク ロードバランサのバックエンドとしてターゲット インスタンスを使用していて、UDP パケットの断片化が想定される場合、ロードバランスされた IP アドレスごとに UDP 転送ルールを 1 つだけ使用して、すべてのポート（0～65535）でトラフィックを受け入れるように転送ルールを構成します。これにより、同じ宛先ポートがない場合でも、すべてのフラグメントが同じ転送ルールに到達するようになります。
制限事項
- Google Cloud コンソールでは、ターゲット プール ベースの外部パススルー ネットワーク ロードバランサを作成できません。代わりに、gcloud または REST API を使用してください。
- 外部パススルー ネットワーク ロードバランサは、VPC ネットワーク ピアリングをサポートしていません。
次のステップ
- Google Cloud Armor は、外部パススルー ネットワーク ロードバランサの高度なネットワーク DDoS 対策をサポートしています。詳細については、高度なネットワーク DDoS 対策を構成するをご覧ください。
- 外部パススルー ネットワーク ロードバランサを構成し、一連の Apache インスタンスにトラフィックを分散するには、ターゲット プールを使用して外部パススルー ネットワーク ロードバランサを設定するをご覧ください。
- 外部パススルー ネットワーク ロードバランサがターゲット プールではなくリージョン バックエンド サービスでどのように機能するかを確認するには、以下をご覧ください。