内部 TCP / UDP 負荷分散の概要

Google Cloud 内部 TCP / UDP 負荷分散は、Andromeda ネットワーク仮想化スタック上に構築されたリージョン ロードバランサです。

内部 TCP / UDP 負荷分散は、Virtual Private Cloud(VPC)ネットワークの同じリージョンに存在する内部仮想マシン(VM)インスタンス間でトラフィックを分散します。これにより、同じ VPC ネットワークのシステムまたは VPC ネットワークに接続しているシステムのみがアクセス可能な内部 IP アドレスの背後でサービスを実行し、スケーリングできます。

内部 TCP / UDP 負荷分散サービスには、フロントエンド(転送ルール)とバックエンド(バックエンド サービス)があります。バックエンド サービスのバックエンドとしてインスタンス グループまたは GCE_VM_IP ゾーン NEG を使用できます。この例は、インスタンス グループのバックエンドを示しています。

内部 TCP / UDP ロードバランサの例の概要図。
内部 TCP / UDP ロードバランサの例の概要図(クリックして拡大)

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

ユースケース

内部 TCP / UDP 負荷分散は次のような状況で使用します。

  • TCP または UDP トラフィック用に、高パフォーマンスのパススルー レイヤ 4 ロードバランサが必要な場合。
  • TLS(SSL)を介してトラフィックを処理する場合は、ロードバランサの代わりにバックエンドによって SSL トラフィックを終端させることもできます。内部 TCP / UDP ロードバランサは、SSL トラフィックを終端させることはできません。

  • プロキシを経由せずに元のパケットを転送する必要がある場合。たとえば、クライアントの送信元 IP アドレスを保持する必要がある場合が該当します。

  • 既存の環境でパススルー ロードバランサを使用していて、これを変更せずに移行する場合。

内部 TCP / UDP ロードバランサは、多くのユースケースに対応しています。このセクションでは、そのいくつかについて説明します。

アクセスの例

接続ネットワークから VPC ネットワーク内の内部 TCP / UDP ロードバランサにアクセスする方法は、次のとおりです。

  • VPC ネットワーク ピアリング
  • Cloud VPN と Cloud Interconnect

詳細例については、内部 TCP / UDP 負荷分散と接続されたネットワークをご覧ください。

3 層ウェブサービスの例

内部 TCP / UDP 負荷分散は、他のロードバランサと組み合わせて使用できます。たとえば、外部 HTTP(S) ロードバランサを使用する場合、外部 HTTP(S) ロードバランサはウェブ階層であり、内部 TCP / UDP ロードバランサの背後にあるサービスに依存します。

次の図は、外部 HTTP(S) ロードバランサと内部 TCP / UDP ロードバランサを使用する 3 層構成の例を示しています。

HTTP(S) 負荷分散と内部 TCP / UDP 負荷分散を使用する 3 層ウェブアプリ。
HTTP(S) 負荷分散と内部 TCP / UDP 負荷分散を使用する 3 層ウェブアプリ(クリックして拡大)

グローバル アクセスを使用する 3 層ウェブサービスの例

グローバル アクセスを有効にすると、次の図のように別のリージョンにウェブ層 VM を配置できます。

この多層アプリケーションの例のフローは、次のとおりです。

  • グローバルに利用可能な、インターネットに接続したウェブ層が、HTTP(S) 負荷分散を使用して負荷分散を行う。
  • us-east1 リージョンの内部バックエンド負荷分散されたデータベース層に、グローバル ウェブ層がアクセスする。
  • europe-west1 リージョンのウェブ層の一部であるクライアント VM が、us-east1 にある内部負荷分散されたデータベース層にアクセスする。
HTTP(S) 負荷分散、グローバル アクセス、内部 TCP / UDP 負荷分散を使用する 3 層ウェブアプリ。
HTTP(S) 負荷分散、グローバル アクセス、内部 TCP / UDP 負荷分散を使用する 3 層ウェブアプリ(クリックして拡大)

ネクストホップとしての内部 TCP / UDP ロードバランサの使用

内部 TCP / UDP ロードバランサは、最終宛先へのパスに沿ってパケットを転送する際の次のゲートウェイとして使用できます。これを行うには、カスタム静的ルートでロードバランサをネクストホップに設定します。

カスタムルートでネクストホップとしてデプロイされた内部 TCP / UDP ロードバランサは、プロトコル(TCP、UDP、ICMP)に関係なくすべてのトラフィックを処理します。

次に、NAT ゲートウェイへのネクストホップとして内部 TCP / UDP ロードバランサを使用するサンプル アーキテクチャを示します。内部 TCP / UDP ロードバランサを介してファイアウォールまたはゲートウェイ仮想アプライアンス バックエンドにトラフィックをルーティングできます。

NAT のユースケース(クリックして拡大)
NAT のユースケース(クリックして拡大)

