サーバーレス 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 ディレクトリを初期化します。

権限を構成する

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

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

外部 IP アドレスの予約

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

コンソール

  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

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

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

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

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

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

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

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

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

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

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

コンソール

ロードバランサに名前を付ける

  1. Google Cloud Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. [HTTP(S) 負荷分散] で [設定を開始] をクリックします。
  3. [インターネット接続または内部専用] で [インターネットから自分の VM へ] を選択します。
  4. [続行] をクリックします。
  5. ロードバランサの [名前] に「helloworld-lb」と入力します。
  6. ウィンドウを開いたままにして続行します。

バックエンド サービスの構成

  1. [バックエンドの設定] をクリックします。
  2. [バックエンド サービスを作成または選択] プルダウン メニューで、マウスポインタを [バックエンド サービス] に合わせ、[バックエンド サービスを作成] を選択します。
  3. バックエンド サービスの [名前] を helloworld-backend-service に設定します。
  4. [バックエンド タイプ] で [サーバーレス ネットワーク エンドポイント グループ] を選択します。
  5. [プロトコル] プルダウン メニューで [HTTPS] を選択します。
  6. [バックエンド] の [新しいバックエンド] ウィンドウで、[サーバーレス ネットワーク エンドポイント グループを作成] を選択します。
    1. [名前] に「helloworld-serverless-neg」と入力します。
    2. [リージョン] で、us-central1 を選択します。
    3. サーバーレス ネットワーク エンドポイント グループの種類を選択します。この例では Cloud Run(フルマネージド)サービスを使用しているため、[Cloud Run] を選択します。
      1. [サービス名を選択] を選択します。
      2. [サービス] プルダウンで [helloworld] サービスを選択します。
    4. [作成] をクリックします。
  7. [新しいバックエンド] ウィンドウで、[完了] をクリックします。
  8. (省略可)[Cloud CDN を有効にする] を選択します。
  9. [作成] をクリックします。

ホストルールとパスマッチャーを構成する

ホストルールとパスマッチャーは、外部 HTTP(S) ロードバランサの URL マップの構成要素です。

  1. [ホストとパスのルール] をクリックします。
  2. デフォルトのホストとパスを保持します。つまり、すべてのリクエストが helloworld-backend-service に転送されます。

フロントエンドを構成する

  1. [フロントエンドの設定] をクリックします。
  2. [名前] を入力します。
  3. HTTPS ロードバランサを作成するには、SSL 証明書gcloud compute ssl-certificates list)が必要です。前に説明した Google マネージド証明書を使用することをおすすめします。外部 HTTP(S) ロードバランサを構成するには、次のフィールドに値を入力します。

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

    プロパティ 値(値を入力するか、指定されたオプションを選択)
    プロトコル HTTPS
    ネットワーク サービス階層 プレミアム
    IP バージョン IPv4
    IP アドレス example-ip
    ポート 443
    証明書 既存の SSL 証明書を選択するか、新しい証明書を作成します。

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

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

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

    プロパティ 値(値を入力するか、指定されたオプションを選択)
    プロトコル HTTP
    ネットワーク サービス階層 プレミアム
    IP バージョン IPv4
    IP アドレス example-ip
    ポート 80

  4. [完了] をクリックします。

構成の確認

  1. [確認と完了] をクリックします。
  2. [バックエンド]、[ホストとパスのルール]、[フロントエンド] を確認します。
  3. [作成] をクリックします。
  4. ロードバランサの作成が完了するまで待ちます。
  5. ロードバランサの名前(helloworld-lb)をクリックします。
  6. ロードバランサの IP アドレスをメモします(次のタスクで使用します)。次のタスクでは IP_ADDRESS とします。

