外部 SSL プロキシ ロードバランサは、インターネットから送信された SSL トラフィックを Google Cloud VPC ネットワーク内の仮想マシン（VM）インスタンスに分散するリバース プロキシ ロードバランサです。
SSL トラフィックに外部 SSL プロキシ ロードバランサを使用する場合、ユーザー SSL (TLS) 接続はロード バランシング レイヤで終了し、SSL (推奨) または TCP を使用して、最も近い使用可能なバックエンド インスタンスにプロキシされます。サポートされているバックエンドのタイプについては、バックエンドをご覧ください。
プレミアム ティアの外部 SSL プロキシ ロードバランサは、グローバル ロード バランシング サービスとして構成できます。スタンダード ティアの外部 SSL プロキシ ロードバランサは、リージョン単位でロードバランサを処理します。詳細については、Network Service Tiers でのロードバランサの動作をご覧ください。
この例では、アイオワとボストンのユーザーからのトラフィックが負荷分散層で停止し、選択したバックエンドとの接続が確立されます。
外部 SSL プロキシ ロードバランサは 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 または TCP スタックで脆弱性が見つかると、VM の安全性を維持するため、ロードバランサで自動的にパッチが適用されます。
すべてのポートをサポートします。外部 SSL プロキシ ロードバランサの各転送ルールは、
1から65535までの 1 つの TCP ポートをサポートしています。Google マネージド SSL 証明書を使用するには、証明書のプロビジョニングと更新が正常に完了するように、TCP ポート 443 を使用するよう転送ルールを構成する必要があります。SSL ポリシーSSL ポリシーによって、外部 SSL プロキシのロードバランサがクライアントとネゴシエートする SSL の機能を制御できます。
TLS の終端ロケーションに対する地理的制御外部 SSL プロキシ ロードバランサは、クライアントとロードバランサ間のレイテンシを最小限に抑えるため、グローバルに分散するロケーションで TLS を終了します。どこで TLS を終端するかを地理的に制御する必要がある場合は、外部パススルー ネットワーク ロードバランサ（/load-balancing/docs/network/）を代わりに使用し、ニーズに適したリージョンにあるバックエンドで TLS を終端する必要があります。
Google Cloud Armor とのインテグレーション。Google Cloud Armor セキュリティ ポリシーを使用すると、分散型サービス拒否攻撃（DDoS）などの標的型攻撃からインフラストラクチャを保護できます。
アーキテクチャ
外部 SSL プロキシのロードバランサのコンポーネントは次のとおりです。
転送ルールと IP アドレス
転送ルールは、IP アドレス、ポート、プロトコルに基づいて、ターゲット プロキシとバックエンド サービスからなる負荷分散構成にトラフィックをルーティングします。
各転送ルールは、アプリケーションの DNS レコードで使用できる単一の IP アドレスを提供します。DNS ベースの負荷分散は必要ありません。使用できる静的 IP アドレスを予約するか、Cloud Load Balancing から割り当てます。推奨されているのは静的 IP アドレスの予約です。静的アドレスを予約しない場合、転送ルールを削除して新しく作り直すたびに DNS レコードを編集して、新しく割り当てられたエフェメラル IP アドレスに直す必要があるからです。
外部 SSL プロキシ ロードバランサで使用する各外部転送ルールは、転送ルールのポート指定にリストされたポートのいずれかのみを参照できます。
外部 SSL プロキシ ロードバランサは、ポート範囲の単一ポート（連続）をサポートします。複数の連続したポートをサポートするには、複数の転送ルールを構成する必要があります。同じ仮想 IP アドレスと異なるポートを使用して複数の転送ルールを構成できます。したがって、別々のカスタムポートを持つ複数のアプリケーションを同じ SSL プロキシの仮想 IP アドレスにプロキシできます。
ターゲット プロキシ
外部 SSL プロキシ ロードバランサは、クライアントからの SSL 接続を終端して、バックエンドへの新しい接続を作成します。ターゲット プロキシは、これらの新しい接続をバックエンド サービスに転送します。
デフォルトでは、元のクライアントの IP アドレスとポート情報は保持されません。PROXY プロトコルを使用してこの情報を保持できます。
SSL 証明書
ターゲット SSL プロキシを使用する外部プロキシ ネットワーク ロードバランサには、ロードバランサの構成の一部として秘密鍵と SSL 証明書が必要です。
Google Cloud には、秘密鍵と SSL 証明書をターゲット SSL プロキシに割り当てるための構成方法が 2 つあります。1 つは Compute Engine SSL 証明書、もう 1 つは証明書マネージャーです。各構成の詳細については、SSL 証明書の概要で証明書の構成方法をご覧ください。
Google Cloud では、セルフマネージドと Google マネージドの 2 種類の証明書タイプが用意されています。各タイプの詳細については、SSL 証明書の概要で証明書のタイプをご覧ください。
バックエンド サービス
バックエンド サービスは、接続されているバックエンドの 1 つまたは複数に受信トラフィックを振り分けます。これらのバックエンドはそれぞれ、インスタンス グループまたはネットワーク エンドポイント グループと、バックエンドの処理能力に関する情報から構成されます。バックエンドの処理能力は、CPU または 1 秒あたりのリクエスト数（RPS）に基づいています。
各バックエンド サービスは、使用可能なバックエンドに対して実行するヘルスチェックを指定します。
外部 SSL プロキシ ロードバランサは、次の分散モードがサポートしています。
UTILIZATION（デフォルト）: インスタンス グループのバックエンド使用率が指定値を下回ると、インスタンスはトラフィックを受け入れます。この値を設定するには、--max-utilizationパラメータを使用し、0.0（0%）～1.0（100%）の値を渡します。デフォルトは0.8（80%）です。CONNECTION: 接続数が指定された値を下回った場合に、インスタンスがトラフィックを受け入れます。この値は、次のいずれかに設定できます。--max-connections: インスタンス グループ内のすべてのバックエンド インスタンスの最大接続数。--max-connections-per-instance: 1 つのインスタンスが処理できる最大接続数。インスタンス グループの平均接続数がこの数を超えていない場合、リクエストは転送されます。
分散モードを UTILIZATION に設定している場合でも、--max-connections または --max-connections-per-instance を指定できます。--max-utilization と接続パラメータの両方を指定した場合、いずれかの上限に達すると、グループはすべて使用されているとみなされます。
バックエンド サービスのリソースの詳細については、バックエンド サービスの概要をご覧ください。
ユーザーへの中断を最小限に抑えるために、バックエンド サービスのコネクション ドレインを有効にできます。このような中断は、バックエンドの停止、手動による削除、オートスケーラーによる削除によって発生することがあります。コネクション ドレインを使用してサービスの中断を最小限に抑える方法については、コネクション ドレインの有効化のドキュメントをご覧ください。
バックエンドと VPC ネットワーク
すべてのバックエンドは同じプロジェクトに配置する必要があります。ただし、配置先の VPC ネットワークは異なってもかまいません。GFE プロキシ システムはそれぞれの VPC ネットワーク内のバックエンドと直接通信するため、異なる VPC ネットワークを VPC ネットワーク ピアリングで接続する必要はありません。
ファイアウォール ルール
外部プロキシ ネットワーク ロードバランサには、次のファイアウォール ルールが必要です。
バックエンドに到達するように Google Front End（GFE）からのトラフィックを許可する、上り（内向き）許可ファイアウォール ルール。
バックエンドに到達するようにヘルスチェック プローブ範囲からのトラフィックを許可する、上り（内向き）許可ファイアウォール ルール。ヘルスチェック プローブの詳細と、プローブからのトラフィックを許可する必要がある理由については、プローブ IP 範囲とファイアウォール ルールをご覧ください。
ファイアウォール ルールは GFE プロキシではなく、VM インスタンス レベルで実装されます。Google Cloud ファイアウォール ルールを使用して、トラフィックがロードバランサに到達しないようにすることはできません。
これらのファイアウォール ルールのポートは、次のように構成する必要があります。
各バックエンド サービスのヘルスチェックのための宛先ポートへのトラフィックを許可します。
インスタンス グループのバックエンドの場合: バックエンド サービスの名前付きポートと、各インスタンス グループの名前付きポートに関連付けられたポート番号とのマッピングによって、構成するポートを決定します。同じバックエンド サービスに割り当てられたインスタンス グループ間でポート番号が異なる可能性があります。
GCE_VM_IP_PORTNEG バックエンドの場合: エンドポイントのポート番号へのトラフィックを許可します。
許可する必要がある送信元 IP アドレスの範囲は次のとおりです。
35.191.0.0/16130.211.0.0/22
これらの範囲は、GFE からのヘルスチェックとリクエストに適用されます。
送信元 IP アドレス
バックエンドから見たパケットの送信元 IP アドレスは、ロードバランサの Google Cloud の外部 IP アドレスではありません。つまり、2 つの TCP 接続があります。
グローバル外部プロキシ ネットワーク ロードバランサの場合:接続 1: 元のクライアントからロードバランサ（GFE）への接続。
- 送信元 IP アドレス: オリジナルのクライアント（クライアントが NAT の背後にある場合や外部プロキシの場合は外部 IP アドレス）。
- 宛先 IP アドレス: ロードバランサの IP アドレス。
接続 2: ロードバランサ（GFE）からバックエンド VM またはエンドポイントへの接続。
送信元 IP アドレス: ファイアウォール ルールで指定された範囲の IP アドレス。
宛先 IP アドレス: VPC ネットワーク内のバックエンド VM またはコンテナの内部 IP アドレス。
接続 1: 元のクライアントからロードバランサ（プロキシ専用サブネット）への接続。
- 送信元 IP アドレス: オリジナルのクライアント（クライアントが NAT の背後にある場合や外部プロキシの場合は外部 IP アドレス）。
- 宛先 IP アドレス: ロードバランサの IP アドレス。
接続 2: ロードバランサ（プロキシ専用サブネット）からバックエンド VM またはエンドポイントへの接続。
送信元 IP アドレス: ロードバランサと同じリージョン、同じネットワークにデプロイされたすべての Envoy ベースのロードバランサ間で共有されるプロキシ専用サブネットの IP アドレス。
宛先 IP アドレス: 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 は、転送ルールを構成するポートとポート 80 および 443 に対してのみ、SYN プローブへのレスポンスとして SYN-ACK パケットを送信します。GFE は、ロードバランサの IP アドレスと、転送ルールで構成されている宛先ポートにパケットが送信された場合にのみ、パケットをバックエンドに送信します。パケットが別のロードバランサの IP アドレスや、転送ルールに構成されていないポートのロードバランサの IP アドレスに送信された場合、ロードバランサのバックエンドへのパケット送信は発生しません。ロードバランサの IP アドレスに送信されたパケットには、Google のフリート内の任意の GFE が応答可能ですが、ロードバランサの IP アドレスと宛先ポートの組み合わせをスキャンすると、TCP 接続ごとに 1 つの GFE のみが検査されます。ロードバランサの IP アドレスは、単一のデバイスまたはシステムに割り当てられていません。したがって、GFE ベースのロードバランサの IP アドレスをスキャンしても、Google のフリート内のすべての GFE がスキャンされるわけではありません。
以下では、この点を考慮し、バックエンド インスタンスのセキュリティをより効果的に監査する方法を説明します。
セキュリティ監査担当者は、ロードバランサの構成で転送ルールの構成を検査する必要があります。転送ルールは、ロードバランサがパケットを受け入れてバックエンドに転送する宛先ポートを定義しています。GFE ベースのロードバランサの場合、1 つの外部転送ルールで参照できる宛先 TCP ポートは 1 つだけです。
セキュリティ監査担当者は、バックエンド VM に適用されるファイアウォール ルールの構成を検査する必要があります。ファイアウォール ルールの設定では、GFE からバックエンド VM へのトラフィックをブロックしますが、GFE への受信トラフィックはブロックしません。ベスト プラクティスについては、ファイアウォール ルールのセクションをご覧ください。
共有 VPC アーキテクチャ
外部 SSL プロキシ ロードバランサは、共有 VPC を使用するネットワークをサポートします。共有 VPC を使用すると、ネットワーク管理者とサービス デベロッパーの責任を明確に分離できます。開発チームはサービス プロジェクトでのサービスの構築に集中し、ネットワーク インフラストラクチャ チームはロード バランシングのプロビジョニングと管理を行うことができます。共有 VPC についてまだよく理解していない場合は、共有 VPC の概要のドキュメントをご覧ください。
| IP アドレス | 転送ルール | ターゲット プロキシ | バックエンド コンポーネント |
|---|---|---|---|
| 外部 IP アドレスは、ロードバランサと同じプロジェクトで定義する必要があります。 | 外部転送ルールは、バックエンド インスタンスと同じプロジェクト（サービス プロジェクト）で定義する必要があります。 | ターゲット SSL プロキシは、バックエンド インスタンスと同じプロジェクトで定義する必要があります。 | グローバル バックエンド サービスは、バックエンド インスタンスと同じプロジェクトで定義する必要があります。これらのインスタンスは、バックエンドとしてバックエンド サービスに接続されたインスタンス グループ内に存在する必要があります。バックエンド サービスに関連するヘルスチェックも、バックエンド サービスと同じプロジェクトで定義する必要があります。 |
トラフィック分散
外部 SSL プロキシ ロードバランサでバックエンドにトラフィックを分散する方法は、バックエンドの選択（セッション アフィニティ）に使用される分散モードとハッシュ方法によって異なります。
接続の分散方法
外部 SSL プロキシ ロードバランサは、プレミアム ティアのグローバル ロード バランシング サービスとして構成できます。また、スタンダード ティアのリージョン サービスとして構成することもできます。
プレミアム ティアの場合:
- Google は、全世界のあらゆる拠点からロードバランサの IP アドレスをアドバタイズします。各ロードバランサの IP アドレスはグローバル エニーキャストです。
- 複数のリージョンにバックエンドを持つバックエンド サービスを構成した場合、Google Front End（GFE）は、ユーザーに最も近いリージョンの正常なバックエンド インスタンス グループまたは NEG にリクエストを転送しようとします。このプロセスについては、このページで詳しく説明します。
スタンダード ティアの場合:
Google は、転送ルールのリージョンに関連付けられた接続拠点からロードバランサの IP アドレスをアドバタイズします。ロードバランサは、リージョン外部 IP アドレスを使用します。
バックエンドは、転送ルールと同じリージョンに構成できます。ここで説明するプロセスは引き続き適用されますが、ロードバランサは対象の 1 つのリージョン内に存在する正常なバックエンドにのみリクエストを転送します。
リクエストの分散プロセス:
- 転送ルールの外部 IP アドレスは、Google ネットワークの境界にあるエッジルーターによってアドバタイズされます。各アドバタイズは、レイヤ 3/4 ロード バランシング システム（Maglev）へのネクストホップを一覧表示します。
- Maglev システムは、最初のレイヤの Google Front End（GFE）にトラフィックを転送します。最初のレイヤの GFE は、必要に応じて TLS を終了し、このプロセスに従ってトラフィックを 2 番目のレイヤの GFE にルーティングします。
- バックエンド サービスがインスタンス グループまたは
GCE_VM_IP_PORTNEG バックエンドを使用する場合、最初のレイヤの GFE は、インスタンス グループまたは NEG を含むリージョン内か、またはその近くに配置された 2 番目のレイヤの GFE を優先します。 - ハイブリッド NEG、サーバーレス NEG、インターネット NEG のバックエンド バケットとバックエンド サービスの場合、最初のレイヤの GFE は 2 番目の GFE をリージョンのサブセットで選択します。これにより、2 つの GFE 間のラウンドトリップ時間が最小化されます。
2 番目のレイヤの GFE の優先は保証されず、Google のネットワーク条件とメンテナンスに基づいて動的に変更される可能性があります。
2 番目のレイヤの GFE は、ヘルスチェックのステータスと実際のバックエンド容量の使用率を認識します。
- 2 番目のレイヤの GFE は、リージョン内のゾーンのバックエンドにリクエストを転送します。
- プレミアム ティアの場合は、2 番目のレイヤの GFE が、異なるリージョンのゾーンにあるバックエンドにリクエストを送信する可能性があります。この動作はスピルオーバーと呼ばれます。
- スピルオーバーは、2 番目のレイヤの GFE に認識されるすべてのバックエンドが容量の上限に達した場合か、正常ではない場合に可能です。
- 2 番目のレイヤの GFE には、別のリージョンのゾーンに存在する利用可能な正常なバックエンドに関する情報があります。
バックエンドにリクエストを分散する場合、GFE はゾーンレベルで動作します。
スピルオーバーには次の 2 つの原則が適用されます。
通常、2 番目のレイヤの GFE は、バックエンドのロケーションのサブセットを提供するように構成されています。
スピルオーバー動作は、使用可能なすべての Google Cloud ゾーンを使い切るわけではありません。特定のゾーンまたはリージョン全体のバックエンドからトラフィックを転送する必要がある場合は、容量スケーラーをゼロに設定する必要があります。ヘルスチェックに失敗するようにバックエンドを構成しても、2 番目のレイヤの GFE が別のリージョンのゾーンにバックエンドをスピルオーバーする保証はありません。
分散モード
バックエンド サービスにバックエンドを追加するときは、ロード バランシング モードを設定します。
外部 SSL プロキシ ロードバランサの場合、分散モードは CONNECTION または UTILIZATION に設定できます。
ロード バランシング モードが CONNECTION に設定されている場合、バックエンドで処理できる同時接続数に基づいて負荷が分散されます。次のパラメータ（maxConnections（リージョン マネージド インスタンス グループを除く）、maxConnectionsPerInstance、maxConnectionsPerEndpoint）のいずれかも指定する必要があります。
負荷分散モードが UTILIZATION に設定されている場合、インスタンス グループ内のインスタンスの使用率に基づいて負荷が分散されます。
ロードバランサのタイプとサポートされている分散モードの比較については、負荷分散の方法をご覧ください。
セッション アフィニティ
バックエンドが良好な状態で処理能力があれば、セッション アフィニティにより、同じクライアントからのすべてのリクエストが同じバックエンドに送信されます。
外部 SSL プロキシ ロードバランサにはクライアント IP アフィニティが用意されています。このアフィニティにより、同じクライアント IP アドレスからのすべてのリクエストが同じバックエンドに転送されます。
フェイルオーバー
バックエンドが異常な状態になった場合、トラフィックは同じリージョン内の正常なバックエンドに自動的にリダイレクトされます。リージョン内のすべてのバックエンドが異常な状態の場合、トラフィックは他のリージョンの正常なバックエンドに分散されます（プレミアム ティアのみ）。すべてのバックエンドが異常な状態の場合、ロードバランサはトラフィックを破棄します。
GKE アプリケーションのロード バランシング
Google Kubernetes Engine でアプリケーションを構築する場合は、スタンドアロン NEG を使用してトラフィックを直接コンテナにロード バランシングできます。スタンドアロン NEG では、NEG を作成する Service オブジェクトを作成し、NEG をバックエンド サービスに関連付けます。これにより、ロードバランサが Pod に接続できるようになります。
関連する GKE のドキュメント:
制限事項
各外部 SSL プロキシ ロードバランサには、単一のバックエンド サービス リソースが含まれます。バックエンド サービスに対する変更は即時に行われるわけではありません。変更が Google Front End（GFE）に反映されるまでに数分かかる場合があります。
外部 SSL ロードバランサは、クライアント証明書ベースの認証（別名: 相互 TLS 認証）をサポートしていません。
HTTPS トラフィックは外部 SSL プロキシ ロードバランサでサポートされますが、HTTPS トラフィックに外部アプリケーション ロードバランサを使用することを検討してください。外部アプリケーション ロードバランサは、HTTP リクエストパスによるルーティングやリクエスト レートによる分散など、HTTP 固有の多くの機能をサポートしています。外部アプリケーション ロードバランサがサポートする機能の詳細については、外部アプリケーション ロードバランサの概要をご覧ください。
外部 SSL プロキシ ロードバランサは、WebSockets や IMAP over SSL など、SSL を使用する他のプロトコルでも使用できます。
外部 SSL プロキシ ロードバランサでは、証明書の共通名（
CN）属性またはサブジェクト代替名（SAN）属性に含まれるドメインにおいて小文字のみがサポートされます。ドメイン名に大文字を含む証明書は、ターゲット プロキシでプライマリ証明書として設定されている場合にのみ返されます。
次のステップ
- 外部 SSL プロキシ ロードバランサを構成する。外部 SSL プロキシ ロードバランサの設定をご覧ください。
- SSL ポリシーの作成、変更、削除を行う。SSL ポリシーの使用をご覧ください。
- 外部 SSL プロキシ ロードバランサを設定する。モニタリングの使用をご覧ください。
- Google の接続拠点（PoP）の一覧を表示する。GFE のロケーションをご覧ください。