TCP プロキシ負荷分散の概要

TCP プロキシ負荷分散は、インターネットから送信された TCP トラフィックを Google Cloud VPC ネットワークの仮想マシン(VM)インスタンスに分散するリバース プロキシ ロードバランサです。TCP プロキシ負荷分散を使用する場合、1 つの TCP 接続で受信したトラフィックは負荷分散レイヤで終端し、TCP または SSL を使用して最も近い利用可能なバックエンドに転送されます。

TCP プロキシ負荷分散を使用すると、世界中のすべてのユーザーが単一の IP アドレスを使用できます。TCP プロキシ ロードバランサは、ユーザーに最も近いバックエンドに自動的にトラフィックをルーティングします。

プレミアム ティアの TCP プロキシ負荷分散は、グローバル負荷分散サービスとして構成できます。スタンダード ティアの TCP プロキシ ロードバランサは、リージョン単位で負荷分散を処理します。詳細については、TCP プロキシ ロード バランシングをご覧ください。

この例では、ソウルとボストンのユーザーからのトラフィックの接続が負荷分散レイヤで終端しています。このような接続には 1a2a ラベルが付けられています。選択されたバックエンド インスタンスに、ロードバランサから接続が個別に確立されています。このような接続には 1b2b ラベルが付けられています。

TCP 終端処理を使用した Cloud Load Balancing(クリックして拡大)
TCP 終端処理を使用した Cloud Load Balancing(クリックして拡大)

TCP プロキシ負荷分散は、SMTP(簡易メール転送プロトコル)用のポート 25 など、一部の一般的なポートの TCP トラフィックを対象としています。詳細については、ポートの仕様をご覧ください。この同じポートで暗号化されるクライアント トラフィックの場合は、SSL プロキシ負荷分散を使用してください。

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

利点

TCP プロキシ ロードバランサには次のような利点があります。

  • IPv6 ターミネーション。TCP プロキシ負荷分散は、IPv4 アドレスと IPv6 アドレスのクライアント トラフィックをサポートしています。クライアントの IPv6 リクエストは負荷分散レイヤで終端し、IPv4 経由でバックエンドにプロキシされます。
  • インテリジェント ルーティング。ロードバランサは、処理能力があるバックエンドのロケーションにリクエストをルーティングできます。L3/L4 ロードバランサの場合は、利用可能な処理能力にかかわらず、常にリージョンのバックエンドにルーティングされます。より高度なルーティングを使用すると、x*N ではなく、N+1 または N+2 でプロビジョニングできるようになります。
  • セキュリティ パッチ。TCP スタックに脆弱性が発見された場合、Cloud Load Balancing によって自動的にロードバランサにパッチが適用されます。これにより、インスタンスが安全に保たれます。
  • 次の一般的な TCP ポートのサポート: 25、43、110、143、195、443、465、587、700、993、995、1883、3389、5222、5432、5671、5672、5900、5901、6379、8085、8099、9092、9200、9300。

アーキテクチャ

TCP プロキシのロードバランサのコンポーネントは次のとおりです。

転送ルールと IP アドレス

転送ルールは、IP アドレス、ポート、プロトコルに基づいて、ターゲット プロキシとバックエンド サービスからなる負荷分散構成にトラフィックをルーティングします。

各転送ルールは、アプリケーションの DNS レコードで使用できる単一の IP アドレスを提供します。DNS ベースの負荷分散は必要ありません。使用できる静的 IP アドレスを予約するか、Cloud Load Balancing から割り当てます。推奨されているのは静的 IP アドレスの予約です。静的アドレスを予約しない場合、転送ルールを削除して新しく作り直すたびに DNS レコードを編集して、新しく割り当てられたエフェメラル IP アドレスに直す必要があるからです。

TCP プロキシ ロードバランサの定義で使用される外部転送ルールは、転送ルールのポートの仕様にリストされたポートのいずれか 1 つのみを参照できます。

ターゲット プロキシ

TCP プロキシ負荷分散では、クライアントからの TCP 接続を終端してバックエンドへの新しい接続を作成します。デフォルトでは、元のクライアントの IP アドレスとポート情報は保持されません。PROXY プロトコルを使用してこの情報を保持できます。ターゲット プロキシは、受信リクエストを直接バックエンド サービスに転送します。

バックエンド サービス

バックエンド サービスは、接続されているバックエンドの 1 つまたは複数に受信トラフィックを振り分けます。これらのバックエンドはそれぞれ、インスタンス グループまたはネットワーク エンドポイント グループと、バックエンドの処理能力に関する情報から構成されます。バックエンドの処理能力は、CPU または 1 秒あたりのリクエスト数(RPS)に基づいています。

