サーバーレス NEG の設定

ネットワーク エンドポイント グループ(NEG)は、ロードバランサのバックエンド エンドポイントのグループを指定します。サーバーレス NEG は、Cloud RunApp Engine、または Cloud Functions サービスを指すバックエンドです。

サーバーレス NEG は次のいずれかに相当します。

  • Cloud Run サービス、または同じ URL パターンを共有する複数のサービス。
  • Cloud Functions の関数、または同じ URL パターンを共有する関数のグループ。
  • App Engine アプリ(スタンダードまたはフレキシブル)、アプリ内の特定のサービス、またはアプリの特定のバージョン。

このページでは、リクエストをサーバーレス バックエンドにルーティングする外部 HTTP(S) ロードバランサの作成方法を説明します。ここでのサーバーレスという用語は、サーバーレス コンピューティング プロダクトである App Engine、Cloud Functions、Cloud Run(フルマネージド)を意味します。

サーバーレス NEG を使用すると、外部 HTTP(S) 負荷分散を適用した Google Cloud サーバーレス アプリを使用できます。サーバーレス NEG バックエンドを使用してロードバランサを構成した後は、そのロードバランサへのリクエストがサーバーレス アプリのバックエンドにルーティングされるようになります。

始める前に

始める前に、次のことを行います。

  1. サーバーレス NEG の概要を読む。
  2. App Engine、Cloud Functions、または Cloud Run(フルマネージド)サービスをデプロイする
  3. Google Cloud SDK をインストールする
  4. 権限を構成する
  5. SSL 証明書リソースを追加する

App Engine、Cloud Functions、または Cloud Run(フルマネージド)サービスをデプロイする

このページで説明する手順では、Cloud Run(フルマネージド)、Cloud Functions、または App Engine サービスがすでに実行中であることを前提としています。

このページの例では、Cloud Run(フルマネージド)Python クイックスタートを使用して helloworld サービスを us-central1 リージョンにデプロイしています。このページの残りの部分では、サーバーレス NEG バックエンドを使用してリクエストを helloworld サービスにルーティングする外部 HTTP(S) ロードバランサを設定する方法を説明します。

サーバーレス アプリをまだデプロイしていない場合、またはサンプルアプリでサーバーレス NEG を試す場合は、以下のいずれかのクイックスタートを使用してください。サーバーレス アプリはどのリージョンでも作成できますが、後でサーバーレス NEG とロードバランサを作成する際は、サーバーレス アプリと同じリージョンで作成する必要があります。

Cloud Run(フルマネージド)

シンプルな Hello World アプリケーションを作成してコンテナ イメージにパッケージ化し、そのコンテナ イメージを Cloud Run(フルマネージド)にデプロイする場合は、クイックスタート: ビルドとデプロイをご覧ください。

サンプル コンテナをすでに Container Registry にアップロードしている場合は、クイックスタート: 事前にビルドされたサンプル コンテナをデプロイするをご覧ください。

Cloud Functions

Cloud Functions: Python クイックスタートをご覧ください。

App Engine

次の Python 3 向け App Engine クイックスタート ガイドをご覧ください。

Google Cloud SDK をインストールする

gcloud コマンドライン ツールをインストールします。このツールのコンセプトとインストールについては、gcloud の概要をご覧ください。

これまで gcloud コマンドライン ツールを実行したことがない場合は、gcloud init を実行して gcloud ディレクトリを初期化します。

これは、Google Cloud Console でサーバーレス NEG を作成できないためです。

権限を構成する

このガイドに沿って作業を進めるには、プロジェクト内でサーバーレス NEG と外部 HTTP(S) ロードバランサを作成する必要があります。それにはプロジェクトのオーナーまたは編集者であるか、次の Compute Engine IAM のロールが必要です。

タスク 必要なロール
ロードバランサとネットワーク コンポーネントの作成 ネットワーク管理者
NEG の作成と変更 Compute インスタンス管理者
SSL 証明書の作成と変更 セキュリティ管理者

SSL 証明書リソースを作成する

