内部 HTTP(S) ロードバランサのプロキシ専用サブネット

このページでは、リージョン ロードバランサのプロキシ専用サブネットを使用する方法を説明します。

内部 HTTP(S) 負荷分散の概要については、内部 HTTP(S) ロード バランシングの概要をご覧ください。

プロキシ専用サブネットは、リージョン ロードバランサのプロキシ用に予約されています。他の目的には使用できません。各リージョンの VPC ネットワークごとにアクティブにできるプロキシ専用サブネットは 1 つだけです。

ロードバランサの転送ルールを作成する前に、プロキシ専用サブネットを作成しておく必要があります。リージョン ロードバランサを使用する VPC ネットワークの各リージョンには、プロキシ専用サブネットが必要です。

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

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

2. いずれかのプロキシがクライアントのネットワーク接続を受信して終了します。

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

各ロードバランサのプロキシには内部 IP アドレスが割り当てられます。リージョン内のすべてのリージョン ロードバランサのプロキシには、VPC ネットワークのそのリージョン内のプロキシ専用サブネットに属する内部 IP アドレスが使用されます。プロキシ専用サブネットでは 64 個以上の IP アドレスを指定する必要があります。これは、/26 以下のプレフィックス長に対応します。

注: プロキシ専用サブネットには RFC 1918 以外のアドレス範囲を使用できます。これは、RFC 1918 アドレス範囲内で使用可能なアドレスが不足している場合に便利です。

プロキシ専用サブネットを使用するのは、リージョンのリージョン ロードバランサ用に Google Cloud によって作成されたプロキシだけです。プロキシ専用サブネットからは、ロードバランサの転送ルールの IP アドレスは取得されません。また、バックエンド VM とエンドポイントの IP アドレスも、プロキシ専用サブネットから取得されません。

各プロキシは、対応するロードバランサの転送ルールで指定された IP アドレスとポートでリッスンします。プロキシからバックエンド VM またはエンドポイントに送信される各パケットには、プロキシ専用サブネットからの送信元 IP アドレスが含まれています。

プロキシの割り当ては、ロードバランサ レベルではなく VPC レベルで行われます。つまり、同じリージョンおよび同じ VPC ネットワーク内にある複数のリージョン ロードバランサが、ロード バランシングのためにプロキシを共有します。

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

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

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

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

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

プロキシ専用サブネットは 10.129.0.0/23（この例では）です。

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

リージョン ロードバランサのサブネットの予約は、サブネットの作成と基本的に同じ手順です。ただし、いくつかのフラグを追加します。

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

注: 推奨される設定は --purpose=REGIONAL_MANAGED_PROXY です。--purpose=INTERNAL_HTTPS_LOAD_BALANCER でも機能します。

重要: リージョン外部 HTTP(S) ロードバランサは、--purpose が REGIONAL_MANAGED_PROXY に設定されたプロキシ専用サブネットを使用します。ネットワークの同じリージョンに内部 HTTP(S) ロードバランサとリージョン外部 HTTP(S) ロードバランサの両方を作成することはできません。

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

リージョン ロードバランサを使用する仮想ネットワーク（VPC）の各リージョンに、プロキシ専用サブネットを 1 つ作成する必要があります。このサブネットは、リージョン内のすべてのリージョン ロードバランサによって共有されます。

ネットワークが自動モードかカスタムモードかに関係なく、プロキシ専用サブネットを作成する必要があります。推奨されるサブネット サイズは /23 です（512 個のプロキシ専用アドレス）。少なくとも /26 にする必要があります（64 個のプロキシ専用アドレス）。

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 です。

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

プロキシ専用サブネットからの接続を受け入れるには、バックエンドにファイアウォール ルールを構成する必要があります。ファイアウォール ルールの構成で fw-allow-proxies 構成をご覧ください。

プロキシの可用性

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-timeout を 0s に設定します。サブネット内のアドレスが割り当てられているプロキシへのすべての接続がすぐに終了します。

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_BALANCER と REGIONAL_MANAGED_PROXY の両方のサブネットを配置することはできません。

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

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

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

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

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

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

次のステップ

• 内部 HTTP(S) 負荷分散の構成について、内部 HTTP(S) 負荷分散の設定で確認する。