ネットワーク負荷分散のコンセプト

ネットワーク負荷分散は、プロキシを使用しないリージョンのロードバランサです。

概要

Google Cloud Platform(GCP)ネットワーク負荷分散は、VPC ネットワークの同じリージョン内の VM インスタンス間でトラフィックを分散します。

ネットワーク ロードバランサでは、転送ルールに従って TCP / UDP トラフィックをリージョン バックエンドの間で分散します。

ネットワーク負荷分散を使用すると、TCP プロキシSSL プロキシのロードバランサでサポートされていないポートで UDP、TCP、SSL のトラフィックを負荷分散できます。

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

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

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

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

ネットワーク ロードバランサは、ターゲット プールを使用してトラフィックの負荷分散を行います。

ネットワーク ロードバランサはインターネットからのトラフィックを分散します。GCP 内のインスタンス間で発生するトラフィックの負荷分散は行いません。

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

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

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

Cloud Load Balancer との相違点については、負荷分散の選択負荷分散の概要をご覧ください。

ネットワーク負荷分散について

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

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

したがって:

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

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

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

アーキテクチャ

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

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

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

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

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

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

負荷分散アルゴリズム

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

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

クライアントからの複数の接続が同じインスタンスに向かうことが必要な場合、別のセッション アフィニティの設定を選択できます。詳しくは、ターゲット プールのドキュメントの sessionAffinity をご覧ください。

ターゲット プール

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

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

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

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

詳しくは、ターゲット プールとその設定方法をご覧ください。

転送ルール

転送ルールはターゲット プールおよびターゲット インスタンスと連携して機能し、負荷分散機能とプロトコル転送機能をサポートします。負荷分散とプロトコル転送を使用するには、トラフィックを特定のターゲット プール(負荷分散の場合)またはターゲット インスタンス(プロトコル転送の場合)に振り向ける転送ルールを作成する必要があります。転送ルールを設定することなく、これらの機能を使用することはできません。

転送ルールのリソースは転送ルールのコレクションに含まれています。各転送ルールでは、特定の IP アドレス、プロトコル、およびポート範囲(オプション)と、単一のターゲット プールまたはターゲット インスタンスが照合されます。トラフィックが転送ルールから提供される外部 IP アドレスに送信されると、転送ルールによって、対応するターゲット プールまたはターゲット インスタンスにそのトラフィックが振り向けられます。プロジェクトごとに、最大 50 個の転送ルール オブジェクトを作成できます。

詳しくは、転送ルールとその設定方法をご覧ください。

Google Cloud Platform(GCP)Virtual Private Cloud(VPC)ネットワークに到達する前に断片化する可能性のある UDP パケットの負荷を分散する場合は、負荷分散および断片化された UDP パケットをご覧ください。

複数の転送ルール

同じネットワーク TCP/UDP ロードバランサに複数のリージョン外部転送ルールを構成できます。各転送ルールでは、固有のリージョン外部 IP アドレスを指定できます。また、複数の転送ルールで同じリージョン外部 IP アドレスを参照することもできます。複数の転送ルールは同じターゲット プロキシを参照できます。

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

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

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

ヘルスチェック

ヘルスチェックを行うと、稼働中で接続の受信準備ができたインスタンスに対してのみ、Compute Engine が新しい接続を転送するようになります。Compute Engine は指定された頻度で各インスタンスにヘルスチェック リクエストを送信します。インスタンスでヘルスチェック失敗が許容回数を超えると、そのインスタンスは新しいトラフィックの受信対象とみなされなくなります。既存の接続がアクティブに終了されることはないので、インスタンスは正常にシャットダウンして TCP 接続を閉じることができます。

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

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

リターンパス

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

ファイアウォール ルールとネットワーク負荷分散

ネットワーク ロードバランサのヘルスチェックは、次の IP 範囲から送信されます。この範囲からのトラフィックを許可する上り許可ファイアウォール ルールを作成する必要があります。ファイアウォールルールの例については、ネットワーク負荷分散のルールをご覧ください。

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

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

セッション アフィニティ

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

ターゲット プールsessionAffinity パラメータをご覧ください。

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

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

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

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

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

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

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

次のステップ

一連の Apache インスタンスにトラフィックを分散させる方法については、ネットワーク負荷分散の設定をご覧ください。

使ってみる

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...