Cloud Run、App Engine、または Cloud Run functions を使用してグローバル外部アプリケーション ロードバランサを設定する。

このページでは、リクエストをサーバーレス バックエンドにルーティングする外部アプリケーション ロードバランサを作成する方法を説明します。ここでのサーバーレスという用語は、次のサーバーレス コンピューティング プロダクトを指します。

  • App Engine
  • Cloud Run 関数
  • Cloud Run

外部アプリケーション ロードバランサと API Gateway の統合により、サーバーレス バックエンドは Cloud Load Balancing のすべての機能を活用できるようになります。トラフィックを API Gateway にルーティングするように外部アプリケーション ロードバランサを構成するには、API Gateway の外部アプリケーション ロードバランサ スタートガイドをご覧ください。API Gateway の外部アプリケーション ロードバランサ サポートはプレビュー版です。

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

サーバーレス NEG の詳細については、サーバーレス NEG の概要をご覧ください。

従来のアプリケーション ロードバランサの既存のユーザーで、グローバル外部アプリケーション ロードバランサで新しいデプロイを計画する場合は、移行の概要をご覧ください。

始める前に

  1. App Engine、Cloud Run 関数、または Cloud Run のサービスをデプロイする
  2. まだ行っていない場合は、Google Cloud CLI をインストールする
  3. 権限を構成する
  4. SSL 証明書リソースを追加する

App Engine、Cloud Run 関数、または Cloud Run のサービスをデプロイする

このページで説明する手順では、Cloud Run、Cloud Run 関数、または App Engine のサービスをすでに実行中であることを前提としています。

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

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

Cloud Run

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

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

Cloud Run 関数

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

App Engine

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

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

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

gcloud CLI を実行したことがない場合は、gcloud init を実行して gcloud ディレクトリを初期化します。

権限を構成

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

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

外部 IP アドレスを予約

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

コンソール

  1. Google Cloud コンソールで、[外部 IP アドレス] ページに移動します。

    [外部 IP アドレス] に移動

  2. [静的外部 IP アドレスを予約] をクリックします。

  3. [名前] に「example-ip」と入力します。

  4. [ネットワーク サービス ティア] で [プレミアム] を選択します。

  5. [IP バージョン] で [IPv4] を選択します。

  6. [種類] で [グローバル] を選択します。

  7. [予約] をクリックします。

gcloud

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

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

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

SSL 証明書リソースを作成

HTTPS ロードバランサを作成するには、ロードバランサのフロントエンドに SSL 証明書リソースを追加する必要があります。Google マネージド SSL 証明書またはセルフマネージド SSL 証明書を使用して SSL 証明書リソースを作成します。

  • Google マネージド証明書。このうち、Google Cloud が自動的に取得、管理、更新する Google マネージド証明書をおすすめします。Google マネージド証明書を作成するには、そのドメインをプロビジョニングするためのドメインと DNS レコードが必要です。また、前の手順で作成したロードバランサの IP アドレス(example-ip)を指すようにドメインの DNS A レコードを更新する必要があります。詳しい手順については、Google マネージド証明書をご覧ください。

  • 自己署名証明書。この段階でドメインを設定したくない場合は、テスト用に自己署名 SSL 証明書を使用できます。

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

SSL 証明書リソース(または Google マネージド証明書で必要とされるドメイン)を作成せずにこのプロセスをテストする場合、このページの手順を使用して代わりに HTTP ロードバランサを設定できます。

ロードバランサを作成する

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

Cloud Run アプリケーション用の外部アプリケーション ロードバランサのアーキテクチャ。
Cloud Run アプリケーション用の外部アプリケーション ロードバランサのアーキテクチャ(クリックして拡大)。

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

Console

構成を開始する

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. [ロードバランサを作成] をクリックします。
  3. [ロードバランサの種類] で [アプリケーション ロードバランサ(HTTP / HTTPS)] を選択し、[次へ] をクリックします。
  4. [インターネット接続または内部] で [インターネット接続(外部)] を選択し、[次へ] をクリックします。
  5. [グローバルまたはシングル リージョンのデプロイ] で [グローバル ワークロードに最適] を選択し、[次へ] をクリックします。
  6. [ロードバランサの世代] で [グローバル外部アプリケーション ロードバランサ] を選択し、[次へ] をクリックします。
  7. [構成] をクリックします。