その他のユースケースには次のものがあります。

  • ハブアンドスポーク: VPC ネットワーク ピアリングを使用したネクストホップ ルートの交換 - hub VPC ネットワークに配置されたネクストホップ ファイアウォール仮想アプライアンスで、ハブアンドポーク トポロジを構成できます。ロードバランサを hub VPC ネットワークのネクストホップとして使用するルートは、各 spoke ネットワークで使用できます。
  • バックエンド VM 上の複数の NIC への負荷分散。

これらのユースケースの詳細については、ネクストホップとしての内部 TCP / UDP ロードバランサをご覧ください。

内部 TCP / UDP 負荷分散の仕組み

内部 TCP / UDP ロードバランサには次の特性があります。

  • マネージド サービスである。
  • プロキシではない。
  • 仮想ネットワークで実装される。

プロキシ ロードバランサとは異なり、内部 TCP / UDP ロードバランサは、クライアントからの接続を終了せずに、バックエンドへの新しい接続を開きます。代わりに、内部 TCP / UDP ロードバランサは、元の接続をクライアントから正常なバックエンドに中断されることなく直接転送します。

  • 中間デバイスや単一障害点が存在しない。
  • ロードバランサの IP アドレスへのクライアント リクエストは、直接正常なバックエンド VM に送信されます。
  • 正常なバックエンド VM からのレスポンスは、ロードバランサを経由せず、クライアントに直接送信されます。TCP 応答は、Direct Server Return を使用します。詳細については、TCP と UDP のリクエストと返信パケットをご覧ください。

ロードバランサは、ヘルスチェック プローブを使用して VM の状態を監視します。詳細については、ヘルスチェックをご覧ください。

Google Cloud Linux ゲスト環境Windows ゲスト環境、またはそれと同様のプロセスは、各バックエンド VM をロードバランサの IP アドレスで構成します。Google Cloud イメージから作成された VM では、ゲスト エージェント(旧称 Windows ゲスト環境または Linux ゲスト環境)によって、ロードバランサの IP アドレスのローカルルートがインストールされます。Container-Optimized OS をベースとした Google Kubernetes Engine インスタンスは、代わりに iptables を使用してこれを実装します。

Google Cloud の仮想ネットワーキングが、トラフィック配信とスケーリングを適切に管理します。

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

内部 TCP / UDP ロードバランサがそれぞれサポートしているものは、次のとおりです。

内部 TCP / UDP ロードバランサがサポートしていないものは、次のとおりです。

クライアント アクセス

クライアント VM は同じネットワークまたは、VPC ネットワーク ピアリングを使用して接続された VPC ネットワークに存在する必要があります。グローバル アクセスを有効にすると、任意のリージョンのクライアント VM インスタンスが内部 TCP / UDP ロードバランサにアクセスできるようになります。

次の表にクライアント アクセスの概要を示します。

グローバル アクセスが無効な場合 グローバル アクセスが有効な場合
クライアントはロードバランサと同じリージョンになければなりません。また、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。 クライアントはどのリージョンにでも配置できます。ただし、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。
オンプレミスのクライアントは Cloud VPN トンネルまたは相互接続のアタッチメント(VLAN)経由でロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、ロードバランサと同じリージョンになければなりません。 オンプレミスのクライアントは Cloud VPN トンネルまたは相互接続のアタッチメント(VLAN)経由でロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、どのリージョンにでも配置できます。

リクエスト パケットと返信パケットの IP アドレス

クライアント システムが TCP または UDP パケットを内部 TCP / UDP ロードバランサに送信すると、パケットの送信元と宛先は次のようになります。

  • 送信元: クライアントのプライマリ内部 IP アドレスまたはクライアントのエイリアス IP 範囲の IP アドレス。
  • 宛先: ロードバランサの転送ルールの IP アドレス。

パケットは、ロードバランサ自体の宛先 IP アドレスを持つロードバランサのバックエンド VM に到達します。このタイプのロードバランサはプロキシではありません。これは想定された動作です。したがって、ロードバランサのバックエンド VM で実行されるソフトウェアは、以下の処理を実行する必要があります。

  • ロードバランサの IP アドレスまたは任意の IP アドレス(0.0.0.0 または ::)でのリッスン(バインド)
  • ロードバランサの転送ルールに含まれるポートでのリッスン(バインド)

戻りパケットは、ロードバランサのバックエンド VM からクライアントに直接送信されます。リターン パケットの送信元アドレスと宛先 IP アドレスはプロトコルによって異なります。

  • TCP は接続指向であり、内部 TCP / UDP ロードバランサは Direct Server Return を使用します。つまり、レスポンス パケットはロードバランサの転送ルールの IP アドレスから送信されます。
  • 対照的に、UDP はコネクションレスです。デフォルトでは、返信パケットはバックエンド インスタンスのネットワーク インターフェースのプライマリ内部 IP アドレスから送信されます。ただし、この動作は変更できます。たとえば、UDP サーバーを転送ルールの IP アドレスにバインドするように構成すると、転送ルールの IP アドレスからレスポンス パケットが送信されます。