gcloud

  1. Cloud Run(フルマネージド)サービス用のサーバーレス NEG を作成します。この例では、helloworld という Cloud Run(フルマネージド)サービスがデプロイ済みであることを前提としています。
    gcloud 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 compute network-endpoint-groups create に関する gcloud リファレンス ガイドをご覧ください。
  2. バックエンド サービスを作成し、そのバックエンド サービスにバックエンドとしてサーバーレス NEG を追加します。
    gcloud compute backend-services create helloworld-backend-service \
        --global
    
    gcloud 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 証明書リソースは、Google マネージド SSL 証明書またはセルフマネージド SSL 証明書を使用して作成できます。このうち、Google Cloud が自動的に取得、管理、更新する Google マネージド証明書をおすすめします。
    Google マネージド証明書を作成するには、ドメインが必要です。ドメインがない場合は、自己署名 SSL 証明書を使用してテストできます。

    www-ssl-certという名前の Google マネージド SSL 証明書リソースを作成するには、次のコマンドを実行します。
    gcloud compute ssl-certificates create www-ssl-cert \
        --domains [DOMAIN]
    
    www-ssl-cert という名前のセルフマネージド SSL 証明書リソースを作成するには、次のコマンドを実行します。
    gcloud compute ssl-certificates create www-ssl-cert \
        --certificate [CRT_FILE_PATH] \
        --private-key [KEY_FILE_PATH]
    
  5. URL マップにリクエストをルーティングするターゲット HTTPS プロキシを作成します。

    HTTP ロードバランサの場合、HTTP ターゲット プロキシを作成します。
      gcloud compute target-http-proxies create helloworld-http-proxy \
        --url-map=helloworld-url-map
      
    HTTPS ロードバランサの場合は、HTTPS ターゲット プロキシを作成します。プロキシはロードバランサの一部であり、HTTPS 負荷分散用の SSL 証明書を保持するため、この手順で証明書も読み込みます。
    gcloud compute target-https-proxies create helloworld-https-proxy \
        --ssl-certificates=www-ssl-cert \
        --url-map=helloworld-url-map
    
  6. 受信リクエストをプロキシにルーティングするグローバル転送ルールを作成します。

    HTTP ロードバランサの場合:
    gcloud compute forwarding-rules create http-forwarding-rule \
        --address=example-ip \
        --target-http-proxy=helloworld-http-proxy \
        --global \
        --ports=80
    
    HTTPS ロードバランサの場合:
    gcloud compute forwarding-rules create https-forwarding-rule \
        --address=example-ip \
        --target-https-proxy=helloworld-https-proxy \
        --global \
        --ports=443
    

ロードバランサの IP アドレスを使用するようにドメインの DNS レコードを更新する

まだ行っていない場合は、ドメインの DNS A レコードを更新してロードバランサの IP アドレスを指定します。これにより、既存の Cloud Run(フルマネージド)または App Engine のカスタム ドメイン URL に送信されるトラフィックが代わりにロードバランサによってルーティングされます。

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

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 サービスにルーティングします。

Google マネージド証明書を使用する場合、既存のサービスを外部 HTTP(S) ロードバランサに移行すると、ダウンタイム(通常は 1 時間以内)が発生する可能性があります。これは、ロードバランサの IP アドレスを指すように DNS レコードを更新するまで、外部 HTTP(S) ロードバランサの SSL 証明書がプロビジョニングされないためです。

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

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

  1. Google Cloud Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. 作成したロードバランサをクリックします。
  3. ロードバランサの IP アドレスをメモします。
  4. HTTP ロードバランサを作成した場合は、ウェブブラウザで http://IP_ADDRESS に移動してロードバランサをテストできます。IP_ADDRESSロードバランサの IP アドレスに置き換えます。helloworld サービスのホームページが表示されます。

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

    これが機能せず、Google マネージド証明書を使用している場合は、証明書リソースのステータスが ACTIVE であることを確認します。詳しくは、Google マネージド SSL 証明書リソースのステータスをご覧ください。

    テストに自己署名証明書を使用した場合、ブラウザに警告が表示されます。自己署名証明書を受け付けるためには、ブラウザで明示的に設定する必要があります。警告は無視してクリックし、実際のページを表示してください。

    ローカルマシンのコマンドラインから curl を使用することもできます。IP_ADDRESSロードバランサの IPv4 アドレスに置き換えます。helloworld サービスのホームページが表示されることを確認します。

    Google マネージド証明書を使用している場合は、ロードバランサの IP アドレスを指すドメインをテストします。次に例を示します。

    curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:IP_ADDRESS:443
    

    自己署名証明書を使用する場合は、-k フラグも指定する必要があります。curl の -k オプションを指定すると、自己署名証明書を使用している場合に curl が機能します。独自のサイトをテストする場合にのみ、-k パラメータを使用してください。通常の状況下では有効な証明書が重要なセキュリティ手段です。証明書の警告は無視しないでください。

  5. (省略可)カスタム ドメインを使用する場合は、更新された DNS 設定が反映されるまでに時間がかかる場合があります。次に、ウェブブラウザでドメイン(https://test.example.com など)をテストします。helloworld サービスのホームページが表示されます。

追加の構成オプション

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

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

上記の例では、バックエンドとして機能する 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 を作成する

コンソール

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

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

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

  1. Google Cloud Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. バックエンド サービスを編集するロードバランサの名前をクリックします。
  3. [ロードバランサの詳細] ページで、[編集] をクリックします。
  4. [HTTP(S) ロードバランサの編集] ページで、[バックエンドの設定] をクリックします。
  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 Functions

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

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

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>"

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

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 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

サーバーレス NEG バックエンドのロードバランサを削除すると、そのロードバランサに関連付けられたバックエンド サービスのみが削除されます。サーバーレス NEG は自動的に削除されません。このセクションで説明するように、サーバーレス NEG を手動で削除する必要があります。

次のステップ