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

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

グローバル負荷分散には、Network Service Tiers のうちデフォルトの階層であるプレミアム階層を使用する必要があります。それ以外の場合は、負荷分散はリージョン単位で処理されます。

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

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

TCP 負荷分散は、IPv4 アドレスと IPv6 アドレスのクライアント トラフィックに対応しています。クライアントの IPv6 リクエストは負荷分散層で終端され、IPv4 経由でバックエンドにプロキシされます。

TCP プロキシ負荷分散を使用する場合、負荷分散層でクライアントの TCP セッションを終端し、TCP または SSL を使用してバックエンド インスタンスにトラフィックを転送できます。

TCP プロキシ負荷分散の例

TCP プロキシ負荷分散を使用すると、1 つの TCP 接続で受信したトラフィックを負荷分散層で終端してから、利用可能な最も近いバックエンドにプロキシされます。

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

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

TCP プロキシ負荷分散は、グローバル負荷分散サービスとして構成できます。 この構成では、バックエンドを複数のリージョンにデプロイできます。グローバル負荷分散では、ユーザーに最も近いリージョンに自動的にトラフィックが送られます。あるリージョンがその処理能力に達すると、ロードバランサによって処理能力がある別のリージョンに新しい接続が自動的に振り分けられます。既存のユーザー接続は現在のリージョンにそのまま残ります。

利点

TCP プロキシ負荷分散には次のメリットがあります。

  • インテリジェント ルーティング。ロードバランサは、処理能力があるバックエンドのロケーションにリクエストをルーティングできます。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 プロキシ負荷分散はプレミアム ティアのグローバル サービスです。バックエンド サービスは 1 つだけですが、(プレミアム ティアでは)複数のリージョンにバックエンドを配置できます。トラフィックは次のようにバックエンドに割り当てられます。

  1. クライアントがリクエストを送信すると、負荷分散サービスは送信元 IP アドレスからリクエストの大まかな送信元を特定します。
  2. 負荷分散サービスは、バックエンド サービスが所有するバックエンドのロケーション、全体の容量、現在の総使用量を確認します。
  3. ユーザーに最も近いバックエンド インスタンスに使用可能な容量がある場合、このバックエンドのセットにリクエストが転送されます。
  4. 指定されたリージョンに届いたリクエストは、そのリージョン内で使用可能なすべてのバックエンド インスタンスに均等に分散されます。ただし、負荷が非常に小さい場合は分散が不均等に見える場合もあります。
  5. 指定されたリージョン内に使用可能な容量を持つ正常なインスタンスがない場合、ロードバランサは代替手段として、使用可能な容量を持つ次に近いリージョンにリクエストを送信します。

スタンダード階層では、TCP プロキシ負荷分散はリージョン サービスです。バックエンドはすべて、ロードバランサの外部 IP アドレスと転送ルールで使用されるリージョンに配置する必要があります。

コンポーネント

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

転送ルールとアドレス

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

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

ターゲット プロキシ

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

バックエンド サービス

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

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

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

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

バックエンドへのプロトコル

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

ファイアウォール ルール

バックエンド インスタンスは、ロードバランサの GFE / ヘルスチェック範囲からの接続を許可する必要があります。つまり、130.211.0.0/2235.191.0.0/16 からのトラフィックがバックエンド インスタンスまたはエンドポイントに到達することを許可するファイアウォール ルールを作成する必要があります。これらの IP アドレス範囲は、ヘルスチェック パケットと、バックエンドに送信されるすべての負荷分散されたパケットのソースとして使用されます。

このファイアウォール ルールに構成するポートは、以下のバックエンド インスタンスまたはエンドポイントへのトラフィックを許可する必要があります。

  • 各転送ルールで使用されるポートを許可する
  • それぞれのバックエンド サービスに構成された各ヘルスチェックで使用されるポートを許可する

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

ヘルスチェック プローブの詳細と、130.211.0.0/2235.191.0.0/16 からのトラフィックを許可する必要がある理由については、プローブ IP 範囲とファイアウォール ルールをご覧ください。

送信元 IP アドレス

各バックエンド仮想マシン(VM)インスタンスまたはコンテナから見たパケットの送信元 IP アドレスは、次の範囲の IP アドレスです。

  • 35.191.0.0/16
  • 130.211.0.0/22

実際の負荷分散トラフィックの送信元 IP アドレスは、ヘルスチェック プローブ IP 範囲と同じです。

バックエンドから見たトラフィックの送信元 IP アドレスは、ロードバランサの Google Cloud の外部 IP アドレスではありません。つまり、2 つの HTTP、SSL、または TCP セッションがあります。

  • セッション 1: 元のクライアントからロードバランサ(GFE)へのもの。

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

    • 送信元 IP アドレス: 35.191.0.0/16 または 130.211.0.0/22 いずれかの範囲の IP アドレス。

      実際の送信元アドレスは予測できません。

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

分散モード

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

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

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

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

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

セッション アフィニティ

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

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

ポートを開く

TCP プロキシ ロードバランサはリバース プロキシのロードバランサです。ロードバランサによって受信接続が終端され、ロードバランサからバックエンドへの新しい接続が開かれます。リバース プロキシ機能は、Google Front End(GFE)が提供します。

GFE には、他の Google Cloud ロードバランサや他の Google サービスをサポートする複数のオープンポートがあります。ロードバランサの外部 IP アドレスに対してセキュリティ スキャンまたはポートスキャンを実行すると、他のポートも開いているように見えます。

このことは、TCP プロキシのロードバランサには影響しません。SSL プロキシ ロードバランサの定義で使用される外部転送ルールは、特定のポートセットのみを参照できます。異なる TCP の宛先ポートのトラフィックはロードバランサのバックエンドには転送されません。 未許可のポートに TCP セッションを開こうとすることで、追加のポートへのトラフィックが処理されていないことを確認できます。リクエストを処理する GFE によって、TCP リセット(RST)パケットとの接続が閉じられます。

次のステップ