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

このページでは、Envoy ベースのロードバランサで使用されるプロキシ専用サブネットを操作する方法について説明します。プロキシ専用サブネットは、ロードバランサが使用する Envoy プロキシ専用として予約されたプロキシのプールを提供します。他の目的には使用できません。どの時点でも、VPC ネットワークのリージョンごとにアクティブにできるプロキシ専用サブネットは 1 つだけです。

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

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

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

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

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

ネットワークが自動モードかカスタムモードかに関係なく、プロキシ専用サブネットを作成する必要があります。プロキシ専用サブネットでは 64 個以上の IP アドレスを指定する必要があります。これは、/26 以下のプレフィックス長に対応します。推奨されるサブネット サイズは /23 です(512 個のプロキシ専用アドレス)。

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

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

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

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

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

次の図は、リージョン外部 HTTP(S) ロードバランサに必要な Google Cloud リソースを示しています。

リージョン外部 HTTP(S) ロードバランサのコンポーネント(クリックして拡大)
リージョン外部 HTTP(S) ロードバランサのコンポーネント(クリックして拡大)

次の図は、内部 HTTP(S) ロードバランサに必要な Google Cloud リソースを示しています。

内部 HTTP(S) ロードバランサのコンポーネント - 番号付き(クリックして拡大)
内部 HTTP(S) ロードバランサのコンポーネント - 番号付き(クリックして拡大)

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

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

プロキシ専用サブネットの作成

プロキシ専用サブネットの作成は、サブネットの作成と基本的に同じ手順です。ただし、いくつかのフラグを追加します。

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

内部 HTTP(S) ロードバランサの場合、--purpose=INTERNAL_HTTPS_LOAD_BALANCER も機能しますが、--purpose=REGIONAL_MANAGED_PROXY が推奨設定です。

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

Console

  1. Cloud Console で [VPC ネットワーク] ページに移動します。
    [VPC ネットワーク] ページに移動
  2. プロキシ専用サブネットを追加する共有 VPC ネットワークの名前をクリックします。
  3. [サブネットを追加] をクリックします。
  4. 名前を入力します。
  5. リージョンを選択します。
  6. [目的] を [リージョン マネージド プロキシ] に設定します。
  7. IP アドレス範囲を入力します。
  8. [追加] をクリックします。

gcloud

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

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

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

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

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

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

プロキシの可用性

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

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

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

デプロイメントでバックエンドの数を変更する場合は、プロキシ専用サブネットのサイズまたはアドレス範囲の変更が必要になることがあります。

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

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

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

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

Console

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

    1. Cloud Console で [VPC ネットワーク] ページに移動します。
      [VPC ネットワーク] ページに移動
    2. プロキシ専用サブネットを追加する共有 VPC ネットワークの名前をクリックします。
    3. [サブネットを追加] をクリックします。
    4. 名前を入力します。
    5. リージョンを選択します。
    6. [目的] を [リージョン マネージド プロキシ] に設定します。
    7. [ロール] で [バックアップ] を選択します。
    8. IP アドレス範囲を入力します。
    9. [追加] をクリックします。
  2. バックアップのプロキシ専用サブネットのプライマリ IP アドレス範囲が含まれるように、バックエンド VM またはエンドポイントに適用する上り(内向き)許可ファイアウォール ルールを作成または変更します

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

    1. Cloud Console で [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_SUBNET \
       --purpose=REGIONAL_MANAGED_PROXY \
       --role=BACKUP \
       --region=REGION \
       --network=VPC_NETWORK_NAME \
       --range=CIDR_RANGE
    
  2. バックアップのプロキシ専用サブネットのプライマリ IP アドレス範囲が含まれるように、バックエンド VM またはエンドポイントに適用する上り(内向き)許可ファイアウォール ルールを作成または変更します。

  3. 次の gcloud コマンドを実行して、バックアップ プロキシ専用サブネットをアクティブ ロールに昇格し、前にアクティブだったプロキシ専用サブネットをバックアップ ロールに降格します。

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

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

    • BACKUP_PROXY_SUBNET: 新しく作成したバックアップ プロキシ専用サブネットの名前
    • REGION: 新しく作成したバックアップ プロキシ専用サブネットのリージョン
    • CONNECTION_DRAINING_TIMEOUT には、Google Cloud が前にアクティブだったプロキシ専用サブネットのプロキシから既存の接続を移行するために必要な時間を秒数で指定します。
  4. コネクション ドレインがタイムアウトしたか、バックエンド VM またはエンドポイントへの接続が以前アクティブだったプロキシ専用サブネットのプロキシから行われていないことを確認したら、次の操作を行います。

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

例: プロキシ専用サブネットの変更

このセクションでは、リージョン内のプロキシ専用サブネットを変更するために必要な手順を示す構成例を示します。

  1. リージョン専用のバックアップ プロキシ専用サブネットを作成します。

    gcloud compute networks subnets create new-l7ilb-backend-subnet-us-west1 \
       --purpose=REGIONAL_MANAGED_PROXY \
       --role=BACKUP \
       --region=us-west1 \
       --network=default \
       --range=10.130.0.0/23
    
  2. バックエンド ファイアウォールを更新して、新しいサブネットからの接続を受け入れます。

    gcloud compute firewall-rules update l7-ilb-firewall \
       --source-ranges 10.129.0.0/23,10.130.0.0/23
    
  3. 新しいサブネットを更新して、リージョン内の ACTIVE プロキシ専用サブネットに設定し、古いサブネットが廃棄されるのを待ちます。

    gcloud compute networks subnets update new-l7ilb-ip-range-us-west1 \
       --drain-timeout 1h --role ACTIVE
    

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

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

    gcloud compute networks subnets list
    

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

  5. バックエンドのファイアウォール ルールを更新して、新しいサブネットからの接続のみを許可します。

    gcloud compute firewall-rules update l7-ilb-firewall \
       --source-ranges 10.130.0.0/23
    
  6. 古いサブネットを削除します。

    gcloud compute networks subnets delete l7ilb-ip-range-us-west1 \
       --region us-west1
    

プロキシ専用サブネットの削除

プロキシ専用サブネットを削除すると、プライマリ 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_BALANCERREGIONAL_MANAGED_PROXY の両方のサブネットを配置することはできません。

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

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

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

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

  • プロキシ専用サブネットで IP アドレスが不足していても、Google Cloud は警告を表示しません。

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

次のステップ