このページでは、クロスリージョン内部アプリケーション ロードバランサをデプロイして、オンプレミスまたは他のパブリック クラウドにあり、ハイブリッド接続経由で到達可能なネットワーク エンドポイントにトラフィックをロード バランシングする方法について説明します。
まだ行っていない場合は、ハイブリッド接続 NEG の概要を確認して、ハイブリッド ロード バランシングを設定するためのネットワーク要件を把握してください。
設定の概要
この例では、次の図に示すように、ゾーンとハイブリッド接続の NEG バックエンド用にクロスリージョン内部アプリケーション ロードバランサを設定します。
ハイブリッド ロード バランシングのデプロイメントを設定する前に、ハイブリッド接続を構成する必要があります。選択したハイブリッド接続プロダクトに応じて、Cloud VPN または Cloud Interconnect(Dedicated または Partner)のいずれかを使用します。
SSL 証明書リソースを設定する
次のように、Certificate Manager SSL 証明書リソースを作成します。
- グローバル セルフマネージド証明書をデプロイする。
- Certificate Authority Service インスタンスによって発行された Google マネージド証明書を作成する。
- DNS 認証を使用して Google マネージド証明書をデプロイする。
Google マネージド証明書を使用することをおすすめします。
権限
ハイブリッド ロード バランシングを設定するには、次の権限が必要です。
- Google Cloud上で必要な権限 - Google Cloud とオンプレミス環境または他のクラウド環境との間のハイブリッド接続を確立する権限。必要な権限の一覧については、関連する Network Connectivity プロダクトのドキュメントをご覧ください。
- ハイブリッド接続 NEG とロードバランサを作成する権限。このガイドで説明するタスクの実行に必要な権限は、Compute ロードバランサ管理者のロール(roles/compute.loadBalancerAdmin)に含まれています。
 
- オンプレミス環境またはGoogle Cloud 以外のクラウド環境で必要な権限 - IP:Portの組み合わせでGoogle Cloud からオンプレミス環境または他のクラウド環境のサービスに到達できるように、ネットワーク エンドポイントを構成する権限。詳細については、お使いの環境のネットワーク管理者にお問い合わせください。
- Google のヘルスチェック プローブがエンドポイントに到達することを許可するように、ファイアウォール ルールをオンプレミス環境または他のクラウド環境に作成する権限。
 
さらに、このページの手順を完了するには、ハイブリッド接続 NEG、ロードバランサ、ゾーン NEG(およびそれらのエンドポイント)を作成して、ロードバランサの Google Cloudベースのバックエンドとして機能させる必要があります。
そのためには、プロジェクトのオーナーまたは編集者であるか、次の Compute Engine IAM のロールが必要です。
| タスク | 必要なロール | 
|---|---|
| ネットワーク、サブネット、負荷分散コンポーネントの作成 | Compute ネットワーク管理者( roles/compute.networkAdmin) | 
| ファイアウォール ルールの追加と削除 | Compute セキュリティ管理者( roles/compute.securityAdmin) | 
| インスタンスの作成 | Compute インスタンス管理者( roles/compute.instanceAdmin) | 
ハイブリッド接続を確立する
オンプレミス環境または他のクラウド環境と Google Cloud を接続するには、Cloud Router またはルーター アプライアンス VM とともに Cloud Interconnect VLAN アタッチメントまたは Cloud VPN トンネルを使用して、ハイブリッド接続を確立する必要があります。高可用性接続の使用をおすすめします。
グローバル動的ルーティングが有効になっている Cloud Router は、Border Gateway Protocol(BGP)を介して特定のエンドポイントを学習し、 Google Cloud VPC ネットワークにそのエンドポイントをプログラムします。リージョン動的ルーティングはサポートされていません。静的ルートもサポートされていません。
ハイブリッド ネットワーキング(Cloud Interconnect、Cloud VPN、またはルーター アプライアンス VM)とロードバランサの両方を構成するには、同じプロジェクト内の同じネットワークまたは別の VPC ネットワークを使用できます。次の点にご注意ください。
- 別の VPC ネットワークを使用する場合は、2 つのネットワークを VPC ネットワーク ピアリングを使用して接続するか、同じ Network Connectivity Center ハブの VPC スポークにする必要があります。 
- 同じ VPC ネットワークを使用する場合は、VPC ネットワークのサブネットの CIDR 範囲がリモートの CIDR 範囲と競合しないようにしてください。IP アドレスが重複する場合、リモート接続よりもサブネット ルートが優先されます。 
手順については、次のドキュメントをご覧ください。
Google Cloud外部にある環境を設定する
次の手順で、ハイブリッド ロード バランシング用のオンプレミス環境またはその他のクラウド環境を設定します。
- オンプレミス サービスをGoogle Cloud (IP:Port)に公開するようにネットワーク エンドポイントを構成します。
- オンプレミス環境または他のクラウド環境でファイアウォール ルールを構成します。
- プライベート環境への特定の必要なルートをアドバタイズするように Cloud Router を構成します。
ネットワーク エンドポイントを設定する
ハイブリッド接続を設定したら、オンプレミス環境または他のクラウド環境内に、IP:port の組み合わせを使用して Cloud Interconnect、Cloud VPN、またはルーター アプライアンス経由で到達可能なネットワーク エンドポイントを構成します。この IP:port の組み合わせは、このプロセスの後半に Google Cloud で作成されるハイブリッド接続 NEG の 1 つ以上のエンドポイントとして構成されます。
IP エンドポイントへのパスが複数ある場合、ルーティングは Cloud Router の概要で説明されているように動作します。
ファイアウォール ルールの設定
オンプレミス環境またはその他のクラウド環境に、次のファイアウォール ルールを作成する必要があります。
- オンプレミス環境またはその他のクラウド環境で上り(内向き)許可ファイアウォール ルールを作成して、リージョンのプロキシ専用サブネットからのトラフィックがエンドポイントに到達できるようにします。
- ハイブリッド NEG では、Google のヘルスチェック プローブ範囲からのトラフィックを許可する必要はありません。ただし、1 つのバックエンド サービスでハイブリッド NEG とゾーン NEG の組み合わせを使用している場合は、ゾーン NEG の Google ヘルスチェック プローブ範囲からのトラフィックを許可する必要があります。 
ルートをアドバタイズする
オンプレミス環境またはその他のクラウド環境に次のカスタム IP 範囲をアドバタイズするように、Cloud Router を構成します。
- リージョンのプロキシ専用サブネットの範囲。
Google Cloud 環境を設定する
以降のステップでは、環境間のハイブリッド接続の構成に使用した VPC ネットワーク(この手順では NETWORK)を使用します。
また、使用するリージョン(この手順では REGION_A と REGION_B)が Cloud VPN トンネルまたは Cloud Interconnect VLAN の作成に使用したリージョンと同じであることを確認します。
GEO タイプの DNS ルーティング ポリシーを構成できます。バックエンド サブネットを構成する
このサブネットは、ロードバランサのゾーン NEG バックエンドの作成に使用します。
コンソール
- Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。 
- 環境間のハイブリッド接続の構成に使用されたネットワークに移動します。 
- [サブネット] セクションで次の設定を行います。 - [サブネット作成モード] を [カスタム] に設定します。
- [新しいサブネット] セクションに、次の情報を入力します。- サブネットの名前を入力します。
- [リージョン] には、REGION_A を選択します。
- IP アドレス範囲を入力します。
 