基本構成

  1. ロードバランサの名前に「serverless-lb」と入力します。
  2. ウィンドウを開いたままにして続行します。

フロントエンドの構成

  1. [フロントエンドの構成] をクリックします。
  2. [名前] に名前を入力します。
  3. HTTPS ロードバランサを作成するには、SSL 証明書gcloud compute ssl-certificates list)が必要です。

    前述のように、Google マネージド証明書を使用することをおすすめします。

  4. 外部アプリケーション ロードバランサを構成するには、各フィールドを次のように指定します。

    以下のオプションが次の値で構成されていることを確認します。

    プロパティ 値(値を入力するか、指定されたオプションを選択)
    プロトコル HTTPS
    ネットワーク サービス階層 プレミアム
    IP バージョン IPv4
    IP アドレス example-ip
    ポート 443
    省略可: HTTP キープアライブ タイムアウト 5~1,200 秒のタイムアウト値を入力します。デフォルト値は 610 秒です。
    証明書 既存の SSL 証明書を選択するか、新しい証明書を作成します。

    HTTPS ロードバランサを作成するには、HTTPS プロキシで使用する SSL 証明書リソースが必要です。SSL 証明書リソースは、Google マネージド SSL 証明書またはセルフマネージド SSL 証明書を使用して作成できます。
    Google マネージド証明書を作成するには、ドメインが必要です。ドメインの A レコードは、ロードバランサの IP アドレス(この例では example-ip)に解決される必要があります。Google Cloud マネージド証明書を使用することをおすすめします。これらの証明書は Google Cloud で自動的に取得、管理、更新されます。ドメインがない場合は、自己署名 SSL 証明書を使用してテストできます。
    省略可: HTTP から HTTPS へのリダイレクトを有効にする このチェックボックスを使用して、HTTP から HTTPS へのリダイレクトを有効にします。

    このチェックボックスをオンにすると、HTTPS ロードバランサと同じ IP アドレスを使用し、HTTP リクエストをロードバランサの HTTPS フロントエンドにリダイレクトする追加の部分的な HTTP ロードバランサが作成されます。

    このチェックボックスは、HTTPS プロトコルが選択されていて、予約済みの IP アドレスが使用されている場合にのみ選択できます。

    SSL 証明書リソース(または Google マネージド証明書によって必要とされるドメイン)を設定せずにこのプロセスをテストする場合は、HTTP ロードバランサを設定できます。

    HTTP ロードバランサを作成するには、次のオプションがこれらの値で構成されていることを確認します。

    プロパティ 値(値を入力するか、指定されたオプションを選択)
    プロトコル HTTP
    ネットワーク サービス階層 プレミアム
    IP バージョン IPv4
    IP アドレス example-ip
    ポート 80
    省略可: HTTP キープアライブ タイムアウト 5~1,200 秒のタイムアウト値を入力します。デフォルト値は 610 秒です。
  5. [完了] をクリックします。

バックエンドの構成

  1. [バックエンドの構成] をクリックします。
  2. [バックエンド サービスとバックエンド バケット] リストで、[バックエンド サービスを作成] をクリックします。
  3. [名前] に名前を入力します。
  4. [バックエンド タイプ] で、[サーバーレス ネットワーク エンドポイント グループ] を選択します。
  5. [プロトコル] は変更せず、そのままにします。このパラメータは無視されます。
  6. [バックエンド] セクションの [新しいバックエンド] で、[サーバーレス ネットワーク エンドポイント グループを作成] を選択します。
  7. [名前] に名前を入力します。
  8. [リージョン] で、[us-central1] を選択し、[Cloud Run] を選択します。
  9. [サービス名を選択] を選択します。
  10. [サービス] リストで、ロードバランサを作成する Cloud Run サービスを選択します。
  11. [作成] をクリックします。
  12. [新しいバックエンド] セクションで、[完了] をクリックします。
  13. [作成] をクリックします。

