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

Google Cloud 内部プロキシ ネットワーク ロードバランサは、オープンソースの Envoy プロキシ ソフトウェアと Andromeda ネットワークの仮想化スタックを活用したプロキシベースのロードバランサです。

内部プロキシ ネットワーク ロードバランサはレイヤ 4 ロードバランサで、同じ VPC ネットワーク内のクライアントまたは VPC ネットワークに接続されているクライアントのみがアクセスできるリージョン内部 IP アドレスの背後で TCP サービス トラフィックを実行し、スケーリングできます。ロードバランサは、まず Envoy プロキシでクライアントとロードバランサ間の TCP 接続を終端します。プロキシは、Google Cloud、オンプレミス、またはその他のクラウド環境でホストされているバックエンドへの 2 番目の TCP 接続を開きます。その他のユースケースについては、プロキシ ネットワーク ロードバランサの概要をご覧ください。

運用モード

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

  • リージョン内部プロキシ ネットワーク ロードバランサこれは、オープンソースの Envoy プロキシをベースにマネージド サービスとして実装されるリージョン ロードバランサです。リージョン モードでは、すべてのクライアントとバックエンドが指定されたリージョンに配置されるため、リージョンのコンプライアンスが必要な場合に役立ちます。

  • クロスリージョン内部プロキシ ネットワーク ロードバランサこれは、オープンソースの Envoy プロキシでマネージド サービスとして実装されるマルチリージョン ロードバランサです。クロスリージョン モードを使用すると、グローバルに分散しているバックエンド サービスにトラフィックをロードバランスできます。たとえば、最も近いバックエンドにトラフィックを転送するトラフィック管理ができます。このロードバランサは高可用性も実現します。バックエンドを複数のリージョンに配置すると、単一リージョンにおける障害を回避できます。1 つのリージョンのバックエンドが停止した場合でも、トラフィックを別のリージョンにフェイルオーバーできます。

    次の表に、リージョン モードとクロスリージョン モードの重要な違いを示します。

    機能 リージョン内部プロキシ ネットワーク ロードバランサ クロスリージョン内部プロキシ ネットワーク ロードバランサ
    ロードバランサの仮想 IP アドレス（VIP） 特定の Google Cloud リージョンのサブネットから割り振られます。 特定の Google Cloud リージョンのサブネットから割り振られます。

    複数のリージョンの VIP アドレスは、同じグローバル バックエンド サービスを共有できます。
    クライアント アクセス デフォルトでは、グローバルにアクセス可能ではありません。
    必要に応じて、グローバル アクセスを有効にすることができます。    		 常にグローバルにアクセス可能任意の Google Cloud リージョンのクライアントがロードバランサにトラフィックを送信できます。
    ロードバランスされたバックエンド リージョン バックエンド。
    ロードバランサは、ロードバランサのプロキシと同じリージョンにあるバックエンドにのみトラフィックを送信できます。    		 グローバル バックエンド。
    ロードバランサは、任意のリージョンのバックエンドにトラフィックを送信できます。
    高可用性とフェイルオーバー 同じリージョン内の正常なバックエンドへの自動フェイルオーバー。 同一または異なるリージョンの正常なバックエンドへの自動フェイルオーバー。

モードを特定する

Cloud コンソール

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

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

  2. [ロードバランサ] タブに、ロードバランサのタイプ、プロトコル、リージョンが表示されます。リージョンが空の場合、ロードバランサはクロスリージョン モードになっています。次の表に、ロードバランサのモードを識別する方法を示します。

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

gcloud

  1. ロードバランサのモードを確認するには、次のコマンドを実行します。

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

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

    ロードバランサ モード ロード バランシング スキーム 転送ルール
    リージョン内部プロキシ ネットワーク ロードバランサ INTERNAL_MANAGED リージョン
    クロスリージョン内部プロキシ ネットワーク ロードバランサ INTERNAL_MANAGED グローバル

アーキテクチャ

次の図は、内部プロキシ ネットワーク ロードバランサに必要な Google Cloud リソースを示しています。

リージョン

この図は、プレミアム ティアにリージョン内部プロキシ ネットワーク ロードバランサをデプロイした場合のコンポーネントを示しています。

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

クロスリージョン

次の図は、同じ VPC ネットワーク内のプレミアム ティアにクロスリージョン内部プロキシ ネットワーク ロードバランサをデプロイした場合のコンポーネントを示しています。各グローバル転送ルールは、クライアントの接続に使用するリージョン IP アドレスを使用します。

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

プロキシ専用サブネット