- [完了] をクリックします。
 
- [作成] をクリックします。 
- 別のリージョンにサブネットを追加するには、[サブネットを追加] をクリックして、REGION_B の前の手順を繰り返します。 
gcloud
- 環境間のハイブリッド接続の構成に使用したネットワークにサブネットを作成します。 - gcloud compute networks subnets create SUBNET_A \ --network=NETWORK \ --range=LB_SUBNET_RANGE1 \ --region=REGION_A- gcloud compute networks subnets create SUBNET_B \ --network=NETWORK \ --range=LB_SUBNET_RANGE2 \ --region=REGION_B
API
subnetworks.insert メソッドに POST リクエストを送信します。PROJECT_ID は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks
{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "LB_SUBNET_RANGE1",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}
subnetworks.insert メソッドに POST リクエストを送信します。PROJECT_ID は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks
{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "LB_SUBNET_RANGE2",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}
次のように置き換えます。
- SUBNET_Aと- SUBNET_B: サブネットの名前
- LB_SUBNET_RANGE1と- LB_SUBNET_RANGE2: サブネットの IP アドレス範囲
- REGION_Aと- REGION_B: ロードバランサを構成したリージョン
プロキシ専用サブネットを構成する
プロキシ専用サブネットには、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。このプロキシは、クライアントからの接続を終端し、バックエンドへの新しい接続を作成します。
このプロキシ専用サブネットは、VPC ネットワークの同じリージョン内のすべての Envoy ベースのロードバランサで使用されます。特定の目的では、リージョンごと、ネットワークごとにアクティブなプロキシ専用サブネットが 1 つだけの場合があります。
コンソール
Google Cloud コンソールを使用している場合は、後ほど [ロード バランシング] ページでプロキシ専用サブネットを作成することもできます。
プロキシ専用サブネットを今すぐ作成する場合は、次の操作を行います。
- Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。 
- VPC ネットワークの名前をクリックします。
- [サブネット] タブで [サブネットを追加] をクリックします。
- プロキシ専用サブネットの [名前] を指定します。
- [リージョン] リストで [REGION_A] を選択します。
- [目的] リストで、[クロスリージョンのマネージド プロキシ] を選択します。
- [IP アドレス範囲] フィールドに「10.129.0.0/23」と入力します。
- [追加] をクリックします。
REGION_B にプロキシ専用サブネットを作成します。
- [サブネットを追加] をクリックします。
- プロキシ専用サブネットの [名前] を指定します。
- [リージョン] リストで [REGION_B] を選択します。
- [目的] リストで、[クロスリージョンのマネージド プロキシ] を選択します。
- [IP アドレス範囲] フィールドに「10.130.0.0/23」と入力します。
- [追加] をクリックします。
gcloud
gcloud compute networks subnets create コマンドを使用して、プロキシ専用サブネットを作成します。
    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=PROXY_ONLY_SUBNET_RANGE1
    
    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=PROXY_ONLY_SUBNET_RANGE2
    次のように置き換えます。