ルーティング ルール

ルーティング ルールは、トラフィックの転送方法を決定します。ルーティングを構成するには、ホストルールとパスマッチャーを設定します。これは外部アプリケーション ロードバランサの URL マップの構成要素です。

  1. [ルーティング ルール] をクリックします。

  2. デフォルトのホストとパスを保持します。この例では、すべてのリクエストが前の手順で作成したバックエンド サービスに送信されます。

構成の確認

  1. [確認と完了] をクリックします。
  2. すべての設定を確認します。
  3. 省略可: [同等のコード] をクリックして、ロードバランサの作成に使用する REST API リクエストを表示します。
  4. [作成] をクリックします。
  5. ロードバランサの作成が完了するまで待ちます。
  6. ロードバランサの名前(serverless-lb)をクリックします。
  7. ロードバランサの IP アドレスをメモします(次のタスクで使用します)。次のタスクでは IP_ADDRESS とします。

gcloud

  1. サーバーレス アプリにサーバーレス NEG を作成します。

    Cloud Run サービスを使用してサーバーレス NEG を作成するには:

       gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME \
           --region=us-central1 \
           --network-endpoint-type=serverless  \
           --cloud-run-service=CLOUD_RUN_SERVICE_NAME
       
    その他のオプションについては、gcloud compute network-endpoint-groups creategcloud リファレンス ガイドをご覧ください。
  2. バックエンド サービスを作成します。
       gcloud compute backend-services create BACKEND_SERVICE_NAME \
           --load-balancing-scheme=EXTERNAL_MANAGED \
           --global
       
  3. サーバーレス NEG をバックエンドとしてバックエンド サービスに追加します。
       gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
           --global \
           --network-endpoint-group=SERVERLESS_NEG_NAME \
           --network-endpoint-group-region=us-central1
       
  4. 受信リクエストをバックエンド サービスに転送するための URL マップを作成します。
       gcloud compute url-maps create URL_MAP_NAME \
           --default-service BACKEND_SERVICE_NAME
       

    この URL マップの例では、1 つのサーバーレス アプリを表す 1 つのバックエンド サービスのみを対象としているため、ホストルールやパスマッチャーを設定する必要はありません。複数のバックエンド サービスを対象とする場合、ホスト名に基づいてリクエストを特定のサービスに転送するにはホストルールを使用します。また、パスマッチャーを設定すると、リクエストパスに基づいてリクエストを特定のサービスに転送できます。

  5. HTTPS ロードバランサを作成するには、HTTPS ターゲット プロキシで使用する SSL 証明書リソースが必要です。SSL 証明書リソースは、Google マネージド SSL 証明書またはセルフマネージド SSL 証明書を使用して作成できます。このうち、Google Cloud が自動的に取得、管理、更新する Google マネージド証明書をおすすめします。

    Google マネージド証明書を作成するには、ドメインが必要です。ドメインがない場合は、自己署名 SSL 証明書を使用してテストできます。

    Google マネージド SSL 証明書リソースを作成するには、次のコマンドを実行します。
       gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
           --domains DOMAIN
       
    セルフマネージド SSL 証明書リソースを作成するには、次のコマンドを実行します。
       gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
           --certificate CRT_FILE_PATH \
           --private-key KEY_FILE_PATH
       
  6. URL マップにリクエストを転送するターゲット HTTP(S) プロキシを作成します。

    HTTP ロードバランサの場合は、HTTP ターゲット プロキシを作成します。

       gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
          --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
          --url-map=URL_MAP_NAME
       

    HTTPS ロードバランサの場合は、HTTPS ターゲット プロキシを作成します。プロキシはロードバランサの一部であり、HTTPS ロード バランシング用の SSL 証明書を保持するため、この手順で証明書も読み込みます。

       gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
           --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
           --ssl-certificates=SSL_CERTIFICATE_NAME \
           --url-map=URL_MAP_NAME
       

    以下を置き換えます。

    • TARGET_HTTP_PROXY_NAME: ターゲット HTTP プロキシの名前。
    • TARGET_HTTPS_PROXY_NAME: ターゲット HTTPS プロキシの名前。
    • HTTP_KEEP_ALIVE_TIMEOUT_SEC: クライアント HTTP キープアライブ タイムアウトの指定に使用するオプション フィールド。タイムアウト値は 5~1,200 秒の範囲で指定してください。デフォルト値は 610 秒です。
    • SSL_CERTIFICATE_NAME: SSL 証明書の名前。
    • URL_MAP_NAME: URL マップの名前。
  7. 受信リクエストをプロキシに転送する転送ルールを作成します。

    HTTP ロードバランサの場合:

       gcloud compute forwarding-rules create HTTP_FORWARDING_RULE_NAME \
       --load-balancing-scheme=EXTERNAL_MANAGED \
       --network-tier=PREMIUM \
       --address=example-ip \
       --target-http-proxy=TARGET_HTTP_PROXY_NAME \
       --global \
       --ports=80
       

    HTTPS ロードバランサの場合:

       gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
           --load-balancing-scheme=EXTERNAL_MANAGED \
           --network-tier=PREMIUM \
           --address=example-ip \
           --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
           --global \
           --ports=443
       