上の図では、プロキシ専用サブネットには、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。Envoy ベースの内部プロキシ ネットワーク ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを作成する必要があります。次の表に、リージョン モードとクロスリージョン モードでのプロキシ専用サブネットの違いを示します。

ロードバランサ モード プロキシ専用サブネットの --purpose フラグの値
リージョン内部プロキシ ネットワーク ロードバランサ

REGIONAL_MANAGED_PROXY

リージョン ロードバランサとクロスリージョン ロードバランサで同じサブネットを共有することはできません

リージョンと VPC ネットワーク内のすべてのリージョン Envoy ベースのロードバランサは、同じプロキシ専用サブネットを共有します。
クロスリージョン内部プロキシ ネットワーク ロードバランサ

GLOBAL_MANAGED_PROXY

リージョン ロードバランサとクロスリージョン ロードバランサで同じサブネットを共有することはできません

ロードバランサが構成される各リージョンで、クロスリージョンの Envoy ベースのロードバランサにはプロキシ専用サブネットが必要です。同じリージョンとネットワークにあるクロスリージョン ロードバランサ プロキシは、同じプロキシ専用サブネットを共有します。

さらに、

  • プロキシ専用サブネットは Envoy プロキシにのみ使用され、バックエンドには使用されません。
  • リージョンと VPC ネットワーク内のすべての内部プロキシ ネットワーク ロードバランサのバックエンド仮想マシン（VM）インスタンスまたはエンドポイントは、プロキシ専用サブネットからの接続を受信します。
  • 内部プロキシ ネットワーク ロードバランサの IP アドレスは、プロキシ専用サブネットにはありません。ロードバランサの IP アドレスは内部マネージド転送ルールによって定義されます。

転送ルールと IP アドレス

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

クライアントは IP アドレスとポートを使用してロードバランサの Envoy プロキシに接続します。転送ルールの IP アドレスはロードバランサの IP アドレスです（仮想 IP アドレスまたは VIP と呼ぶこともあります）。ロードバランサに接続するクライアントは TCP を使用する必要があります。サポートされているプロトコルの一覧については、ロードバランサの機能の比較をご覧ください。

転送ルールに関連付けられた内部 IP アドレスは、バックエンドと同じネットワークとリージョンにあるサブネットから取得できます。内部プロキシ ネットワーク ロードバランサで使用する各転送ルールは、1 つの TCP ポートのみを参照できます。転送ルールに関連付けられた内部 IP アドレスは、同じネットワークとリージョンにある任意のサブネットから取得できます。

次の表に、リージョン モードとクロスリージョン モードの転送ルールの違いを示します。

ロードバランサ モード 転送ルール、IP アドレス、プロキシ専用サブネット --purpose クライアントからロードバランサのフロントエンドへのルーティング
リージョン内部プロキシ ネットワーク ロードバランサ

リージョン forwardingRules

リージョン IP アドレス

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

INTERNAL_MANAGED

プロキシ専用サブネット --purpose:

REGIONAL_MANAGED_PROXY

IP アドレス --purpose:

SHARED_LOADBALANCER_VIP

グローバル アクセスを有効にして、任意のリージョンのクライアントがロードバランサにアクセスできるようにします。また、バックエンドもロードバランサと同じリージョンに存在する必要があります。
クロスリージョン内部プロキシ ネットワーク ロードバランサ

グローバル globalForwardingRules

リージョン IP アドレス

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

INTERNAL_MANAGED

プロキシ専用サブネット --purpose:

GLOBAL_MANAGED_PROXY

IP アドレス --purpose:

SHARED_LOADBALANCER_VIP

グローバル アクセスはデフォルトで有効になっており、任意のリージョンのクライアントがロードバランサにアクセスできます。バックエンドは複数のリージョンに配置できます。

ターゲット プロキシ

内部プロキシ ネットワーク ロードバランサは、クライアントからの TCP 接続を終端してバックエンドへの新しい接続を作成します。デフォルトでは、元のクライアントの IP アドレスとポート情報は保持されません。PROXY プロトコルを使用してこの情報を保持できます。ターゲット プロキシは、受信リクエストを直接ロードバランサのバックエンド サービスにルーティングします。

次の表に、各モードの内部プロキシ ネットワーク ロードバランサに必要なターゲット プロキシ API を示します。

ターゲット プロキシ リージョン内部プロキシ ネットワーク ロードバランサ クロスリージョン内部プロキシ ネットワーク ロードバランサ
TCP リージョン regionTargetTcpProxies グローバル targetTcpProxies

バックエンド サービス