- PROXY_SN_Aと- PROXY_SN_B: プロキシ専用サブネットの名前
- PROXY_ONLY_SUBNET_RANGE1と- PROXY_ONLY_SUBNET_RANGE2: プロキシ専用サブネットの IP アドレス範囲
- REGION_Aと- REGION_B: ロードバランサを構成したリージョン
API
subnetworks.insert メソッドを使用してプロキシ専用サブネットを作成します。PROJECT_ID は、実際のプロジェクト ID に置き換えます。
    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks
    {
      "name": "PROXY_SN_A",
      "ipCidrRange": "PROXY_ONLY_SUBNET_RANGE1",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
  
    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks
    {
      "name": " PROXY_SN_B",
      "ipCidrRange": "PROXY_ONLY_SUBNET_RANGE2",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
  ファイアウォール ルールの作成
この例では、 Google Cloudのゾーン NEG バックエンド用に次のファイアウォール ルールを作成します。
- fw-allow-health-check: ロードバランスされているインスタンスに適用される上り(内向き)ルール。Google Cloud ヘルスチェック システム(- 130.211.0.0/22と- 35.191.0.0/16)からのトラフィックを許可します。この例では、ターゲットタグ- allow-health-checkを使用して、適用するゾーン NEG を識別します。
- fw-allow-ssh: 任意のアドレスから TCP ポート 22 への SSH 受信接続を許可する上り(内向き)ルール。このルールには、送信元の IP 範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲のみを指定できます。この例では、ターゲットタグ- allow-sshを使用して、適用する仮想マシン(VM)インスタンスを識別します。
- fw-allow-proxy-only-subnet: プロキシ専用サブネットからの接続がゾーン NEG バックエンドに到達することを許可する上り(内向き)ルール。
コンソール
- Google Cloud コンソールで、[ファイアウォール ポリシー] ページに移動します。 
- [ファイアウォール ルールを作成] をクリックして、ヘルスチェック プローブからのトラフィックを許可するルールを作成します。 - [名前] に「fw-allow-health-check」と入力します。
- [ネットワーク] で NETWORK を選択します。
- [ターゲット] で [指定されたターゲットタグ] を選択します。
- [ターゲットタグ] フィールドに「allow-health-check」を入力します。
- [ソースフィルタ] を [IPv4 範囲] に設定します。
- [送信元 IPv4 範囲] を 130.211.0.0/22と35.191.0.0/16に設定します。
- [プロトコルとポート] で [指定したプロトコルとポート] を選択します。
- [TCP] を選択し、ポート番号に「80」と入力します。
- [作成] をクリックします。
 
- [名前] に「
- [ファイアウォール ルールを作成] を再度クリックして、SSH 接続の受信を許可するルールを作成します。 - 名前: fw-allow-ssh
- ネットワーク: NETWORK
- 優先度: 1000
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: allow-ssh
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲: 0.0.0.0/0
- プロトコルとポート: [指定したプロトコルとポート] を選択します。
- [TCP] を選択し、ポート番号に「22」と入力します。
- [作成] をクリックします。
 
- 名前: 
- [ファイアウォール ルールを作成] を再度クリックして、プロキシ専用サブネットからの受信接続を許可するルールを作成します。 - 名前: fw-allow-proxy-only-subnet
- ネットワーク: NETWORK
- 優先度: 1000
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: allow-proxy-only-subnet
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲: PROXY_ONLY_SUBNET_RANGE1 と PROXY_ONLY_SUBNET_RANGE2
- プロトコルとポート: [指定したプロトコルとポート] を選択します。
- [TCP] を選択し、ポート番号に「80」と入力します。
- [作成] をクリックします。
 
- 名前: 
gcloud
- Google Cloud ヘルスチェックが TCP ポート - 80でバックエンド インスタンスに到達できるように- fw-allow-health-check-and-proxyルールを作成します。- gcloud compute firewall-rules create fw-allow-health-check \ --network=NETWORK \ --action=allow \ --direction=ingress \ --target-tags=allow-health-check \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --rules=tcp:80
- ネットワーク タグ - allow-sshを使用して、VM との SSH 接続を許可する- fw-allow-sshファイアウォール ルールを作成します。- source-rangesを省略すると、Google Cloud は任意の送信元としてルールを解釈します。- gcloud compute firewall-rules create fw-allow-ssh \ --network=NETWORK \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22
- ロードバランサが TCP ポート - 80でバックエンド インスタンスと通信することを許可するプロキシ専用サブネットの上り(内向き)許可ファイアウォール ルールを作成します。- gcloud compute firewall-rules create fw-allow-proxy-only-subnet \ --network=NETWORK \ --action=allow \ --direction=ingress \ --target-tags=allow-proxy-only-subnet \ --source-ranges=PROXY_ONLY_SUBNET_RANGE1,PROXY_ONLY_SUBNET_RANGE2 \ --rules=tcp:80
ゾーン NEG を設定する
Google Cloudベースのバックエンドの場合は、ハイブリッド接続を構成したリージョンに複数のゾーン NEG を構成することをおすすめします。
この例では、REGION_A リージョンにゾーン NEG を設定します(GCE_VM_IP_PORT タイプのエンドポイント)。まず、ZONE_A ゾーンに VM を作成します。次に、ZONE_A ゾーンにゾーン NEG を作成し、VM のネットワーク エンドポイントを NEG に追加します。高可用性をサポートするために、REGION_B リージョンに同様のゾーン NEG を設定します。一方のリージョンのバックエンドが停止した場合、トラフィックはもう一方のリージョンにフェイルオーバーされます。
VM を作成する
コンソール
- Google Cloud コンソールで、[VM インスタンス] ページに移動します。 
- 次の名前とゾーンの組み合わせを使用して、VM ごとに手順 3 から 8 を繰り返します。 - vm-a1の名前- ゾーン: ZONE_A(リージョン REGION_A 内)
- サブネット: SUBNET_A
 
- vm-b1の名前- ゾーン: ZONE_B(リージョン REGION_B 内)
- サブネット: SUBNET_B
 
 
- [インスタンスを作成] をクリックします。 
- 前の手順で示したように名前を設定します。 
- [リージョン] で、前の手順で示したように選択します。 
- [ゾーン] で、前の手順で示したように選択します。 
- [ブートディスク] セクションで、ブートディスク オプションとして Debian GNU/Linux 12 (bookworm) が選択されていることを確認します。必要に応じて [選択] をクリックし、イメージを変更します。 
- [詳細オプション] セクションで、[ネットワーキング] を開いて次の操作を行います。 - ネットワーク タグ(allow-ssh、allow-health-check、allow-proxy-only-subnet)を追加します。
- [ネットワーク インターフェース] セクションで、[ネットワーク インターフェースを追加] をクリックし、次のように変更してから、[完了] をクリックします。
- ネットワーク: NETWORK
- サブネットワーク: 前の手順と同じ。
- プライマリ内部 IP: エフェメラル(自動)
- 外部 IP: エフェメラル
 
- [管理] を開きます。次のスクリプトの内容を [自動化] フィールドにコピーして貼り付けます。スクリプトの内容はすべての VM で同じです。 - #! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2 
 
- ネットワーク タグ(
- [作成] をクリックします。 
gcloud
VM とそのゾーンの名前にこれらの組み合わせを使用して、次のコマンドを実行して VM を作成します。スクリプトの内容は両方の VM で同じです。
gcloud compute instances create VM_NAME \
    --zone=GCP_NEG_ZONE \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh,allow-health-check,allow-proxy-only-subnet \
    --subnet=LB_SUBNET_NAME \
    --metadata=startup-script='#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      vm_hostname="$(curl -H "Metadata-Flavor:Google" \
      http://metadata.google.internal/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2'
- vm-a1の- VM_NAME- ゾーン GCP_NEG_ZONE(リージョンREGION_AのZONE_Aとして)
- サブネット LB_SUBNET_NAME(SUBNET_Aとして)
 
- ゾーン 
- vm-b1の- VM_NAME- ゾーン GCP_NEG_ZONE(リージョンREGION_BのZONE_Bとして)
- サブネット LB_SUBNET_NAME(SUBNET_Bとして)
 
- ゾーン 
ゾーン NEG を作成する
コンソール
ゾーン ネットワーク エンドポイント グループを作成するには:
- Google Cloud コンソールで、[ネットワーク エンドポイント グループ] ページに移動します。 
- 次の名前とゾーンの組み合わせを使用して、ゾーン NEG ごとに手順 3 から 8 を繰り返します。 - 名前: neg-1- ゾーン: ZONE_A(リージョン REGION_A 内)
- サブネット: SUBNET_A
 
- 名前: neg-2- ゾーン: ZONE_B(リージョン REGION_B 内)
- サブネット: SUBNET_B
 
 
- 名前: 
- [ネットワーク エンドポイント グループを作成] をクリックします。 
- 前の手順で示したように名前を設定します。 
- [ネットワーク エンドポイント グループの種類] で [ネットワーク エンドポイント グループ(ゾーン)] を選択します。 
- [ネットワーク] で NETWORK を選択します。 
- 前の手順で示したサブネットワークを選択します。 
- 前の手順で示したゾーンを選択します。 
- [デフォルト ポート] で「 - 80」と入力します。
- [作成] をクリックします。 
エンドポイントをゾーン NEG に追加します。
- Google Cloud コンソールで、[ネットワーク エンドポイント グループ] ページに移動します。 
- 前の手順で作成したネットワーク エンドポイント グループの名前をクリックします。[ネットワーク エンドポイント グループの詳細] ページが表示されます。 
- [このグループのネットワーク エンドポイント] セクションで [ネットワーク エンドポイントを追加] をクリックします。[ネットワーク エンドポイントの追加] ページが表示されます。 
- [VM インスタンス] を選択して、ネットワーク エンドポイントとして内部 IP アドレスを追加します。[ネットワーク インターフェース] セクションに、VM の名前、ゾーン、サブネットが表示されます。 
- 新しいネットワーク エンドポイントの IP アドレスを入力します。 
- ポートタイプを選択します。 - [デフォルト] を選択すると、エンドポイントはネットワーク エンドポイント グループのすべてのエンドポイントにデフォルト ポート 80を使用します。この例では、Apache サーバーがポート80でリクエストを配信しているため、これで十分です。
- [カスタム] を選択した場合は、使用するエンドポイントのポート番号を入力します。
 
- [デフォルト] を選択すると、エンドポイントはネットワーク エンドポイント グループのすべてのエンドポイントにデフォルト ポート 
- 他のエンドポイントを追加するには、[ネットワーク エンドポイントを追加] をクリックし、前の手順を繰り返します。 
- すべてのエンドポイントを追加したら、[作成] をクリックします。 
gcloud
- 名前、ゾーン、サブネットの組み合わせを使用して、( - GCE_VM_IP_PORTエンドポイントを含む)ゾーン NEG を作成します。- gcloud compute network-endpoint-groups createコマンドを使用します。- gcloud compute network-endpoint-groups create GCP_NEG_NAME \ --network-endpoint-type=GCE_VM_IP_PORT \ --zone=GCP_NEG_ZONE \ --network=NETWORK \ --subnet=LB_SUBNET_NAME- 名前: neg-1- ゾーン GCP_NEG_ZONE: リージョンREGION_AのZONE_A
- サブネット LB_SUBNET_NAME:SUBNET_A
 
- ゾーン 
- 名前: neg-2- ゾーン GCP_NEG_ZONE: リージョンREGION_BのZONE_B
- サブネット LB_SUBNET_NAME:SUBNET_B
 
- ゾーン 
 - 次の手順で説明するように、NEG の作成時に - --default-portオプションを使用してポートを指定するか、各エンドポイントのポート番号を指定します。
- 名前: 
- エンドポイントを - neg1と- neg2に追加します。- gcloud compute network-endpoint-groups update neg1 \ --zone=ZONE_A \ --add-endpoint='instance=vm-a1,port=80'- gcloud compute network-endpoint-groups update neg2 \ --zone=ZONE_B \ --add-endpoint='instance=vm-b1,port=80'
ハイブリッド接続 NEG を設定する
NEG を作成するときは、 Google Cloud とオンプレミスまたは他のクラウド環境との間の地理的距離を最小限に抑えるゾーンを使用します。たとえば、ドイツのフランクフルトのオンプレミス環境にサービスをホストする場合、NEG を作成するときに europe-west3-aGoogle Cloud ゾーンを指定できます。
また、Cloud Interconnect を使用している場合は、NEG の作成に使用するゾーンは、Cloud Interconnect アタッチメントが構成されているリージョンに存在しています。
ハイブリッド NEG は、分散 Envoy ヘルスチェックのみをサポートします。
コンソール
ハイブリッド接続ネットワーク エンドポイント グループを作成するには:
- Google Cloud コンソールで、[ネットワーク エンドポイント グループ] ページに移動します。 
- [ネットワーク エンドポイント グループを作成] をクリックします。 
- 次の名前とゾーンの組み合わせを使用して、ハイブリッド NEG ごとに手順 4~9 を繰り返します。 - 名前 ON_PREM_NEG_NAME: hybrid-1- ゾーン: ON_PREM_NEG_ZONE1
- サブネット: SUBNET_A
 
- 名前 ON_PREM_NEG_NAME: hybrid-2- ゾーン: ON_PREM_NEG_ZONE2
- サブネット: SUBNET_B
 
 
- 名前 ON_PREM_NEG_NAME: 
- 前の手順で示したように名前を設定します。 
- ネットワーク エンドポイント グループの種類として [ハイブリッド接続ネットワーク エンドポイント グループ(ゾーン)] を選択します。 
- [ネットワーク] で NETWORK を選択します。 
- [サブネット] で、前の手順で示したように選択します。 
- [ゾーン] で、前の手順で示したように選択します。 
- デフォルト ポートを入力します。 
- [作成] をクリックします。 
ハイブリッド接続 NEG にエンドポイントを追加します。
- Google Cloud コンソールで、[ネットワーク エンドポイント グループ] ページに移動します。 
- 前の手順で作成したネットワーク エンドポイント グループの名前をクリックします。[ネットワーク エンドポイント グループの詳細] ページが表示されます。 
- [このグループのネットワーク エンドポイント] セクションで [ネットワーク エンドポイントを追加] をクリックします。[ネットワーク エンドポイントの追加] ページが表示されます。 
- 新しいネットワーク エンドポイントの IP アドレスを入力します。 
- ポートタイプを選択します。 - [デフォルト] を選択すると、エンドポイントはネットワーク エンドポイント グループのすべてのエンドポイントにデフォルト ポートを使用します。
- [カスタム] を選択すると、使用するエンドポイントに異なるポート番号を入力できます。
 
- 他のエンドポイントを追加するには、[ネットワーク エンドポイントを追加] をクリックし、前の手順を繰り返します。 
- すべてのGoogle Cloud 以外のエンドポイントを追加したら、[作成] をクリックします。 
gcloud
- 次の名前の組み合わせを使用してハイブリッド接続 NEG を作成します。 - gcloud compute network-endpoint-groups createコマンドを使用します。- gcloud compute network-endpoint-groups create ON_PREM_NEG_NAME \ --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \ --zone=ON_PREM_NEG_ZONE \ --network=NETWORK- 名前 ON_PREM_NEG_NAME:hybrid-1- ゾーン ON_PREM_NEG_ZONE:ON_PREM_NEG_ZONE1
 
- ゾーン 
- 名前 ON_PREM_NEG_NAME:hybrid-2- ゾーン GCP_NEG_ZONE:ON_PREM_NEG_ZONE2
 
- ゾーン 
 
- 名前 
- オンプレミス バックエンド VM のエンドポイントを - ON_PREM_NEG_NAMEに追加します。- gcloud compute network-endpoint-groups update ON_PREM_NEG_NAME \ --zone=ON_PREM_NEG_ZONE \ --add-endpoint="ip=ON_PREM_IP_ADDRESS_1,port=PORT_1" \ --add-endpoint="ip=ON_PREM_IP_ADDRESS_2,port=PORT_2"
このコマンドを使用すると、オンプレミスまたはクラウド環境で構成したネットワーク エンドポイントを追加できます。--add-endpoint を必要な回数だけ繰り返します。
ロードバランサを構成する
コンソール
gcloud
- gcloud compute health-checks create httpコマンドを使用して HTTP ヘルスチェックを定義します。- gcloud compute health-checks create http gil7-basic-check \ --use-serving-port \ --global 
- gcloud compute backend-services createコマンドを実行し、バックエンド サービスを作成してロギングを有効にします。- gcloud compute backend-services create BACKEND_SERVICE \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=HTTP \ --enable-logging \ --logging-sample-rate=1.0 \ --health-checks=gil7-basic-check \ --global-health-checks \ --global 
- gcloud compute backend-services add-backendコマンドを使用して、バックエンド サービスにバックエンドを追加します。- gcloud compute backend-services add-backend BACKEND_SERVICE \ --global \ --balancing-mode=RATE \ --max-rate-per-endpoint=MAX_REQUEST_RATE_PER_ENDPOINT \ --network-endpoint-group=neg1 \ --network-endpoint-group-zone=ZONE_A \ --network-endpoint-group=neg2 \ --network-endpoint-group-zone=ZONE_B - バランシング モードの構成の詳細については、gcloud CLI のドキュメントで - --max-rate-per-endpointフラグをご覧ください。
- ハイブリッド NEG をバックエンドとしてバックエンド サービスに追加します。 - gcloud compute backend-services add-backend BACKEND_SERVICE \ --global \ --balancing-mode=RATE \ --max-rate-per-endpoint=MAX_REQUEST_RATE_PER_ENDPOINT \ --network-endpoint-group=hybrid1 \ --network-endpoint-group-zone=ON_PREM_NEG_ZONE1 \ --network-endpoint-group=hybrid2 \ --network-endpoint-group-zone=ON_PREM_NEG_ZONE2 \ - バランシング モードの構成の詳細については、gcloud CLI のドキュメントで - --max-rate-per-endpointパラメータをご覧ください。
- gcloud compute url-maps createコマンドを使用して、URL マップを作成します。- gcloud compute url-maps create gil7-map \ --default-service=BACKEND_SERVICE \ --global 
- ターゲット プロキシを作成します。 - HTTP の場合: - gcloud compute target-http-proxies createコマンドを使用して、ターゲット プロキシを作成します。- gcloud compute target-http-proxies create gil7-http-proxy \ --url-map=gil7-map \ --global - HTTPS の場合: - Google マネージド証明書を作成するには、次のドキュメントをご覧ください。 - Certificate Authority Service インスタンスによって発行された Google マネージド証明書を作成する。
- DNS 認証を使用して Google マネージド証明書をデプロイする。
 - Google マネージド証明書を作成したら、証明書をターゲット プロキシに関連付けます。証明書マップは、クロスリージョン内部アプリケーション ロードバランサでサポートされていません。 - セルフマネージド証明書を作成するには、次のドキュメントをご覧ください。 - ファイルパスを変数名に割り当てます。 - export LB_CERT=PATH_TO_PEM_FORMATTED_FILE - export LB_PRIVATE_KEY=PATH_TO_PEM_LB_PRIVATE_FILE - gcloud certificate-manager certificates createコマンドを使用して、すべてのリージョン SSL 証明書を作成します。- gcloud certificate-manager certificates create gilb-certificate \ --private-key-file=$LB_CERT \ --certificate-file=$LB_PRIVATE_KEY \ --scope=all-regions - SSL 証明書を使用して、 - gcloud compute target-https-proxies createコマンドでターゲット プロキシを作成します。- gcloud compute target-https-proxies create gil7-https-proxy \ --url-map=gil7-map \ --certificate-manager-certificates=gilb-certificate \ --global 
- 2 つの転送ルールを作成します。1 つは - REGION_Aリージョンの VIP- IP_ADDRESS1で、もう 1 つは- REGION_Bリージョンの VIP- IP_ADDRESS2です。転送ルールの IP アドレスには、- LB_SUBNET_RANGE1または- LB_SUBNET_RANGE2の IP アドレス範囲を使用します。プロキシ専用サブネットを使用すると、転送ルールの作成に失敗します。- カスタム ネットワークでは、転送ルールでサブネットを参照する必要があります。このサブネットは、VM サブネットでありプロキシ専用サブネットではありません。 - HTTP の場合: - 適切なフラグを設定して - gcloud compute forwarding-rules createコマンドを実行します。- gcloud compute forwarding-rules create FWRULE_A \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=NETWORK \ --subnet=SUBNET_A \ --subnet-region=REGION_A \ --address=IP_ADDRESS1 \ --ports=80 \ --target-http-proxy=gil7-http-proxy \ --global - gcloud compute forwarding-rules create FWRULE_B \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=NETWORK \ --subnet=SUBNET_B \ --subnet-region=REGION_B \ --address=IP_ADDRESS2 \ --ports=80 \ --target-http-proxy=gil7-http-proxy \ --global - HTTPS の場合: - 適切なフラグを設定して - gcloud compute forwarding-rules createコマンドを実行し、転送ルールを作成します。- gcloud compute forwarding-rules create FWRULE_A \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=NETWORK \ --subnet=SUBNET_A \ --subnet-region=REGION_A \ --address=IP_ADDRESS1 \ --ports=443 \ --target-https-proxy=gil7-https-proxy \ --global - gcloud compute forwarding-rules create FWRULE_B \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=NETWORK \ --subnet=SUBNET_B \ --subnet-region=REGION_B \ --address=IP_ADDRESS2 \ --ports=443 \ --target-https-proxy=gil7-https-proxy \ --global 
ドメインをロードバランサに接続する
ロードバランサを作成したら、ロードバランサに関連付けられた IP アドレスをメモします(例: IP_ADDRESS1、IP_ADDRESS2)。ドメインがロードバランサを参照するようにするには、Cloud DNS またはドメイン登録サービスを使用して A レコードを作成します。SSL 証明書に複数のドメインを追加する場合は、それぞれについて A レコードを追加して、すべてがロードバランサの IP アドレスを指すようにする必要があります。
ロードバランサをテストする
VM インスタンスを作成して接続をテストする
- クライアント VM を作成します。 - gcloud compute instances create l7-ilb-client-a \ --image-family=debian-12 \ --image-project=debian-cloud \ --network=NETWORK \ --subnet=SUBNET_A \ --zone=ZONE_A \ --tags=allow-ssh- gcloud compute instances create l7-ilb-client-b \ --image-family=debian-12 \ --image-project=debian-cloud \ --network=NETWORK \ --subnet=SUBNET_B \ --zone=ZONE_B \ --tags=allow-ssh
- SSH を使用して各クライアント インスタンスに接続します。 - gcloud compute ssh l7-ilb-client-a \ --zone=ZONE_A - gcloud compute ssh l7-ilb-client-b \ --zone=ZONE_B 
- IP アドレスがホスト名を提供していることを確認します。 - クライアント VM が両方の IP アドレスに到達できることを確認します。コマンドが成功し、リクエストを処理したバックエンド VM の名前が返されます。 - HTTP テストの場合: - curl IP_ADDRESS1 - curl IP_ADDRESS2 - HTTPS テストの場合: - curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:IP_ADDRESS1:443 - curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:IP_ADDRESS2:443 - DOMAIN_NAME は、アプリケーションのドメイン名( - test.example.comなど)に置き換えます。- -kフラグを指定すると、curl は証明書の検証をスキップします。
- 省略可: 構成された DNS レコードを使用して、クライアント VM に最も近い IP アドレスを解決します。たとえば、DNS_ENTRY は - service.example.comです。- curl DNS_ENTRY 
 
100 件のリクエストを実行する
100 件の curl リクエストを実行し、ロードバランスされていることをレスポンスから確認します。
HTTP の場合:
- クライアント VM が両方の IP アドレスに到達できることを確認します。コマンドが成功し、リクエストを処理したバックエンド VM の名前が返されます。 - { RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl --silent IP_ADDRESS1)" done echo "***" echo "*** Results of load-balancing to IP_ADDRESS1: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }- { RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl --silent IP_ADDRESS2)" done echo "***" echo "*** Results of load-balancing to IP_ADDRESS2: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
HTTPS の場合:
- クライアント VM が両方の IP アドレスに到達できることを確認します。コマンドが成功し、リクエストを処理したバックエンド VM の名前が返されます。 - DOMAIN_NAME は、アプリケーションのドメイン名( - test.example.comなど)に置き換えます。- { RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:IP_ADDRESS1:443)" done echo "***" echo "*** Results of load-balancing to IP_ADDRESS1: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }- { RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:IP_ADDRESS2:443)" done echo "***" echo "*** Results of load-balancing to IP_ADDRESS2: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
フェイルオーバーをテストする
- REGION_Bのバックエンドが異常な状態またはアクセス不能になった場合は、- REGION_Aリージョンのバックエンドへのフェイルオーバーを確認します。- REGION_Bからすべてのバックエンドを削除してシミュレーションを行います。- gcloud compute backend-services remove-backend BACKEND_SERVICE \ --balancing-mode=RATE \ --network-endpoint-group=neg2 \ --network-endpoint-group-zone=ZONE_B 
- SSH を使用して、 - REGION_Bのクライアント VM に接続します。- gcloud compute ssh l7-ilb-client-b \ --zone=ZONE_B 
- REGION_Bリージョンのロード バランシングされた IP アドレスにリクエストを送信します。出力は次のようになります。- { RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:IP_ADDRESS2:443)" done echo "***" echo "*** Results of load-balancing to IP_ADDRESS2: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
追加の構成オプション
このセクションでは、代替および追加の構成オプションを提供する構成例を示します。これらのタスクはすべて省略可です。また、任意の順序で行うことができます。
DNS ルーティング ポリシーを構成する
クライアントが複数のリージョンにある場合は、これらのリージョンの VIP を使用して、クロスリージョン内部アプリケーション ロードバランサにアクセスできるようにすることをおすすめします。GEO タイプの DNS ルーティング ポリシーを使用して、クライアントに最も近いリージョンのロードバランサ VIP にクライアント トラフィックを転送できます。このマルチリージョンを設定することで、レイテンシとネットワーク転送の費用を最小限に抑えることができます。さらに、リージョンの停止に対する耐障害性を確保するため、DNS ベースのグローバル ロード バランシング ソリューションを設定することもできます。
Cloud DNS はヘルスチェックをサポートしており、エンドポイントのヘルスチェックに失敗すると自動フェイルオーバーが有効になります。フェイルオーバー中は、残りの正常なエンドポイントの間でトラフィックが分割されるように自動的に調整されます。詳細については、DNS ルーティング ポリシーとヘルスチェックを管理するをご覧ください。
gcloud
30 秒の TTL の DNS エントリを作成するには、gcloud dns record-sets create コマンドを使用します。
gcloud dns record-sets create DNS_ENTRY --ttl="30" \ --type="A" --zone="service-zone" \ --routing-policy-type="GEO" \ --routing-policy-data="REGION_A=gil7-forwarding-rule-a@global;REGION_B=gil7-forwarding-rule-b@global" \ --enable-health-checking
次のように置き換えます。
- DNS_ENTRY: レコードセットの DNS またはドメイン名- 例: - service.example.com
- REGION_Aと- REGION_B: ロードバランサを構成したリージョン
API
ResourceRecordSets.create メソッドに POST リクエストを送信して DNS レコードを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。
POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/SERVICE_ZONE/rrsets
{
  "name": "DNS_ENTRY",
  "type": "A",
  "ttl": 30,
  "routingPolicy": {
    "geo": {
      "items": [
        {
          "location": "REGION_A",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        },
        {
          "location": "REGION_B",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS_B",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        }
      ]
    }
  }
}
クライアント HTTP キープアライブ タイムアウトを更新する
前の手順で作成したロードバランサは、クライアント HTTP キープアライブ タイムアウトのデフォルト値で構成されています。クライアントの HTTP キープアライブ タイムアウトを更新するには、次の操作を行います。
コンソール
- Google Cloud コンソールで、[ロード バランシング] ページに移動します。 
- 変更するロードバランサの名前をクリックします。
- [編集] をクリックします。
- [フロントエンドの構成] をクリックします。
- [高度な機能] を開きます。[HTTP キープアライブ タイムアウト] にタイムアウト値を入力します。
- [更新] をクリックします。
- 変更を確認するには、[確認と完了] をクリックして、[更新] をクリックします。
gcloud
HTTP ロードバランサの場合は、gcloud compute target-http-proxies update コマンドを使用してターゲット HTTP プロキシを更新します。
      gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \
          --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
          --global
    HTTPS ロードバランサの場合は、gcloud compute target-https-proxies update コマンドを使用してターゲット HTTPS プロキシを更新します。
      gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \
          --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
          --global
    次のように置き換えます。
- TARGET_HTTP_PROXY_NAME: ターゲット HTTP プロキシの名前。
- TARGET_HTTPS_PROXY_NAME: ターゲット HTTPS プロキシの名前。
- HTTP_KEEP_ALIVE_TIMEOUT_SEC: HTTP キープアライブ タイムアウト値(5~600 秒)。
外れ値検出を有効にする
グローバル バックエンド サービスで外れ値検出を有効にすると、正常でないサーバーレス NEG を識別し、正常でないサーバーレス NEG に送信されるリクエストの数を減らすことができます。
外れ値検出は、次のいずれかの方法を使用して、バックエンド サービスで有効になります。
- consecutiveErrorsメソッド(- outlierDetection.consecutiveErrors)。このメソッドでは- 5xxシリーズの HTTP ステータス コードがエラーとみなされます
- consecutiveGatewayFailureメソッド(- outlierDetection.consecutiveGatewayFailure)。このメソッドは、- 502、- 503、- 504の HTTP ステータス コードのみエラーとみなされます。
既存のバックエンド サービスで外れ値検出を有効にするには、次の操作を行います。外れ値検出を有効にした後でも、一部のリクエストが正常でないサービスに送信され、5xx ステータス コードがクライアントに返される場合があることに注意してください。エラー率をさらに低減するには、外れ値検出パラメータ用により積極的な値を構成します。詳しくは、outlierDetection フィールドをご覧ください。
コンソール
- Google Cloud コンソールで、[ロード バランシング] ページに移動します。 
- バックエンド サービスを編集するロードバランサの名前をクリックします。 
- [ロードバランサの詳細] ページで、[編集] をクリックします。 
- [Edit cross-region internal Application Load Balancer] ページで、[バックエンドの構成] をクリックします。 
- [バックエンドの構成] ページで、変更するバックエンド サービスの [編集] をクリックします。 
- 下にスクロールして [高度な構成] セクションを開きます。 
- [外れ値検出] セクションで、[有効にする] チェックボックスをオンにします。 
- [編集] をクリックして外れ値検出を構成します。 - 以下のオプションが次の値で構成されていることを確認します。 - プロパティ - 値 - 連続するエラー - 5 - 間隔 - 1000 - ベースの排出時間 - 30000 - 最大排出率 - 50 - 連続するエラーの適用 - 100 - この例では、外れ値検出分析が 1 秒ごとに実行されます。Envoy プロキシが連続して受信した HTTP - 5xxステータス コードの数が 5 以上の場合、バックエンド エンドポイントは Envoy プロキシのロード バランシング プールから 30 秒間除外されます。適用の割合が 100% に設定されている場合、バックエンド サービスでは、外れ値検出分析が実行されるたびに、これらの特定の Envoy プロキシのロード バランシング プールから正常でないエンドポイントが排出されます。除外条件が満たされると、ロード バランシング プールからバックエンド エンドポイントの最大 50% が排出されます。
- [保存] をクリックします。 
- バックエンド サービスを更新するには、[更新] をクリックします。 
- ロードバランサを更新するには、[Edit cross-region internal Application Load Balancer] ページで [更新] をクリックします。 
gcloud
- バックエンド サービスを YAML ファイルにエクスポートします。 - gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME.yaml --global - BACKEND_SERVICE_NAMEは、バックエンド サービスの名前に置き換えます。
- outlierDetectionセクションの次の YAML 構成でハイライト表示されているように、バックエンド サービスの YAML 構成を編集して、外れ値検出のフィールドを追加します。- この例では、外れ値検出分析が 1 秒ごとに実行されます。Envoy プロキシが連続して受信した HTTP - 5xxステータス コードの数が 5 以上の場合、バックエンド エンドポイントは Envoy プロキシのロード バランシング プールから 30 秒間除外されます。適用の割合が 100% に設定されている場合、バックエンド サービスでは、外れ値検出分析が実行されるたびに、これらの特定の Envoy プロキシのロード バランシング プールから正常でないエンドポイントが排出されます。除外条件が満たされると、ロード バランシング プールからバックエンド エンドポイントの最大 50% が排出されます。- name: BACKEND_SERVICE_NAME backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME - balancingMode: UTILIZATION capacityScaler: 1.0 group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2 outlierDetection: baseEjectionTime: nanos: 0 seconds: 30 consecutiveErrors: 5 enforcingConsecutiveErrors: 100 interval: nanos: 0 seconds: 1 maxEjectionPercent: 50 port: 80 selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME sessionAffinity: NONE timeoutSec: 30 ...- 次のように置き換えます。 - BACKEND_SERVICE_NAME: バックエンド サービスの名前
- PROJECT_ID: オブジェクトの ID
- REGION_Aと- REGION_B: ロードバランサを構成したリージョン
- SERVERLESS_NEG_NAME: 最初のサーバーレス NEG の名前
- SERVERLESS_NEG_NAME_2: 2 番目のサーバーレス NEG の名前
 
- 最新の構成をインポートして、バックエンド サービスを更新します。 - gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME.yaml --global - バックエンド サービスで外れ値検出が有効になりました。 
次のステップ
- アプリケーション ロードバランサを IPv6 に変換する
- 内部アプリケーション ロードバランサの概要
- Envoy ベースのロードバランサ向けプロキシ専用サブネット
- 証明書を管理する
- ロード バランシングの設定をクリーンアップする