ドメインをロードバランサに接続する

ロードバランサが作成されたら、ロードバランサに関連付けられた IP アドレスをメモします(例: 30.90.80.100)。ドメイン登録サービスを使用して A レコードを作成し、ドメインがロードバランサを参照するようにします。SSL 証明書に複数のドメインを追加する場合は、それぞれについて A レコードを追加して、すべてがロードバランサの IP アドレスを指すようにする必要があります。たとえば、www.example.comexample.comA レコードを作成するには、次のようにします。

NAME                  TYPE     DATA
www                   A        30.90.80.100
@                     A        30.90.80.100

DNS プロバイダとして Cloud DNS を使用する場合は、レコードの追加、変更、削除をご覧ください。

ロードバランサをテストする

ロードバランサを構成したので、ロードバランサの IP アドレスにトラフィックを送信できるようになりました。ドメインを構成した場合、ドメイン名にトラフィックを送信することもできます。ただし、DNS の伝播が完了するまでに時間がかかることがあるため、テスト用の IP アドレスで始めることもできます。

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. 作成したロードバランサをクリックします。

  3. ロードバランサの IP アドレスをメモします。

  4. HTTP ロードバランサの場合は、ウェブブラウザを使用して http://IP_ADDRESS に移動し、ロードバランサをテストします。IP_ADDRESS は、ロードバランサの IP アドレスに置き換えます。helloworld サービスのホームページが表示されます。

  5. HTTPS ロードバランサの場合は、ウェブブラウザを使用して https://IP_ADDRESS に移動し、ロードバランサをテストします。IP_ADDRESS は、ロードバランサの IP アドレスに置き換えます。helloworld サービスのホームページが表示されます。
    結果に問題があり、Google マネージド証明書を使用している場合は、証明書リソースのステータスが ACTIVE であることを確認します。詳しくは、Google マネージド SSL 証明書リソースのステータスをご覧ください。
    テストに自己署名証明書を使用した場合、ブラウザに警告が表示されます。自己署名証明書を受け付けるためには、ブラウザで明示的に設定する必要があります。警告は無視してクリックし、実際のページを表示します。

追加の構成オプション

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

マルチリージョン ロード バランシングを設定する

このページの例では、us-central1 リージョンのバックエンドとして機能する Cloud Run サービスは 1 つだけです。サーバーレス NEG で同時に参照できるエンドポイントは 1 つだけなので、負荷分散は複数のリージョン間では行われません。外部アプリケーション ロードバランサはフロントエンドとしてのみ機能し、指定された helloworld アプリのエンドポイントにトラフィックをプロキシします。ただし、エンドユーザーのレイテンシを改善するため、複数のリージョンから Cloud Run アプリを提供しなければいけない場合もあります。

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

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

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

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

次の図に、この構成を示します。

