Envoy ベースのロードバランサ向けプロキシ専用サブネット

このページでは、Envoy ベースのロードバランサで使用されるプロキシ専用サブネットを操作する方法について説明します。プロキシ専用サブネットは、Google Cloud ロードバランサが使用する Envoy プロキシ専用として予約された IP アドレスのプールを提供します。他の目的には使用できません。

プロキシは受信接続を終了し、URL マップ、バックエンド サービスのセッション アフィニティ、各バックエンド インスタンス グループまたは NEG の分散モード、その他の要素に基づいて各リクエストを実行する場所を評価します。

  1. クライアントは、ロードバランサの転送ルールの IP アドレスとポートに接続します。

  2. 各プロキシは、対応するロードバランサの転送ルールで指定された IP アドレスとポートでリッスンします。いずれかのプロキシがクライアントのネットワーク接続を受信して終了します。

  3. プロキシは、NEG 内の適切なバックエンド VM またはエンドポイントと接続を確立します。これは、ロードバランサの URL マップとバックエンド サービスによって決まります。

各ロードバランサのプロキシには内部 IP アドレスが割り当てられます。プロキシからバックエンド VM またはエンドポイントに送信されるパケットには、プロキシ専用サブネットからの送信元 IP アドレスが含まれています。

プロキシ専用サブネットは他の目的に使用できません。プロキシ専用サブネットからは、ロードバランサの転送ルールの IP アドレスは取得されません。また、バックエンド VM とエンドポイントの IP アドレスも、プロキシ専用サブネットから取得されません。

サポートされているロードバランサ

次の Envoy ベースのロードバランサには、プロキシ専用サブネットが必要です。

プロキシ専用サブネットとロードバランサのアーキテクチャの関係

次の図に、リージョン内部アプリケーション ロードバランサに必要な Google Cloud リソースを示します。

番号の付いたリージョン内部アプリケーション ロードバランサのコンポーネント。
番号の付いたリージョン内部アプリケーション ロードバランサのコンポーネント（クリックして拡大）。

図に示すように、Envoy ベースのロードバランサのデプロイには少なくとも 2 つのサブネットが必要です。

  • ロードバランサのバックエンド VM とバックエンドのエンドポイントは、プライマリ IP アドレスの範囲が 10.1.2.0/24（この例では）の単一のサブネットを使用します。このサブネットは、プロキシ専用のサブネットではありません。サブネットがロードバランサと同じリージョンにある場合、バックエンド VM とエンドポイントに複数のサブネットを使用できます。内部アプリケーション ロードバランサの場合、転送ルールに関連付けられたロードバランサの IP アドレスをこのサブネット内に配置することもできます（ただし、必須ではありません）。
  • プロキシ専用サブネットは 10.129.0.0/23（この例では）です。

プロキシ専用サブネットの推奨サイズ

プロキシ専用サブネットでは 64 個以上の IP アドレスを指定する必要があります。これは、/26 以下のプレフィックス長に対応します。まず、/23 プレフィックス（512 プロキシ専用アドレス）を持つプロキシ専用サブネットから始めて、トラフィックの変化に応じてサイズを変更することをおすすめします。

プロキシは、ロードバランサ レベルではなく VPC レベルで割り当てられます。Envoy ベースのロードバランサを使用する VPC ネットワークの各リージョンに、プロキシ専用サブネットを 1 つ作成する必要があります。同じリージョンおよび同じ VPC ネットワーク内に複数のロードバランサをデプロイすると、ロード バランシング用に同じプロキシ専用サブネットが共有されます。

Envoy ベースのロードバランサは、トラフィックのニーズに基づき、トラフィックを処理するために必要なプロキシの数を自動的にスケーリングします。プロキシ インスタンスの料金は、トラフィックのニーズに対応するために必要なプロキシ インスタンスの数に基づきます。プロキシが追加されるごとに、上記の表に記載された 1 時間あたりの料金に従い、追加で課金されます。