各 TCP プロキシ ロードバランサには、単一のバックエンド サービス リソースが含まれます。バックエンド サービスに対する変更は即時に行われるわけではありません。変更が Google Front End(GFE)に反映されるまでに数分かかる場合があります。

各バックエンド サービスは、使用可能なバックエンドに対して実行するヘルスチェックを指定します。

ユーザーへの中断を最小限に抑えるために、バックエンド サービスのコネクション ドレインを有効にできます。このような中断は、バックエンドの停止、手動による削除、オートスケーラーによる削除によって発生することがあります。コネクション ドレインを使用してサービスの中断を最小限に抑える方法については、コネクション ドレインの有効化のドキュメントをご覧ください。

バックエンドと通信するためのプロトコル

TCP プロキシ ロードバランサのバックエンド サービスを構成する際には、バックエンド サービスがバックエンドと通信するために使用するプロトコルを設定します。SSL または TCP を選択できます。ロードバランサは、指定したプロトコルのみを使用し、他のプロトコルとの接続をネゴシエートしません。

ファイアウォール ルール

HTTP(S) ロード バランシングには、次のファイアウォール ルールが必要です。

  • グローバル外部 HTTP(S) ロードバランサの場合、上り(内向き)許可ルールによって、バックエンドに到達するように Google Front End(GFE)からのトラフィックが許可されます。
    リージョン外部 HTTP(S) ロードバランサの場合、上り(内向き)許可ルールによって、プロキシ専用サブネットからのトラフィックが許可されます。
  • ヘルスチェック プローブ範囲からのトラフィックを許可する上り(内向き)許可ルール。ヘルスチェック プローブの詳細と、プローブからのトラフィックを許可する必要がある理由については、プローブ IP 範囲とファイアウォール ルールをご覧ください。

これらのファイアウォール ルールのポートは、次のように構成する必要があります。

  • 各バックエンド サービスのヘルスチェックのための宛先ポートへのトラフィックを許可します。

  • インスタンス グループのバックエンドの場合: バックエンド サービスの名前付きポートと、各インスタンス グループの名前付きポートに関連付けられたポート番号とのマッピングによって、構成するポートを決定します。同じバックエンド サービスに割り当てられたインスタンス グループ間でポート番号が異なる可能性があります。

  • GCE_VM_IP_PORT NEG バックエンドの場合: エンドポイントのポート番号へのトラフィックを許可します。

ファイアウォール ルールは GFE プロキシではなく、VM インスタンス レベルで実装されます。Google Cloud ファイアウォール ルールを使用して、トラフィックがロードバランサに到達しないようにすることはできません。グローバル外部 HTTP(S) ロードバランサの場合、Google Cloud Armor を使用してこれを実現できます。

SSL プロキシ ロードバランサと TCP プロキシ ロードバランサの場合、必要なソース範囲は次のとおりです。

  • 130.211.0.0/22
  • 35.191.0.0/16

これらの範囲は、GFE からのヘルスチェックとリクエストに適用されます。

送信元 IP アドレス

バックエンドから見たパケットの送信元 IP アドレスは、ロードバランサの Google Cloud の外部 IP アドレスではありません。つまり、2 つの TCP 接続があります。

  • 接続 1: 元のクライアントからロードバランサ(GFE)への接続。

    • 送信元 IP アドレス: オリジナルのクライアント(クライアントが NAT の背後にある場合や外部プロキシの場合は外部 IP アドレス)。
    • 宛先 IP アドレス: ロードバランサの IP アドレス。
  • 接続 2: ロードバランサ(GFE)からバックエンド VM またはエンドポイントへの接続。

    • 送信元 IP アドレス: ファイアウォール ルールで指定された範囲の IP アドレス。

    • 宛先 IP アドレス: VPC ネットワーク内のバックエンド VM またはコンテナの内部 IP アドレス。

オープンポート

TCP プロキシ ロードバランサはリバース プロキシのロードバランサです。ロードバランサによって受信接続が終端され、ロードバランサからバックエンドへの新しい接続が開かれます。これらのロードバランサは、世界中の Google Front End(GFE)プロキシを使用して実装されています。

GFE には、同じアーキテクチャで実行される他の Google サービスをサポートするための複数のオープンポートがあります。GFE で開かれる可能性のあるポートの一覧を確認するには、転送ルール: ポートの仕様をご覧ください。GFE で実行されている他の Google サービス用に他のオープンポートが存在する可能性もあります。