次の表は、レスポンス パケットの送信元と宛先をまとめたものです。

トラフィックの種類 送信元 宛先
TCP ロードバランサの転送ルールの IP アドレス リクエスト パケットの送信元
UDP UDP サーバー ソフトウェアによって異なります リクエスト パケットの送信元

アーキテクチャ

複数のバックエンドを持つ内部 TCP / UDP ロードバランサは、すべてのバックエンド間で接続を分散します。分散の方法と構成オプションの詳細は、トラフィックの分散をご覧ください。

内部 TCP / UDP ロードバランサのバックエンドとして、インスタンス グループまたはゾーン NEG を使用できますが、両方を組み合わせることはできません。

  • インスタンス グループを選択した場合は、非マネージド インスタンス グループ、マネージド ゾーン インスタンス グループ、マネージド リージョン インスタンス グループ、またはこれらのインスタンス グループ タイプの組み合わせを使用できます。
  • ゾーン NEG を選択する場合は、GCE_VM_IP ゾーン NEG を使用する必要があります。

高可用性では、単一のゾーンに依存しない内部ロードバランサを設計する方法について説明しています。

内部 TCP / UDP ロードバランサのバックエンド VM として参加するインスタンスでは、適切な Linux または Windows ゲスト環境、または同等の機能を提供する他のプロセスが実行されている必要があります。これらのゲスト環境では、メタデータ サーバー(metadata.google.internal169.254.169.254)に接続し、インスタンスのメタデータを読み取ることが可能である必要があります。これによって、ロードバランサの内部 IP アドレスに送信されるトラフィックを受け入れるローカルルートを生成できます。

この図は、2 つの個別のインスタンス グループに存在する VM 間のトラフィック分散を示しています。クライアント インスタンスからロードバランサの IP アドレス(10.10.10.9)に送信されたトラフィックが、いずれかのインスタンス グループのバックエンド VM 間で分散されます。サービスを提供するいずれかのバックエンド VM から送信されたレスポンスがクライアント VM に直接配信されます。

内部 TCP / UDP 負荷分散は、カスタムモードまたは自動モードの VPC ネットワークで使用できます。既存のレガシー ネットワークで内部 TCP / UDP ロードバランサを作成することもできます。

内部 TCP / UDP ロードバランサは、次の Google Cloud コンポーネントから構成されます。

コンポーネント 目的 要件
内部 IP アドレス ロードバランサのアドレスです。 内部 IP アドレスは、内部転送ルールと同じサブネット内に存在する必要があります。サブネットは、バックエンド サービスと同じリージョンと VPC ネットワークに存在する必要があります。
内部転送ルール 内部転送ルールを内部 IP アドレスと組み合わせると、ロードバランサのフロントエンドになります。ロードバランサが受け入れるプロトコルとポートを定義し、トラフィックをリージョンの内部バックエンド サービスにルーティングします。 内部 TCP / UDP ロードバランサの転送ルールは、次の条件を満たす必要があります。
load-balancing-schemeINTERNAL と指定されている。
• バックエンド サービスの protocol に一致する TCP または UDPip-protocol を使用する。
• バックエンド サービスと同じ VPC ネットワークとリージョン内の subnet を参照する。
リージョンの内部バックエンド サービス リージョンの内部バックエンド サービスは、バックエンドとの通信に使用するプロトコルを定義し、ヘルスチェックを指定します。バックエンドには、非マネージド インスタンス グループ、マネージド ゾーン インスタンス グループ、マネージド リージョン インスタンス グループ、GCE_VM_IP エンドポイントを使用したゾーン NEG があります。 バックエンド サービスは、次の条件を満たす必要があります。
load-balancing-schemeINTERNAL と指定されている。
• 転送ルールの ip-protocol に一致する TCP または UDPprotocol を使用する。
• 関連付けられたヘルスチェックを含む。
• 関連付けられたリージョンを含む。転送ルールとすべてのバックエンドは、バックエンド サービスと同じリージョンに存在する必要があります
• 単一の VPC ネットワークに関連付けられている必要があります。指定されていない場合、各バックエンド VM のデフォルトのネットワーク インターフェース(nic0)で使用されるネットワークに基づいてネットワークが推定されます。

バックエンドサービスは特定のサブネットには結びつけられませんが、転送ルールのサブネットは、バックエンド サービスと同じ VPC ネットワークにある必要があります。
ヘルスチェック バックエンド サービスはいずれもヘルスチェックが関連付けられている必要があります。ヘルスチェックでは、Google Cloud が管理しているバックエンドについて、トラフィックの受信に適格であるかどうかを検討する際に使用するパラメータを定義します。正常なバックエンド VM のみが、クライアント VM からロードバランサの IP アドレスに送信されたトラフィックを受信します。
転送ルールとバックエンド サービスでは TCPUDP のいずれかを使用できます。ただし、Google Cloud では UDP トラフィックに対するヘルスチェックが行われません。詳細は、ヘルスチェックと UDP トラフィックをご覧ください。

