内部 TCP / UDP 負荷分散のコンセプト

内部 TCP / UDP 負荷分散はリージョン単位のロードバランサであり、内部仮想マシンのインスタンスのみにアクセス可能なプライベート負荷分散 IP アドレスの背後でサービスの実行とスケーリングを行うことができます。

概要

Google Cloud Platform(GCP)の内部 TCP / UDP 負荷分散は、プライベートの内部(RFC 1918)IP アドレスを使用して、VPC ネットワーク内の同じリージョン内の VM インスタンス間でトラフィックを分散します。

次の概要図に示されるように、内部 TCP / UDP 負荷分散サービスには、フロントエンド(転送ルール)とバックエンド(バックエンド サービスとインスタンス グループ)があります。

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

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

内部 TCP / UDP ロードバランサはそれぞれ、TCP トラフィックまたは UDP トラフィックのいずれか一方をサポートします。

内部 TCP / UDP ロードバランサは、内部負荷分散スキームを使用するバックエンド サービスを 1 つ使用するため、インスタンス間で GCP 内のトラフィックの負荷が分散されます。インターネットから発生したトラフィックの負荷分散には使用できません。

内部 TCP / UDP ロードバランサが対象とする範囲は、グローバルではなくリージョンです。このため 1 つの内部 TCP / UDP ロードバランサで複数のリージョンを対象にはできません。ロードバランサは、1 つのリージョン内のすべてのゾーンに対してサービスを提供します。詳しくは、リージョンとゾーンをご覧ください。

各 Cloud ロードバランサ間の相違点については、ロードバランサの選択負荷分散の概要をご覧ください。

使用例

アクセスの例

接続されたネットワークから VPC ネットワーク内の内部 TCP / UDP ロードバランサにアクセスするには、以下を使用します。

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

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

3 層ウェブサービスの例

ウェブ層で外部ロードバランサを使用し、それが内部ロードバランサの背後にあるサービスに依存する場合は、内部 TCP / UDP 負荷分散を HTTP(S) ロードバランサなどのロードバランサとともに使用できます。

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

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

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

内部 TCP / UDP 負荷分散には次の特徴があります。

  • ロードバランサはマネージド サービスである。
  • ロードバランサはプロキシではない。
  • 仮想ネットワークで実装される。
  • 中間デバイスや単一障害点が存在しない。
  • バックエンド VM からの応答は、ロードバランサを介さずに直接クライアントに送信される。

内部 TCP / UDP 負荷分散は、デバイスベースまたはインスタンス ベースのロードバランサとは異なり、クライアントからの接続を終端しません。トラフィックは、ロードバランサに送られてからバックエンドに送られるのではなく、直接バックエンドに送信されます。GCP の Linux または Windows ゲスト環境では、各バックエンド VM がロードバランサの IP アドレスを使用して構成され、GCP 仮想ネットワークによって適切なトラフィック配信とスケーリングが管理されます。

アーキテクチャ

複数のバックエンド インスタンス グループを持つ内部 TCP / UDP ロードバランサの場合は、接続がこれらすべてのインスタンス グループのバックエンド VM 間に分散されます。配信の方法と構成オプションの詳細は、トラフィックの分散をご覧ください。