HTTPS ロードバランサを作成する場合は、ロードバランサのフロントエンドに SSL 証明書リソースを追加する必要があります。SSL 証明書リソースは、セルフマネージド SSL 証明書または Google マネージド SSL 証明書を使用して作成します。このうち、Google Cloud が自動的に取得、管理、更新する Google マネージド証明書をおすすめします。

この例では、SSL 証明書リソースがすでに作成されていることを前提としています。

外部 IP アドレスの予約

この段階でサービスは実行中なので、顧客がロードバランサにアクセスするために使用するグローバル静的外部 IP アドレスを設定します。

Console

  1. Google Cloud Console で外部 IP アドレスのページに移動します。
    [外部 IP アドレス] ページに移動
  2. [静的アドレスを予約] をクリックして、IPv4 アドレスを予約します。
  3. example-ip の [名前] を割り当てます。
  4. ネットワーク階層を [プレミアム] に設定します。
  5. [IP バージョン] を IPv4 に設定します。
  6. [タイプ] で [グローバル] をオンにします。
  7. [予約] をクリックします。

gcloud

gcloud compute addresses create example-ip \
    --ip-version=IPV4 \
    --global

予約されている IPv4 アドレスをメモします。

gcloud compute addresses describe example-ip \
    --format="get(address)" \
    --global

外部 HTTP(S) ロードバランサの作成

次の図では、ロードバランサがサーバーレス NEG バックエンドを使用して、リクエストをサーバーレス Cloud Run(フルマネージド)サービスに転送します。この例では、Cloud Run(フルマネージド)Python クイックスタートを使用して helloworld-python サービスをデプロイしています。

シンプルな HTTPS 負荷分散(クリックして拡大)
Cloud Run アプリの HTTPS 負荷分散

サーバーレス NEG バックエンドを使用するバックエンド サービスではヘルスチェックがサポートされません。したがって、ロードバランサでサーバーレス NEG バックエンドのみを使用する場合、ヘルスチェックを許可するファイアウォール ルールを作成する必要はありません。

gcloud

  1. Cloud Run(フルマネージド)サービス用のサーバーレス NEG を作成します。この例では、helloworld という Cloud Run(フルマネージド)サービスがデプロイ済みであることを前提としています。
    gcloud beta compute network-endpoint-groups create helloworld-serverless-neg \
        --region=us-central1 \
        --network-endpoint-type=serverless  \
        --cloud-run-service=helloworld
    
    App Engine サービス用または Cloud Functions の関数用の NEG を作成するには、gcloud beta compute network-endpoint-groups create に関する gcloud リファレンス ガイドをご覧ください。
  2. バックエンド サービスを作成し、そのバックエンド サービスにバックエンドとしてサーバーレス NEG を追加します。
    gcloud compute backend-services create helloworld-backend-service \
        --global
    
    gcloud beta compute backend-services add-backend helloworld-backend-service \
        --global \
        --network-endpoint-group=helloworld-serverless-neg \
        --network-endpoint-group-region=us-central1
    
  3. 受信リクエストを helloworld-backend-service バックエンド サービスにルーティングするための URL マップを作成します。
    gcloud compute url-maps create helloworld-url-map \
        --default-service helloworld-backend-service
    
    この URL マップの例では、1 つの Cloud Run(フルマネージド)サービスを表す 1 つのバックエンド サービスのみを対象としているため、ホストルールやパスマッチャーを設定する必要はありません。複数のバックエンド サービスを対象とする場合、ホスト名に基づいてリクエストを特定のサービスに転送するにはホストルールを使用します。また、パスマッチャーを設定すると、リクエストパスに基づいてリクエストを特定のサービスに転送できます。
  4. HTTPS ロードバランサを作成する場合は、HTTPS プロキシで使用する SSL 証明書リソースが必要です。SSL 証明書リソースは、セルフマネージド SSL 証明書または Google マネージド SSL 証明書を使用して作成できます。このうち、Google Cloud が自動的に取得、管理、更新する Google マネージド証明書をおすすめします。Google マネージド証明書を作成するには、ドメインが必要です。ドメインがない場合は、自己署名 SSL 証明書を使用してテストできます。www-ssl-cert という名前のセルフマネージド SSL 証明書リソースを作成するには、次のコマンドを実行します。
    gcloud compute ssl-certificates create www-ssl-cert \
        --certificate [CRT_FILE_PATH] \
        --private-key [KEY_FILE_PATH]
    
    www-ssl-cert という名前の Google マネージド SSL 証明書リソースを作成するには、次のコマンドを実行します。
    gcloud compute ssl-certificates create www-ssl-cert \
        --domains [DOMAIN]
    
  5. URL マップに従ってリクエストをルーティングするターゲット HTTPS プロキシを作成します。プロキシはロードバランサの一部であり、HTTPS 負荷分散用の SSL 証明書を保持するため、この手順で証明書も読み込みます。
    gcloud compute target-https-proxies create helloworld-https-proxy \
        --ssl-certificates=www-ssl-cert \
        --url-map=helloworld-url-map
    
  6. 受信リクエストをプロキシにルーティングするグローバル転送ルールを作成します。
    gcloud compute forwarding-rules create https-content-rule \
        --address=example-ip \
        --target-https-proxy=helloworld-https-proxy \
        --global \
        --ports=443
    