サーバーレス アプリケーションのマルチリージョン ルーティング。
サーバーレス アプリケーションのマルチリージョン ルーティング

このセクションでは、このページで前述したロードバランサの設定に基づき、同じリージョンにある Cloud Run サービスを参照する us-central1 リージョンに 1 つのサーバーレス NEG を作成しました。また、europe-west1 リージョンに 2 つ目の Cloud Run サービスを作成していることを前提としています。作成する 2 番目のサーバーレス NEG は、europe-west1 リージョンのこの Cloud Run サービスを参照します。

この例では、次の手順を完了します。

  1. europe-west1 リージョンに 2 つ目のサーバーレス NEG を作成します。
  2. 2 つ目のサーバーレス NEG をバックエンド サービスに接続します。

既存のバックエンド サービスに 2 つ目のサーバーレス NEG を追加する手順は次のとおりです。

コンソール

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. バックエンド サービスを編集するロードバランサの名前をクリックします。

  3. [ロードバランサの詳細] ページで、[編集] をクリックします。

  4. [グローバル外部アプリケーション ロードバランサの編集] ページで、[バックエンドの構成] をクリックします。

  5. [バックエンドの構成] ページで、変更するバックエンド サービスの [編集] をクリックします。

  6. [バックエンド] セクションで、[バックエンドを追加] をクリックします。

  7. [サーバーレス ネットワーク エンドポイント グループ] リストで、[サーバーレス ネットワーク エンドポイント グループの作成] を選択します。

  8. サーバーレス NEG の名前を入力します。

  9. [リージョン] で europe-west1 を選択します。

  10. [サーバーレス ネットワーク エンドポイント グループの種類] では、[Cloud Run] を選択し、次の操作を行います。

    1. [サービスの選択] オプションを選択します。
    2. [サービス] リストで、ロードバランサを作成する Cloud Run サービスを選択します。
  11. [作成] をクリックします。

  12. [新しいバックエンド] ページで、[完了] をクリックします。

  13. [保存] をクリックします。

  14. バックエンド サービスを更新するには、[更新] をクリックします。

  15. ロードバランサを更新するには、[グローバル外部アプリケーション ロードバランサの編集] ページで [更新] をクリックします。

gcloud

  1. 2 つ目のサーバーレス NEG を Cloud Run サービスがデプロイされているのと同じリージョンに作成します。

    gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME_2 \
      --region=europe-west1 \
      --network-endpoint-type=SERVERLESS \
      --cloud-run-service=CLOUD_RUN_SERVICE_2
    

    以下を置き換えます。

    • SERVERLESS_NEG_NAME_2: 2 番目のサーバーレス NEG の名前
    • CLOUD_RUN_SERVICE_2: Cloud Run サービスの名前。
  2. 2 番目のサーバーレス NEG をバックエンドとしてバックエンド サービスに追加します。

    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
      --global \
      --network-endpoint-group=SERVERLESS_NEG_NAME_2 \
      --network-endpoint-group-region=europe-west1
    

    以下を置き換えます。

    • BACKEND_SERVICE_NAME: バックエンド サービスの名前
    • SERVERLESS_NEG_NAME_2: 2 番目のサーバーレス NEG の名前

マルチリージョンの Cloud Run デプロイで認証済みの Pub/Sub push サブスクリプションを使用する

認証済みの push リクエストの場合、デフォルトでは、Cloud Run はリージョン固有のオーディエンス フィールドの存在を想定しています。マルチリージョンの Cloud Run デプロイの場合、push リクエストが別のリージョンの Cloud Run サービスに転送されると、オーディエンスの不一致が原因で JWT トークンの検証が失敗します。

リージョン固有の制約を回避するには:

  1. 異なるリージョンのサービス デプロイと同じカスタム オーディエンスを構成します。
  2. カスタム オーディエンスを JWT トークン内のオーディエンスとして使用するように Pub/Sub プッシュ メッセージを構成します。

