このドキュメントでは、Cloud Run でクロスリージョン内部アプリケーション ロードバランサをデプロイする方法について説明します。この設定を行うには、ロードバランサにサーバーレス NEG バックエンドを使用します。
サーバーレス NEG を使用すると、ロードバランサで Cloud Run サービスを使用できます。サーバーレス NEG バックエンドを使用してロードバランサを構成した後は、そのロードバランサへのリクエストが Cloud Run バックエンドに転送されるようになります。
クロスリージョン ロード バランシングを使用すると、特定のリージョンがアクセス不能となった場合にトラフィックが別のリージョンに自動的に転送され、冗長性が確保されます。プロキシ トラフィックは、Envoy のロケーションに基づいて次のように Cloud Run サービスに分散されます。
- マルチリージョンの Cloud Run サービスが Envoy と同じリージョンに構成されている場合は、Envoy と同じリージョンにある NEG が優先されます。外れ値検出が有効で、ローカル NEG が異常な場合にのみ、トラフィックがフェイルオーバー リージョンに送信されます。
- マルチリージョンの Cloud Run サービスが Envoy と同じリージョンに構成されていない場合、トラフィックはすべての NEG に均等に分散されます。近くにある NEG が優先されることはありません。
- Identity-Aware Proxy が有効になっている場合は、単一のサーバーレス NEG のみがサポートされます。追加の Cloud Run サービスを構成することは可能ですが、ロードバランサはそれらのサービスにトラフィックを送信しません。
始める前に
このガイドに進む前に、次の内容を理解しておいてください。
Cloud Run サービスをデプロイする
このページで説明する手順では、Cloud Run サービスをすでに実行中であることを前提としています。
このページの例では、Cloud Run クイックスタートを使用して Cloud Run サービスをデプロイできます。
インターネットから Cloud Run サービスにアクセスできないようにするには、上り(内向き)を internal
に制限します。内部アプリケーション ロードバランサからのトラフィックは内部トラフィックとみなされます。
Cloud Run サービスを複数のリージョンに配置すると、1 つのリージョンでの障害を防ぐことができます。Cloud Run サービスを REGION_A
リージョンと REGION_B
リージョンにデプロイするには、次のコマンドを実行します。
gcloud
gcloud run deploy CLOUD_RUN_SERVICE_NAMEA \ --platform=managed \ --allow-unauthenticated \ --ingress=internal \ --region=REGION_A \ --image=IMAGE_URLA
gcloud run deploy CLOUD_RUN_SERVICE_NAMEB \ --platform=managed \ --allow-unauthenticated \ --ingress=internal \ --region=REGION_B \ --image=IMAGE_URLB
作成するサービスの名前をメモします。このページの残りの部分では、このサービスにリクエストを転送するロードバランサの設定方法について説明します。
SSL 証明書リソースを設定する
次のように Certificate Manager SSL 証明書リソースを作成します。
- グローバル セルフマネージド証明書をデプロイする
- Certificate Authority Service インスタンスによって発行された Google マネージド証明書を作成する
- DNS 認証を使用して Google マネージド証明書をデプロイする
Google マネージド証明書を使用することをおすすめします。
権限
このガイドに従うには、プロジェクト内でインスタンスを作成してネットワークを変更できる必要があります。そのためにはプロジェクトのオーナーまたは編集者であるか、または次の Compute Engine IAM のロールをすべて持っている必要があります。
タスク | 必要なロール |
---|---|
ネットワーク、サブネット、ロードバランサ コンポーネントの作成 | Compute ネットワーク管理者 |
ファイアウォール ルールの追加と削除 | Compute セキュリティ管理者 |
インスタンスの作成 | Compute インスタンス管理者 |
詳細については、次のガイドをご覧ください。
設定の概要
クロスリージョン内部アプリケーション ロードバランサは、次の図のように構成できます。
図に示すように、この例では、REGION_A
と REGION_B
リージョン内に 1 つのバックエンド サービスと 2 つの Cloud Run デプロイメントがある VPC ネットワークに、クロスリージョン内部アプリケーション ロードバランサを作成します。
クロスリージョン内部アプリケーション ロードバランサの設定は次のとおりです。
次のサブネットを持つ VPC ネットワーク。
REGION_A
に、サブネットSUBNET_A
と 1 つのプロキシ専用サブネットREGION_B
に、サブネットSUBNET_B
と 1 つのプロキシ専用サブネット
クロスリージョン内部アプリケーション ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを作成する必要があります。リージョンのプロキシ専用サブネットは、リージョン内のすべてのクロスリージョン内部アプリケーション ロードバランサで共有されます。ロードバランサからサービスのバックエンドに送信されるパケットのソースアドレスは、プロキシ専用サブネットから割り振られます。この例では、リージョン
REGION_A
のプロキシ専用サブネットのプライマリ IP アドレス範囲は10.129.0.0/23
で、REGION_B
のプライマリ IP アドレス範囲は10.130.0.0/23
であり、これが推奨サブネット サイズです。ネットワーク内のプロキシ専用サブネット トラフィック フローを許可するファイアウォール ルール。
10.129.0.0/23
と10.130.0.0/23
(この例ではプロキシ専用サブネットの範囲)からの TCP ポート80
、443
、8080
トラフィックを許可する 1 つのルールが追加されることになります。ヘルスチェック プローブ用の別のファイアウォール ルール。
REGION_A
リージョンとREGION_B
リージョンに Cloud Run デプロイのサーバーレス バックエンドが存在する高可用性設定。一方のリージョンのバックエンドが停止した場合、トラフィックはもう一方のリージョンにフェイルオーバーされます。バックエンドの使用状況と健全性をモニタリングするグローバル バックエンド サービス。バックエンド サービスで外れ値検出を有効にします。
グローバル URL マップはリクエストの URL を解析し、リクエスト URL のホストとパスに基づいて特定のバックエンド サービスにリクエストを転送します。
グローバル ターゲット HTTP または HTTPS プロキシ。ユーザーからリクエストを受け取り、URL マップに転送します。HTTPS の場合、リージョン SSL 証明書リソースを構成します。HTTPS 負荷分散を構成する場合、ターゲット プロキシは SSL 証明書を使用して SSL トラフィックを復号します。ターゲット プロキシは、HTTP または HTTPS を使用してトラフィックをインスタンスに転送できます。
ロードバランサの内部 IP アドレスを持つグローバル転送ルール。受信リクエストをターゲット プロキシに転送します。
転送ルールに関連付けられた内部 IP アドレスは、同じネットワークとリージョンにある任意のサブネットから取得できます。次の条件に注意してください。
- IP アドレスは、バックエンド インスタンス グループと同じサブネットから取得できます(必須ではありません)。
- IP アドレスは、
--purpose
フラグがGLOBAL_MANAGED_PROXY
に設定されている予約済みプロキシ専用サブネットからは取得しないでください。 - 複数の転送ルールで同じ内部 IP アドレスを使用する場合は、IP アドレス
--purpose
フラグをSHARED_LOADBALANCER_VIP
に設定します。
省略可: クライアントに最も近いリージョンのロードバランサ VIP にクライアント トラフィックを転送するように、
GEO
タイプの DNS ルーティング ポリシーを構成します。
ネットワークとサブネットを構成する
VPC ネットワーク内で、バックエンドが構成されている各リージョンにサブネットを構成します。さらに、ロードバランサを構成する各リージョンに proxy-only-subnet
を構成します。
この例では、次の VPC ネットワーク、リージョン、サブネットを使用します。
ネットワーク。ネットワークは、
NETWORK
という名前のカスタムモード VPC ネットワークです。バックエンドのサブネット。
REGION_A
リージョンのSUBNET_A
という名前のサブネットは、プライマリ IP 範囲として10.1.2.0/24
を使用します。REGION_B
リージョンにあるSUBNET_A
という名前のサブネットには、プライマリ IP 範囲として10.1.3.0/24
を使用します。プロキシのサブネット。
REGION_A
リージョンのPROXY_SN_A
という名前のサブネットは、プライマリ IP 範囲として10.129.0.0/23
を使用します。REGION_B
リージョンのPROXY_SN_B
という名前のサブネットは、プライマリ IP 範囲として10.130.0.0/23
を使用します。
クロスリージョン内部アプリケーション ロードバランサには、VPC 内の任意のリージョンからアクセスできます。これにより、任意のリージョンのクライアントがロードバランサのバックエンドにグローバルにアクセスできるようになります。
バックエンド サブネットを構成する
コンソール
Google Cloud コンソールの [VPC ネットワーク] ページに移動します。
[VPC ネットワークを作成] をクリックします。
ネットワークの [名前] を指定します。
[サブネット] セクションで、[サブネット作成モード] を [カスタム] に設定します。
ロードバランサのバックエンド用のサブネットを作成します。[新しいサブネット] セクションに、次の情報を入力します。
- サブネットの [名前] を指定します。
- [リージョン] では、[REGION_A] を選択します。
- IP アドレス範囲には、「
10.1.2.0/24
」を入力します。
[完了] をクリックします。
[サブネットを追加] をクリックします。
ロードバランサのバックエンド用のサブネットを作成します。[新しいサブネット] セクションに、次の情報を入力します。
- サブネットの [名前] を指定します。
- [リージョン] では、[REGION_B] を選択します。
- IP アドレス範囲には、「
10.1.3.0/24
」を入力します。
[完了] をクリックします。
[作成] をクリックします。
gcloud
gcloud compute networks create
コマンドを使用してカスタム VPC ネットワークを作成します。gcloud compute networks create NETWORK --subnet-mode=custom
gcloud compute networks subnets create
コマンドを使用して、REGION_A
リージョンのNETWORK
ネットワークにサブネットを作成します。gcloud compute networks subnets create SUBNET_A \ --network=NETWORK \ --range=10.1.2.0/24 \ --region=REGION_A
gcloud compute networks subnets create
コマンドを使用して、REGION_B
リージョンのNETWORK
ネットワークにサブネットを作成します。gcloud compute networks subnets create SUBNET_B \ --network=NETWORK \ --range=10.1.3.0/24 \ --region=REGION_B
API
networks.insert
メソッドに POST
リクエストを送信します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks { "routingConfig": { "routingMode": "regional" }, "name": "NETWORK", "autoCreateSubnetworks": false }
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": "10.1.2.0/24", "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": "10.1.3.0/24", "region": "projects/PROJECT_ID/regions/REGION_B", }
プロキシ専用サブネットを構成する
プロキシ専用サブネットには、Google Cloud が開発者に代わって 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=10.129.0.0/23
gcloud compute networks subnets create PROXY_SN_B \ --purpose=GLOBAL_MANAGED_PROXY \ --role=ACTIVE \ --region=REGION_B \ --network=NETWORK \ --range=10.130.0.0/23
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": "10.129.0.0/23", "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": "10.130.0.0/23", "network": "projects/PROJECT_ID/global/networks/NETWORK", "region": "projects/PROJECT_ID/regions/REGION_B", "purpose": "GLOBAL_MANAGED_PROXY", "role": "ACTIVE" }
サーバーレス NEG を作成する
Cloud Run サービスにサーバーレス NEG を作成します。
gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-a \ --region=REGION_A \ --network-endpoint-type=serverless \ --cloud-run-service=CLOUD_RUN_SERVICE_NAMEA
gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-b \ --region=REGION_B \ --network-endpoint-type=serverless \ --cloud-run-service=CLOUD_RUN_SERVICE_NAMEB
ロードバランサを構成する
ロードバランサからサーバーレス NEG バックエンドへのトラフィックは、ファイアウォール ルールの対象外である VPC の外部で定義された特別なルートを使用します。したがって、ロードバランサにサーバーレス NEG バックエンドしかない場合は、プロキシ専用サブネットからサーバーレス バックエンドへのトラフィックを許可するファイアウォール ルールを作成する必要はありません。
コンソール
構成を開始する
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
- [ロードバランサを作成] をクリックします。
- [ロードバランサの種類] で [アプリケーション ロードバランサ(HTTP / HTTPS)] を選択し、[次へ] をクリックします。
- [インターネット接続または内部] で [内部] を選択し、[次へ] をクリックします。
- [クロスリージョンまたはシングル リージョンのデプロイ] では、[クロスリージョン ワークロードに最適] を選択し、[次へ] をクリックします。
- [構成] をクリックします。
基本構成
- ロードバランサの [名前] を入力します。
- [ネットワーク] で [NETWORK] を選択します。
2 つの転送ルールを使用してフロントエンドを構成する
HTTP の場合:
- [フロントエンドの構成] をクリックします。
- 転送ルールの [名前] を指定します。
- [サブネットワークのリージョン] リストで、[REGION_A] を選択します。
プロキシ専用サブネットを予約する
- [サブネットワーク] リストで、[SUBNET_A] を選択します。
- [IP アドレス] リストで、[IP アドレスを作成] をクリックします。[静的内部 IP アドレスの予約] ページが開きます。
- 静的 IP アドレスの [名前] を指定します。
- [静的 IP アドレス] リストで、[ユーザー指定] を選択します。
- [カスタム IP アドレス] フィールドに、「
10.1.2.99
」と入力します。 - [予約] を選択します。
- [完了] をクリックします。
- 2 番目の転送ルールを追加するには、[フロントエンドの IP とポートを追加] をクリックします。
- 転送ルールの [名前] を指定します。
- [サブネットワークのリージョン] リストで、[REGION_B] を選択します。
プロキシ専用サブネットを予約する
- [サブネットワーク] リストで、[SUBNET_B] を選択します。
- [IP アドレス] リストで、[IP アドレスを作成] をクリックします。[静的内部 IP アドレスの予約] ページが開きます。
- 静的 IP アドレスの [名前] を指定します。
- [静的 IP アドレス] リストで、[ユーザー指定] を選択します。
- [カスタム IP アドレス] フィールドに、「
10.1.3.99
」と入力します。 - [予約] を選択します。
- [完了] をクリックします。
HTTPS の場合:
クライアントとロードバランサ間で HTTPS を使用する場合は、プロキシを構成するために 1 つ以上の SSL 証明書リソースが必要になります。all-regions
Google マネージド証明書を作成するには、次のドキュメントをご覧ください。
- Certificate Authority Service インスタンスによって発行された Google マネージド証明書を作成する。
- DNS 認証を使用して Google マネージド証明書をデプロイする。
Google マネージド証明書を作成したら、証明書をターゲット プロキシに直接関連付けます。証明書マップは、クロスリージョン内部アプリケーション ロードバランサでサポートされていません。
all-regions
セルフマネージド証明書を作成するには、リージョンのセルフマネージド証明書をデプロイするをご覧ください。
- [フロントエンドの構成] をクリックします。
- 転送ルールの [名前] を指定します。
- [プロトコル] フィールドで
HTTPS (includes HTTP/2)
を選択します。 - [ポート] が
443
に設定されていることを確認します。 - [サブネットワークのリージョン] リストで、[REGION_A] を選択します。
プロキシ専用サブネットを予約する
- [サブネットワーク] リストで、[SUBNET_A] を選択します。
- [IP アドレス] リストで、[IP アドレスを作成] をクリックします。[静的内部 IP アドレスの予約] ページが開きます。
- 静的 IP アドレスの [名前] を指定します。
- [静的 IP アドレス] リストで、[ユーザー指定] を選択します。
- [カスタム IP アドレス] フィールドに、「
10.1.3.99
」と入力します。 - [予約] を選択します。
- [証明書の追加] セクションで、証明書を選択します。
- 省略可: プライマリ SSL 証明書に加えて証明書を追加するには:
- [証明書を追加] をクリックします。
- リストから証明書を選択します。
- [SSL ポリシー] リストから SSL ポリシーを選択します。SSL ポリシーを作成していない場合は、デフォルトの Google Cloud SSL ポリシーが適用されます。
- [完了] をクリックします。
- フロントエンド構成の [名前] に、名前を入力します。
- [プロトコル] フィールドで
HTTPS (includes HTTP/2)
を選択します。 - [ポート] が
443
に設定されていることを確認します。 - [サブネットワークのリージョン] リストで、[REGION_B] を選択します。
プロキシ専用サブネットを予約する
- [サブネットワーク] リストで、[SUBNET_B] を選択します。
- [IP アドレス] リストで、[IP アドレスを作成] をクリックします。[静的内部 IP アドレスの予約] ページが開きます。
- 静的 IP アドレスの [名前] を指定します。
- [静的 IP アドレス] リストで、[ユーザー指定] を選択します。
- [カスタム IP アドレス] フィールドに、「
10.1.3.99
」と入力します。 - [予約] を選択します。
- [証明書の追加] セクションで、証明書を選択します。
- 省略可: プライマリ SSL 証明書に加えて証明書を追加するには:
- [証明書を追加] をクリックします。
- リストから証明書を選択します。
- [SSL ポリシー] リストから SSL ポリシーを選択します。SSL ポリシーを作成していない場合は、デフォルトの Google Cloud SSL ポリシーが適用されます。
- [完了] をクリックします。
- [バックエンドの構成] をクリックします。
- [バックエンド サービスの作成または選択] リストで、[バックエンド サービスを作成] をクリックします。
- [名前] に、バックエンド サービスの名前を入力します。
- [プロトコル] で [HTTP] を選択します。
- [名前付きポート] に「
http
」と入力します。 - [バックエンド タイプ] リストで、[サーバーレス ネットワーク エンドポイント グループ] を選択します。
- [新しいバックエンド] セクションで、次の操作を行います。
- [サーバーレス ネットワーク エンドポイント グループ] リストで、[
gl7ilb-serverless-neg-a
] を選択します。 - [完了] をクリックします。
- 別のバックエンドを追加するには、[バックエンドを追加] をクリックします。
- [サーバーレス ネットワーク エンドポイント グループ] リストで、[
gl7ilb-serverless-neg-b
] を選択します。 - [完了] をクリックします。
- [ルーティング ルール] をクリックします。
- [モード] で、[単純なホストとパスのルール] を選択します。
- 一致しないホストとパスに対してバックエンド サービスが 1 つしかないことを確認します。
- [確認と完了] をクリックします。
- ロードバランサの構成を確認します。
- [作成] をクリックします。
2 番目のフロントエンド構成を追加します。
ルーティング ルールを構成する
構成を確認する
gcloud
gcloud compute backend-services create
コマンドを使用してバックエンド サービスを定義します。gcloud compute backend-services create gil7-backend-service \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=HTTP \ --global
gcloud compute backend-services add-backend
コマンドを使用して、バックエンド サービスにバックエンドを追加します。gcloud compute backend-services add-backend gil7-backend-service \ --network-endpoint-group=gl7ilb-serverless-neg-a \ --network-endpoint-group-region=REGION_A \ --global
gcloud compute backend-services add-backend gil7-backend-service \ --network-endpoint-group=gl7ilb-serverless-neg-b \ --network-endpoint-group-region=REGION_B \ --global
gcloud compute url-maps create
コマンドを使用して、URL マップを作成します。gcloud compute url-maps create gil7-map \ --default-service=gil7-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_LB_PRIVATE_KEY_FILE
gcloud certificate-manager certificates create
コマンドを使用して、すべてのリージョン SSL 証明書を作成します。gcloud certificate-manager certificates create gilb-certificate \ --private-key-file=$LB_PRIVATE_KEY \ --certificate-file=$LB_CERT \ –-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
2 つの転送ルールを作成します。1 つは
REGION_B
リージョンの VIP(10.1.2.99
)、もう 1 つはREGION_A
リージョンの VIP(10.1.3.99
)です。カスタム ネットワークでは、転送ルールでサブネットを参照する必要があります。これは、プロキシ サブネットではなく、仮想マシン(VM)インスタンスのサブネットです。
HTTP の場合:
適切なフラグを設定して
gcloud compute forwarding-rules create
コマンドを実行します。gcloud compute forwarding-rules create gil7-forwarding-rule-a \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=NETWORK \ --subnet=SUBNET_B \ --subnet-region=REGION_B \ --address=10.1.3.99 \ --ports=80 \ --target-http-proxy=gil7-http-proxy \ --global
gcloud compute forwarding-rules create gil7-forwarding-rule-b \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=NETWORK \ --subnet=SUBNET_A \ --subnet-region=REGION_A \ --address=10.1.2.99 \ --ports=80 \ --target-http-proxy=gil7-http-proxy \ --global
HTTPS の場合:
適切なフラグを設定して
gcloud compute forwarding-rules create
コマンドを実行し、転送ルールを作成します。gcloud compute forwarding-rules create gil7-forwarding-rule-a \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=NETWORK \ --subnet=SUBNET_B \ --address=10.1.3.99 \ --ports=443 \ --target-https-proxy=gil7-https-proxy \ --global
gcloud compute forwarding-rules create gil7-forwarding-rule-b \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=NETWORK \ --subnet=SUBNET_A \ --address=10.1.2.99 \ --ports=443 \ --target-https-proxy=gil7-https-proxy \ --global
API
backendServices.insert
メソッドに POST
リクエストを送り、グローバル バックエンド サービスを作成します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices { "name": "gil7-backend-service", "backends": [ { "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl7ilb_serverless_negwest", "balancingMode": "UTILIZATION" }, { "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl7ilb_serverless_negeast", } ], "loadBalancingScheme": "INTERNAL_MANAGED" }
urlMaps.insert
メソッドに POST
リクエストを送り、URL マップを作成します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps { "name": "l7-ilb-map", "defaultService": "projects/PROJECT_ID/global/backendServices/gil7-backend-service" }
HTTP の場合:
targetHttpProxies.insert
メソッドに POST
リクエストを送り、ターゲット HTTP プロキシを作成します。PROJECT_ID
は、実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpProxy { "name": "l7-ilb-proxy", "urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map" }
globalforwardingRules.insert
メソッドに POST
リクエストを送り、転送ルールを作成します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules { "name": "gil7-forwarding-rule-a", "IPAddress": "10.1.2.99", "IPProtocol": "TCP", "portRange": "80-80", "target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy", "loadBalancingScheme": "INTERNAL_MANAGED", "subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A", "network": "projects/PROJECT_ID/global/networks/NETWORK", "networkTier": "PREMIUM" }
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules { "name": "gil7-forwarding-rule-b", "IPAddress": "10.1.3.99", "IPProtocol": "TCP", "portRange": "80-80", "target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy", "loadBalancingScheme": "INTERNAL_MANAGED", "subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B", "network": "projects/PROJECT_ID/global/networks/NETWORK", "networkTier": "PREMIUM" }
HTTPS の場合:
証明書と秘密鍵ファイルを読み取り、SSL 証明書を作成します。次の例では、Python でこの処理を行います。
targetHttpsProxies.insert
メソッドに POST
リクエストを送り、ターゲット HTTPS プロキシを作成します。PROJECT_ID
は、実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpsProxy { "name": "l7-ilb-proxy", "urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map", "sslCertificates": /projects/PROJECT_ID/global/sslCertificates/SSL_CERT_NAME }
globalForwardingRules.insert
メソッドに POST
リクエストを送り、転送ルールを作成します。PROJECT_ID
は実際のプロジェクト ID に置き換えます。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules { "name": "gil7-forwarding-rule-a", "IPAddress": "10.1.2.99", "IPProtocol": "TCP", "portRange": "80-80", "target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy", "loadBalancingScheme": "INTERNAL_MANAGED", "subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A", "network": "projects/PROJECT_ID/global/networks/NETWORK", "networkTier": "PREMIUM" }
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules { "name": "gil7-forwarding-rule-b", "IPAddress": "10.1.3.99", "IPProtocol": "TCP", "portRange": "80-80", "target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy", "loadBalancingScheme": "INTERNAL_MANAGED", "subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B", "network": "projects/PROJECT_ID/global/networks/NETWORK", "networkTier": "PREMIUM" }
ロードバランサをテストする
ロード バランシング サービスが稼働中になったので、転送ルールへトラフィックを送信できます。また、各インスタンスに分散されるトラフィックを監視できます。
ファイアウォール ルールを構成する
この例では、テスト クライアント VM に fw-allow-ssh
ファイアウォール ルールが必要です。fw-allow-ssh
は、テスト クライアント VM に適用される上り(内向き)ルールであり、任意のアドレスから TCP ポート 22
への SSH 接続の受信を許可します。このルールには、送信元の IP アドレス範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP アドレス範囲を指定できます。この例では、ターゲットタグ allow-ssh
を使用しています。
gcloud
ネットワーク タグ
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
VM インスタンスを作成して接続をテストする
クライアント VM を作成します。
gcloud compute instances create l7-ilb-client-a \ --image-family=debian-10 \ --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-10 \ --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 の名前が返されます。
curl 10.1.2.99
curl 10.1.3.99
HTTPS テストの場合、
curl
は次のもので置き換えます。curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443
curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443
-k
フラグを指定すると、curl は証明書の検証をスキップします。省略可: 構成済みの DNS レコードを使用して IP アドレスを解決します。
curl service.example.com
100 個のリクエストを実行してロードバランスされていることを確認する
HTTP の場合:
{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl --silent 10.1.2.99)" done echo "" echo " Results of load-balancing to 10.1.2.99: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl --silent 10.1.3.99)" done echo "" echo " Results of load-balancing to 10.1.3.99: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
HTTPS の場合:
{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)" done echo "" echo " Results of load-balancing to 10.1.2.99: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)" done echo "" echo " Results of load-balancing to 10.1.3.99: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
フェイルオーバーをテストする
REGION_B
リージョンのバックエンドが異常な状態またはアクセス不能になった場合は、REGION_A
リージョンのバックエンドへのフェイルオーバーを確認します。REGION_B
からすべてのバックエンドを削除してシミュレーションを行います。gcloud compute backend-services remove-backend gil7-backend-service \ --network-endpoint-group=gl7ilb-serverless-neg-b \ --network-endpoint-group-zone=ZONE_B
SSH を使用して
REGION_B
のクライアント VM に接続します。gcloud compute ssh l7-ilb-client-b \ --zone=ZONE_B
REGION_B
リージョンでロードバランスされた IP アドレスにリクエストを送信します。コマンド出力に、REGION_A
のバックエンド VM からのレスポンスが表示されます。{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)" done echo "***" echo "*** Results of load-balancing to 10.1.3.99: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
追加の構成オプション
このセクションでは、代替および追加の構成オプションを提供する構成例を示します。これらのタスクはすべて省略可です。また、任意の順序で行うことができます。
URL マスクを使用する
サーバーレス NEG を作成する際に、特定の Cloud Run サービスを選択するのではなく、URL マスクを使用して、同じドメインでリクエストを処理する複数のサービスを指定できます。URL マスクは、URL スキーマのテンプレートです。サーバーレス NEG はこのテンプレートを使用して、受信リクエストの URL からサービス名を抽出し、そのリクエストを適切なサービスにマッピングします。
URL マスクが特に役立つのは、サービスが Google Cloud からデプロイ済みサービスに割り当てられるデフォルトのアドレスではなく、カスタム ドメインにマッピングされている場合です。URL マスクを使用すると、アプリケーションでカスタム URL パターンを使用していても、1 つのルールで複数のサービスとバージョンをターゲットにできます。
サーバーレス NEG の概要: URL マスクをまだ読んでいない場合は、必ずお読みください。
URL マスクを作成する
ロードバランサの URL マスクを作成するには、まず、サービスの URL から取り掛かります。この例では、https://example.com/login
で実行されているサーバーレス アプリのサンプルを使用します。この URL で、アプリの login
サービスが提供されることになります。
- URL から
http
またはhttps
を削除します。これで、example.com/login
だけが残ります。 - サービス名を URL マスクのプレースホルダに置き換えます。
- Cloud Run: Cloud Run サービス名をプレースホルダ
<service>
に置き換えます。Cloud Run サービスにタグが関連付けられている場合は、そのタグ名をプレースホルダ<tag>
に置き換えます。この例では、URL マスクがexample.com/<service>
になります。
- Cloud Run: Cloud Run サービス名をプレースホルダ
省略可: URL のパスの部分からサービス名を抽出できる場合は、ドメインを省略できます。URL マスクのパスの部分は、最初のスラッシュ(
/
)文字で区別されます。スラッシュ(/
)が URL マスクに存在しない場合、マスクはホストのみを表していると見なされます。したがって、この例では URL マスクを/<service>
に短縮できます。同様に、URL のホストの部分から
<service>
を抽出できる場合は、URL マスクからパスを完全に省略できます。最初のプレースホルダの前にあるホストまたはサブドメインの部分と、最後のプレースホルダの後にあるパスの部分も省略できます。このような場合、プレースホルダにその部分に必要な情報が取り込まれます。
以下に、これらのルールを説明する例をいくつか示します。
この表では、example.com
という名前のカスタム ドメインがあり、すべての Cloud Run サービスがこのドメインにマッピングされていることを前提としています。
サービス、タグ名 | Cloud Run のカスタム ドメイン URL | URL マスク |
---|---|---|
サービス: login | https://login-home.example.com/web | <service>-home.example.com |
サービス: login | https://example.com/login/web | example.com/<service> or /<service> |
サービス: login、タグ: test | https://test.login.example.com/web | <tag>.<service>.example.com |
サービス: login、タグ: test | https://example.com/home/login/test | example.com/home/<service>/<tag> または /home/<service>/<tag> |
サービス: login、タグ: test | https://test.example.com/home/login/web | <tag>.example.com/home/<service> |
URL マスクを使用してサーバーレス NEG を作成する
コンソール
新しいロードバランサの場合、このドキュメントで説明したものと同じエンドツーエンドのプロセスを使用できます。バックエンド サービスを構成する場合は、特定のサービスを選択する代わりに、URL マスクを入力します。
既存のロードバランサがある場合は、バックエンド構成を編集し、サーバーレス NEG に特定のサービスの代わりに URL マスクを指定できます。
URL マスクベースのサーバーレス NEG を既存のバックエンド サービスに追加するには、次の操作を行います。
- Google Cloud コンソールで、[ロード バランシング] ページに移動します。
[ロード バランシング] に移動 - 編集するバックエンド サービスがあるロードバランサの名前をクリックします。
- [ロードバランサの詳細] ページで、[ 編集] をクリックします。
- [Edit global external Application Load Balancer] ページで、[バックエンドの構成] をクリックします。
- [バックエンドの構成] ページで、変更するバックエンド サービスの [ 編集] をクリックします。
- [バックエンドを追加] をクリックします。
- [サーバーレス ネットワーク エンドポイント グループの作成] を選択します。
- [名前] に「
helloworld-serverless-neg
」と入力します。 - [リージョン] に、ロードバランサのリージョンが表示されます。
- [サーバーレス ネットワーク エンドポイント グループの種類] で、サポートされているネットワーク エンドポイント グループの種類は Cloud Run のみです。
- [URL マスクを使用] を選択します。
- URL マスクを入力します。URL マスクの作成方法については、URL マスクの作成をご覧ください。
- [作成] をクリックします。
- [新しいバックエンド] で、[完了] をクリックします。
- [更新] をクリックします。
gcloud
example.com/<service>
のサンプル URL マスクを使用してサーバーレス NEG を作成するには:
gcloud compute network-endpoint-groups create SERVERLESS_NEG_MASK_NAME \ --region=REGION \ --network-endpoint-type=serverless \ --cloud-run-url-mask="example.com/<service>"
複数の内部転送ルールで同じ IP アドレスを使用する
複数の内部転送ルールで同じ内部 IP アドレスを共有するには、IP アドレスを予約して --purpose
フラグを SHARED_LOADBALANCER_VIP
に設定する必要があります。
gcloud
gcloud compute addresses create SHARED_IP_ADDRESS_NAME \ --region=REGION \ --subnet=SUBNET_NAME \ --purpose=SHARED_LOADBALANCER_VIP
DNS ルーティング ポリシーを構成する
クライアントが複数のリージョンにある場合は、これらのリージョンの VIP を使用して、クロスリージョン内部アプリケーション ロードバランサにアクセスできるようにすることをおすすめします。このマルチリージョンを設定することで、レイテンシとネットワーク転送の費用を最小限に抑えることができます。さらに、リージョンの停止に対する耐障害性を確保するため、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" } ] } } ] } } }
外れ値検出を有効にする
グローバル バックエンド サービスで外れ値検出を有効にすると、正常でないサーバーレス 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
: オブジェクトの IDREGION_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
バックエンド サービスで外れ値検出が有効になりました。
サーバーレス NEG の削除
バックエンド サービスに接続しているネットワーク エンドポイント グループは削除できません。NEG を削除する前に、NEG がバックエンド サービスから接続解除されていることを確認してください。
コンソール
- 削除するサーバーレス NEG がバックエンド サービスによって使用されていないことを確認するには、[ロード バランシングのコンポーネント] ページの [バックエンド サービス] タブに移動します。
[バックエンド サービス] に移動 - サーバーレス NEG が使用中の場合は、次の操作を行います。
- サーバーレス NEG を使用しているバックエンド サービスの名前をクリックします。
- [ 編集] をクリックします。
- [バックエンド] のリストで をクリックし、バックエンド サービスからサーバーレス NEG バックエンドを削除します。
- [保存] をクリックします。
- Google Cloud コンソールの [ネットワーク エンドポイント グループ] ページに移動します。
[ネットワーク エンドポイント グループ] に移動 - 削除するサーバーレス NEG のチェックボックスをオンにします。
- [削除] をクリックします。
- もう一度 [削除] をクリックして確定します。
gcloud
バックエンド サービスからサーバーレス NEG を削除するには、NEG が作成されたリージョンを指定する必要があります。
gcloud compute backend-services remove-backend BACKEND_SERVICE_NAME \ --network-endpoint-group=SERVERLESS_NEG_NAME \ --network-endpoint-group-region=REGION \ --region=REGION
サーバーレス NEG を削除するには:
gcloud compute network-endpoint-groups delete SERVERLESS_NEG_NAME \ --region=REGION
次のステップ
- Terraform を使用して Cloud Run で内部アプリケーション ロードバランサをデプロイする
- ロード バランシングの設定をクリーンアップする
- 共有 VPC のプロビジョニングを解除する
- 内部アプリケーション ロードバランサのロギングとモニタリング
- 内部アプリケーション ロードバランサに関する問題のトラブルシューティング