内部 IP アドレス

内部 TCP / UDP 負荷分散では、内部転送ルールを作成するときに選択したサブネットのプライマリ IP 範囲に含まれる内部 IPv4 アドレスが使用されます。サブネットのセカンダリ IP 範囲の IP アドレスは使用できません。

内部 TCP / UDP ロードバランサの IP アドレスは、転送ルールを作成するときに指定します。エフェメラル IP アドレスを受信するか、予約済みの IP アドレスを使用するかを選択できます。

ファイアウォール ルール

内部 TCP / UDP ロードバランサには、次のファイアウォール ルールが必要です。

ファイアウォール ルールの構成の例では、両方の作成方法を示しています。

転送ルール

転送ルールでは、ロードバランサがトラフィックを受け入れるポートとプロトコルを指定します。内部 TCP / UDP ロードバランサはプロキシではないため、同じプロトコルとポートでバックエンドにトラフィックを渡します。

内部 TCP / UDP ロードバランサには、少なくとも 1 つの内部転送ルールが必要です。同じロードバランサに対して複数の転送ルールを定義できます。

転送ルールは、ロードバランサのバックエンド コンポーネントと同じ VPC ネットワークとリージョン内の特定のサブネットを参照する必要があります。この要件に関しては、次の点に注意してください。

  • 転送ルールに指定するサブネットは、バックエンド VM で使用されるどのサブネットとも同じである必要はありません。ただし、サブネットは転送ルールと同じリージョンにある必要があります。
  • 内部転送ルールを作成すると、選択したサブネットのプライマリ IP アドレス範囲から、使用可能なリージョンの内部 IP アドレスを Google Cloud が選択します。また、サブネットのプライマリ IP 範囲から内部 IP アドレスを指定することもできます。

転送ルールとグローバル アクセス

グローバル アクセスが有効な場合であっても、内部 TCP / UDP ロードバランサの転送ルールはリージョン単位です。グローバル アクセスを有効にすると、リージョンの内部転送ルールの allowGlobalAccess フラグが true に設定されます。

転送ルールとポートの仕様

内部転送ルールを作成する場合は、次のいずれかのポート指定を選択する必要があります。

  • 1 個から 5 個までのポートを番号で指定する。
  • すべてのポートにトラフィックを転送するには ALL を指定する。

すべての TCP ポートまたはすべての UDP ポートのいずれかをサポートする内部転送ルールでは、バックエンド VM がそれぞれ別のポートで複数のアプリケーションを実行できます。特定のポートに送信されたトラフィックは、対応するアプリケーションに配信され、すべてのアプリケーションで同じ IP アドレスが使用されます。

5 つより多い特定のポートでトラフィックを転送する必要がある場合は、ファイアウォール ルールを転送ルールと組み合わせます。転送ルールを作成するときは、すべてのポートを指定してから、必要なポートへのトラフィックのみを許可する上り(内向き)allow ファイアウォール ルールを作成します。ファイアウォール ルールをバックエンド VM に適用します。

転送ルールは作成後に変更できません。指定したポートまたは内部転送ルールの内部 IP アドレスを変更する必要がある場合は、削除してから再度作成する必要があります。

単一のバックエンド サービスの複数の転送ルール

すべてが同じ内部バックエンド サービスを参照する複数の内部転送ルールを構成できます。内部 TCP / UDP ロードバランサには、少なくとも 1 つの内部転送ルールが必要です。

同じバックエンド サービスに複数の転送ルールを構成すると、TCP または UDP(両方ではない)のいずれかを使用して、次のことが可能になります。

  • ロードバランサに複数の IP アドレスを割り当てる。それぞれに一意の IP アドレスを使用した、複数の転送ルールを作成できます。各転送ルールでは、すべてのポートまたは最大 5 つのポートを指定できます。

  • 同じ IP アドレスを使用する特定のポートセットをロードバランサに割り当てる。同じ IP アドレスを共有する複数の転送ルールを作成し、各転送ルールで特定の最大 5 つのポートを使用するように設定できます。単一の転送ルールですべてのポートを指定する代わりに、この方法を使用できます。

共通の内部 IP アドレスを共有する 2 つ以上の内部転送ルールに関するシナリオについては、同じ IP アドレスを持つ複数の転送ルールをご覧ください。

複数の内部転送ルールを使用する場合は、バックエンド VM で実行されているソフトウェアがすべての転送ルール IP アドレスまたは任意のアドレス(0.0.0.0/0)にバインドするように構成してください。ロードバランサを通じて配信されるパケットの宛先 IP アドレスは、対応する内部転送ルールに関連付けられた内部 IP アドレスです。詳細については、TCP と UDP のリクエストと返信パケットをご覧ください。