リージョン範囲でのルーティングを設定する

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

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

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

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

  1. 2 つの Cloud Run サービスをそれぞれ異なるリージョンに設定します。2 つの Cloud Run サービスのうち、hello-world-eu をヨーロッパ内のリージョンにデプロイし、hello-world-us を米国内のリージョンにデプロイしたとします。
  2. 次の設定で外部アプリケーション ロードバランサを作成します。
    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 Run functions: 関数名をプレースホルダ <function> に置き換えます。この例では、URL マスクが example.com/<function> になります。
    3. App Engine: サービス名をプレースホルダ <service> に置き換えます。サービスにバージョンが関連付けられている場合は、そのバージョンをプレースホルダ <version> に置き換えます。この例では、URL マスクが example.com/<service> になります。
    4. API Gateway: ゲートウェイ名をプレースホルダ <gateway> に置き換えます。この例では、これで URL マスクが example.com/<gateway> になります。
  3. (省略可)URL のパスの部分からサービス名(またはファンクション、バージョン、タグ)を抽出できる場合は、ドメインを省略できます。URL マスクのパスの部分は、最初の / 文字で区別されます。/ が URL マスクに存在しない場合、マスクはホストのみを表していると見なされます。したがって、この例では URL マスクを /<service>/<gateway> または /<function> に短縮できます。

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

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

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

Cloud Run

この表では、example.com というカスタム ドメインがあり、すべての 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 Run functions

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

サービス名、バージョン カスタム ドメイン 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>

API Gateway

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

ゲートウェイの名前 API Gateway(プレビュー)のカスタム ドメイン URL URL マスク
login https://example.com/login /<gateway>
login https://example.com/home/login /home/<gateway>
login https://login.example.com <gateway>.example.com
login https://login.home.example.com <gateway>.home.example.com

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

Console

新しいロードバランサの場合、このトピックで説明したものと同じエンドツーエンドのプロセスを使用できます。バックエンド サービスを構成する場合は、特定のサービスを選択する代わりに、URL マスクを入力します。

既存のロードバランサがある場合は、バックエンド構成を編集し、サーバーレス NEG に特定のサービスの代わりに URL マスクを指定できます。

URL マスクベースのサーバーレス NEG を既存のバックエンド サービスに追加するには:

  1. Google Cloud Console の [Cloud Load Balancing] ページに移動します。
    [負荷分散] ページに移動
  2. バックエンド サービスを編集するロードバランサの名前をクリックします。
  3. [ロードバランサの詳細] ページで、[編集] をクリックします。
  4. [Edit global external Application Load Balancer] ページで、[Backend configuration] をクリックします。
  5. [バックエンドの構成] ページで、変更するバックエンド サービスの [編集] をクリックします。
  6. [バックエンドを追加] をクリックします。
  7. [サーバーレス ネットワーク エンドポイント グループの作成] を選択します。
    1. [名前] に「helloworld-serverless-neg」と入力します。
    2. [リージョン] で、us-central1 を選択します。
    3. [サーバーレス ネットワーク エンドポイント グループの種類] で、サーバーレス アプリが作成されたプラットフォーム(またはサービスまたは関数)を選択します。
      1. [URL マスクを使用] を選択します。
      2. URL マスクを入力します。URL マスクを作成する方法については、URL マスクの作成をご覧ください。
      3. [作成] をクリックします。
  8. [新しいバックエンド] セクションで、[完了] をクリックします。
  9. [更新] をクリックします。

gcloud: Cloud Run

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

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

gcloud: Cloud Run 関数

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

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

gcloud: App Engine

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

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

gcloud: API Gateway

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

gcloud beta compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway \
  --serverless-deployment-url-mask="example.com/<gateway>"

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

外部アプリケーション ロードバランサによって処理されるカスタム ドメインを移行する

サーバーレス コンピューティング アプリがカスタム ドメインにマッピングされている場合、既存の Cloud Run、Cloud Run functions、API Gateway、または App Engine のカスタム ドメイン 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 Run functions、API Gateway、または App Engine のサービスに転送します。

Cloud CDN を有効にする

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

グローバル外部アプリケーション ロードバランサによって使用されるバックエンド サービスで Cloud CDN を有効にするには、gcloud compute backend-services update コマンドを使用します。

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

