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

SSL プロキシ負荷分散は、インターネットから送信された SSL トラフィックを Google Cloud VPC ネットワークの仮想マシン(VM)インスタンスに分散するリバース プロキシ ロードバランサです。

SSL トラフィックに SSL プロキシ負荷分散を使用すると、ユーザー SSL(TLS)接続を負荷分散レイヤで終端し、SSL(推奨)または TCP を使用して、利用可能な最も近いバックエンド インスタンスにプロキシされます。サポートされているバックエンドのタイプについては、バックエンドをご覧ください。

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

この例では、アイオワとボストンのユーザーからのトラフィックが負荷分散層で停止し、選択したバックエンドとの接続が確立されます。

Cloud Load Balancing と SSL 終端処理(クリックして拡大)
Cloud Load Balancing と SSL 終端処理(クリックして拡大)

SSL プロキシ負荷分散は、HTTP(S) 以外のトラフィックを対象としています。HTTP(S) トラフィックの場合は、HTTP(S) 負荷分散の使用をおすすめします。

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

利点

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

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

  • インテリジェント ルーティング。ロードバランサは、処理能力があるバックエンドのロケーションにリクエストをルーティングできます。L3/L4 ロードバランサの場合は、利用可能な処理能力にかかわらず、常にリージョンのバックエンドにルーティングされます。より高度なルーティングを使用すると、x*N ではなく、N+1 または N+2 でプロビジョニングできるようになります。

  • バックエンド使用率の向上。使用されている暗号の CPU 効率が良くない場合、SSL の処理によって CPU に多大な負荷がかかる可能性があります。CPU のパフォーマンスを最大化するには、ECDSA SSL 証明書と TLS 1.2 を使用し、ロードバランサとインスタンス間の SSL に ECDHE-ECDSA-AES128-GCM-SHA256 暗号スイートを使用します。

  • 証明書管理。顧客向けの SSL 証明書は、デベロッパーが自分で取得および管理する証明書(セルフマネージド証明書)か、Google が取得して管理する証明書(Google マネージド証明書のいずれかです。Google マネージド SSL 証明書の場合、1 つの証明書で最大 100 個までのドメインがサポートされます。Google マネージド証明書では、複数のドメインがサポートされます。証明書は、ロードバランサにのみプロビジョニングする必要があります。VM インスタンスでは、自己署名証明書を使用して管理を簡素化できます。

  • セキュリティ パッチ。SSL または TCP スタックで脆弱性が見つかると、VM の安全性を維持するため、ロードバランサで自動的にパッチが適用されます。

  • 次の一般的なポートのサポート: 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。Google マネージド SSL 証明書を SSL プロキシの負荷分散に使用する場合、Google マネージド SSL 証明書のプロビジョニングと更新を行うには、トラフィックのフロントエンド ポートを 443 に設定する必要があります。

  • SSL ポリシーSSL ポリシーによって、SSL プロキシのロードバランサがクライアントとネゴシエートする SSL の機能を制御できます。

  • TLS の終端ロケーションに対する地理的制御SSL プロキシ ロードバランサは、クライアントとロードバランサ間のレイテンシを最小限に抑えるため、グローバルに分散するロケーションで TLS を終了します。どこで TLS を終端するかを地理的に制御する必要がある場合は、ネットワーク負荷分散を代わりに使用し、ニーズに適したリージョンにあるバックエンドで TLS を終端する必要があります。

アーキテクチャ

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

転送ルールと IP アドレス

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

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

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

ターゲット プロキシ

SSL プロキシ負荷分散は、クライアントからの SSL 接続を終端し、バックエンドへの新しい接続を作成します。ターゲット プロキシは、受信リクエストを直接バックエンド サービスにルーティングします。

デフォルトでは、元のクライアントの IP アドレスとポート情報は保持されません。PROXY プロトコルを使用してこの情報を保持できます。

SSL 証明書

ターゲット SSL プロキシに 1 つ以上の SSL 証明書をインストールする必要があります。 これらの証明書は、Google Front End(GFE)とクライアント間の通信を保護するために、ターゲット SSL プロキシによって使用されます。この証明書は、セルフマネージド SSL 証明書または Google マネージド SSL 証明書のいずれかとなります。 SSL 証明書の上限と割り当てについては、負荷分散の割り当てページの SSL 証明書をご覧ください。

SSL ポリシーを作成して、ロードバランサがネゴシエートする SSL の機能を管理できます。詳しくは、SSL ポリシーの概要をご覧ください。

暗号化されていない TCP を介して負荷分散層とバックエンド インスタンス間でトラフィックを送信すると、バックエンドから SSL 処理をオフロードできます。ただし、その場合、セキュリティの強度が弱くなります。そのため、この方法はおすすめしません。 最高レベルのセキュリティを実現するには、SSL プロキシ ロードバランサのデプロイにエンドツーエンドの暗号化を使用します。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。

Google がユーザー トラフィックを暗号化する方法に関する一般的な情報については、Google Cloud での転送中の暗号化ホワイト ペーパーをご覧ください。

バックエンド サービス

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

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

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

ファイアウォール ルール

バックエンド インスタンスでは、次のソースからの接続を許可する必要があります。

  • バックエンドに送信されたすべてのリクエストのロードバランサの Google Front End(GFE)
  • ヘルスチェック プローブ

このトラフィックを許可するには、上り(内向き)ファイアウォール ルールを作成する必要があります。これらのファイアウォール ルールのポートでは、次のようにトラフィックを許可する必要があります。

  • 各バックエンド サービスのヘルスチェックの宛先ポート。

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

  • GCE_VM_IP_PORT NEG バックエンドの場合: エンドポイントのポート番号。

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

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

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 アドレス: Virtual Private Cloud(VPC)ネットワーク内のバックエンド VM またはコンテナの内部 IP アドレス。

クライアントの送信元 IP アドレスの保持

ロードバランサへの受信接続の元の送信元 IP アドレスを保持するため、PROXY プロトコル(バージョン 1)のヘッダーを先頭に追加して、元の接続情報を保持するようにロードバランサを構成できます。詳細については、プロキシの proxy プロトコル ヘッダーの更新をご覧ください。

オープンポート

SSL プロキシ ロードバランサはリバース プロキシのロードバランサです。ロードバランサによって受信接続が終端され、ロードバランサからバックエンドへの新しい接続が開かれます。これらのロードバランサは、世界中の 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 への受信トラフィックはブロックしません。ベスト プラクティスについては、ファイアウォール ルールのセクションをご覧ください。

トラフィック分散

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

接続の分散方法

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

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

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

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

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

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

配信プロセスをリクエストする:

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

ロードバランサは次のプロセスを使用します。

  1. 転送ルールの外部 IP アドレスは、Google ネットワークの境界にあるエッジルーターによってアドバタイズされます。各アドバタイズには、可能な限りユーザーに近いレイヤ 3/4 負荷分散システム(Maglev)へのネクストホップが一覧表示されます。
  2. Maglev システムは、受信パケットの送信元 IP アドレスを検査します。受信したリクエストは、Google の geo-IP システムが可能な限りユーザーの近くにいると判断した Maglev システムに送信されます。
  3. Maglev システムは、トラフィックを最初のレイヤの Google Front End(GFE)に転送します。第 1 レイヤの GFE は、必要に応じて TLS を終了し、このプロセスに従ってトラフィックを第 2 レイヤの GFE にルーティングします。
    1. バックエンド サービスがインスタンス グループまたは GCE_VM_IP_PORT NEG バックエンドを使用する場合、最初のレイヤの GFE は、インスタンス グループまたは NEG を含むリージョン内またはその近くに配置された第 2 レイヤの GFE を優先します。
    2. ハイブリッド NEG、サーバーレス NEG、インターネット NEG のバックエンド バケットとバックエンド サービスの場合、第 1 レイヤの 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 つのゾーンを他のゾーンよりも優先する場合があります。これは正常な、想定されている設定です。ロードバランサが受信する接続数が増加するまで、リージョンのゾーン間での分散は行われません。

分散モード

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

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

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

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

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

セッション アフィニティ

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

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

フェイルオーバー

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

GKE アプリケーションの負荷分散

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

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

制限事項

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

  • SSL ロードバランサは、クライアント証明書ベースの認証(別名: 相互 TLS 認証)をサポートしていません。

  • SSL プロキシ負荷分散は HTTPS トラフィックを処理できますが、おすすめしません。HTTPS の場合は、代わりに HTTP(S) 負荷分散を使用してください。HTTP(S) 負荷分散も次の処理を行うため、ほとんどの場合こちらの方が適切な選択肢になります。

    • HTTP/2 と HTTP/3 をネゴシエーションします。
    • 無効な HTTP リクエストまたはレスポンスを拒否します。
    • URL ホストとパスに基づいて、別の VM にリクエストを転送します。
    • Cloud CDN と統合します。
    • バックエンド インスタンス間でリクエストの負荷をより均等に分散し、バックエンドをより効率的に使用できます。HTTPS では各リクエストは別個に負荷分散されますが、SSL プロキシ負荷分散では同じ SSL または TCP 接続からのすべてのバイトが同じバックエンド インスタンスに送信されます。
  • Google マネージド SSL 証明書を使用する SSL プロキシ ロードバランサの場合、証明書のプロビジョニングと更新を問題なく完了するには、フロントエンド ポートに 443 を含める必要があります。

    SSL プロキシ負荷分散は、WebSockets や IMAP over SSL など、SSL を使用する他のプロトコルでも使用できます。

  • SSL プロキシ ロードバランサでは、証明書の共通名(CN)属性またはサブジェクト代替名(SAN)属性に含まれるドメインにおいて小文字のみがサポートされます。ドメイン名に大文字を含む証明書は、ターゲット プロキシでプライマリ証明書として設定されている場合にのみ返されます。

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

次のステップ