外部 HTTP(S) ロードバランサのテスト

ロードバランサを構成したので、ロードバランサの IP アドレスにトラフィックを送信できるようになりました。

Console

  1. Google Cloud Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. ウェブブラウザを使用してロードバランサをテストするには、https://ip-address にアクセスします。ip-address は、ロードバランサの IP アドレスです。helloworld サービスのホームページが表示されることを確認します。

gcloud / curl の使用

curl コマンドを使用して、URL からのレスポンスをテストします。ip-address は、ロードバランサの IPv4 アドレスに置き換えます。helloworld サービスのホームページが表示されます。

curl https://ip-address

追加の構成オプション

このセクションでは、代替および追加の構成オプションを提供する構成例を示します。これらのタスクはすべて省略可です。また、任意の順序で行うことができます。

マルチリージョン負荷分散を設定する

上記の例では、バックエンドとして機能する Cloud Run(フルマネージド)サービスが 1 つのみでした。サーバーレス NEG で同時に参照できるエンドポイントは 1 つだけなので、負荷分散は実際には行われません。外部 HTTP(S) ロードバランサはフロントエンドとしてのみ機能し、指定された helloworld アプリのエンドポイントにトラフィックをプロキシします。一方、サービスの可用性を高めると同時に、ユーザーに対するレイテンシを短縮するために、複数のリージョンから Cloud Run(フルマネージド)アプリを提供しなければならない場合もあります。

バックエンド サービスに複数の NEG が含まれている場合、ロードバランサはトラフィックを負荷分散するために、リクエストを最も近くの使用可能なリージョン内のサーバーレス NEG に転送します。ただし、バックエンド サービスに含めることができるサーバーレス NEG はリージョンごとに 1 つのみです。Cloud Run(フルマネージド)サービスを複数のリージョンで利用可能にするには、クロスリージョン ルーティングを設定する必要があります。世界中どこでも機能しながらも、ユーザーに最も近いリージョンからユーザー リクエストを処理する単一の URL スキームを使用できなければなりません。最も近いリージョンが利用できないか、そのリージョンの容量が不足している場合、リクエストは別のリージョンにルーティングされます。

マルチリージョンで処理するように設定するには、すべてのリージョン Cloud Run(フルマネージド)デプロイメントの互換性を確保し、どのリージョンからでもトラフィックを処理できるようにするために、プレミアム ネットワーク階層を使用する必要があります。