バックエンド サービス

それぞれの内部 TCP / UDP ロードバランサには、バックエンドのパラメータと動作を定義するリージョン内部転送ルールが 1 つあります。バックエンド サービスの名前は、Google Cloud Console に表示される内部 TCP / UDP ロードバランサの名前です。

各バックエンド サービスは、次のバックエンド パラメータを定義します。

  • プロトコル。バックエンド サービスは、1 つ以上の内部転送ルールで指定されたポートで TCP トラフィックまたは UDP トラフィックのいずれか一方のみを受け取ります。バックエンド サービスでは、トラフィックが送信された同じポート上のバックエンド VM にトラフィックを配信できます。バックエンド サービス プロトコルは、転送ルールのプロトコルと一致する必要があります。

  • トラフィック分散。バックエンド サービスは、構成可能なセッション アフィニティに従ってトラフィックの分散を許可します

  • ヘルスチェック。バックエンド サービスには、関連付けられたヘルスチェックが必要です。

各バックエンド サービスは単一のリージョンで動作し、1 つの VPC ネットワーク内でバックエンド VM のトラフィックを分散します。

バックエンド サービスとネットワーク インターフェース

各バックエンド サービスは、1 つの VPC ネットワークと Google Cloud リージョンで動作します。VPC ネットワークは暗黙にすることも、gcloud compute backend-services create コマンドで --network フラグを使用して明示的に指定することもできます。

  • 明示的に指定すると、バックエンド サービスの VPC --network フラグが、トラフィックの負荷分散が行われる各バックエンド VM のネットワーク インターフェースを識別します。各バックエンド VM には、指定された VPC ネットワーク内のネットワーク インターフェースが必要です。この場合、ネットワーク インターフェース識別子(nic0nic7)がバックエンド VM 間で異なる場合があります。バックエンドのタイプに応じて、次の点に注意してください。

    インスタンス グループのバックエンド

    • VM ごとに指定された VPC ネットワーク内にインターフェースがある場合、同じ非マネージド インスタンス グループ内の異なるバックエンド VM は異なるインターフェース識別子を使用する場合があります。
    • インターフェース識別子は、すべてのバックエンド インスタンス グループ間で同じである必要はありません。あるバックエンド インスタンス グループ内のバックエンド VM では nic0、別のバックエンド インスタンス グループ内のバックエンド VM では nic2 でも構いません。

    ゾーン NEG バックエンド

    • 同じ GCE_VM_IP ゾーン NEG 内の異なるエンドポイントでも、異なるインターフェース識別子が使用される場合があります。
    • ゾーン NEG にエンドポイントを追加する際に VM 名と IP アドレスの両方を指定すると、Google Cloud はそのエンドポイントが、NEG の選択された VPC ネットワークにある VM の NIC のプライマリ内部 IP アドレスであることを検証します。検証に失敗すると、エンドポイントが NEG ネットワーク内の VM の NIC のプライマリ IP アドレスと一致しないことを示すエラー メッセージが表示されます。
    • ゾーン NEG にエンドポイントを追加するときに IP アドレスを指定しない場合、Google Cloud は NEG の選択された VPC ネットワーク内で NIC のプライマリ内部 IP アドレスを選択します。
  • バックエンド サービスを作成するときに --network フラグを指定しない場合、バックエンド サービスはすべてのバックエンド VM が最初に使用するネットワーク インターフェース(1 つしかない場合もあります)のネットワークに基づいてネットワークを選択します。つまり、すべてのバックエンド インスタンス グループ内のすべての VM に対して、nic0 は同じ VPC ネットワーク内になければなりません。

ヘルスチェック

ロードバランサのバックエンド サービスは、グローバルまたはリージョンのヘルスチェックに関連付けられている必要があります。VPC ネットワークの外側の特殊ルートを使用することで、ヘルスチェック システムとバックエンドとの間で容易に通信できます。

既存のヘルスチェックを使用することも、新たに定義することもできます。トラフィック分散での説明のとおり、内部 TCP / UDP ロードバランサは、ヘルスチェックのステータスを使用して、新しい接続をルーティングする方法を決定します。

次の任意のヘルスチェック プロトコルを使用できます。ヘルスチェックのプロトコルがロードバランサのプロトコルと一致する必要はありません。

  • HTTP、HTTPS、HTTP/2。バックエンド VM が HTTP、HTTPS、または HTTP/2 を使用してトラフィックを処理する場合、HTTP ベースのヘルスチェックではそのプロトコルに適したオプションが提供されるため、それぞれのプロトコルと一致するヘルスチェックの使用をおすすめします。内部 TCP / UDP ロードバランサを介して HTTP タイプのトラフィックを処理すると、ロードバランサのプロトコルが TCP になります。
  • SSL または TCP。バックエンド VM が HTTP タイプのトラフィックを処理しない場合は、SSL または TCP のヘルスチェックを使用する必要があります。

