外部 TCP / UDP ネットワーク負荷分散の概要

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

ネットワーク負荷分散は、Virtual Private Cloud(VPC)ネットワークの同じリージョン内の仮想マシン(VM)インスタンス間でトラフィックを分散します。ネットワーク ロードバランサは TCP または UDP トラフィックをリージョン バックエンド間で転送します。

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

サポートされているポートの詳細については、Google Cloud ロードバランサの概要をご覧ください。

ネットワーク負荷分散には次の特長があります。

  • ネットワーク負荷分散はマネージド サービスです。
  • ネットワーク負荷分散は、Andromeda 仮想ネットワーキングGoogle Maglev で実装されます。
  • ネットワーク ロードバランサはプロキシではありません。
  • バックエンド VM からのレスポンスは、ロードバランサを経由せず、クライアントに直接送信されます。業界用語では、これを Direct Server Return と呼んでいます。
  • ロードバランサはパケットの送信元 IP アドレスを保持します。
  • パケットの宛先 IP アドレスは、ロードバランサの転送ルールに関連付けられたリージョンの外部 IP アドレスです。

したがって:

  • ネットワーク ロードバランサのバックエンド VM として参加するインスタンスでは、適切な Linux ゲスト環境Windows ゲスト環境、または同等の機能を提供する他のプロセスが実行されている必要があります。

    ゲスト OS 環境(または同等のプロセス)ではバックエンド VM ごとにローカルルートを構成します。このルートにより、宛先がロードバランサの転送ルールの IP アドレスと一致するパケットを VM で受信できるようになります。

  • 負荷分散トラフィックを受け入れるバックエンド インスタンスでは、ロードバランサの転送ルールに関連付けられた IP アドレス(または任意の IP アドレス 0.0.0.0/0)にバインドするようにソフトウェアを構成する必要があります。

次の図に、カリフォルニア、ニューヨーク、シンガポールのユーザーを示します。これらのユーザーは、myapp、test、travel というバックエンド リソースに接続しています。範囲がエニーキャストになっているため、シンガポールのユーザーが米国西部のバックエンドに接続しても、トラフィックは最も近いシンガポールに送信されます。そこから、トラフィックはリージョン バックエンドにルーティングされます。

3 つのリージョン バックエンドと 3 つの転送ルール(クリックして拡大)
ネットワーク負荷分散の例(クリックして拡大)

Google Cloud ロードバランサとの相違点については、次のドキュメントをご覧ください。

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

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

ネットワーク ロードバランサはインターネットからのトラフィックを分散します。

ネットワーク ロードバランサのスコープは、グローバルではなくリージョンです。つまり、ネットワーク ロードバランサが複数のリージョンにまたがることはできません。ロードバランサは単一リージョン内のすべてのゾーンにサービスを提供します。

ユースケース

ネットワーク負荷分散は次のような状況で使用します。

  • UDP トラフィックの負荷分散が必要な場合。または、他のロードバランサでサポートされていない TCP ポートの負荷分散が必要な場合。
  • ロードバランサではなく、バックエンドで SSL トラフィックの復号を行う場合。ネットワーク負荷分散はこのタスクを実行できません。SSL トラフィックをバックエンドで復号すると、VM の CPU 使用量が非常に多くなります。
  • ロードバランサの SSL 証明書を自己管理する場合。Google マネージド SSL 証明書は HTTP(S) 負荷分散と SSL プロキシ負荷分散でのみ使用できます。
  • プロキシを経由せずに元のパケットを転送する必要がある場合。
  • 既存の環境でパススルー ロードバランサを使用していて、これを変更せずに移行する場合。

アーキテクチャ

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

ネットワーク ロードバランサには、常に 1 つのターゲット プールがあります。複数の転送ルールからターゲット プールを参照できます。

ターゲット プールは、ロードバランサのバックエンドです。負荷分散されるトラフィック間のバックエンド インスタンスを指定します。各転送ルールは、ロードバランサのフロントエンドです。プロジェクトあたりの転送ルールとターゲット プールの数には制限がある点にご注意ください。

ネットワーク ロードバランサは、アドレス、ポート、プロトコル タイプなどの受信 IP プロトコル データに基づいてシステムの負荷を分散します。

ネットワーク ロードバランサはパススルー ロードバランサであるため、バックエンドは元のクライアント リクエストを受け取ります。ネットワーク ロードバランサは、Transport Layer Security(TLS)のオフロードやプロキシを行いません。トラフィックは VM に直接ルーティングされます。

