ターゲット プールベースの外部 TCP / UDP ネットワーク負荷分散の概要

Google Cloud の外部 TCP / UDP ネットワーク負荷分散(以降はネットワーク負荷分散と呼びます)は、プロキシを使用しないリージョンのロードバランサです。

ネットワーク負荷分散は、Virtual Private Cloud(VPC)ネットワーク内の同じリージョン内にあるバックエンド仮想マシン(VM)インスタンス間で TCP または UDP トラフィックを分散させます。ネットワーク ロードバランサは、以下からのトラフィックを受信できます。

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

各ネットワーク ロードバランサは、TCP トラフィックまたは UDP トラフィックのいずれかをサポートします。

ネットワーク ロードバランサのスコープは、グローバルではなくリージョンです。ネットワーク ロードバランサのすべてのバックエンド インスタンスは同じリージョンに配置する必要があります。バックエンドはリージョンの任意のゾーンに配置できます。

ネットワーク ロードバランサは、すべてのポートをサポートします。ネットワーク負荷分散を使用すると、TCP トラフィックと UDP トラフィックを負荷分散できます。ロードバランサはパススルー ロードバランサであるため、バックエンドは負荷分散された TCP 接続または UDP パケット自体を終端します。たとえば、バックエンドで HTTPS ウェブサーバーを実行し、ネットワーク負荷分散を使用してリクエストをルーティングすることで、バックエンド自体で TLS を終端できます。

アーキテクチャ

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

ネットワーク ロードバランサには、常に 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)にバインドするようにソフトウェアを構成する必要があります。

ネットワーク負荷分散は Cloud Load Balancing Autoscaler をサポートしています。バックエンド使用率に基づいてターゲット プール内のインスタンス グループに自動スケーリングを実行できます。詳細については、CPU 使用率に基づくスケーリングをご覧ください。

ターゲット プールに単一の VM インスタンスを含めるようにする場合、プロトコル転送機能の使用を検討する必要があります。

ターゲット プールは、TCP と UDP トラフィックを処理する転送ルールと組み合わせた場合のみ使用できます。その他のすべてのプロトコルには、ターゲット インスタンスを作成する必要があります。ターゲット プールを転送ルールと組み合わせて使用するには、その前にターゲット プールを新たに作成する必要があります。各プロジェクトには、最大 50 個のターゲット プールを設定できます。

転送ルール

転送ルールは、ターゲット プールと連携して機能し、負荷分散をサポートします。負荷分散を使用するには、特定のターゲット プールにトラフィックを転送する転送ルールを作成する必要があります。転送ルールを設定することなくトラフィックを負荷分散することはできません。

各転送ルールでは、特定の IP アドレス、プロトコル、ポート範囲(オプション)が、単一のターゲット プールと照合されます。転送ルールから提供される外部 IP アドレスにトラフィックが送信されると、そのトラフィックは転送ルールによって、対応するターゲット プールに送信されます。

Google Cloud VPC ネットワークに到達する前に断片化されたと考えられる UDP パケットを負荷分散する場合は、負荷分散と断片化された UDP パケットをご覧ください。

複数の転送ルール

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

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

  • 同じターゲット プールに複数の外部 IP アドレスを構成する必要がある。
  • 同じターゲット プールに同じ外部 IP アドレスを使用して、異なるポート範囲または異なるプロトコルを構成する必要がある。

複数の転送ルールを使用する場合は、必要なすべての IP アドレスにバインドするように、バックエンド VM で実行されるソフトウェアを構成します。これは、ロードバランサを介して配信されるパケットの宛先 IP アドレスが、それぞれのリージョン外部転送ルールに関連付けられているリージョン外部 IP アドレスであるためです。

ヘルスチェック

ヘルスチェックにより、Compute Engine は、稼働中で接続の受信準備ができたインスタンスに対してのみ、新しい接続を転送するようになります。Compute Engine は指定された頻度で各インスタンスにヘルスチェック リクエストを送信します。インスタンスでヘルスチェックの条件を満たさない回数が許容回数を超えると、そのインスタンスは新しいトラフィックの受信対象とみなされなくなります。

TCP 接続の正常なシャットダウンと終了を可能にするために、既存の接続がアクティブに終了されることはありません。ただし、異常なバックエンドへの既存の接続は、長期間使用可能であるとは限りません。可能であれば、できるだけ早く正常ではないバックエンドのシャットダウン プロセスを開始してください。

ヘルスチェックでは異常なインスタンスへのクエリが継続的に行われ、チェックの適合が指定された回数を超えると、インスタンスがプールに戻されます。すべてのインスタンスが UNHEALTHY とマークされている場合、ロードバランサは既存のすべてのインスタンスに新しいトラフィックを転送します。

ネットワーク負荷分散では、従来の HTTP ヘルスチェックを使用してインスタンスの状態を判断します。HTTP を使用しないサービスでも、ヘルスチェック システムが照会できるインスタンスごとに基本的なウェブサーバーを実行する必要があります。