作成するヘルスチェックの種類に関係なく、Google Cloud は、ロードバランサのバックエンド サービスによって選択された VPC 内のネットワーク インターフェースへの内部 TCP / UDP ロードバランサの転送ルールの IP アドレスに、ヘルスチェック プローブを送信します。これにより、負荷分散されたトラフィックの配信方法がシミュレートされます。バックエンド VM で実行するソフトウェアは、負荷分散されたトラフィックと、ロードバランサの IP アドレスに送信されたヘルスチェック プローブの両方に応答する必要があります。詳細については、プローブ パケットの宛先をご覧ください。

ヘルスチェックと UDP トラフィック

Google Cloud では、UDP プロトコルを使用するヘルスチェックを提供していません。UDP トラフィックで内部 TCP / UDP 負荷分散を使用する場合は、バックエンド VM でヘルスチェック情報を提供する TCP ベースのサービスを実行する必要があります。

この構成では、クライアントのリクエストが UDP プロトコルを使用して負荷分散され、TCP サービスが Google Cloud ヘルスチェック プローバーへの情報提供に使用されます。たとえば、Google Cloud に HTTP 200 レスポンスを返す単純な HTTP サーバーをバックエンド VM ごとに実行できます。この例では、バックエンド VM 上で実行する独自のロジックを使用して、UDP サービスが適切に構成され実行されている場合にのみ HTTP サーバーが 200 を返すようにする必要があります。

高可用性アーキテクチャ

内部 TCP / UDP ロードバランサは可用性が高く設計されています。高可用性のメカニズムは単一のデバイスや VM インスタンスに依存しないため、ロードバランサの可用性を高くするための特別な手順はありません。

バックエンド VM インスタンスが複数のゾーンにデプロイされるようにするには、次のデプロイに関する推奨事項に従ってください。

共有 VPC アーキテクチャ

次の表は、共有 VPC ネットワークで使用される内部 TCP / UDP 負荷分散のコンポーネント要件をまとめたものです。例については、共有 VPC のプロビジョニングのページで内部 TCP / UDP ロードバランサの作成をご覧ください。

IP アドレス 転送ルール バックエンド コンポーネント
内部 IP アドレスは、バックエンド VM と同じプロジェクトで定義する必要があります。

共有 VPC ネットワークでロードバランサを使用できるようにするには、Google Cloud 内部 IP アドレスは、バックエンド VM が配置されている同じサービス プロジェクト内で定義する必要がありますさらに、ホスト プロジェクト内の目的の共有 VPC ネットワーク内のサブネットを参照する必要があります。アドレス自体は、参照先サブネットのプライマリ IP 範囲から取得します。

サービス プロジェクトで内部 IP アドレスを作成し、その IP アドレスのサブネットがサービス プロジェクトの VPC ネットワークにある場合、内部 TCP / UDP ロードバランサは、サービス プロジェクトに対しローカルです。共有 VPC ホスト プロジェクトに対してローカルではありません。
内部転送ルールは、バックエンド VM と同じプロジェクトで定義する必要があります。

共有 VPC ネットワークでロードバランサを使用できるようにするには、内部転送ルールは、バックエンド VM が配置されている同じサービス プロジェクト内で定義する必要がありますさらに、関連付けられている内部 IP アドレスが参照する同じサブネット(共有 VPC ネットワーク内)を参照する必要があります。

サービス プロジェクトで内部転送ルールを作成し、転送ルールのサブネットがサービス プロジェクトの VPC ネットワーク内にある場合、内部 TCP / UDP ロードバランサは、サービス プロジェクトに対してローカルです。共有 VPC ホスト プロジェクトに対してローカルではありません。
共有 VPC のシナリオでは、バックエンド VM はサービス プロジェクト内にあります。そのサービス プロジェクトでは、リージョン内部のバックエンド サービスとヘルスチェックを定義する必要があります。

トラフィック分散

内部 TCP / UDP ロードバランサによる新しい接続の分散方法は、フェイルオーバーが構成されているかどうかによって異なります。

  • フェイルオーバーを構成していない場合、少なくとも 1 つのバックエンド VM が正常であれば、内部 TCP / UDP ロードバランサによって正常なバックエンド VM に新しい接続が分散されます。すべてのバックエンド VM が正常でない場合は、最後の手段としてロードバランサによりすべてのバックエンドの間で新しい接続が分散されます。この場合、ロードバランサにより正常でないバックエンド VM にそれぞれ新しい接続が転送されます。

  • フェイルオーバーを構成している場合、内部 TCP / UDP ロードバランサは、構成したフェイルオーバー ポリシーに従って、アクティブ プール内の VM 間で新しい接続を分散します。すべてのバックエンド VM が正常でない場合は、次のいずれかの動作から選択できます。

    • デフォルト)ロードバランサは、プライマリ VM にのみトラフィックを分散します。これは最後の手段です。バックアップ VM は、この最後の接続分散から除外されます。
    • ロードバランサは、トラフィックをドロップするように構成されています。