マルチリージョン ロードバランサを設定するには:

  1. 2 つの Cloud Run(フルマネージド)サービスをそれぞれ異なるリージョンに設定します。ここでは、2 つの Cloud Run(フルマネージド)サービスの一方をヨーロッパ内のリージョンにデプロイし、もう一方を米国内のリージョンにデプロイしたとします。
  2. 次の設定を使用して外部 HTTP(S) ロードバランサを作成します。
    1. 2 つのサーバーレス NEG を使用してグローバル バックエンド サービスを設定します。
      1. ヨーロッパ内にデプロイされた Cloud Run サービスと同じリージョンに最初の NEG を作成します。
      2. 米国内にデプロイされた Cloud Run サービスと同じリージョンに 2 つ目の NEG を作成します。
    2. プレミアム ネットワーク階層を使用してフロントエンド構成を設定します。

残りの設定は、上記と同じです。最終的な設定は次のようになります。

サーバーレス アプリへのトラフィックの分散(クリックして拡大)
サーバーレス アプリのマルチリージョン ルーティング(フェイルオーバー対応)

リージョン ルーティングを設定する

複数のリージョンからアプリケーションを提供する一般的な理由は、データの局所性に関する要件に対処するためです。たとえば、ヨーロッパのユーザーが送信したリクエストは常にヨーロッパ内に位置するリージョンで処理されるようにするとします。このように設定するには、ヨーロッパのユーザー用とヨーロッパ以外のユーザー用にそれぞれ個別の URL を使用した URL スキームを使用して、ヨーロッパのユーザーをヨーロッパの URL に転送する必要があります。

このようなシナリオでは、URL マップを使用して、特定の URL からのリクエストを対応するリージョンにルーティングします。こうした設定では、あるリージョンを対象とするリクエストが別のリージョンに配信されることは決してありません。したがって、リージョン間での分離が実現されます。一方、リージョンで障害が発生しても、リクエストは別のリージョンにルーティングされません。そのため、この設定によってサービスの可用性が向上することはありません。

リージョン ルーティングを設定するには、1 つの転送ルールで異なる複数のリージョンを組み合わせられるようにするために、プレミアム ネットワーク階層を使用する必要があります。

リージョン ルーティングを使用してロードバランサを設定するには:

  1. 2 つの Cloud Run(フルマネージド)サービスをそれぞれ異なるリージョンに設定します。2 つの Cloud Run(フルマネージド)サービスのうち、hello-world-eu をヨーロッパ内のリージョンにデプロイし、hello-world-us を米国内のリージョンにデプロイしたとします。
  2. 次の設定を使用して外部 HTTP(S) ロードバランサを作成します。
    1. ヨーロッパ内に、サーバーレス NEG を使用してバックエンド サービスを設定します。このサーバーレス NEG は、ヨーロッパ内にデプロイされた Cloud Run(フルマネージド)サービスと同じリージョンに作成する必要があります。
    2. 米国内に、別のサーバーレス NEG を使用して 2 つ目のバックエンド サービスを設定します。このサーバーレス NEG は、米国内にデプロイされた Cloud Run サービスと同じリージョンに作成する必要があります。
    3. 1 つの URL セットはヨーロッパ内のバックエンド サービスにルーティングされ、残りすべてのリクエストは米国内のバックエンド サービスにルーティングされるように、適切なホストとパスルールを使用して URL マップを設定します。
    4. プレミアム ネットワーク階層を使用してフロントエンド構成を設定します。

残りの設定は、上記と同じです。最終的な設定は次のようになります。

