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

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

ネットワーク負荷分散は、Virtual Private Cloud(VPC)ネットワークの同じリージョン内の仮想マシン(VM)インスタンス間でトラフィックを分散します。ネットワーク ロードバランサは TCP または UDP トラフィックをリージョン バックエンド間で転送します。ネットワーク負荷分散を使用すると、TCP プロキシ ロードバランサSSL プロキシ ロードバランサでサポートされていないポートで UDP、TCP、SSL のトラフィックを負荷分散できます。

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

  • ネットワーク負荷分散はマネージド サービスです。
  • ネットワーク負荷分散は、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 Load Balancing との相違点については、次のドキュメントを参照してください。

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

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

ネットワーク ロードバランサは、ターゲット プールを使用して、負荷分散されるトラフィック間のバックエンド インスタンスを含めます。

ネットワーク ロードバランサはインターネットからのトラフィックを分散します。インスタンス間において Google Cloud 内で発生するトラフィックの負荷分散には使用できません。

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

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

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

アーキテクチャ

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

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

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

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

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

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

負荷分散アルゴリズム

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

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

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

ターゲット プール

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

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

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

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

転送ルール

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

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

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

複数の転送ルール

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

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

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

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

ヘルスチェック

ヘルスチェックを行うことで、Compute Engine が、新しい接続トラフィックを受信する準備ができているインスタンスにのみ転送することを確認できます。Compute Engine は指定された頻度で各インスタンスにヘルスチェック リクエストを送信します。インスタンスでヘルスチェックの条件を満たさない回数が許容回数を超えると、そのインスタンスは新しいトラフィックの受信対象とみなされなくなります。既存の接続が突然解除されることがなくなるため、インスタンスは正常にシャットダウンして TCP 接続を閉じることができます。

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

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

リターンパス

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 フラグメントが同じインスタンスに転送されて再構成されます。

次のステップ