新しい接続の分散方法は、ロードバランサのセッション アフィニティの設定によって異なります。

ヘルスチェックの状態によって、新しい接続の分散が制御されます。正常でないバックエンド VM で接続の処理が続いている場合、確立済みの TCP セッションはその正常でないバックエンド VM で存続します。

セッション アフィニティのオプション

セッション アフィニティは、クライアントからロードバランサのバックエンド VM への新しい接続の分散を制御します。バックエンド VM がクライアントの状態情報を追跡する必要がある場合は、セッション アフィニティを設定します。これは、ウェブ アプリケーションなど、状態の維持が必要なアプリケーションの一般的な要件となります。

セッション アフィニティはベストエフォート ベースで機能します。

内部 TCP / UDP ロードバランサは、バックエンド インスタンス グループではなく、内部バックエンド サービス全体に指定する次に示すセッション アフィニティのオプションをサポートします。

タイプ 意味 サポートされているプロトコル
なし これはデフォルトの設定です。

これは、クライアント IP、プロトコル、ポートと同じように動作します。

TCP、UDP トラフィック
クライアント IP 同じ送信元 IP アドレスと宛先 IP アドレスからの接続は、次の 2 タプルハッシュに基づいて、同じインスタンスに送信されます。
  • IP パケットの送信元アドレス
  • IP パケットの宛先アドレス
TCP、UDP トラフィック
クライアント IP とプロトコル 同じ送信元と宛先の IP アドレスとプロトコルからの接続は、次の 3 タプルハッシュに基づいて同じインスタンスに送信されます。
  • IP パケットの送信元アドレス
  • IP パケットの宛先アドレス
  • プロトコル(TCP または UDP)
TCP、UDP トラフィック
クライアント IP、プロトコル、ポート パケットは、次の情報から作成されたハッシュを使用してバックエンドに送信されます。
  • パケットの送信元 IP アドレス
  • パケットの送信元ポート(存在する場合)
  • パケットの宛先 IP アドレス
  • パケットの宛先ポート(存在する場合)
  • プロトコル
送信元アドレス、宛先アドレス、プロトコル情報は、IP パケットのヘッダーから取得されます。送信元ポートと宛先ポート(存在する場合)は、レイヤ 4 ヘッダーから取得されます。
たとえば、TCP セグメントや非断片化 UDP データグラムには常に、送信元ポートと宛先ポートが含まれます。断片化された UDP データグラムにはポート情報は含まれません。
ポート情報が存在しない場合、5 タプルハッシュは実質的に 3 タプルハッシュになります。
TCP トラフィックのみ

宛先 IP アドレスは、カスタム静的ルートのためにロードバランサにパケットが配信される場合を除き、ロードバランサの転送ルールの IP アドレスになります。内部 TCP / UDP ロードバランサがルートのネクストホップである場合は、この記事の次のセクションである「セッション アフィニティとネクストホップの内部 TCP / UDP ロードバランサ」をご覧ください。

セッション アフィニティとネクストホップの内部 TCP / UDP ロードバランサ

選択したセッション アフィニティのオプションに関係なく、Google Cloud ではパケットの宛先が使用されますパケットをロードバランサに直接送信する場合、パケットの宛先はロードバランサの転送ルールの IP アドレスと一致します。

ただし、内部 TCP / UDP ロードバランサをカスタム静的ルートのネクストホップとして使用する場合、パケットの宛先はロードバランサの転送ルールの IP アドレスにはなりません。宛先がルートの宛先範囲内にあるパケットの場合、ルートはロードバランサに振り向けられます。

カスタム静的ルートのネクストホップとして内部 TCP / UDP ロードバランサを使用する方法については、ネクストホップとしての内部 TCP / UDP ロードバランサをご覧ください。

セッション アフィニティとヘルスチェックの状態

バックエンド VM のヘルス ステータスを変更すると、セッション アフィニティが失われる場合があります。たとえば、1 つのバックエンド VM が正常でなくなり、ほかに正常なバックエンド VM が少なくとも 1 つ存在する場合、内部 TCP / UDP ロードバランサは新しい接続を正常でない VM には分散しません。クライアントにその正常でない VM とのセッション アフィニティがある場合は、正常なバックエンド VM に転送され、そのセッション アフィニティが失われます。

1 つのクライアントから接続をテストする