サーバーレス アプリへのトラフィックの分散(クリックして拡大)
サーバーレス アプリのリージョン ルーティング(フェイルオーバーなし)

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 サービスが提供されることになります。

  1. URL から http または https を削除します。これで、example.com/login だけが残ります。
  2. サービス名を URL マスクのプレースホルダに置き換えます。
    1. Cloud Run(フルマネージド): Cloud Run(フルマネージド)サービス名をプレースホルダ <service> に置き換えます。Cloud Run(フルマネージド)サービスにタグが関連付けられている場合は、そのタグ名をプレースホルダ <tag> に置き換えます。この例では、これで URL マスクが example.com/<service> になります。
    2. Cloud Functions: ファンクション名をプレースホルダ <function> に置き換えます。この例では、これで URL マスクが <function>.example.com になります。
    3. App Engine: サービス名をプレースホルダ <service> に置き換えます。サービスにバージョンが関連付けられている場合は、そのバージョンをプレースホルダ <version> に置き換えます。この例では、これで URL マスクが example.com/<service> になります。
  3. (省略可)URL のパスの部分からサービス名(またはファンクション、バージョン、タグ)を抽出できる場合は、ドメインを省略できます。URL マスクのパスの部分は、最初の / 文字で区別されます。/ が URL マスクに存在しない場合、マスクはホストのみを表していると見なされます。したがって、この例では URL マスクを /<service> または /<function> に短縮できます。

    同様に、URL のホストの部分からサービス名を抽出できる場合は、URL マスクからパスを完全に省略できます。

    最初のプレースホルダの前にあるホストまたはサブドメインの部分と、最後のプレースホルダの後にあるパスの部分も省略できます。このような場合、プレースホルダにその部分に必要な情報が取り込まれます。

以下に、これらのルールを説明する例をいくつか示します。

Cloud Run

この表では、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>

Cloud Functions

この表では、example.com という名前のカスタム ドメインがあり、すべての Cloud Functions サービスがこのドメインにマッピングされていることを前提としています。

ファンクション名 Cloud Functions のカスタム ドメイン URL URL マスク
login https://example.com/login /<function>
login https://example.com/home/login /home/<function>
login https://login.example.com <function>.example.com
login https://login.home.example.com <function>.home.example.com

App Engine

この表では、example.com という名前のカスタム ドメインがあり、すべての App Engine サービスがこのドメインにマッピングされていることを前提としています。

サービス名、バージョン App Engine のカスタム ドメイン URL URL マスク
サービス: login https://login.example.com/web <service>.example.com
サービス: login https://example.com/home/login/web example.com/home/<service> または /home/<service>
サービス: login、バージョン: test https://test.example.com/login/web <version>.example.com/<service>
サービス: login、バージョン: test https://example.com/login/test example.com/<service>/<version>

URL マスクを使用してサーバーレス NEG を作成する

gcloud: Cloud Run

example.com/<service> のサンプル URL マスクを使用してサーバーレス NEG を作成するには:

gcloud beta compute network-endpoint-groups create helloworld-serverless-neg \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --cloud-run-url-mask=example.com/<service>

gcloud: Cloud Functions

example.com/<function> のサンプル URL マスクを使用してサーバーレス NEG を作成するには:

gcloud beta compute network-endpoint-groups create helloworld-serverless-neg \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --cloud-function-url-mask=example.com/<function>

gcloud: App Engine

example.com/<service> のサンプル URL マスクを使用してサーバーレス NEG を作成するには:

gcloud beta compute network-endpoint-groups create helloworld-serverless-neg \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --app-engine-url-mask=example.com/<service>

ロードバランサが URL マスク不一致の問題に対処する方法については、サーバーレス NEG に関する問題のトラブルシューティングをご覧ください。

外部 HTTP(S) ロードバランサで処理されるカスタム ドメインを移行する

サーバーレス コンピューティング アプリがカスタム ドメインにマッピングされている場合、既存の Cloud Run(フルマネージド)、Cloud Functions、または App EngineIf のカスタム ドメイン URL に送信されたトラフィックが代わりにロードバランサによってルーティングされるように、DNS レコードを更新しなければならない場合があります。

たとえば、example.com という名前のカスタム ドメインがあり、すべての Cloud Run サービスがこのドメインにマッピングされている場合は、ロードバランサの IP アドレスを指すように example.com の DNS レコードを更新します。

DNS レコードを更新する前に、カスタム ドメインのローカル DNS での解決をロードバランサの IP アドレスにすることで、ローカルで構成をテストできます。ローカルでテストするには、example.com がロードバランサの IP アドレスを指すように、ローカルマシン上の /etc/hosts/ ファイルを変更するか、curl --resolve フラグを使用して、curl がリクエストにロードバランサの IP アドレスを使用するように強制します。