Cloud CDN は、Cloud Run、Cloud Run functions、API Gateway、および App Engine バックエンドを使用するバックエンド サービスでサポートされます。

外部アプリケーション ロードバランサで IAP を有効にする

注: IAP は Cloud CDN と互換性がありません。

IAP を有効または無効にするように構成できます(デフォルトは無効です)。有効にした場合、oauth2-client-idoauth2-client-secret の値を指定する必要があります。

IAP を有効にするには、バックエンド サービスを更新して、--iap=enabled フラグに oauth2-client-idoauth2-client-secret を追加します。

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --iap=enabled,oauth2-client-id=ID,oauth2-client-secret=SECRET \
    --global

必要に応じて、Google Cloud コンソール、gcloud CLI、または API を使用して、Compute Engine リソースに対して IAP を有効にできます。

Google Cloud Armor を有効にする

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

Cloud Run functions を使用している場合、internal-and-gclb Ingress 設定を使用すれば、デフォルトの URL に送信されるリクエストをブロックできます。

Cloud Run を使用している場合、上り(内向き)を内部と Cloud Load Balancing に制限することで、デフォルトの URL または Cloud Run を介して設定された他のカスタム ドメインに送信されるリクエストをブロックできます。

App Engine を使用している場合は、上り(内向き)制御を使用すると、ロードバランサ(VPC を使用している場合は VPC)から送信されるリクエストだけをアプリで受信できます。

適切な上り(内向き)設定がないと、ユーザーはサーバーレス アプリケーションのデフォルトの URL を使用して、ロードバランサ、Google Cloud Armor セキュリティ ポリシー、SSL 証明書、(ロードバランサを通過する)秘密鍵をバイパスできます。

省略可: デフォルトのバックエンド セキュリティ ポリシーを構成します。デフォルトのセキュリティ ポリシーでは、ユーザーが構成したしきい値を超えるトラフィックをスロットリングします。デフォルトのセキュリティ ポリシーの詳細については、レート制限の概要をご覧ください。

  1. Google Cloud Armor のデフォルトのセキュリティ ポリシーを無効にするには、バックエンド セキュリティ ポリシーのリストメニューで None を選択します。
  2. [セキュリティ] セクションで [デフォルトのセキュリティ ポリシー] を選択します。
  3. [ポリシー名] フィールドで、自動生成された名前を受け入れるか、セキュリティ ポリシーの名前を入力します。
  4. [リクエスト数] フィールドで、デフォルトのリクエスト数を受け入れるか、110,000 の整数を入力します。
  5. [間隔] フィールドで、間隔を選択します。
  6. [キーへの適用] フィールドで、[すべて]、[IP アドレス]、[X-Forwarded-For IP アドレス] のいずれかの値を選択します。これらのオプションの詳細については、レート制限対象のクライアントを特定するをご覧ください。

ロギングとモニタリングを有効にする

外部アプリケーション ロードバランサのバックエンド サービスのログの有効化、無効化、表示を行えます。Google Cloud コンソールを使用する場合、サーバーレス NEG バックエンドを使用するバックエンド サービスではロギングがデフォルトで有効になります。gcloud を使用すると、必要に応じて各バックエンド サービスのロギングを無効にできます。手順については、ロギングをご覧ください。

また、ロードバランサは、モニタリング データを Cloud Monitoring にエクスポートします。モニタリング指標は、ロードバランサの構成、使用状況、パフォーマンスを評価する際に使用できます。指標は、問題のトラブルシューティングや、リソース使用率とユーザー エクスペリエンスの向上にも役立ちます。手順については、モニタリングをご覧ください。

クライアント HTTP キープアライブ タイムアウトを更新する

前の手順で作成したロードバランサは、クライアント HTTP キープアライブ タイムアウトのデフォルト値で構成されています。

クライアントの HTTP キープアライブ タイムアウトを更新するには、次の操作を行います。