ロードバランサのバックエンドには、非マネージド インスタンス グループ、マネージド ゾーン インスタンス グループ、またはマネージド リージョン インスタンス グループ(ネットワーク エンドポイント グループ(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 ロードバランサには、リージョン内のクライアント VM からのみアクセスできます。内部 TCP / UDP ロードバランサにパケットを送信するには、同じ VPC ネットワーク内のクライアント VM を同一リージョンに配置する必要がありますが、同じサブネット内でなくても構いません。ロードバランサが定義されている VPC ネットワークに正しく接続できるネットワークであれば、別のネットワーク内のクライアント システムからも内部 TCP / UDP ロードバランサと通信できます。内部 TCP / UDP 負荷分散と接続ネットワークをご覧ください。

高可用性

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

以下のおすすめの方法では、単一のゾーンに依存しないようにバックエンド VM インスタンスをデプロイする方法について説明しています。

コンポーネント

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

コンポーネント 目的 要件
内部 IP アドレス ロードバランサのアドレスです。 内部 IP アドレスは、内部転送ルールと同じサブネット内に存在する必要があります。サブネットはバックエンド サービスと同じリージョンに存在する必要があります。
内部転送ルール 内部転送ルールを内部 IP アドレスと組み合わせると、ロードバランサのフロントエンドになります。ロードバランサが受け入れるプロトコルとポートを定義し、トラフィックをリージョンの内部バックエンド サービスにルーティングします。 内部 TCP / UDP ロードバランサの転送ルールは、次の条件を満たす必要があります。
INTERNALload-balancing-scheme を含む。
バックエンド サービスの protocol に一致する、TCP または UDPip-protocol を使用する。
• バックエンド サービスと同じリージョン内の VPC ネットワーク内の subnet を参照する。
リージョンの内部バックエンド サービス リージョンの内部バックエンド サービスは、バックエンド(インスタンス グループ)との通信に使用するプロトコルを定義し、ヘルスチェックを指定します。バックエンドには、非マネージド インスタンス グループ、ゾーンのマネージド インスタンス グループ、またはリージョンのマネージド インスタンス グループを使用できます。 バックエンド サービスは、次の条件を満たす必要があります。
INTERNALload-balancing-scheme を含む。
転送ルールの protocol に一致する、TCP または UDPprotocol を使用する。
• 関連付けられたヘルスチェックを含む。
• 同じリージョン内のバックエンドを参照する。バックエンド インスタンス グループは、リージョンの任意のサブネットに配置できます。バックエンド サービス自体は、特定のサブネットに関連付けられません。
ヘルスチェック バックエンド サービスはいずれもヘルスチェックが関連付けられている必要があります。ヘルスチェックでは、GCP が管理しているバックエンドについて、トラフィックの受信に適格であるかどうかを検討する際に使用するパラメータを定義します。クライアント VM からロードバランサの IP アドレスに送信されたトラフィックを受信するのは、バックエンド インスタンス グループ内の正常な VM に限られます。 転送ルールとバックエンド サービスでは TCPUDP のいずれかを使用できます。ただし、GCP では UDP トラフィックに対するヘルスチェックが行われません。詳細は、ヘルスチェックと UDP トラフィックをご覧ください。

内部 IP アドレス

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

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

転送ルール

内部 TCP / UDP 負荷分散には、バックエンド サービスおよびインスタンス グループ(まとめてバックエンド コンポーネントとします)と同じリージョン内のサブネットに 1 つ以上の内部転送ルールが必要になります。内部転送ルールは、同じリージョン内に存在し、ロードバランサのバックエンド サービスと同じプロトコルを使用している必要があります。

転送ルールでは、ロードバランサがトラフィックを受け入れるポートが定義されます。内部 TCP / UDP ロードバランサはプロキシではありません。トラフィックを受信したポートと同じポート上のバックエンドにトラフィックを渡します。転送ルールごとにポート番号を 1 つ以上指定する必要があります。

内部転送ルールを作成するときは、ポートだけでなく VPC ネットワーク内の特定のサブネットを参照する必要があります。転送ルールに指定するサブネットは、バックエンド VM で使用されるサブネットのいずれとも同じである必要はありませんが、転送ルール、サブネット、およびバックエンド サービスはすべて同じリージョン内に存在する必要があります。内部転送ルールを作成するときに、選択したサブネットのプライマリ IP アドレス範囲から使用可能な内部 IP アドレスが GCP によって選択されます。また、サブネットのプライマリ IP 範囲から内部 IP アドレスを指定することもできます。

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

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

  • 1 つ以上、最大 5 つのポートを番号で指定する。
  • すべてのポートにトラフィックを転送するには ALL を指定する。

すべてのポートをサポートする内部転送ルールを作成して、TCP などの特定のプロトコルのすべてのトラフィックを 1 つの内部ロードバランサに転送します。これにより、バックエンド VM では複数のアプリケーションを各ポートで 1 つずつ実行できます。特定のポートに送信されたトラフィックは、対応するアプリケーションに配信され、すべてのアプリケーションで同じ IP アドレスが使用されます。

すべてのポートでバックエンド アプリケーションを開くことに懸念がある場合は、バックエンド VM にファイアウォール ルールをデプロイして、受信トラフィックの範囲を想定ポートに設定します。

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

複数の転送ルール

同一の内部ロードバランサに複数の内部転送ルールを構成できます。各転送ルールには固有で一意の IP アドレスが必要であり、1 つのバックエンド サービスのみを参照できます。複数の内部転送ルールから同一のバックエンド サービスを参照できます。

同じ内部 TCP / UDP ロードバランサに複数の IP アドレスが必要な場合や、特定のポートを異なる IP アドレスに関連付ける必要がある場合は、複数の内部転送ルールの構成が便利です。ロードバランサを介して配信されるパケットの宛先 IP アドレスは、それぞれの内部転送ルールが関連付けられている内部 IP アドレスになるため、複数の内部転送ルールを使用する際は、バックエンド VM で実行されるソフトウェアを構成して、すべての必要な IP アドレスがバインドされるようにします。

内部 TCP / UDP 負荷分散の設定ページで、セカンダリ転送ルールを作成する手順をご覧ください。この例では、同一のロードバランサに 2 つの転送ルール(1 つは 10.1.2.99 を使用、もう 1 つは 10.5.6.99 を使用)が構成されています。バックエンド VM は、これらのうち一方の IP アドレスでパケットを受信するように構成する必要があります。これを行う方法の 1 つでは、任意の IP アドレス(0.0.0.0/0)にバックエンドがバインドされるように構成します。

バックエンド サービス

各内部 TCP / UDP ロードバランサは、リージョンを範囲とする 1 つの内部バックエンド サービスを使用します。このバックエンド サービスの名前は、GCP Console に表示される内部 TCP / UDP ロードバランサの名前になります。

バックエンド サービスは、1 つ以上の内部転送ルールによってルーティングされたトラフィックを受け入れます。リージョンの内部バックエンド サービスは、TCP または UDP のトラフィックの一方を受け入れますが、両方は受け入れません。トラフィックは、転送ルールに基づいて、トラフィックの送信先にされたポートと同じポートのバックエンド VM に配信されます。

バックエンド サービスには、少なくとも 1 つのバックエンド インスタンス グループがあり、ヘルスチェックが関連付けられている必要があります。バックエンドは、バックエンド サービス(および転送ルール)と同じリージョン内の非マネージド インスタンス グループ、ゾーンのマネージド インスタンス グループ、またはリージョンのマネージド インスタンス グループいずれでも構いません。バックエンド サービスは、バックエンド VM にトラフィックを分散し、構成されている場合はセッション アフィニティを管理します。

ヘルスチェック

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

既存のヘルスチェックを使用することも、新たに定義することもできます。内部 TCP / UDP ロードバランサは、ヘルスチェックに合格したトラフィックのみをバックエンド VM に送信します。ただし、バックエンド VM のすべてがヘルスチェックに不合格であった場合は、GCP によってそれらのすべてにトラフィックが分散されます。

次に示すヘルスチェック プロトコルはどれでも使用できます。ヘルスチェックのプロトコルは、ロードバランサ自体のプロトコルと一致している必要はありません。

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

作成するヘルスチェックの種類に関係なく、GCP ではヘルスチェック プローブが内部 TCP / UDP ロードバランサの IP アドレスに送信され、負荷が分散されたトラフィックがどのように送信されるかをシミュレーションします。バックエンド VM 上で動作するソフトウェアは、負荷が分散されたトラフィックと、ロードバランサ自体の IP アドレスに送信されたヘルスチェック プローブの両方に応答する必要があります。詳しくは、ヘルスチェック パケットの宛先をご覧ください。

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

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

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

トラフィック分散

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

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

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

デフォルトでは、クライアントの IP アドレス、ソースポート、ロードバランサの内部転送ルールの IP アドレス、宛先ポート、プロトコルの 5 つの情報から計算されたハッシュが新しい接続の分散のメソッドで使用されます。TCP トラフィックのトラフィック分散の方法は、セッション アフィニティ オプションを指定して変更できます。

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

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

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

セッション アフィニティは、TCP トラフィックのベスト エフォート型で動作します。UDP プロトコルはセッションをサポートしていないため、セッション アフィニティは UDP トラフィックに影響しません。

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

  • なし: デフォルト設定。事実上、クライアントの IP プロトコルおよびポートと同じになります。
  • クライアント IP: クライアントの IP アドレスと宛先 IP アドレスから作成されたハッシュに基づいて、特定のクライアントのリクエストを同じバックエンド VM にルーティングします。
  • クライアント IP とプロトコル: クライアントの IP アドレス、宛先 IP アドレス、ロードバランサのプロトコル(TCP または UDP)の 3 つの情報から作成されたハッシュに基づいて、特定のクライアントのリクエストを同じバックエンド VM にルーティングします。
  • クライアント IP、プロトコル、ポート: 次の 5 つの情報から作成されたハッシュに基づいて、特定のクライアントのリクエストを同じバックエンド VM に送ります。

    • リクエストを送信したクライアントの送信元 IP アドレス
    • リクエストを送信したクライアントのソースポート
    • 宛先 IP アドレス
    • 宛先ポート
    • プロトコル(TCP または UDP)

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

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

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

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

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

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

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

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

クライアント システムが負荷分散対象外の VM、つまりバックエンド VM でない場合、新しい接続がロードバランサの正常なバックエンド VM に配信されます。ただし、すべてのセッション アフィニティのオプションが、少なくともクライアント システムの IP アドレスに依存するため、同じクライアントからの接続は、予測より頻繁に同じバックエンド VM に配信されることがあります。実地面では、単一クライアントから内部 TCP / UDP ロードバランサに接続した場合、これを介したトラフィック配信を正確にモニタリングできないことになります。トラフィック分散のモニタリングに必要なクライアント数は、ロードバランサの種類、トラフィックの種類、正常なバックエンドの数によって異なります。

クライアント VM がロードバランサのバックエンド VM でもある場合、ロードバランサの転送ルールの IP アドレスに送信される接続には、常にクライアント / バックエンド VM 自体が応答することになります。この現象は、バックエンド VM が正常であるかどうかに関わりなく、ロードバランサの内部転送ルールで指定されたプロトコルとポート(複数可)上のトラフィックだけではなく、ロードバランサの IP アドレスに送信されたすべてのトラフィックで発生します。詳細は、負荷が分散された VM からのリクエストの送信をご覧ください。

制限事項

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

次のステップ