example.com の DNS レコードが HTTP(S) ロードバランサの IP アドレスに解決されると、example.com に送信されたリクエストがロードバランサ経由でルーティングされるようになります。ロードバランサは、その URL マップに従ってリクエストを該当するバックエンド サービスにディスパッチします。さらに、URL マスクを使用してバックエンド サービスが構成されている場合、サーバーレス NEG はそのマスクを使用してリクエストを適切な Cloud Run(フルマネージド)、Cloud Functions、または App Engine サービスにルーティングします。

Cloud CDN を有効にする

Cloud Run(フルマネージド)サービスに対して Cloud CDN を有効にすると、ユーザーの近くにコンテンツがキャッシングされるため、コンテンツ配信を最適化できます。

外部 HTTP(S) ロードバランサのバックエンド サービスで Cloud CDN を有効にするには、gcloud compute backend-services update コマンドを使用します。

  gcloud compute backend-services update helloworld-backend-service \
    --enable-cdn \
    --global

Cloud CDN は、Cloud Run(フルマネージド)、Cloud Functions、および App Engine バックエンドを使用するバックエンド サービスでサポートされます。

Google Cloud Armor を有効にする

Google Cloud Armor は、分散型サービス拒否(DDoS)攻撃からすべての GCLB プロキシ ロードバランサを保護するセキュリティ プロダクトです。Google Cloud Armor は、外部 HTTP(S) ロードバランサを介してアクセスされるサービスで構成可能なセキュリティ ポリシーも提供します。HTTP(S) 負荷分散用の Google Cloud Armor セキュリティ ポリシーについては、Google Cloud Armor セキュリティ ポリシーの概要をご覧ください。

Google Cloud Armor は Cloud Run(フルマネージド)、Cloud Functions、および App Engine バックエンドを使用するバックエンド サービスを対象に構成できますが、この機能には特に Cloud Run(フルマネージド)と App Engine に関連する制限事項がいくつかあります。Google Cloud が割り当てたデフォルトのサービス URL にアクセスできるユーザーは、ロードバランサをバイパスして、構成された Google Cloud Armor セキュリティ ポリシーを回避し、直接それらのサービス URL にアクセスできます。

Cloud Functions を使用している場合、internal-and-gclb Ingress 設定を使用すれば、Cloud Functions で設定されたデフォルトの cloudfunctions.net URL またはその他のカスタム ドメインに送信されるリクエストをブロックできます。

サーバーレス NEG を削除する

バックエンド サービスに接続しているネットワーク エンドポイント グループは削除できません。NEG を削除する前に、NEG がバックエンド サービスから接続解除されていることを確認してください。

バックエンド サービスからサーバーレス NEG を削除するには、NEG が作成されたリージョンを指定する必要があります。helloworld-backend-service はグローバル リソースであるため、--global フラグも指定する必要があります。

gcloud beta compute backend-services remove-backend helloworld-backend-service \
    --network-endpoint-group=helloworld-serverless-neg \
    --network-endpoint-group-region=us-central1 \
    --global

サーバーレス NEG を削除するには:

gcloud beta compute network-endpoint-groups delete helloworld-serverless-neg \
    --region=us-central1

バックエンド サービスへのトラフィック送信を停止する

バックエンド サービスからすべてのサーバーレス NEG を削除しても、ユーザーへの 502 Bad Gateway レスポンスは自動的に生成されません。これは既知の問題です。すべてのサーバーレス NEG バックエンドがバックエンド サービスから削除された後も、ユーザーにはリクエストに対する HTTP 200 OK レスポンスが継続して表示されます。この動作を変更する場合:

  1. バックエンドがゼロの、新しいバックエンド サービスを作成します。
  2. ロードバランサの URL マップを更新して、すべてのリクエストに対しデフォルトでこの新しいバックエンド サービスを使用します。
  3. サーバーレス NEG が接続されていた元のバックエンド サービスを削除します。

これで、ユーザーには想定される HTTP 502 Bad Gateway レスポンス(またはその他のエラー)が表示されるようになります。

次のステップ