外部プロキシ ネットワーク ロードバランサの概要

このドキュメントでは、Google Cloud 外部プロキシ ネットワーク ロードバランサの構成に必要なコンセプトについて説明します。

外部プロキシ ネットワーク ロードバランサは、インターネットから送信された TCP トラフィックを Google Cloud Virtual Private Cloud（VPC）ネットワーク内の仮想マシン（VM）インスタンスに分散するリバース プロキシ ロードバランサです。外部プロキシ ネットワーク ロードバランサを使用する場合、受信 TCP または SSL ユーザー トラフィックはロードバランサで終端します。新しい接続は、TCP または SSL（推奨）を使用して、最も近い使用可能なバックエンドにトラフィックを転送します。その他のユースケースについては、プロキシ ネットワーク ロードバランサの概要をご覧ください。

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

次の例では、都市 A と都市 B のユーザーからの SSL トラフィックがロード バランシング レイヤで終端し、選択したバックエンドとの個別の接続が確立されています。

SSL 終端を使用した Cloud Load Balancing。
Cloud Load Balancing と SSL 終端処理（クリックして拡大）

運用モード

外部プロキシ ネットワーク ロードバランサは、次のモードで構成できます。

  • 従来のプロキシ ネットワーク ロードバランサは、グローバルに分散された Google Front End（GFE）に実装されます。このロードバランサは、TCP トラフィックまたは SSL トラフィックを処理するように構成できます。前者にはターゲット TCP プロキシを、後者にはターゲット SSL プロキシを使用します。プレミアム ティアでは、このロードバランサはグローバル ロード バランシング サービスとして構成できます。スタンダード ティアでは、このロードバランサはリージョン ロード バランシング サービスとして構成されています。従来のプロキシ ネットワーク ロードバランサは、WebSockets や IMAP over SSL など、SSL を使用する他のプロトコルでも使用できます。
  • グローバル外部プロキシ ネットワーク ロードバランサは、グローバルに分散された GFE に実装され、高度なトラフィック管理機能をサポートします。このロードバランサは、TCP トラフィックまたは SSL トラフィックを処理するように構成できます。前者にはターゲット TCP プロキシを、後者にはターゲット SSL プロキシを使用します。このロードバランサは、プレミアム ティアでグローバル ロード バランシング サービスとして構成されています。グローバル外部プロキシ ネットワーク ロードバランサは、WebSockets や IMAP over SSL など、SSL を使用する他のプロトコルでも使用できます。
  • リージョン外部プロキシ ネットワーク ロードバランサは、オープンソースの Envoy プロキシ ソフトウェア スタックに実装されています。処理できるのは TCP トラフィックだけです。このロードバランサは、プレミアム ティアまたはスタンダード ティアのいずれかを使用できるリージョン ロード バランシング サービスとして構成されます。

モードを特定する

ロードバランサのモードを確認するには、次の手順を完了します。