ロードバランサに割り当てられるプロキシの数は、10 分間にトラフィックを処理するために必要な容量に基づいて計算されます。料金は、この期間内における以下の数のうち、大きいほうを基に計算されます。

  • トラフィックの帯域幅の要件を満たすために必要なプロキシの数。各プロキシ インスタンスは、1 秒あたり最大 18 MB 処理できます。必要な帯域幅の総量をモニタリングし、その総量を 1 つのプロキシ インスタンスがサポートできる帯域幅で割ることで必要なプロキシの数を計算します。
  • 接続とリクエストを処理するために必要なプロキシの数。以下のリソースの合計を計算し、それぞれの値を 1 つのプロキシ インスタンスが処理できる値で割ることで必要なプロキシの数を計算します。
    • 1 秒あたり 600（HTTP）または 150（HTTPS）の新しい接続
    • 3,000 のアクティブな接続
    • 1 秒あたり 1,400 リクエスト*

* プロキシ インスタンスは、Cloud Logging が無効になっている場合、1 秒あたり 1,400 のリクエストを処理できます。Logging を有効にすると、プロキシ インスタンスが処理できる 1 秒あたりのリクエスト数はより少なくなります。たとえば、リクエストを 100% ロギングする場合、プロキシのリクエスト処理能力は 1 秒あたり 700 リクエストまで減少します。より少ない割合のトラフィックをサンプリングするように Logging を設定することもできるため、費用の制御とオブザーバビリティの要件を同時に満たすことができます。

プロキシ専用サブネットの課金方法の詳細な例については、Cloud Load Balancing の料金ドキュメントのプロキシ インスタンスの料金をご覧ください。

プロキシ専用サブネットを作成する

ネットワークが自動モードかカスタムモードかにかかわらず、Envoy ベースのロードバランサにはプロキシ専用サブネットを作成する必要があります。プロキシ専用サブネットの作成は、サブネットの作成と基本的に同じ手順です。ただし、いくつかのフラグを追加します。

プロキシ専用サブネットの場合、ロードバランサに応じて、--purpose を REGIONAL_MANAGED_PROXY または GLOBAL_MANAGED_PROXY に設定する必要があります。

既存のサブネットをプロキシ専用サブネットとして再利用することはできません。Envoy ベースのロードバランサがある各リージョンに新しいサブネットを作成する必要があります。これは、subnets update コマンドがサブネットの --purpose フィールドの変更を許可しないためです。

リージョン ロードバランサの転送ルールを作成する前に、ロードバランサのプロキシで使用するプロキシ専用サブネットを作成する必要があります。リージョンのプロキシ専用サブネットを最初に作成せずにロードバランサを構成すると、ロードバランサの作成プロセスでエラーが発生します。

コンソール

  1. Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。
    [VPC ネットワーク] ページに移動
  2. プロキシ専用サブネットを追加する共有 VPC ネットワークの名前をクリックします。
  3. [サブネットを追加] をクリックします。
  4. 名前を入力します。
  5. リージョンを選択します。
  6. [目的] を次のいずれかに設定します。
    • リージョン ロードバランサの場合: リージョン マネージド プロキシ
    • クロスリージョン ロードバランサの場合: クロスリージョンのマネージド プロキシ
    • IP アドレス範囲を入力します。
    • [追加] をクリックします。

gcloud

プロキシ専用サブネットを作成するには、gcloud compute networks subnets create コマンドを実行します。

gcloud compute networks subnets create SUBNET_NAME \
    --purpose=SUBNET_PURPOSE \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK_NAME \
    --range=CIDR_RANGE

フィールドは次のように定義されています。

  • SUBNET_NAME は、プロキシ専用サブネットの名前です。
  • SUBNET_PURPOSE は、サブネットの目的です。ロードバランサに応じて、REGIONAL_MANAGED_PROXY または GLOBAL_MANAGED_PROXY に設定します。
  • REGION は、プロキシ専用サブネットのリージョンです。
  • VPC_NETWORK_NAME は、サブネットを含む VPC ネットワークの名前です。
  • CIDR_RANGE は、サブネットのプライマリ IP アドレスの範囲です。サブネット マスクの長さは 26 以下にして、リージョン内のプロキシで 64 個以上の IP アドレスを使用できるようにします。推奨されるサブネット マスクの長さは /23 です。

完全な構成例については、プロキシ専用サブネットの構成をご覧ください。

プロキシ専用サブネットからの接続を受け入れるには、バックエンドにファイアウォール ルールを構成する必要があります。ファイアウォール ルールの設定を含む完全な構成例については、以下をご覧ください。

プロキシの可用性

