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

このページでは、内部 HTTP(S) 負荷分散のプロキシ専用サブネットを使用する方法を説明します。内部 HTTP(S) 負荷分散の概要については、内部 HTTP(S) 負荷分散の概要をご覧ください。

プロキシ専用サブネットは、内部 HTTP(S) 負荷分散プロキシ専用として予約されています。他の目的には使用できません。各 VPC ネットワークのリージョンごとに、1 つのプロキシ専用サブネットだけをアクティブにできます。

内部 HTTP(S) ロードバランサの転送ルールを作成する前に、プロキシ専用サブネットを作成しておく必要があります。内部 HTTP(S) ロードバランサを使用する仮想プライベート ネットワーク(VPC)の各リージョンに、プロキシ専用サブネットを作成する必要があります。

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

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

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

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

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

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

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

次の図に、トラフィック フローの概要を示します。

レイヤ 7 ベースの負荷分散を使用した内部サービス(クリックして拡大)
レイヤ 7 ベースの負荷分散を使用した内部サービス(クリックして拡大)

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

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

内部 HTTP(S) 負荷分散コンポーネント(クリックして拡大)
内部 HTTP(S) 負荷分散コンポーネント(クリックして拡大)

図に示されているように、内部 HTTP(S) ロードバランサのデプロイには少なくとも 2 つのサブネットが必要です。

  • ロードバランサの内部管理転送ルール、バックエンド VM の IP アドレス、バックエンド エンドポイントの IP アドレスは、プライマリ IP アドレスの範囲が 10.1.2.0/24 のサブネットを 1 つ使用します。このサブネットは、プロキシ専用のサブネットではありません。サブネットがロードバランサと同じリージョンにある場合、バックエンド VM とエンドポイントに複数のサブネットを使用できます。

  • プロキシ専用サブネットは 10.129.0.0/23 です。

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

内部 HTTP(S) ロードバランサのサブネットの予約は、サブネットの作成と基本的に同じです。ただし、いくつかのフラグを追加します。

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

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

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

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

gcloud compute networks subnets create SUBNET_NAME \
    --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
    --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 です。

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

Cloud Console を使用している場合は、次のページで説明するように、負荷分散 UI でプロキシ専用サブネットを作成できます。

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

プロキシの可用性

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

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

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

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

プロキシ専用サブネットを変更する場合は、バックアップ プロキシ専用サブネットを作成する必要があります。これは、リージョンごと、VPC ネットワークごとにアクティブにできるプロキシ専用サブネットは 1 つだけで、サブネットのプライマリ IP 範囲の拡張が可能なためです。各ネットワークでは、リージョンごとにアクティブとバックアップのプロキシ専用サブネットをそれぞれ 1 つだけ作成できます。

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

    gcloud compute networks subnets create SUBNET_NAME \
       --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
       --role=BACKUP \
       --region=REGION \
       --network=VPC_NETWORK_NAME \
       --range=CIDR_RANGE
    
  2. バックアップのプロキシ専用サブネットのプライマリ IP 範囲が含まれるように、バックエンド VM またはエンドポイントに適用する上り(内向き)許可ファイアウォール ルールを作成または変更します。

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

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

    プレースホルダを有効な値に置き換えます。

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

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

    • 新しくアクティブになったプロキシ専用サブネットは新しい接続に使用されます。
    • 以前アクティブだったプロキシ専用サブネットは、新しい接続に使用されなくなります。
    • Google Cloud は、以前にアクティブで、現在はバックアップのプロキシ専用サブネット内のプロキシから既存の接続のドレインを開始します。
  4. コネクション ドレインがタイムアウトしたか、バックエンド VM またはエンドポイントへの接続が以前アクティブだった(現在はバックアップの)プロキシ専用サブネットのプロキシから行われていないことを確認したら、次の操作を行います。

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

要件と制限事項

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

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

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

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

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

  • 特定のリージョンと VPC ネットワークで最初の内部 HTTP(S) ロードバランサを作成する前に、そのリージョンとネットワークにアクティブなプロキシ専用サブネットが存在している必要があります。

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

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

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

    gcloud compute networks subnets create new-l7ibackend-subnet-us-west1 \
       --purpose INTERNAL_HTTPS_LOAD_BALANCER \
       --role BACKUP \
       --region us-west1 \
       --network default \
       --addresses 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. 新しいサブネットを更新して、リージョン内のアクティブ プロキシ専用サブネットに設定し、古いサブネットが廃棄されるのを待ちます。

    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 つ以上の内部 HTTP(S) ロードバランサがある場合、アクティブなプロキシ専用サブネットは削除できません。

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

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

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

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

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

次のステップ