コンソール

  1. Google Cloud コンソールの [ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. [ロードバランサ] タブに、ロードバランサのタイプ、プロトコル、リージョンが表示されます。リージョンが空の場合、ロードバランサはグローバルです。

    次の表に、ロードバランサのモードを識別する方法を示します。

    ロードバランサ モード ロードバランサの種類 アクセスタイプ リージョン
    従来のプロキシ ネットワーク ロードバランサ ネットワーク（クラシック プロキシ） 外部
    グローバル外部プロキシ ネットワーク ロードバランサ ネットワーク（プロキシ） 外部
    リージョン外部プロキシ ネットワーク ロードバランサ ネットワーク（プロキシ） 外部 リージョンを指定

gcloud

  1. gcloud compute forwarding-rules describe コマンドを使用します。

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

  2. コマンド出力で、ロード バランシング スキーム、リージョン、ネットワーク ティアを確認します。次の表に、ロードバランサのモードを識別する方法を示します。

    ロードバランサ モード ロード バランシング スキーム 転送ルール ネットワーク ティア
    従来のプロキシ ネットワーク ロードバランサ EXTERNAL グローバル スタンダードまたはプレミアム
    グローバル外部プロキシ ネットワーク ロードバランサ EXTERNAL_MANAGED グローバル プレミアム
    リージョン外部プロキシ ネットワーク ロードバランサ EXTERNAL_MANAGED リージョン スタンダードまたはプレミアム

アーキテクチャ

次の図は、グローバルとリージョンの外部プロキシ ネットワーク ロードバランサのコンポーネントを示しています。

グローバル

次の図は、グローバル外部プロキシ ネットワーク ロードバランサのデプロイメントのコンポーネントを示しています。このアーキテクチャは、グローバル外部プロキシ ネットワーク ロードバランサとプレミアム ティアの従来のプロキシ ネットワーク ロードバランサの両方に適用されます。

グローバル外部プロキシ ネットワーク ロードバランサのコンポーネント
グローバル外部プロキシ ネットワーク ロードバランサのコンポーネント（クリックして拡大）

リージョン

次の図は、リージョン外部プロキシ ネットワーク ロードバランサのデプロイメントのコンポーネントを示しています。

リージョン外部プロキシ ネットワーク ロードバランサのコンポーネント
リージョン外部プロキシ ネットワーク ロードバランサのコンポーネント（クリックして拡大）

外部プロキシ ネットワーク ロードバランサのコンポーネントは次のとおりです。

プロキシ専用サブネット

プロキシ専用サブネットには、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを 1 つ作成する必要があります。このプロキシ専用サブネットの --purpose フラグは REGIONAL_MANAGED_PROXY に設定されています。同じリージョンと VPC ネットワーク内にあるすべてのリージョン Envoy ベースのロードバランサは、同じプロキシ専用サブネットの Envoy プロキシのプールを共有します。

リージョンと VPC ネットワーク内のすべてのロードバランサのバックエンド VM またはエンドポイントは、プロキシ専用サブネットからの接続を受信します。

重要ポイント:

  • プロキシ専用サブネットは Envoy プロキシにのみ使用され、バックエンドには使用されません。
  • ロードバランサの IP アドレスは、プロキシ専用サブネットにはありません。ロードバランサの IP アドレスは外部マネージド転送ルールによって定義されます。

転送ルールと IP アドレス

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

IP アドレスの指定。各転送ルールは、アプリケーションの DNS レコードで使用できる単一の IP アドレスを参照します。使用できる静的 IP アドレスを予約するか、Cloud Load Balancing から割り当てます。静的 IP アドレスを予約することをおすすめします。それ以外の場合は、転送ルールを削除して新しく作り直すたびに、新しく割り当てられたエフェメラル IP アドレスで DNS レコードを更新する必要があります。

ポートの指定。このロードバランサの定義で使用される外部転送ルールは、1～65535 の 1 つのポートのみを参照できます。連続する複数のポートをサポートする場合は、複数の転送ルールを構成する必要があります。同じ仮想 IP アドレスと異なるポートを使用して複数の転送ルールを構成できます。したがって、別々のカスタムポートを持つ複数のアプリケーションを同じ TCP プロキシの仮想 IP アドレスにプロキシできます。詳細については、転送ルールのポート指定をご覧ください。

連続した複数のポートをサポートするには、複数の転送ルールを構成する必要があります。同じ仮想 IP アドレスと異なるポートを使用して複数の転送ルールを構成できます。したがって、別々のカスタムポートを持つ複数のアプリケーションを同じ TCP プロキシの仮想 IP アドレスにプロキシできます。

次の表は、さまざまなタイプのロードバランサを比較したものです。

ロードバランサ モード ネットワーク サービス ティア 転送ルール、IP アドレス、ロード バランシング スキーム インターネットからロードバランサのフロントエンドへの転送
従来のプロキシ ネットワーク ロードバランサ プレミアム ティア

グローバル外部転送ルール

グローバル外部 IP アドレス

ロード バランシング スキーム: EXTERNAL

 インターネット上のクライアントに最も近い GFE にルーティングされるリクエスト。
スタンダード ティア

リージョン外部転送ルール

リージョン外部 IP アドレス

ロード バランシング スキーム: EXTERNAL

 ロードバランサのリージョン内の GFE に転送されるリクエスト。
グローバル外部プロキシ ネットワーク ロードバランサ プレミアム ティア

グローバル外部転送ルール

グローバル外部 IP アドレス

ロード バランシング スキーム: EXTERNAL_MANAGED

 インターネット上のクライアントに最も近い GFE にルーティングされるリクエスト。
リージョン外部プロキシ ネットワーク ロードバランサ プレミアム ティアとスタンダード ティア *

リージョン外部転送ルール

リージョン外部 IP アドレス

ロード バランシング スキーム: EXTERNAL_MANAGED

 ロードバランサと同じリージョン内の Envoy プロキシにルーティングされるリクエスト。
* Google Cloud コンソールを使用して、プレミアム ティアでリージョン外部プロキシ ネットワーク ロードバランサを作成することはできません。また、Google Cloud コンソールでは、これらのロードバランサはスタンダード ティアをサポートするリージョンでのみ使用できます。代わりに gcloud または API を使用してください。

転送ルールと VPC ネットワーク

このセクションでは、外部アプリケーション ロードバランサで使用される転送ルールを VPC ネットワークに関連付ける方法について説明します。

ロードバランサ モード VPC ネットワークの関連付け
グローバル外部プロキシ ネットワーク ロードバランサ

従来のプロキシ ネットワーク ロードバランサ

関連付けられた VPC ネットワークはありません。

転送ルールでは、常に VPC ネットワーク外の IP アドレスが使用されます。したがって、転送ルールには VPC ネットワークが関連付けられていません。
リージョン外部プロキシ ネットワーク ロードバランサ

転送ルールの VPC ネットワークは、プロキシ専用サブネットが作成されたネットワークです。ネットワークは、転送ルールを作成するときに指定します。

ターゲット プロキシ

外部プロキシ ネットワーク ロードバランサは、クライアントからの接続を終端し、バックエンドへの新しい接続を作成します。ターゲット プロキシは、これらの新しい接続をバックエンド サービスに転送します。

アプリケーションで処理する必要があるトラフィックの種類に応じて、ターゲット TCP プロキシまたはターゲット SSL プロキシを使用して外部プロキシ ネットワーク ロードバランサを構成できます。

  • ターゲット TCP プロキシ: TCP トラフィックが想定される場合は、ターゲット TCP プロキシを使用してロードバランサを構成します。
  • ターゲット SSL プロキシ: 暗号化されたクライアント トラフィックが想定される場合は、ターゲット SSL プロキシでロードバランサを構成します。このタイプのロードバランサは、HTTP(S) 以外のトラフィックのみを想定しています。HTTP(S) トラフィックの場合は、外部アプリケーション ロードバランサの使用をおすすめします。

デフォルトでは、ターゲット プロキシは元のクライアントの IP アドレスとポート情報を保持しません。この情報を保持するには、ターゲット プロキシで PROXY プロトコルを有効にします。

ロードバランサ モード ネットワーク サービス ティア ターゲット プロキシ
従来のプロキシ ネットワーク ロードバランサ プレミアム ティア targetTcpProxies または targetSslProxies
スタンダード ティア targetTcpProxies または targetSslProxies
グローバル外部プロキシ ネットワーク ロードバランサ プレミアム ティア targetTcpProxies または targetSslProxies
リージョン外部プロキシ ネットワーク ロードバランサ プレミアム ティアとスタンダード ティア regionTargetTcpProxies

SSL 証明書

SSL 証明書は、ターゲット SSL プロキシを使用してグローバル外部プロキシ ネットワーク ロードバランサと従来のプロキシ ネットワーク ロードバランサをデプロイする場合にのみ必要です。

ターゲット SSL プロキシを使用する外部プロキシ ネットワーク ロードバランサには、ロードバランサの構成の一部として秘密鍵と SSL 証明書が必要です。

  • Google Cloud には、秘密鍵と SSL 証明書をターゲット SSL プロキシに割り当てるための構成方法が 2 つあります。1 つは Compute Engine SSL 証明書、もう 1 つは証明書マネージャーです。各構成の詳細については、SSL 証明書の概要で証明書の構成方法をご覧ください。

  • Google Cloud では、セルフマネージドと Google マネージドの 2 種類の証明書タイプが用意されています。各タイプの詳細については、SSL 証明書の概要で証明書のタイプをご覧ください。

バックエンド サービス

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

各ロードバランサには、使用可能なバックエンドに対して実行されるヘルスチェックを指定する、単一のバックエンド サービス リソースがあります。

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

バックエンド サービス リソースの詳細については、バックエンド サービスの概要をご覧ください。

次の表に、サポートされているバックエンド機能を示します。

ロードバランサ モード バックエンド サービスでサポートされるバックエンド
インスタンス グループ ゾーン NEG インターネット NEG サーバーレス NEG ハイブリッド NEG Private Service Connect NEG GKE
従来のプロキシ ネットワーク ロードバランサ スタンドアロン ゾーン NEG を使用する
グローバル外部プロキシ ネットワーク ロードバランサ * GCE_VM_IP_PORT タイプのエンドポイント*
リージョン外部プロキシ ネットワーク ロードバランサ GCE_VM_IP_PORT タイプのエンドポイント リージョン NEG のみ Private Service Connect NEG を追加する

* グローバル外部プロキシ ネットワーク ロードバランサは、IPv4 と IPv6（デュアル スタック）のインスタンス グループとゾーン NEG バックエンドをサポートしています。ゾーン NEG を使用したデュアル スタックは、GCE_VM_IP_PORT タイプのエンドポイントのみがサポートしています。

バックエンドと VPC ネットワーク

バックエンドを配置するロケーションの制限は、ロードバランサの種類によって異なります。

グローバル外部プロキシ ネットワーク ロードバランサと従来のプロキシ ネットワーク ロードバランサの場合、インスタンス グループ バックエンドのすべてのバックエンド インスタンスと NEG バックエンドのすべてのバックエンド エンドポイントは同じプロジェクトに配置する必要があります。ただし、インスタンス グループのバックエンドまたは NEG は、そのプロジェクトの別の VPC ネットワークを使用できます。GFE はそれぞれの VPC ネットワーク内のバックエンドと直接通信するため、異なる VPC ネットワークを VPC ネットワーク ピアリングで接続する必要はありません。

リージョン外部プロキシ ネットワーク ロードバランサの場合、これはバックエンドのタイプによって異なります。

  • インスタンス グループ、ゾーン NEG、ハイブリッド接続 NEG の場合、すべてのバックエンドはバックエンド サービスと同じプロジェクトとリージョンに配置する必要があります。ただし、ロードバランサは、バックエンド サービスと同じプロジェクトで別の VPC ネットワークを使用するバックエンドを参照できます（この機能はプレビュー版です）。ロードバランサの VPC ネットワークとバックエンド VPC ネットワーク間の接続は、VPC ネットワーク ピアリング、Cloud VPN トンネル、Cloud Interconnect VLAN アタッチメント、または Network Connectivity Center フレームワークを使用して構成できます。

    バックエンド ネットワークの定義

    • ゾーン NEG とハイブリッド NEG の場合、NEG の作成時に VPC ネットワークを明示的に指定します。
    • マネージド インスタンス グループの場合、VPC ネットワークはインスタンス テンプレートで定義されます。
    • 非マネージド インスタンス グループの場合、インスタンス グループの VPC ネットワークは、インスタンス グループに追加された最初の VM の nic0 インターフェースの VPC ネットワークと一致するように設定されます。

    バックエンド ネットワークの要件

    バックエンド ネットワークは、次のいずれかのネットワーク要件を満たしている必要があります。

    • バックエンドの VPC ネットワークは、転送ルールの VPC ネットワークと完全に一致する必要があります。

    • バックエンドの VPC ネットワークは、VPC ネットワーク ピアリングを使用して転送ルールの VPC ネットワークに接続する必要があります。転送ルールの VPC ネットワークのプロキシ専用サブネットと、バックエンド インスタンスまたはエンドポイントで使用されるサブネットとの通信を許可するには、サブネット ルート交換を構成する必要があります。

    • バックエンドの VPC ネットワークと転送ルールの VPC ネットワークは、同じ Network Connectivity Center ハブの VPC スポークである必要があります。インポート フィルタとエクスポート フィルタでは、転送ルールの VPC ネットワークのプロキシ専用サブネットと、バックエンド インスタンスまたはエンドポイントで使用されるサブネットとの通信を許可する必要があります。

  • 他のすべてのバックエンド タイプの場合、すべてのバックエンドを同じ VPC ネットワークとリージョンに配置する必要があります。

バックエンドとネットワーク インターフェース

インスタンス グループのバックエンドを使用する場合、パケットは常に nic0 に配信されます。別の NIC にパケットを送信する場合は、NEG バックエンドを使用します。

ゾーン NEG バックエンドを使用する場合、パケットは NEG のエンドポイントで表されるネットワーク インターフェースに送信されます。NEG エンドポイントは、NEG に明示的に定義された VPC ネットワークと同じ VPC ネットワークに存在する必要があります。

バックエンドと通信するためのプロトコル

外部プロキシ ネットワーク ロードバランサのバックエンド サービスを構成するときに、バックエンド サービスがバックエンドとの通信に使用するプロトコルを設定します。

  • 従来のプロキシ ネットワーク ロードバランサの場合は、TCP または SSL を選択できます。
  • グローバル外部プロキシ ネットワーク ロードバランサの場合は、TCP または SSL を選択できます。
  • リージョン外部プロキシ ネットワーク ロードバランサの場合は、TCP を使用できます。

ロードバランサは、指定したプロトコルのみを使用し、他のプロトコルとの接続をネゴシエートしません。

ファイアウォール ルール

次のファイアウォール ルールが必要です。

  • 従来のプロキシ ネットワーク ロードバランサの場合は、GFE からのトラフィックがバックエンドに到達することを許可する上り（内向き）allow ファイアウォール ルール。
  • グローバル外部プロキシ ネットワーク ロードバランサの場合は、GFE からのトラフィックがバックエンドに到達することを許可する上り（内向き）allow ファイアウォール ルール。
  • リージョン外部プロキシ ネットワーク ロードバランサの場合は、プロキシ専用サブネットからのトラフィックがバックエンドに到達することを許可する上り（内向き）ファイアウォール ルール。
  • ヘルスチェック プローブ範囲からのトラフィックがバックエンドに到達できることを許可する上り（内向き）allow ファイアウォール ルール。ヘルスチェック プローブの詳細と、プローブからのトラフィックを許可する必要がある理由については、プローブ IP 範囲とファイアウォール ルールをご覧ください。

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

これらのファイアウォール ルールのポートは、次のように構成する必要があります。

  • 各バックエンド サービスのヘルスチェックのための宛先ポートへのトラフィックを許可します。
  • インスタンス グループのバックエンドの場合: バックエンド サービスの名前付きポートと、各インスタンス グループの名前付きポートに関連付けられたポート番号とのマッピングによって、構成するポートを決定します。同じバックエンド サービスに割り当てられたインスタンス グループ間でポート番号が異なる可能性があります。
  • GCE_VM_IP_PORT NEG ゾーン NEG バックエンドの場合: エンドポイントのポート番号へのトラフィックを許可します。

次の表は、ファイアウォール ルールに必要な送信元 IP アドレス範囲をまとめたものです。

ロードバランサ モード ヘルスチェックのソース範囲 リクエストのソース範囲
グローバル外部プロキシ ネットワーク ロードバランサ
  • 35.191.0.0/16
  • 130.211.0.0/22

バックエンドへの IPv6 トラフィックの場合:

  • 2600:2d00:1:b029::/64
 GFE トラフィックのソースはバックエンド タイプによって異なります。
  • インスタンス グループとゾーン NEG（GCE_VM_IP_PORT）:
    • 130.211.0.0/22
    • 35.191.0.0/16

    バックエンドへの IPv6 トラフィックの場合:

    • 2600:2d00:1:1::/64
従来のプロキシ ネットワーク ロードバランサ
  • 35.191.0.0/16
  • 130.211.0.0/22
 これらの範囲は、ヘルスチェック プローブと GFE からのリクエストに適用されます。
リージョン外部プロキシ ネットワーク ロードバランサ1、2
  • 35.191.0.0/16
  • 130.211.0.0/22

バックエンドへの IPv6 トラフィックの場合:

  • 2600:2d00:1:b029::/64
 これらの範囲は、ヘルスチェック プローブに適用されます。

* ハイブリッド NEG の許可リストに Google のヘルスチェック プローブ範囲を追加する必要はありません。ただし、1 つのバックエンド サービスでハイブリッド NEG とゾーン NEG の組み合わせを使用している場合は、ゾーン NEG の許可リストに Google ヘルスチェック プローブ範囲を追加する必要があります。

† リージョン インターネット NEG の場合、ヘルスチェックは省略可能です。リージョン インターネット NEG を使用するロードバランサからのトラフィックは、プロキシ専用サブネットから発信されます。このトラフィックは、Cloud NAT により、手動または自動的に割り振られた NAT IP アドレスに NAT 変換されます。このトラフィックには、ヘルスチェック プローブと、ロードバランサからバックエンドへのユーザー リクエストの両方が含まれます。詳細については、リージョン NEG: 下り（外向き）に Cloud NAT を使用するをご覧ください。

送信元 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 アドレス。

オープンポート

外部プロキシ ネットワーク ロードバランサは、リバース プロキシ ロードバランサです。ロードバランサによって受信接続が終端され、ロードバランサからバックエンドへの新しい接続が開かれます。これらのロードバランサは、世界中の Google Front End（GFE）プロキシを使用して実装されています。

GFE には、同じアーキテクチャで実行される他の Google サービスをサポートするための複数のオープンポートがあります。ポートスキャンを実行すると、GFE で実行されている他の Google サービスのオープンポートが表示される場合があります。

GFE ベースのロードバランサの IP アドレスに対してポートスキャンを実行することは、次の理由により、監査の観点からは役立ちません。

  • 通常、ポートスキャン（たとえば nmap を使用）では、TCP SYN プローブを実行するときにレスポンス パケットや TCP RST パケットは想定されません。GFE は、転送ルールを構成したポートに対してのみ、SYN プローブへのレスポンスとして SYN-ACK パケットを送信します。GFE は、ロードバランサの IP アドレスと、転送ルールで構成されている宛先ポートにパケットが送信された場合にのみ、パケットをバックエンドに送信します。別の IP アドレスまたはポートに送信されたパケットはバックエンドに送信されません。

    GFE は、Google Cloud Armor などのセキュリティ機能を実装しています。Google Cloud Armor Standard を使用すると、GFE は、ボリューム型およびプロトコル ベースの DDoS 攻撃と SYN フラッドを常に阻止します。この保護は、Google Cloud Armor を明示的に構成していない場合でも使用できます。セキュリティ ポリシーを構成した場合または Managed Protection Plus に登録した場合にのみ、課金されます。

  • ロードバランサの IP アドレスに送信されたパケットには、Google のフリート内の任意の GFE が応答可能ですが、ロードバランサの IP アドレスと宛先ポートの組み合わせをスキャンすると、TCP 接続ごとに 1 つの GFE のみが検査されます。ロードバランサの IP アドレスは、単一のデバイスまたはシステムに割り当てられていません。したがって、GFE ベースのロードバランサの IP アドレスをスキャンしても、Google のフリート内のすべての GFE がスキャンされるわけではありません。

以下では、この点を考慮し、バックエンド インスタンスのセキュリティをより効果的に監査する方法を説明します。

  • セキュリティ監査担当者は、ロードバランサの構成で転送ルールの構成を検査する必要があります。転送ルールは、ロードバランサがパケットを受け入れてバックエンドに転送する宛先ポートを定義しています。GFE ベースのロードバランサの場合、1 つの外部転送ルールで参照できる宛先 TCP ポートは 1 つだけです。

  • セキュリティ監査担当者は、バックエンド VM に適用されるファイアウォール ルールの構成を検査する必要があります。設定したファイアウォール ルールでは、GFE からバックエンド VM へのトラフィックはブロックされますが、GFE への受信トラフィックはブロックされません。ベスト プラクティスについては、ファイアウォール ルールのセクションをご覧ください。

共有 VPC アーキテクチャ

従来のプロキシ ネットワーク ロードバランサとリージョン外部プロキシ ネットワーク ロードバランサは、共有 VPC ネットワークを使用するデプロイをサポートしています。共有 VPC を使用すると、ネットワーク管理者とサービス デベロッパーの責任を明確に分離できます。開発チームはサービス プロジェクトでのサービスの構築に集中し、ネットワーク インフラストラクチャ チームはロード バランシングのプロビジョニングと管理を行うことができます。共有 VPC についてまだよく理解していない場合は、共有 VPC の概要のドキュメントをご覧ください。

IP アドレス 転送ルール ターゲット プロキシ バックエンド コンポーネント
外部 IP アドレスは、ロードバランサと同じプロジェクトで定義する必要があります。 外部転送ルールは、バックエンド インスタンスと同じプロジェクト（サービス プロジェクト）で定義する必要があります。 ターゲット TCP または SSL プロキシは、バックエンド インスタンスと同じプロジェクトで定義する必要があります。

従来のプロキシ ネットワーク ロードバランサの場合、グローバル バックエンド サービスはバックエンド インスタンスと同じプロジェクトで定義する必要があります。これらのインスタンスは、バックエンドとしてバックエンド サービスに接続されたインスタンス グループ内に存在する必要があります。バックエンド サービスに関連するヘルスチェックは、バックエンド サービスと同じプロジェクトで定義する必要があります。

通常、リージョン外部プロキシ ネットワーク ロードバランサの場合、バックエンド VM はサービス プロジェクトに配置されます。そのサービス プロジェクトでは、リージョン バックエンド サービスとヘルスチェックを定義する必要があります。

トラフィック分散

バックエンド インスタンス グループまたは NEG をバックエンド サービスに追加する場合は、バックエンドの負荷とターゲット容量を測定する方法を定義するロード バランシング モードを指定します。

外部プロキシ ネットワーク ロードバランサの場合、分散モードは CONNECTION または UTILIZATION に設定できます。

  • ロード バランシング モードが CONNECTION の場合、バックエンドが処理できる接続の合計数に基づいてロードバランスされます。
  • ロード バランシング モードが UTILIZATION に設定されている場合、インスタンス グループ内のインスタンスの使用率に基づいてロードバランスされます。このバランシング モードは、VM インスタンス グループのバックエンドにのみ適用されます。

バックエンド間でのトラフィックの分散方法は、ロードバランサのモードによって異なります。

従来のプロキシ ネットワーク ロードバランサ

従来のプロキシ ネットワーク ロードバランサの場合、バランシング モードを使用して、最も優先するバックエンド（インスタンス グループまたは NEG）を選択します。トラフィックは、ラウンドロビン方式によりバックエンド内のインスタンスまたはエンドポイント間で分散されます。

接続の分散方法

従来のプロキシ ネットワーク ロードバランサは、プレミアム ティアのグローバル ロード バランシング サービスとして構成できます。また、スタンダード ティアのリージョン サービスとして構成することもできます。

バランシング モードとターゲットの選択により、各ゾーン GCE_VM_IP_PORT NEG、ゾーン インスタンス グループ、またはリージョン インスタンス グループのゾーンの観点からバックエンドの完全性が決まります。トラフィックは、コンシステント ハッシュ法を使用してゾーン内で分散されます。

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

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

  • Google は、全世界のあらゆる拠点からロードバランサの IP アドレスをアドバタイズします。各ロードバランサの IP アドレスはグローバル エニーキャストです。

  • 複数のリージョンにバックエンドを持つバックエンド サービスを構成した場合、Google Front End（GFE）は、ユーザーに最も近いリージョンの正常なバックエンド インスタンス グループまたは NEG にリクエストを転送しようとします。

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

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

  • バックエンドは転送ルールと同じリージョン内にのみ構成できます。ロードバランサは対象の 1 つのリージョン内に存在する正常なバックエンドにのみリクエストを転送します。

グローバル外部プロキシ ネットワーク ロードバランサ

グローバル外部プロキシ ネットワーク ロードバランサの場合、トラフィック分散はロード バランシング モードとロード バランシングの局所性ポリシーに基づきます。

バランシング モードでは、各グループ（インスタンス グループまたは NEG）に送信するトラフィックの重みと割合を決定します。ロード バランシングの局所性ポリシー（LocalityLbPolicy）により、グループ内のバックエンドのロード バランシング方法が決まります。

トラフィックを受信すると、バックエンド サービスはバックエンドの分散モードに従ってバックエンド（インスタンス グループまたは NEG）にトラフィックを転送します。バックエンドが選択されると、ロード バランシングの局所性ポリシーに従って、バックエンド グループ内のインスタンスまたはエンドポイント間でトラフィックが分散されます。

詳しくは以下をご覧ください。

接続の分散方法

グローバル外部プロキシ ネットワーク ロードバランサは、プレミアム ティアのグローバル ロード バランシング サービスとして構成できます。

バランシング モードとターゲットの選択によって、各ゾーン GCE_VM_IP_PORT NEG またはゾーン インスタンス グループの観点からバックエンドの完全性が決まります。トラフィックは、コンシステント ハッシュ法を使用してゾーン内で分散されます。

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

  • Google は、全世界のあらゆる拠点からロードバランサの IP アドレスをアドバタイズします。各ロードバランサの IP アドレスはグローバル エニーキャストです。

  • 複数のリージョンにバックエンドを持つバックエンド サービスを構成した場合、Google Front End（GFE）は、ユーザーに最も近いリージョンの正常なバックエンド インスタンス グループまたは NEG にリクエストを転送しようとします。

リージョン外部プロキシ ネットワーク ロードバランサ

リージョン外部プロキシ ネットワーク ロードバランサの場合、トラフィック分散はロード バランシング モードとロード バランシングの局所性ポリシーに基づきます。

バランシング モードでは、各グループ（インスタンス グループまたは NEG）に送信するトラフィックの重みと割合を決定します。ロード バランシングの局所性ポリシー（LocalityLbPolicy）により、グループ内のバックエンドのロード バランシング方法が決まります。

トラフィックを受信すると、バックエンド サービスはバックエンドの分散モードに従ってバックエンド（インスタンス グループまたは NEG）にトラフィックを転送します。バックエンドが選択されると、ロード バランシングの局所性ポリシーに従って、バックエンド グループ内のインスタンスまたはエンドポイント間でトラフィックが分散されます。

詳しくは以下をご覧ください。

セッション アフィニティ

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

外部プロキシ ネットワーク ロードバランサ（グローバルとリージョン）には、次のタイプのセッション アフィニティがあります。

  • NONE。ロードバランサにセッション アフィニティが設定されていません。
  • クライアント IP アフィニティ。同じクライアント IP アドレスからのすべてのリクエストを同じバックエンドに転送します。

フェイルオーバー

バックエンドが異常な状態になった場合、トラフィックは同じリージョン内の正常なバックエンドに自動的にリダイレクトされます。リージョン内のすべてのバックエンドが異常な状態の場合、トラフィックは他のリージョンの正常なバックエンドに分散されます（グローバルと従来のモードのみ）。すべてのバックエンドが異常な状態の場合、ロードバランサはトラフィックを破棄します。

GKE アプリケーションのロード バランシング

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

関連ドキュメントについては、スタンドアロン ゾーン NEG によるコンテナ ネイティブのロード バランシングをご覧ください。

制限事項

  • Google Cloud コンソールを使用してプレミアム ティアでリージョン外部プロキシ ネットワーク ロードバランサを作成することはできません。また、Google Cloud コンソールでは、これらのロードバランサはスタンダード ティアをサポートするリージョンでのみ使用できます。代わりに gcloud CLI または API を使用してください。

  • 次の制限は、SSL ターゲット プロキシでデプロイされる従来のプロキシ ネットワーク ロードバランサとグローバル外部プロキシ ネットワーク ロードバランサにのみ適用されます。

    • 従来のプロキシ ネットワーク ロードバランサとグローバル外部プロキシ ネットワーク ロードバランサは、クライアント証明書ベースの認証（相互 TLS 認証）をサポートしていません。

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

次のステップ