Google Cloud リージョンによっては、新しいロードバランサに対応するのに十分なプロキシ容量がない場合があります。その場合、ロードバランサの作成時に Google Cloud コンソールでプロキシの可用性に関する警告メッセージが表示されます。この問題を解決するには、次のいずれかを行います。

  • ロードバランサに別のリージョンを選択します。これは、別のリージョンにバックエンドがある場合には現実的な選択肢となります。
  • プロキシ専用サブネットがすでに割り当てられている VPC ネットワークを選択します。
  • 容量の問題が解決するまで待ちます。

プロキシ専用サブネットのサイズ / アドレス範囲を変更する

ロードバランサによって処理されるトラフィックの量が増加した場合は、プロキシ専用サブネットのサイズを大きくして、より多くの Envoy プロキシをロードバランサに割り当てる必要があります。

プライマリ アドレス範囲と同じ方法（expand-ip-range コマンドを使用）で、プロキシ専用サブネットを拡張することはできません。代わりに、要件を満たすバックアップ プロキシ専用サブネットを作成し、アクティブなロールに昇格する必要があります。これは、リージョンごと、および VPC ネットワークごとにアクティブにできるプロキシ専用サブネットは 1 つだけで、サブネットのプライマリ IP アドレス範囲の拡張が可能なためです。

プロキシ専用サブネットをバックアップからアクティブに切り替えても、新しい接続は中断しません。

  • 新しくアクティブになったプロキシ専用サブネットは新しい接続に使用されます。
  • 以前アクティブだったプロキシ専用サブネットは、新しい接続に使用されなくなります。
  • Google Cloud は、以前にアクティブで、現在はバックアップのプロキシ専用サブネット内のプロキシから既存の接続のドレインを開始します。

各 VPC ネットワークでは、リージョンごとにアクティブとバックアップのプロキシ専用サブネットをそれぞれ 1 つだけ作成できます。

コンソール

  1. 同じリージョンにバックアップのプロキシ専用サブネットを作成します。必要なプライマリ IP アドレス範囲を指定します。

    1. Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。
      [VPC ネットワーク] ページに移動
    2. プロキシ専用サブネットを追加する共有 VPC ネットワークの名前をクリックします。
    3. [サブネットを追加] をクリックします。
    4. 名前を入力します。
    5. リージョンを選択します。
    6. [目的] を次のいずれかに設定します。
      • リージョン ロードバランサの場合: リージョン マネージド プロキシ
      • クロスリージョン ロードバランサの場合: クロスリージョンのマネージド プロキシ
      • [ロール] で [バックアップ] を選択します。
      • IP アドレス範囲を入力します。
      • [追加] をクリックします。

  2. バックアップのプロキシ専用サブネットのプライマリ IP アドレス範囲が含まれるように、バックエンド VM またはエンドポイントに適用する上り（内向き）許可ファイアウォール ルールを作成または変更します。

  3. バックアップのプロキシ専用サブネットをアクティブ ロールに昇格します。また、前にアクティブだったプロキシ専用サブネットをバックアップ ロールに降格します。

    1. Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。
      [VPC ネットワーク] ページに移動
    2. 変更する共有 VPC ネットワークの名前をクリックします。
    3. [ロード バランシング用に予約されているプロキシ専用サブネット] で、前の手順で作成したバックアップ サブネットを見つけます。
    4. [有効化] をクリックします。
    5. オプションの [ドレイン タイムアウト] を指定します。
    6. [サブネットを有効にします] をクリックします。

  4. コネクション ドレインがタイムアウトしたか、バックエンド VM またはエンドポイントへの接続が以前アクティブだったプロキシ専用サブネットのプロキシから行われていないことを確認したら、次の操作を行います。

    • 以前アクティブだったプロキシ専用サブネットのプライマリ IP アドレス範囲が含まれないように、バックエンド VM またはエンドポイントに適用される上り（内向き）許可ファイアウォール ルールを変更します。
    • 以前にアクティブだった（現在はバックアップの）プロキシ専用サブネットを削除して、サブネットがプライマリ IP アドレス範囲に使用していた IP アドレスを解放します。

gcloud

