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 ベースのロードバランサは、トラフィックのニーズに基づき、トラフィックを処理するために必要なプロキシの数を自動的にスケーリングします。

ロードバランサに割り当てられるプロキシの数は、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 リクエストまで減少します。100% より少ない割合のトラフィックをサンプリングするように Logging を構成することもできるため、費用の制御とオブザーバビリティの要件を同時に満たすことができます。

プロキシが追加されるごとに、1 時間あたりの追加料金が発生します。プロキシ専用サブネットの課金方法については、Cloud Load Balancing の料金ドキュメントの「プロキシ インスタンスの料金」セクションをご覧ください。

Envoy ベースのロードバランサと Secure Web Proxy Envoy プロキシ

Envoy ベースのロードバランサと Secure Web Proxy の両方を同じ VPC に構成する場合は、次の点に注意してください。

  • Envoy ベースのロードバランサと Secure Web Proxy の両方が、同じプロキシ専用サブネットの IP アドレスを使用します。

  • 両方のサービスの IP アドレス要件に対応するには、/22 サブネットなど、より大きなプロキシ専用サブネットの使用を検討してください。これにより、両方の構成に向けて十分なアドレス空間が確保されます。

  • プロキシ容量をモニタリングして、IP アドレスの使用状況を追跡することをおすすめします。これにより、サービスの中断を招く可能性があるプロキシ専用サブネットの枯渇を防ぐことができます。

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

ネットワークが自動モードかカスタムモードかにかかわらず、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 プロキシをロードバランサで使用する必要があります。

通常のサブネットのプライマリ IPv4 アドレス範囲を拡張する場合と同じ方法（expand-ip-range コマンドを使用）で、プロキシ専用サブネットのプライマリ IPv4 アドレス範囲を拡張することはできません。代わりに、プロキシ専用サブネットを新しいサブネットに置き換える必要があります。交換プロセスは次のとおりです。

  • 既存（元の）プロキシ専用サブネットと同じリージョンと VPC ネットワークに、新しいプロキシ専用サブネットを作成します。この新しいプロキシ専用サブネットを作成するときに、その role を BACKUP に設定します（プロキシ専用サブネットの目的ごとに、 Google Cloud は特定のリージョンと VPC ネットワークに 1 つの ACTIVE プロキシ専用サブネットと 1 つの BACKUP プロキシ専用サブネットを存在させることができます）。

  • バックエンドに適用される上り（内向き）許可ファイアウォール ルールを調整して、元のプロキシ専用サブネットと新しいプロキシ専用サブネットの両方のプライマリ IPv4 アドレス範囲からの接続を許可します。

  • 新しいプロキシ専用サブネットのロールを ACTIVE に設定し、ドレイン期間を指定して、バックエンドと元のプロキシ専用サブネット内の Envoy プロキシ間の接続を終了できるようにします（Google Cloud は、新しいプロキシ専用サブネットのロールを ACTIVE に設定すると、元のプロキシ専用サブネットのロールを自動的に BACKUP に設定します）。

  • 元のプロキシ専用サブネットのステータスをモニタリングします（モニタリングの詳細については、gcloud のタブをご覧ください）。ステータスが READY になると、ロールが BACKUP の場合、サブネットは使用されなくなります。この時点で、上り（内向き）許可ファイアウォール ルールを調整して、新しいプロキシ専用サブネットのプライマリ IPv4 アドレス範囲からの接続のみを許可し、元のプロキシ専用サブネットを削除できます。

コンソール

  1. 同じリージョンと VPC ネットワークに新しいプロキシ専用サブネットを作成し、ニーズに合ったプライマリ IPv4 アドレス範囲を指定します。新しいプロキシ専用サブネットのロールをバックアップに設定します。

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

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

  3. 新しいプロキシ専用サブネットのロールをアクティブに設定し、ドレイン タイムアウトを指定して、バックエンドと元のプロキシ専用サブネット間の接続を終了できるようにします。 Google Cloud は、新しいプロキシ専用サブネットのロールをアクティブに設定すると、元のプロキシ専用サブネットのロールをバックアップに自動的に設定します。

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

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

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