従来の HTTPS ヘルスチェックはネットワーク ロードバランサに対応しておらず、他の種類のロードバランサでもほとんど使用できません。

リターンパス

Google Cloud では、VPC ネットワークで定義されていない特殊なルートがヘルスチェックに使用されます。詳細については、ロードバランサのリターンパスをご覧ください。

ファイアウォール ルール

ネットワーク ロードバランサのヘルスチェックは、これらの IP 範囲から送信されます。これらの範囲からのトラフィックを許可する、上り(内向き)許可ファイアウォール ルールを作成する必要があります。

ネットワーク負荷分散はパススルー ロードバランサです。これは、クライアントの送信元 IP アドレスからのトラフィックを許可するようにファイアウォール ルールを作成する必要があるということです。サービスがインターネットに公開されているのであれば、すべての IP 範囲からのトラフィックを許可するのが最も簡単です。特定の送信元 IP アドレスのみが許可されるようにアクセスを制限する場合は、ヘルスチェック IP 範囲からのアクセスを許可するファイアウォール ルールを設定する必要があります。

ファイアウォール ルールの例と構成例については、ネットワーク負荷分散のルールをご覧ください。

共有 VPC アーキテクチャ

次の表は、ネットワーク負荷分散の共有 VPC コンポーネントをまとめたものです。

IP アドレス 転送ルール バックエンド コンポーネント
リージョン外部 IP は、負荷分散されているインスタンスと同じプロジェクトで定義する必要があります。 リージョン転送ルールは、ターゲット プールのインスタンスと同じプロジェクト(サービス プロジェクト)で定義する必要があります。 ターゲット プールは、ターゲット プールのインスタンスと同じリージョンの同じプロジェクトで定義する必要があります。ターゲット プールに関連するヘルスチェックも同じプロジェクトで定義する必要があります。

トラフィック分散

ターゲット プールベースのネットワーク ロードバランサによる新しい接続の分散方法は、セッション アフィニティの構成方法によって異なります。

セッション アフィニティ

セッション アフィニティは、クライアントからロードバランサのバックエンド VM に新しい接続を分散するために使用されるハッシュ方法を制御します。ターゲット プールベースのネットワーク ロードバランサでは、sessionAffinity パラメータを使用してセッション アフィニティを構成します。

詳細については、ターゲット プールの使用をご覧ください。

負荷分散および断片化された UDP パケット

UDP パケットを負荷分散している場合は、以下の点に注意してください。

  1. 断片化されていないパケットは、すべての構成で通常通り処理されます。
  2. UDP パケットは Google Cloud に到達する前に断片化されることがあります。介在するネットワークは、すべてのフラグメントが到達してから転送するため遅延を引き起こすか、フラグメントをドロップすることがあります。Google Cloud はすべてのフラグメントの到着を待たず、個々のフラグメントを到達と同時に転送します。
  3. 後から到達する UDP フラグメントには宛先ポートが含まれないため、次のような場合に問題が発生します。

    • ターゲット プールのセッション アフィニティが NONE(5 タプル アフィニティ)に設定されている場合、ロードバランサでは 5 タプルハッシュを計算できないため、後から到達するフラグメントがドロップされることがあります。
    • 負荷分散された 1 つの IP アドレスに複数の UDP 転送ルールが設定されていると、後から到達するフラグメントが間違った転送ルールに到達することがあります。

断片化された UDP パケットを処理する可能性がある場合は、次の手順を行います。

  • セッション アフィニティを NONECLIENT_IP_PROTOCLIENT_IP のいずれかに設定します。
    • セッション アフィニティを NONE に設定すると、アフィニティを維持する必要がなくなります。このため、ロードバランサは 5 タプルハッシュを使用して断片化されていないパケット用のバックエンドを選択しますが、断片化されたパケットについては 3 タプルハッシュを使用します。
    • セッション アフィニティを CLIENT_IP_PROTO または CLIENT_IP に設定した場合は、送信元ポートと宛先ポートがハッシュに使用されないことになるため、断片化されたパケットとされていないパケットの両方に対して同じハッシュが算出されます。
  • 負荷分散された IP アドレスごとに、UDP 転送ルールを 1 つだけ使用します。これで、すべてのフラグメントが同じ転送ルールに渡されるようになります。

これらの設定により、同じパケットからの UDP フラグメントが同じインスタンスに転送されて再構成されます。

ターゲット インスタンスをバックエンドとして使用する

ネットワーク ロードバランサのバックエンドとしてターゲット インスタンスを使用していて、UDP パケットの断片化が想定される場合、負荷分散された IP アドレスごとに UDP 転送ルールを 1 つだけ使用して、0~65535 のすべてのポートでトラフィックを受け入れるように転送ルールを構成します。これにより、同じ宛先ポートがない場合でも、すべてのフラグメントが同じ転送ルールに到達するようになります。

次のステップ