ロードバランサの転送ルールを作成するときに、エフェメラル仮想 IP アドレス(VIP)を受信するか、リージョン ネットワーク ブロックから派生する VIP を予約します。

次に、その転送ルールをターゲット プールに関連付けます。VIP は、世界的に展開されている Google の拠点からエニーキャストされますが、ネットワーク ロードバランサのバックエンドはリージョンです。ロードバランサに複数のリージョンにまたがるバックエンドを指定することはできません。

Google Cloud ファイアウォールを使用して、バックエンド VM へのアクセスを制御またはフィルタできます。

ネットワーク ロードバランサは、送信元ポート、宛先ポート、IP アドレス、プロトコルを調べて、パケットの転送方法を決定します。TCP トラフィックの場合は、セッション アフィニティを設定することで、ロードバランサの転送動作を変更できます。

負荷分散アルゴリズム

デフォルトでは、トラフィックを複数のインスタンスに分散するため、セッション アフィニティ値が NONE に設定されています。Cloud Load Balancing は、送信元 IP とポート、宛先 IP とポート、プロトコルのハッシュに基づいてインスタンスを選択します。これは、受信 TCP 接続トラフィックが複数のインスタンスにまたがっており、新しい接続トラフィックがそれぞれ別のインスタンスに送信される可能性があることを意味します。接続が閉じられるまで、接続のすべてのパケットは同じインスタンスに振り向けられます。確立済みの接続は負荷分散時に考慮されません。

セッション アフィニティの設定に関係なく、接続が閉じられるまで、接続のすべてのパケットは選択されたインスタンスに送信されます。既存の接続は、新しい受信接続に対する負荷分散の決定に影響を受けません。その結果、長期的な TCP 接続が使用されている場合、バックエンド間で不均衡が生じる可能性があります。

単一クライアントからの複数の接続トラフィックのパケットを同じインスタンスに送信する場合は、異なるセッション アフィニティ値を設定できます。

ターゲット プール

ターゲット プールリソースは、転送ルールから受信トラフィックを受け取るインスタンスのグループを定義します。転送ルールがトラフィックをターゲット プールに送信する際は、Cloud Load Balancing が送信元 IP とポート、宛先 IP とポートのハッシュに基づいて、そのターゲット プールからインスタンスを選択します。インスタンスへのトラフィックの分散についての詳細は、このトピックの負荷分散アルゴリズムのセクションをご覧ください。

ネットワーク ロードバランサは、バックエンド インスタンスのプライマリ ネットワーク インターフェース(nic0)にのみトラフィックを分散します。

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

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

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

転送ルール

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

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

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

複数の転送ルール

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

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

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

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

ヘルスチェック

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

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

複数のヘルスチェック プローバーが、構成可能なチェック間隔に従って各バックエンドをチェックします。詳細については、ヘルスチェックの仕組みをご覧ください。

すべてのターゲット プール VM が正常でない場合にネットワーク ロードバランサがどのように接続を分散するかは、バックアップ プールが構成されているかどうかによって異なります。

  • バックアップ プールが構成されていない場合、ターゲット プール内のすべてのバックエンド VM が正常でないとき、ロードバランサは最後の手段として、ターゲット プール内のすべてのバックエンド VM 間で新しい接続を分散します。

  • バックアップ プールが構成されている場合、ターゲット プール内のすべてのバックエンド VM が正常でないとき、トラフィックはバックアップ プール内の VM に転送されます。バックアップ プール内の VM が正常でない場合については、フェイルオーバーの条件をご覧ください。

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

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

リターンパス

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

ファイアウォール ルール

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

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

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

セッション アフィニティ

ネットワーク負荷分散では、バックエンド サービスのセッション アフィニティを利用しません。ネットワーク負荷分散では、セッション アフィニティのためにターゲット プールを使用します。

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

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

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

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

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

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

  • セッション アフィニティを CLIENT_IP_PROTOCLIENT_IP に設定します。NONE(5 タプルハッシュ)は使用しません。CLIENT_IP_PROTOCLIENT_IP はハッシュに宛先ポートを使用しないため、後から到達するフラグメントに対して、最初のフラグメントと同じハッシュを計算できます。
  • 負荷分散された IP アドレスごとに、UDP 転送ルールを 1 つだけ使用します。これで、すべてのフラグメントが同じ転送ルールに渡されるようになります。

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

共有 VPC

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

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

次のステップ