GFE ベースのロードバランサの IP アドレスに対してポートスキャンを実行することは、次の理由により、監査の観点からは役立ちません。

  • 通常、ポートスキャン(たとえば nmap を使用)では、TCP SYN プローブを実行するときにレスポンス パケットや TCP RST パケットは想定されません。ロードバランサがプレミアム ティアの IP アドレスを使用する場合、GFE はさまざまなポートに対する SYN プローブへのレスポンスとして SYN-ACK パケットを送信します。ただし、GFE は、ロードバランサの IP アドレスと、転送ルールで構成されている宛先ポートにパケットが送信された場合にのみ、パケットをバックエンドに送信します。パケットが別のロードバランサの IP アドレスや、転送ルールに構成されていないポートのロードバランサの IP アドレスに送信された場合、ロードバランサのバックエンドへのパケット送信は発生しません。特別な構成がなくても、Google のインフラストラクチャと GFE は DDoS 攻撃と SYN フラッドに対して多層防御を提供します。

  • ロードバランサの IP アドレスに送信されたパケットには、Google のフリート内の任意の GFE が応答可能ですが、ロードバランサの IP アドレスと宛先ポートの組み合わせをスキャンすると、TCP 接続ごとに 1 つの GFE のみが検査されます。ロードバランサの IP アドレスは、単一のデバイスまたはシステムに割り当てられていません。したがって、GFE ベースのロードバランサの IP アドレスをスキャンしても、Google のフリート内のすべての GFE がスキャンされるわけではありません。

以下では、この点を考慮し、バックエンド インスタンスのセキュリティをより効果的に監査する方法を説明します。

  • セキュリティ監査担当者は、ロードバランサの構成で転送ルールの構成を検査する必要があります。転送ルールは、ロードバランサがパケットを受け入れてバックエンドに転送する宛先ポートを定義しています。GFE ベースのロードバランサの場合、1 つの外部転送ルールで参照できる宛先 TCP ポートは 1 つだけです

  • セキュリティ監査担当者は、バックエンド VM に適用されるファイアウォール ルールの構成を検査する必要があります。ファイアウォール ルールの設定では、GFE からバックエンド VM へのトラフィックをブロックしますが、GFE への受信トラフィックはブロックしません。ベスト プラクティスについては、ファイアウォール ルールのセクションをご覧ください。

トラフィック分散

TCP プロキシ ロードバランサでバックエンドにトラフィックを分散する方法は、バックエンドの選択(セッション アフィニティ)に使用される分散モードとハッシュ方法によって異なります。

接続の分散方法

TCP プロキシ ロード バランシングは、プレミアム ティアのグローバル ロード バランシング サービスとして構成できます。また、スタンダード ティアのリージョン サービスとして構成することもできます。

プレミアム ティアの場合:

  • バックエンド サービスは 1 つだけですが、バックエンド サービスは複数のリージョンにバックエンドを配置できます。グローバル ロード バランシングの場合、バックエンドを複数のリージョンにデプロイすると、ロードバランサはユーザーに最も近いリージョンに自動的にトラフィックを転送します。あるリージョンがその処理能力に達すると、ロードバランサによって処理能力がある別のリージョンに新しい接続が自動的に振り分けられます。既存のユーザー接続は現在のリージョンにそのまま残ります。
  • Google は、全世界のあらゆる拠点からロードバランサの IP アドレスをアドバタイズします。各ロードバランサの IP アドレスはグローバル エニーキャストです。
  • 複数のリージョンにバックエンドを持つバックエンド サービスを構成した場合、Google Front End(GFE)は、ユーザーに最も近いリージョンの正常なバックエンド インスタンス グループまたは NEG にリクエストを転送しようとします。このプロセスについては、このページで詳しく説明します。

スタンダード ティアの場合:

  • Google は、転送ルールのリージョンに関連付けられた接続拠点からロードバランサの IP アドレスをアドバタイズします。ロードバランサは、リージョン外部 IP アドレスを使用します。

  • バックエンドは、転送ルールと同じリージョンに構成できます。ここで説明するプロセスは引き続き適用されますが、ロードバランサは対象の 1 つのリージョン内に存在する正常なバックエンドにのみリクエストを転送します。

リクエストの分散プロセス:

分散モードとターゲットの選択により、各ゾーン GCE_VM_IP_PORT NEG、ゾーン インスタンス グループ、またはリージョン インスタンス グループのゾーンの観点からバックエンドの完全性が定義されます。その後、ゾーン内での分散が一貫したハッシュを使用して行われます。

