TCP プロキシ負荷分散のコンセプト

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

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

TCP プロキシ負荷分散は HTTP 以外のトラフィックを対象としています。HTTP トラフィックの場合は、代わりに HTTP 負荷分散を使用します。プロキシが使用される SSL トラフィックの場合は、SSL プロキシ負荷分散を使用してください。

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

Google Cloud Load Balancing との相違点については、次のドキュメントを参照してください。

概要

TCP トラフィックに TCP プロキシ負荷分散を使用すると、負荷分散レイヤで顧客の TCP セッションを終端し、TCP または SSL を使用して仮想マシンのインスタンスにトラフィックを転送することが可能になります。

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、5222

異なるネットワーク サービス階層でのロードバランサの動作

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

バックエンド バケット

バックエンド バケットは、インスタンス グループではなく Google Cloud Storage バケットに受信トラフィックを転送します。

バケットはデータを保持するコンテナです。バケットは、VM インスタンス、Google App Engine、およびその他のクラウド サービスの間で共通のストレージとして使用できます。データが大量にあり、ローカルで 1 つの VM インスタンスに保存する必要がない場合は、ストレージ バケットをお使いください。

ファイアウォール ルール

ファイアウォール ルールを使用して、インスタンスに到達するトラフィックを許可します。ロードバランサとヘルス チェッカーからのトラフィックの両方を許可するファイアウォール ルールを構成する必要があります。

次の条件を満たす場合に、単一のファイアウォール ルールを使用できます。

  • グローバル転送ルールが使用するポートでトラフィックを許可する。
  • ヘルス チェッカーも同じポートを使用する。

ヘルスチェッカーが別のポートを使用する場合は、そのポートに対して別のファイアウォール ルールを作成する必要があります。

ファイアウォール ルールは、ネットワークのエッジではなく、インスタンス レベルでトラフィックのブロックまたは許可を行うことに注意してください。ロードバランサ自体へのトラフィックはブロックできません。

Google Cloud Platform が使用する IP アドレスは広範で、経時的に変化する点にも注意してください。ある特定の時点での外部 IP アドレスを判別する必要がある場合は、Google Compute Engine のよくある質問の手順に従ってください。

送信元 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 アドレス: IP アドレスは次のいずれかの範囲のものです。35.191.0.0/16 または 130.211.0.0/22

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

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

TCP プロキシ負荷分散の例

TCP プロキシの場合、1 つの TCP 接続上で受信されたトラフィックは負荷分散層で終端されてから、利用可能な最も近いインスタンス グループにプロキシされます。

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

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

セッション アフィニティ

同じクライアントからのリクエストをすべて同じ仮想マシン インスタンスに送信するのが(そのインスタンスが正常で処理能力がある場合)、セッション アフィニティです。

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

インターフェース

TCP プロキシ負荷分散サービスを構成および更新するには、次のインターフェースを使用します。

  • gcloud コマンドライン ツール: Cloud SDK に含まれるコマンドライン ツール。TCP プロキシ負荷分散のドキュメントでは、このツールを使用した例を提供しています。ツールの完全な概要については、gcloud ツールガイドをご覧ください。負荷分散に関連するコマンドは、gcloud compute コマンド グループにあります。

    --help フラグを使用して、gcloud コマンドの詳細なヘルプを入手することもできます。

    gcloud compute http-health-checks create --help
        
  • Google Cloud Console: Google Cloud Console はすべての負荷分散タスクを実行できます。

  • REST API: Cloud Load Balancing API はすべての負荷分散タスクを実行できます。API リファレンス ドキュメントで、使用できるリソースとメソッドについて説明しています。

オープンポート

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

ファイアウォール ルールの設定では、GFE からバックエンドへのトラフィックをブロックしますが、GFE への受信トラフィックはブロックしません。

TCP プロキシのロードバランサには、同じアーキテクチャで実行される他の Google サービスをサポートしているオープンポートが多数あります。ロードバランサの外部 IP アドレスに対してセキュリティ スキャンまたはポートスキャンを実行すると、追加のポートが開いているように見えます。

このことは、TCP プロキシのロードバランサには影響しません。SSL ロードバランサの定義で使用される外部転送ルールは、特定のポートセットのみを参照できます。トラフィックの TCP 宛先ポートが異なれば、ロードバランサのバックエンドに転送されることはないからです。

次のステップ