単一のクライアント システムから内部 TCP / UDP ロードバランサの IP アドレスへの接続をテストする場合、次の点に注意します。

  • クライアント システムが負荷分散対象外の VM、つまりバックエンド VM でない場合、新しい接続がロードバランサの正常なバックエンド VM に配信されます。ただし、すべてのセッション アフィニティのオプションが、少なくともクライアント システムの IP アドレスに依存するため、同じクライアントからの接続は、予測より頻繁に同じバックエンド VM に分散されることがあります。

    実地面では、単一クライアントから内部 TCP / UDP ロードバランサに接続した場合、これを介したトラフィック分散を正確にモニタリングできないことになります。トラフィック分散のモニタリングに必要なクライアント数は、ロードバランサの種類、トラフィックの種類、正常なバックエンドの数によって異なります。

  • クライアント VM がロードバランサのバックエンド VM の場合、ロードバランサの転送ルールの IP アドレスに送信される接続には、常にクライアント / バックエンド VM 自体が応答することになります。この現象は、バックエンド VM が正常であるかどうかにかかわらず、ロードバランサの内部転送ルールで指定されたプロトコルとポート上のトラフィックだけではなく、ロードバランサの IP アドレスに送信されたすべてのトラフィックで発生します。

    詳細については、負荷分散された VM からのリクエストの送信をご覧ください。

フェイルオーバー

内部 TCP / UDP 負荷分散を使用すると、一部のバックエンドをフェイルオーバー バックエンドとして指定できます。これらのバックエンドは、プライマリ バックエンド インスタンス グループの正常な VM の数が、構成可能なしきい値を下回る場合にのみ使用されます。デフォルトでは、すべてのプライマリ VM とフェイルオーバー VM が異常な状態になると、最後の手段として、Google Cloud はすべてのプライマリ VM 間でのみ新しい接続トラフィックを分散します。

内部 TCP / UDP ロードバランサのバックエンド サービスにバックエンドを追加すると、デフォルトでは、そのバックエンドがプライマリ バックエンドになります。バックエンドは、ロードバランサのバックエンド サービスに追加するときに指定できます。また、後でバックエンド サービスを編集して、フェイルオーバー バックエンドに指定することもできます。

内部 TCP / UDP 負荷分散のフェイルオーバーの詳細なコンセプトについては、内部 TCP / UDP 負荷分散のフェイルオーバーの概要をご覧ください。

サブセット化

内部 TCP / UDP ロードバランサのサブセット化によって、内部 TCP / UDP ロードバランサをスケーリングして、内部バックエンド サービスごとに多数のバックエンド VM インスタンスをサポートできます。

サブセット化がこの制限に与える影響については、負荷分散のリソースの割り当てと上限の「バックエンド サービス」をご覧ください。

デフォルトではサブセット化が無効になるため、バックエンド サービスは最大で 250 のバックエンド インスタンスまたはエンドポイントに制限されます。バックエンド サービスが 250 を超えるバックエンドをサポートする必要がある場合は、サブセット化を有効にできます。サブセットが有効になっている場合、クライアント接続ごとにバックエンド インスタンスのサブセットが選択されます。

次の図は、この 2 つの動作モードの違いを簡単なモデルで示しています。

内部 TCP / UDP ロードバランサのサブセット化の有無を比較する(クリックして拡大)
内部 TCP / UDP ロードバランサのサブセット化の有無を比較する(クリックして拡大)

サブセット化しないと、正常なバックエンドの完全なセットの使用率が上がり、新しいクライアント接続はトラフィック分散に従ってすべての正常なバックエンド間で分散されます。サブセット化すると、負荷分散の制限は生じませんが、ロードバランサは 250 以上のバックエンドをサポートできます。

構成手順については、サブセット化の設定をご覧ください。

サブセット化に関する注意点

  • サブセット化が有効になっている場合、バックエンドの数が少ない場合でも、すべてのバックエンドが特定の送信者からトラフィックを受信するわけではありません。
  • サブセットを有効にした場合のバックエンド インスタンスの最大数については、割り当てページをご覧ください。
  • サブセットをサポートしているのは、5 タプルのセッション アフィニティのみです。
  • サブセット化で Packet Mirroring はサポートされていません。
  • 設定を有効にしてから無効にすると、既存の接続が切断されます。
  • Cloud VPN または Cloud Interconnect を介してサブセット化を行ったときに、Google Cloud 側の VPN ゲートウェイの数が十分でない場合(10 未満)は、ロードバランサのバックエンドのサブセットのみが使用される可能性があります。1 つの TCP 接続のパケットを別の VPN ゲートウェイに再ルーティングすると、接続がリセットされます。すべてのバックエンド プールを使用するには、Google Cloud に十分な VPN ゲートウェイが必要です。1 つの TCP 接続のトラフィックが別の VPN ゲートウェイに再ルーティングされた場合、接続がリセットされます。

上限

割り当てと上限について詳しくは、負荷分散のリソースの割り当てをご覧ください。

次のステップ