GFE ベースのグローバル外部 HTTP(S) ロードバランサは、受信リクエストを分散するために次のプロセスを使用します。

  1. 転送ルールの外部 IP アドレスは、Google ネットワークの境界にあるエッジルーターによってアドバタイズされます。各アドバタイズでは、可能な限りユーザーに近いレイヤ 3/4 のロード バランシング システム(Maglev)へのネクストホップの一覧が取得されます。
  2. Maglev システムが受信パケットの送信元 IP アドレスを検査します。受信したリクエストは、Google の geo-IP システムが可能な限りユーザーの近くに存在すると判断した Maglev システムに送信されます。
  3. Maglev システムは、最初のレイヤの Google Front End(GFE)にトラフィックを転送します。最初のレイヤの GFE は、必要に応じて TLS を終了し、このプロセスに従ってトラフィックを 2 番目のレイヤの GFE にルーティングします。
    1. バックエンド サービスがインスタンス グループまたは GCE_VM_IP_PORT NEG バックエンドを使用する場合、最初のレイヤの GFE は、インスタンス グループまたは NEG を含むリージョン内か、またはその近くに配置された 2 番目のレイヤの GFE を優先します。
    2. ハイブリッド NEG、サーバーレス NEG、インターネット NEG のバックエンド バケットとバックエンド サービスの場合、最初のレイヤの GFE は 2 番目の GFE をリージョンのサブセットで選択します。これにより、2 つの GFE 間のラウンドトリップ時間が最小化されます。

      2 番目のレイヤの GFE の優先は保証されず、Google のネットワーク条件とメンテナンスに基づいて動的に変更される可能性があります。

      2 番目のレイヤの GFE は、ヘルスチェックのステータスと実際のバックエンド容量の使用率を認識します。

  4. 2 番目のレイヤの GFE は、リージョン内のゾーンのバックエンドにリクエストを転送します。
  5. プレミアム ティアの場合は、2 番目のレイヤの GFE が、異なるリージョンのゾーンにあるバックエンドにリクエストを送信する可能性があります。この動作はスピルオーバーと呼ばれます。
  6. スピルオーバーには次の 2 つの原則が適用されます。

    • スピルオーバーは、2 番目のレイヤの GFE に認識されるすべてのバックエンドが容量の上限に達した場合か、正常ではない場合に可能です。
    • 2 番目のレイヤの GFE には、別のリージョンのゾーンに存在する利用可能な正常なバックエンドに関する情報があります。

    通常、2 番目のレイヤの GFE は、バックエンドのロケーションのサブセットを提供するように構成されています。

    スピルオーバー動作は、使用可能なすべての Google Cloud ゾーンを使い切るわけではありません。特定のゾーンまたはリージョン全体のバックエンドからトラフィックを転送する必要がある場合は、容量スケーラーをゼロに設定する必要があります。ヘルスチェックに失敗するようにバックエンドを構成しても、2 番目のレイヤの GFE が別のリージョンのゾーンにバックエンドをスピルオーバーする保証はありません。

  7. バックエンドにリクエストを分散する場合、GFE はゾーンレベルで動作します。

    接続数が少ない場合は、2 番目のレイヤの GFE がリージョン内で 1 つのゾーンを他のゾーンよりも優先する場合があります。これは、想定されている正常な設定です。ロードバランサが受信する接続数が増加するまで、リージョンのゾーン間での分散は行われません。

分散モード

バックエンド サービスにバックエンドを追加するときは、負荷分散モードを設定します。

TCP プロキシ負荷分散の場合、分散モードは CONNECTION または UTILIZATION に設定できます。

負荷分散モードが CONNECTION に設定されている場合、バックエンドで処理できる同時接続数に基づいて負荷が分散されます。次のパラメータ(maxConnections(リージョン マネージド インスタンス グループを除く)、maxConnectionsPerInstancemaxConnectionsPerEndpoint)のいずれかも指定する必要があります。

負荷分散モードが UTILIZATION に設定されている場合、インスタンス グループ内のインスタンスの使用率に基づいて負荷が分散されます。

ロードバランサのタイプとサポートされている分散モードの比較については、負荷分散の方法をご覧ください。

セッション アフィニティ

バックエンドが良好な状態で処理能力があれば、セッション アフィニティにより、同じクライアントからのすべてのリクエストが同じバックエンドに送信されます。

TCP プロキシ負荷分散ではクライアント IP アフィニティを使用できます。このアフィニティは、同じクライアント IP アドレスからのすべてのリクエストを同じバックエンドに転送します。

フェイルオーバー

バックエンドが異常な状態になった場合、トラフィックは同じリージョン内の正常なバックエンドに自動的にリダイレクトされます。リージョン内のすべてのバックエンドが異常な状態の場合、トラフィックは他のリージョンの正常なバックエンドに分散されます(プレミアム ティアのみ)。すべてのバックエンドが異常な状態の場合、ロードバランサはトラフィックを破棄します。

GKE アプリケーションのロード バランシング

Google Kubernetes Engine でアプリケーションを構築する場合は、スタンドアロン NEG を使用してトラフィックを直接コンテナにロード バランシングできます。スタンドアロン NEG では、NEG を作成する Service オブジェクトを作成し、NEG をバックエンド サービスに関連付けます。これにより、ロードバランサが Pod に接続できるようになります。

関連する GKE のドキュメント:

制限事項

  • TCP プロキシ ロードバランサは、VPC ネットワーク ピアリングをサポートしていません。

次のステップ