コンソール

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. 変更するロードバランサの名前をクリックします。
  3. [編集] をクリックします。
  4. [フロントエンドの構成] をクリックします。
  5. [高度な機能] を開きます。[HTTP キープアライブ タイムアウト] にタイムアウト値を入力します。
  6. [更新] をクリックします。
  7. 変更を確認するには、[確認と完了] をクリックして、[更新] をクリックします。

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)。このメソッドは、502503504 の HTTP ステータス コードのみエラーとみなされます。

既存のバックエンド サービスで外れ値検出を有効にするには、次の操作を行います。外れ値検出を有効にした後でも、一部のリクエストが正常でないサービスに送信され、5xx ステータス コードがクライアントに返される場合があることに注意してください。エラー率をさらに低減するには、外れ値検出パラメータ用により積極的な値を構成します。詳しくは、outlierDetection フィールドをご覧ください。

コンソール

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. バックエンド サービスを編集するロードバランサの名前をクリックします。

  3. [ロードバランサの詳細] ページで、[編集] をクリックします。

  4. [Edit global external Application Load Balancer] ページで、[バックエンドの構成] をクリックします。

  5. [バックエンドの構成] ページで、変更するバックエンド サービスの [編集] をクリックします。

  6. 下にスクロールして [高度な構成] セクションを開きます。

  7. [外れ値検出] セクションで、[有効にする] チェックボックスをオンにします。

  8. [編集] をクリックして外れ値検出を構成します。

    以下のオプションが次の値で構成されていることを確認します。

    プロパティ
    連続するエラー 5
    間隔 1000
    ベースの排出時間 30000
    最大排出率 50
    連続するエラーの適用 100

    この例では、外れ値検出分析が 1 秒ごとに実行されます。Envoy プロキシが連続して受信した HTTP 5xx ステータス コードの数が 5 以上の場合、バックエンド エンドポイントは Envoy プロキシのロード バランシング プールから 30 秒間除外されます。適用の割合が 100% に設定されている場合、バックエンド サービスでは、外れ値検出分析が実行されるたびに、これらの特定の Envoy プロキシのロード バランシング プールから正常でないエンドポイントが排出されます。除外条件が満たされると、ロード バランシング プールからバックエンド エンドポイントの最大 50% が排出されます。

  9. [保存] をクリックします。

  10. バックエンド サービスを更新するには、[更新] をクリックします。

  11. ロードバランサを更新するには、[Edit global external Application Load Balancer] ページで [更新] をクリックします。

gcloud

  1. バックエンド サービスを YAML ファイルにエクスポートします。

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
      --destination=BACKEND_SERVICE_NAME.yaml --global
    

    BACKEND_SERVICE_NAME は、バックエンド サービスの名前に置き換えます。

  2. 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_AREGION_B: ロードバランサを構成したリージョン
    • SERVERLESS_NEG_NAME: 最初のサーバーレス NEG の名前
    • SERVERLESS_NEG_NAME_2: 2 番目のサーバーレス NEG の名前
  3. 最新の構成をインポートして、バックエンド サービスを更新します。

    gcloud compute backend-services import BACKEND_SERVICE_NAME \
      --source=BACKEND_SERVICE_NAME.yaml --global
    

    バックエンド サービスで外れ値検出が有効になりました。

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

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

Console

  1. 削除するサーバーレス NEG が現在バックエンド サービスによって使用されていないことを確認するには、負荷分散の詳細設定メニューの [バックエンド サービス] タブに移動します。
    [バックエンド サービス] タブに移動
  2. サーバーレス NEG が使用中の場合、次の操作を行います。
    1. サーバーレス NEG を使用するバックエンド サービスの名前をクリックします。
    2. [編集] をクリックします。
    3. [バックエンド] のリストで をクリックし、バックエンド サービスからサーバーレス NEG バックエンドを削除します。
    4. [保存] をクリックします。
  3. Google Cloud コンソールの [ネットワーク エンドポイント グループ] ページに移動します。
    [ネットワーク エンドポイント グループ] ページに移動
  4. 削除するサーバーレス NEG のチェックボックスをオンにします。
  5. [削除] をクリックします。
  6. もう一度 [削除] をクリックして確定します。

gcloud

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

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

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

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

次のステップ