バックエンド サービスによって、受信トラフィックが 1 つ以上の関連バックエンドに振り向けられます。バックエンドは、インスタンス グループまたはネットワーク エンドポイント グループのいずれかになります。バックエンドには、接続に基づいて完全性を定義するためのバランシング モード情報が含まれています（たとえば、グループ バックエンドのみの場合は使用率）。

各内部プロキシ ネットワーク ロードバランサには、単一のバックエンド サービス リソースが含まれます。次の表に、各モードの内部プロキシ ネットワーク ロードバランサが必要とするバックエンド サービスタイプを示します。

リージョン内部プロキシ ネットワーク ロードバランサ クロスリージョン内部プロキシ ネットワーク ロードバランサ
バックエンド サービスのタイプ リージョン regionBackendServices グローバル backendServices

サポートされているバックエンド

バックエンド サービスは、次のタイプのバックエンドをサポートします。

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

すべてのバックエンドは同じ種類（インスタンス グループまたは NEG）である必要があります。異なるタイプのインスタンス グループ バックエンドを同時に使用することも、異なるタイプの NEG バックエンドを同時に使用することもできますが、同じバックエンド サービスでインスタンス グループと NEG バックエンドを併用することはできません。

同じバックエンド サービス内でゾーン NEG とハイブリッド NEG を混在させることができます。

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

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

内部プロキシ ネットワーク ロードバランサのバックエンド サービスを構成するときに、バックエンド サービスがバックエンドとの通信に使用するプロトコルを設定します。ロードバランサは、指定したプロトコルのみを使用し、他のプロトコルとの接続をネゴシエートしません。リージョン内部プロキシ ネットワーク ロードバランサまたはクロスリージョン内部プロキシ ネットワーク ロードバランサは、バックエンドとの通信に TCP のみをサポートします。

ヘルスチェック

各バックエンド サービスは、ロードバランサからの接続を受信するバックエンドの稼働状況を定期的に監視するヘルスチェックを指定します。これにより、処理不能なバックエンドにリクエストが送信されるリスクを軽減できます。ヘルスチェックでは、アプリケーション自体が動作するかどうかはチェックされません。

ヘルスチェック プロトコル

必須ではなく、常に可能というわけでもありませんが、バックエンド サービスのプロトコルに一致するプロトコルでヘルスチェックを使用することをおすすめします。たとえば、TCP ヘルスチェックはバックエンドへの TCP 接続を最も正確にテストします。サポートされているヘルスチェック プロトコルの一覧については、ロード バランシング機能をご覧ください。

次の表に、各モードの内部プロキシ ネットワーク ロードバランサでサポートされているヘルスチェックのスコープを示します。

ロードバランサ モード ヘルスチェックのタイプ
リージョン内部プロキシ ネットワーク ロードバランサ リージョン regionHealthChecks
クロスリージョン内部プロキシ ネットワーク ロードバランサ グローバル healthChecks

ヘルスチェックの詳細については、以下をご覧ください。

ファイアウォール ルール

内部プロキシ ネットワーク ロードバランサには、次のファイアウォール ルールが必要です。

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

  • 各バックエンド サービスのヘルスチェックのための宛先ポートへのトラフィックを許可します。

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

  • GCE_VM_IP_PORT NEG バックエンドの場合: エンドポイントのポート番号へのトラフィックを許可します。

これらのロードバランサのファイアウォール ルール要件には、いくつかの例外があります。

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

クライアント アクセス

クライアントは、同じネットワークまたは、VPC ネットワーク ピアリングを使用して接続された VPC ネットワークに配置できます。

リージョン内部プロキシ ネットワーク ロードバランサの場合、クライアントは、デフォルトでロードバランサと同じリージョンに存在しなければなりません。グローバル アクセスを有効にして、任意のリージョンのクライアントがロードバランサにアクセスできるようにします。

クロスリージョン内部プロキシ ネットワーク ロードバランサの場合、グローバル アクセスはデフォルトで有効になっています。任意のリージョンのクライアントがロードバランサにアクセスできます。

次の表は、リージョン内部プロキシ ネットワーク ロードバランサのクライアント アクセスをまとめたものです。

グローバル アクセスが無効な場合 グローバル アクセスが有効な場合
クライアントはロードバランサと同じリージョンになければなりません。また、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。 クライアントはどのリージョンにでも配置できます。ただし、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。
オンプレミス クライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを介してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、ロードバランサと同じリージョンになければなりません。 オンプレミス クライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを使用してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、どのリージョンにでも配置できます。

共有 VPC アーキテクチャ

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

IP アドレス 転送ルール ターゲット プロキシ バックエンド コンポーネント

内部 IP アドレスは、バックエンドと同じプロジェクトで定義する必要があります。

