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

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

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

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

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

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 を終端する必要があります。

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

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

プレミアム ティア

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

トラフィックは次のようにバックエンドに割り振られます。

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

スタンダード ティア

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

アーキテクチャ

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

転送ルールと IP アドレス

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

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

ターゲット プロキシ

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

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

SSL 証明書

ターゲット SSL プロキシに 1 つ以上の SSL 証明書をインストールする必要があります。

これらの証明書は、Google Front End(GFE)とクライアント間の通信を保護するために、ターゲット SSL プロキシによって使用されます。この証明書は、セルフマネージド SSL 証明書または Google マネージド SSL 証明書のいずれかとなります。

SSL 証明書の上限と割り当てについては、負荷分散の割り当てページの SSL 証明書をご覧ください。

最高レベルのセキュリティを実現するには、SSL プロキシ ロードバランサのデプロイにエンドツーエンドの暗号化を使用します。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。

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

バックエンド サービス

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

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

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

ファイアウォール ルール

バックエンド インスタンスは、ロードバランサの 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 アドレス。

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

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

オープンポート

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

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

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

このことは、SSL プロキシのロードバランサには影響しません。SSL ロードバランサの定義で使用される外部の転送ルールでは、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 宛先ポートのトラフィックは、ロードバランサのバックエンドには転送されません。

トラフィック分散

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

分散モード

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

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

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

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

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

セッション アフィニティ

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

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

フェイルオーバー

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

使用上の注意と制限事項

  • 暗号化されていない TCP を介して負荷分散層とバックエンド インスタンス間でトラフィックを送信すると、バックエンドから SSL 処理をオフロードできます。ただし、その場合、セキュリティの強度が弱くなります。そのため、この方法はおすすめしません。

  • SSL ポリシーを作成するには、gcloud コマンドライン ツールを使用します。

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

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

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

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

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

次のステップ