以下の手順では、アクティブなプロキシ専用サブネットがすでに存在していることを前提としています。

  1. 同じリージョンにバックアップのプロキシ専用サブネットを作成します。必要なプライマリ IP アドレス範囲を指定し、--role=BACKUP フラグを設定して gcloud compute networks subnets create コマンドを実行します。

    gcloud compute networks subnets create BACKUP_PROXY_ONLY_SUBNET_NAME \
   --purpose=SUBNET_PURPOSE \
   --role=BACKUP \
   --region=REGION \
   --network=VPC_NETWORK_NAME \
   --range=BACKUP_PROXY_ONLY_SUBNET_RANGE

    次のように置き換えます。

    • BACKUP_PROXY_ONLY_SUBNET_NAME: 新しく作成したバックアップ プロキシ専用サブネットの名前
    • SUBNET_PURPOSE: 新しく作成されたバックアップ プロキシ専用サブネットの目的
    • REGION: 新しく作成したバックアップ プロキシ専用サブネットのリージョン。これは、現在アクティブなプロキシ専用サブネットと同じリージョンにする必要があります。
    • REGION: 新しく作成したバックアップ プロキシ専用サブネットのネットワーク。これは、現在アクティブなプロキシ専用サブネットと同じネットワークである必要があります。
    • BACKUP_PROXY_ONLY_SUBNET_RANGE: 新しく作成されたバックアップのプロキシ専用サブネットの CIDR 範囲

  2. バックアップのプロキシ専用サブネットのプライマリ IP アドレス範囲が含まれるように、バックエンド VM またはエンドポイントに適用する上り（内向き）許可ファイアウォール ルールを作成または変更します。ファイアウォール ルールで、アクティブなサブネットからの接続が許可されている必要があります。

    gcloud compute firewall-rules update PROXY_ONLY_SUBNET_FIREWALL_RULE \
  --source-ranges ACTIVE_PROXY_ONLY_SUBNET_RANGE,BACKUP_PROXY_ONLY_SUBNET_RANGE

    次のように置き換えます。

    • PROXY_ONLY_SUBNET_FIREWALL_RULE: プロキシ専用サブネットからのトラフィックがバックエンド インスタンスまたはエンドポイントに到達することを許可するファイアウォール ルールの名前
    • ACTIVE_PROXY_ONLY_SUBNET_RANGE: 現在アクティブなプロキシ専用サブネットの CIDR 範囲

  3. 新しいサブネットを更新して、リージョン内の ACTIVE プロキシ専用サブネットに設定し、古いサブネットが廃棄されるのを待ちます。また、前にアクティブだったプロキシ専用サブネットをバックアップ ロールに降格します。

    IP アドレス範囲をすぐにドレインするには、--drain-timeout を 0s に設定します。サブネット内のアドレスが割り当てられているプロキシへのすべての接続がすぐに終了します。

    gcloud compute networks subnets update BACKUP_PROXY_ONLY_SUBNET_NAME \
   --region=REGION \
   --role=ACTIVE \
   --drain-timeout=CONNECTION_DRAINING_TIMEOUT

    次のように置き換えます。

    • CONNECTION_DRAINING_TIMEOUT には、Google Cloud が前にアクティブだったプロキシ専用サブネットのプロキシから既存の接続を移行するために必要な時間を秒数で指定します。

  4. ドレイン ステータスをモニタリングするには、list または describe コマンドを使用します。ドレインの実行中、サブネットのステータスは DRAINING になります。

    gcloud compute networks subnets list

    ドレインが完了するまで待ちます。古いプロキシ専用サブネットがドレインされると、サブネットのステータスは READY になります。

  5. プロキシ専用サブネットのファイアウォール ルールを更新して、新しいサブネットからの接続のみを許可します。

    gcloud compute firewall-rules PROXY_ONLY_SUBNET_FIREWALL_RULE \
  --source-ranges BACKUP_PROXY_ONLY_SUBNET_RANGE

  6. バックエンド VM またはエンドポイントへの接続が、以前アクティブだったプロキシ専用サブネットのプロキシから行われていないことを確認したら、古いサブネットを削除できます。

    gcloud compute networks subnets delete ACTIVE_PROXY_ONLY_SUBNET_NAME \
  --region=REGION

プロキシ専用サブネットの目的を移行する

以前に --purpose=INTERNAL_HTTPS_LOAD_BALANCER でプロキシ専用サブネットを作成した場合は、VPC ネットワークと同じリージョンで他の Envoy ベースのロードバランサを作成する前に、サブネットの目的を REGIONAL_MANAGED_PROXY に移行する必要があります。

コンソール