共有 VPC ネットワークでロードバランサを使用できるようにするには、内部 IP アドレスは、バックエンド VM が配置されている同じサービス プロジェクト内で定義する必要があります。さらに、ホスト プロジェクト内の目的の共有 VPC ネットワーク内のサブネットを参照する必要があります。アドレス自体は、参照先サブネットのプライマリ IP 範囲から取得します。

内部転送ルールは、バックエンドと同じプロジェクトで定義する必要があります。

共有 VPC ネットワークでロードバランサを使用できるようにするには、内部転送ルールは、バックエンド VM が配置されている同じサービス プロジェクト内で定義する必要があります。さらに、関連付けられている内部 IP アドレスが参照する同じサブネット（共有 VPC ネットワーク内）を参照する必要があります。

 ターゲット プロキシは、バックエンドと同じプロジェクトで定義する必要があります。 共有 VPC のシナリオでは、バックエンド VM は通常、サービス プロジェクトに配置されます。そのサービス プロジェクトでは、リージョン内部のバックエンド サービスとヘルスチェックを定義する必要があります。

トラフィック分散

内部プロキシ ネットワーク ロードバランサは、次のようにバックエンドにトラフィックを分散します。

  1. 1 つのクライアントから発信された接続は、そのゾーン内の正常なバックエンド（インスタンス グループまたは NEG）が使用可能であり、容量があれば（バランシング モードによって判別されます）、同じゾーンに送信されます。リージョン内部プロキシ ネットワーク ロードバランサの場合、バランシング モードは CONNECTION（インスタンス グループまたは NEG バックエンド）または UTILIZATION（インスタンス グループ バックエンドのみ）になります。
  2. セッション アフィニティを構成している場合は、クライアントからの接続は同じバックエンドに送信されます。
  3. バックエンドが選択されると、ロード バランシング ポリシーに従ってインスタンス（インスタンス グループ）またはエンドポイント（NEG）間でトラフィックが分散されます。サポートされているロード バランシング ポリシー アルゴリズムについては、リージョン バックエンド サービス API ドキュメントの localityLbPolicy 設定をご覧ください。

セッション アフィニティ

セッション アフィニティでは、バックエンドが良好な状態で容量があれば、同じクライアントからのすべてのリクエストを同じバックエンドに送信するように、ロードバランサのバックエンド サービスを構成できます。

内部ネットワーク ロードバランサはクライアント IP アフィニティを提供します。これにより、バックエンドに容量があり、正常な状態を維持している限り、同じクライアント IP アドレスからのすべてのリクエストが同じバックエンドに転送されます。

フェイルオーバー

バックエンドが異常な状態になると、トラフィックは正常なバックエンドに自動的にリダイレクトされます。次の表に、各モードでのフェイルオーバーの動作を示します。

ロードバランサ モード フェイルオーバーの動作 すべてのバックエンドが異常な場合の動作
リージョン内部プロキシ ネットワーク ロードバランサ

ロードバランサは、ゾーンごとに緩やかなフェイルオーバー アルゴリズムを実装します。ロードバランサは、ゾーン内のすべてのバックエンドが異常になるのを待つのではなく、いずれかのゾーンで正常なバックエンドと異常なバックエンドの比率が一定のしきい値（70%、このしきい値は構成不可）より低くなったときに、別のゾーンへのトラフィックのリダイレクトを開始します。すべてのゾーンのすべてのバックエンドが異常な状態である場合、ロードバランサは直ちにクライアント接続を終端します。

Envoy プロキシは、構成されたトラフィック分散に基づいて、リージョン内の正常なバックエンドにトラフィックを送信します。

 接続を終端する
クロスリージョン内部プロキシ ネットワーク ロードバランサ

同じリージョンまたは他のリージョン内の正常なバックエンドへの自動フェイルオーバー。

トラフィックは、構成されたトラフィック分散に基づいて、複数のリージョンにまたがる正常なバックエンド間で分散されます。

 接続を終端する

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

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

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

割り当てと上限

割り当てと上限について詳しくは、ロード バランシングのリソースの割り当てをご覧ください。

制限事項

  • 内部プロキシ ネットワーク ロードバランサは、IPv6 トラフィックをサポートしていません。
  • 内部プロキシ ネットワーク ロードバランサは、ロードバランサのフロントエンドが 1 つのホストまたはサービス プロジェクトにあるため、バックエンド サービスとバックエンドが別のサービス プロジェクトにある共有 VPC デプロイ（クロス プロジェクト サービス参照とも呼ばれます）をサポートしていません。

次のステップ