gcloud

次の手順では、既存のプロキシ専用サブネットを新しいプロキシ専用サブネットと交換します。以下の手順では、次のものを使用しています。

  • ORIGINAL_PROXY_ONLY_SUBNET_NAME: 既存のプロキシ専用サブネットの名前
  • ORIGINAL_PROXY_ONLY_SUBNET_RANGE: 既存のプロキシ専用サブネットのプライマリ IPv4 アドレス範囲（CIDR 形式）。これは、前に選択したアドレス範囲です。
  • NEW_PROXY_ONLY_SUBNET_NAME: 新しいプロキシ専用サブネットの名前
  • NEW_PROXY_ONLY_SUBNET_RANGE: 新しいプロキシ専用サブネットのプライマリ IPv4 アドレス範囲（CIDR 形式）。ニーズに合わせて IPv4 アドレス範囲を選択します。
  • PROXY_ONLY_SUBNET_FIREWALL_RULE: プロキシ専用サブネットからの接続を許可する上り（内向き）許可 VPC ファイアウォール ルールの名前
  • REGION: 元のプロキシ専用サブネットと新しいプロキシ専用サブネットを含むリージョン
  • VPC_NETWORK_NAME: 元のプロキシ専用サブネットと新しいプロキシ専用サブネットを含むネットワークの VPC ネットワーク名

  1. --role=BACKUP フラグを指定して gcloud compute networks subnets create コマンドを使用し、同じリージョンと VPC ネットワークに新しいプロキシ専用サブネットを作成します。

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

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

    • SUBNET_PURPOSE: プロキシ専用サブネットを使用する必要があるロードバランサに応じて、REGIONAL_MANAGED_PROXY または GLOBAL_MANAGED_PROXY のいずれか。詳細については、サポートされているロードバランサをご覧ください。

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

    gcloud compute firewall-rules update PROXY_ONLY_SUBNET_FIREWALL_RULE \
  --source-ranges=ORIGINAL_PROXY_ONLY_SUBNET_RANGE,NEW_PROXY_ONLY_SUBNET_RANGE

  3. 新しいプロキシ専用サブネットのロールを ACTIVE に設定し、ドレイン タイムアウト（--drain-timeout）を指定して、バックエンドと元のプロキシ専用サブネット間の接続を終了できるようにします。Google Cloud は、新しいプロキシ専用サブネットのロールを ACTIVE に設定すると、元のプロキシ専用サブネットのロールを自動的に BACKUP に設定します。

    元のプロキシ専用サブネット内のバックエンドと Envoy プロキシ間の接続をすぐに切断するには、--drain-timeout を 0s に設定します。

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

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

    • CONNECTION_DRAINING_TIMEOUT: 元のプロキシ専用サブネット内のバックエンドと Envoy プロキシ間の既存の接続を終了する時間を秒単位で指定します。

  4. gcloud compute networks subnets describe コマンドを使用して、元のプロキシ専用サブネットのステータスをモニタリングします。

    gcloud compute networks subnets describe ORIGINAL_PROXY_ONLY_SUBNET_NAME \
   --region=REGION

    ドレインが完了するまで待ちます。ドレイン中、元のプロキシ専用サブネットのステータスは DRAINING になります。元のプロキシ専用サブネットのステータスが READY に変わるまで、describe コマンドを数回実行しなければならない場合があります。

  5. 元のプロキシ専用サブネットが BACKUP ロールの READY になると、サブネットは使用されなくなります。新しいプロキシ専用サブネットのプライマリ IPv4 アドレス範囲のみが含まれるように、バックエンド VM またはエンドポイントに適用される上り（内向き）許可ファイアウォール ルールを更新します。

    gcloud compute firewall-rules update PROXY_ONLY_SUBNET_FIREWALL_RULE \
  --source-ranges=NEW_PROXY_ONLY_SUBNET_RANGE

  6. 元のプロキシ専用サブネットを削除します。

    gcloud compute networks subnets delete ORIGINAL_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）内は、プロキシ専用サブネットのロールをバックアップからアクティブに変更できません。

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

次のステップ