Google Cloud コンソールを使用してロードバランサを作成する場合は、ロードバランサの作成中に、以前に作成したプロキシ専用サブネットの目的を、--purpose=INTERNAL_HTTPS_LOAD_BALANCER から REGIONAL_MANAGED_PROXY に移行するように求められます。

gcloud

既存のプロキシ専用サブネットの目的を --purpose=INTERNAL_HTTPS_LOAD_BALANCER から REGIONAL_MANAGED_PROXY に変更するには、次のコマンドを使用します。

gcloud compute networks subnets update PROXY_ONLY_SUBNET \
    --purpose=REGIONAL_MANAGED_PROXY \
    --region=REGION

プロキシ専用サブネットの目的を --purpose=INTERNAL_HTTPS_LOAD_BALANCER から REGIONAL_MANAGED_PROXY に移行しても、ダウンタイムは発生しません。変更はすぐに反映されます。

プロキシ専用サブネットを削除する

プロキシ専用サブネットを削除すると、プライマリ IP アドレス範囲が解放され、その範囲を別の用途に利用できます。Google Cloud では、プロキシ専用サブネットの削除リクエストを受信すると、次のルールに従って対応します。

  • 同じリージョンと VPC ネットワークに 1 つ以上のリージョン ロードバランサがある場合、アクティブなプロキシ専用サブネットは削除できません。

  • バックアップのプロキシ専用サブネットが同じリージョンと VPC ネットワークに存在する場合、アクティブなプロキシ専用サブネットは削除できません。

    バックアップを削除する前にアクティブなプロキシ専用サブネットを削除しようとすると、「Invalid resource usage: Cannot delete ACTIVE subnetwork because a BACKUP subnetwork exists.」（無効なリソースの使用: バックアップ サブネットワークが存在するため、アクティブなサブネットワークを削除できません）というエラー メッセージが表示されます。

より詳細なルールは次のとおりです。

  • 特定のリージョンと VPC ネットワークにリージョン ロードバランサが定義されていない場合は、そのリージョンのプロキシ専用サブネットを削除できます。バックアップのプロキシ専用サブネットが存在する場合は、これを削除してからアクティブなプロキシ専用サブネットを削除します。

  • 特定のリージョンと VPC ネットワークで定義されたリージョン ロードバランサが 1 つ以上ある場合、アクティブなプロキシ専用サブネットは削除できません。ただし、バックアップのプロキシ専用サブネットをアクティブなロールに昇格させると、以前アクティブだったプロキシ専用サブネットがバックアップ ロールに自動的に降格します。接続が切断された後、バックアップのプロキシ専用サブネットを削除できます。

詳細については、VPC ネットワークのドキュメントのサブネットの削除をご覧ください。

制限事項

プロキシ専用サブネットには、次の制約があります。

  • 2 つの REGIONAL_MANAGED_PROXY プロキシまたは 2 つの INTERNAL_HTTPS_LOAD_BALANCER プロキシを使用できないのと同じように、同じネットワークとリージョンに INTERNAL_HTTPS_LOAD_BALANCER と REGIONAL_MANAGED_PROXY の両方のサブネットを配置することはできません。

  • 1 つのリージョンと VPC ネットワークには、アクティブとバックアップのプロキシ専用サブネットをそれぞれ 1 つずつ作成できます。

  • リージョンとネットワークにプロキシ専用サブネットが作成されていない場合は、バックアップのプロキシ専用サブネットは作成できません。

  • サブネットを更新することで、プロキシ専用サブネットのロールをバックアップからアクティブに切り替えることができます。その場合、Google Cloud は以前にアクティブだったプロキシ専用サブネットを自動的にバックアップに変更します。プロキシ専用サブネットのロールを明示的にバックアップに設定することはできません。

  • プロキシ専用サブネットのコネクション ドレイン期間（--drain-timeout）内は、プロキシ専用サブネットのロールをバックアップからアクティブに変更できません。

  • プロキシ専用サブネットで IP アドレスが不足していても、Google Cloud は警告を表示しません。ただし、プロキシ専用サブネットの IP アドレスの使用状況をモニタリングするように Monitoring を構成できます。アラート ポリシーを定義して、loadbalancing.googleapis.com/subnet/proxy_only/addresses 指標のアラートを設定できます。

  • プロキシ専用サブネットは VPC フローログをサポートしていません。

次のステップ