このページでは、リクエストをサーバーレス バックエンドにルーティングする外部アプリケーション ロードバランサを作成する方法を説明します。ここでのサーバーレスという用語は、次のサーバーレス コンピューティング プロダクトを指します。
- App Engine
- Cloud Functions
- Cloud Run
外部アプリケーション ロードバランサと API Gateway の統合により、サーバーレス バックエンドは Cloud Load Balancing のすべての機能を活用できるようになります。トラフィックを API Gateway にルーティングするように外部アプリケーション ロードバランサを構成するには、API Gateway の外部アプリケーション ロードバランサ スタートガイドをご覧ください。API Gateway の外部アプリケーション ロードバランサ サポートはプレビュー版です。
サーバーレス NEG を使用すると、外部アプリケーション ロードバランサを適用した Google Cloud サーバーレス アプリを使用できます。サーバーレス NEG バックエンドを使用してロードバランサを構成した後は、そのロードバランサへのリクエストがサーバーレス アプリのバックエンドにルーティングされるようになります。
サーバーレス NEG の詳細については、サーバーレス NEG の概要をご覧ください。
始める前に
- App Engine、Cloud Functions、または Cloud Run のサービスをデプロイします。
- まだ行っていない場合は、Google Cloud CLI をインストールします。
- 権限を構成する。
- SSL 証明書リソースを追加する。
App Engine、Cloud Functions、または Cloud Run のサービスをデプロイする
このページで説明する手順では、Cloud Run、Cloud Functions、または App Engine のサービスをすでに実行中であることを前提としています。
このページの例では、Cloud Run Python クイックスタートを使用して、Cloud Run サービスを us-central1 リージョンにデプロイしています。このページの残りの部分では、サーバーレス NEG バックエンドを使用してこのサービスにリクエストをルーティングする外部アプリケーション ロードバランサを設定する方法を説明します。
サーバーレス アプリをまだデプロイしていない場合、またはサンプルアプリでサーバーレス NEG を試す場合は、以下のいずれかのクイックスタートを使用してください。サーバーレス アプリはどのリージョンでも作成できますが、後でサーバーレス NEG とロードバランサを作成する際は、サーバーレス アプリと同じリージョンで作成する必要があります。
Cloud Run
シンプルな Hello World アプリケーションを作成してコンテナ イメージにパッケージ化し、パッケージ化したコンテナ イメージを Cloud Run にデプロイする場合は、クイックスタート: ビルドとデプロイをご覧ください。
サンプル コンテナをすでに Container Registry にアップロードしている場合は、クイックスタート: 事前にビルドされたサンプル コンテナをデプロイするをご覧ください。
Cloud Functions
Cloud Functions: 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 アドレスを設定します。
コンソール
Google Cloud コンソールで、[外部 IP アドレス] ページに移動します。
[静的外部 IP アドレスを予約] をクリックします。
[名前] に「
example-ip」と入力します。[ネットワーク サービス ティア] で [プレミアム] を選択します。
[IP バージョン] で [IPv4] を選択します。
[種類] で [グローバル] を選択します。
[予約] をクリックします。
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 レコードが必要です。ドメインがない場合は、Google Domains から取得できます。詳しくは、Google Domains スタートガイドをご覧ください。また、前の手順で作成したロードバランサの IP アドレス（
example-ip）を指すようにドメインの DNS A レコードを更新する必要があります。詳しい手順については、Google マネージド証明書をご覧ください。自己署名証明書。この段階でドメインを設定したくない場合は、テスト用に自己署名 SSL 証明書を使用できます。
この例では、SSL 証明書リソースがすでに作成されていることを前提としています。
SSL 証明書リソース（または Google マネージド証明書で必要とされるドメイン）を作成せずにこのプロセスをテストする場合、このページの手順を使用して代わりに HTTP ロードバランサを設定できます。
ロードバランサを作成する
次の図では、ロードバランサがサーバーレス NEG バックエンドを使用して、リクエストをサーバーレス Cloud Run サービスに転送しています。この例では、Cloud Run Python クイックスタートを使用して Cloud Run サービスをデプロイしています。
サーバーレス NEG バックエンドを使用するバックエンド サービスではヘルスチェックがサポートされません。したがって、ロードバランサでサーバーレス NEG バックエンドのみを使用する場合、ヘルスチェックを許可するファイアウォール ルールを作成する必要はありません。
コンソール
構成を開始する
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
- [ロードバランサを作成] をクリックします。
- [ロードバランサの種類] で [アプリケーション ロードバランサ（HTTP / HTTPS）] を選択し、[次へ] をクリックします。
- [インターネット接続または内部] で [インターネット接続（外部）] を選択し、[次へ] をクリックします。
- [グローバルまたはシングル リージョンのデプロイ] で [グローバル ワークロードに最適] を選択し、[次へ] をクリックします。
- [ロードバランサの世代] で [従来のアプリケーション ロードバランサ] を選択し、[次へ] をクリックします。
- [構成] をクリックします。
基本構成
- ロードバランサの名前に「
serverless-lb」と入力します。 - ウィンドウを開いたままにして続行します。
フロントエンドの構成
- [フロントエンドの構成] をクリックします。
- [名前] に名前を入力します。
-
HTTPS ロードバランサを作成するには、SSL 証明書（
gcloud compute ssl-certificates list）が必要です。前述のように、Google マネージド証明書を使用することをおすすめします。
- [完了] をクリックします。
外部アプリケーション ロードバランサを構成するには、各フィールドを次のように指定します。
以下のオプションが次の値で構成されていることを確認します。
| プロパティ | 値（値を入力するか、指定されたオプションを選択） |
|---|---|
| プロトコル | HTTPS |
| ネットワーク サービス階層 | プレミアム |
| IP バージョン | IPv4 |
| IP アドレス | example-ip |
| ポート | 443 |
| 証明書 | 既存の 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 |
バックエンドの構成
- [バックエンドの構成] をクリックします。
- [バックエンド サービスとバックエンド バケット] リストで、[バックエンド サービスを作成] をクリックします。
- [名前] に名前を入力します。
- [バックエンド タイプ] で、[サーバーレス ネットワーク エンドポイント グループ] を選択します。
- [プロトコル] は変更せず、そのままにします。このパラメータは無視されます。
- [バックエンド] セクションの [新しいバックエンド] で、[サーバーレス ネットワーク エンドポイント グループを作成] を選択します。
- [名前] に名前を入力します。
- [リージョン] で、[us-central1] を選択し、[Cloud Run] を選択します。
- [サービス名を選択] を選択します。
- [サービス] リストで、ロードバランサを作成する Cloud Run サービスを選択します。
- [作成] をクリックします。
- [新しいバックエンド] で、[完了] をクリックします。
- [作成] をクリックします。
ルーティング ルール
ルーティング ルールは、トラフィックの転送方法を決定します。ルーティングを構成するには、ホストルールとパスマッチャーを設定します。これは外部アプリケーション ロードバランサの URL マップの構成要素です。
-
[ホストとパスのルール] をクリックします。
- デフォルトのホストとパスを保持します。この例では、すべてのリクエストが前の手順で作成したバックエンド サービスに送信されます。
構成の確認
- [確認と完了] をクリックします。
- すべての設定を確認します。
- 省略可: [同等のコード] をクリックして、ロードバランサの作成に使用する REST API リクエストを表示します。
- [作成] をクリックします。
- ロードバランサの作成が完了するまで待ちます。
- ロードバランサの名前（serverless-lb）をクリックします。
- ロードバランサの IP アドレスをメモします（次のタスクで使用します）。次のタスクでは
IP_ADDRESSとします。
gcloud
- サーバーレス アプリにサーバーレス 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 createのgcloudリファレンス ガイドをご覧ください。 - バックエンド サービスを作成します。
gcloud compute backend-services create BACKEND_SERVICE_NAME \ --load-balancing-scheme=EXTERNAL \ --global - サーバーレス NEG をバックエンドとしてバックエンド サービスに追加します。
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --global \ --network-endpoint-group=SERVERLESS_NEG_NAME \ --network-endpoint-group-region=us-central1 - 受信リクエストをバックエンド サービスに転送するための URL マップを作成します。
gcloud compute url-maps create URL_MAP_NAME \ --default-service BACKEND_SERVICE_NAMEこの URL マップの例では、1 つのサーバーレス アプリを表す 1 つのバックエンド サービスのみを対象としているため、ホストルールやパスマッチャーを設定する必要はありません。複数のバックエンド サービスを対象とする場合、ホスト名に基づいてリクエストを特定のサービスに転送するにはホストルールを使用します。また、パスマッチャーを設定すると、リクエストパスに基づいてリクエストを特定のサービスに転送できます。
-
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 -
URL マップにリクエストを転送するターゲット HTTP(S) プロキシを作成します。
HTTP ロードバランサの場合は、HTTP ターゲット プロキシを作成します。
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \ --url-map=URL_MAP_NAMEHTTPS ロードバランサの場合は、HTTPS ターゲット プロキシを作成します。プロキシはロードバランサの一部であり、HTTPS ロード バランシング用の SSL 証明書を保持するため、この手順で証明書も読み込みます。
gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \ --ssl-certificates=SSL_CERTIFICATE_NAME \ --url-map=URL_MAP_NAME - 受信リクエストをプロキシに転送する転送ルールを作成します。
HTTP ロードバランサの場合:
gcloud compute forwarding-rules create HTTP_FORWARDING_RULE_NAME \ --load-balancing-scheme=EXTERNAL \ --network-tier=PREMIUM \ --address=example-ip \ --target-http-proxy=TARGET_HTTP_PROXY_NAME \ --global \ --ports=80HTTPS ロードバランサの場合:
gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \ --load-balancing-scheme=EXTERNAL \ --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.com と example.com に A レコードを作成するには、次のようにします。
NAME TYPE DATA www A 30.90.80.100 @ A 30.90.80.100
DNS プロバイダとして Cloud DNS を使用する場合は、レコードの追加、変更、削除をご覧ください。
ロードバランサをテストする
ロードバランサを構成したので、ロードバランサの IP アドレスにトラフィックを送信できるようになりました。ドメインを構成した場合、ドメイン名にトラフィックを送信することもできます。ただし、DNS の伝播が完了するまでに時間がかかることがあるため、テスト用の IP アドレスで始めることもできます。
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
作成したロードバランサをクリックします。
ロードバランサの IP アドレスをメモします。
HTTP ロードバランサの場合は、ウェブブラウザを使用して
http://IP_ADDRESSに移動し、ロードバランサをテストします。IP_ADDRESSは、ロードバランサの IP アドレスに置き換えます。helloworldサービスのホームページが表示されます。
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 デプロイメントの互換性を確保し、どのリージョンからでもトラフィックを処理できるようにするために、プレミアム ネットワーク階層を使用する必要があります。
マルチリージョン ロードバランサを設定するには:
- 2 つの Cloud Run サービスをそれぞれ異なるリージョンに設定します。ここでは、2 つの Cloud Run サービスの一方を米国内のリージョンにデプロイし、もう一方をヨーロッパ内のリージョンにデプロイしたとします。
- 次の設定で外部アプリケーション ロードバランサを作成します。
- 2 つのサーバーレス NEG を使用してグローバル バックエンド サービスを設定します。
- 米国内にデプロイされた Cloud Run サービスと同じリージョンに最初の NEG を作成します。
- ヨーロッパ内にデプロイされた Cloud Run サービスと同じリージョンに 2 番目の NEG を作成します。
- プレミアム ネットワーク サービス ティアを使用してフロントエンド構成を設定します。
- 2 つのサーバーレス NEG を使用してグローバル バックエンド サービスを設定します。
次の図に、この構成を示します。
このセクションでは、このページで前述したロードバランサの設定に基づき、同じリージョンにある Cloud Run サービスを参照する us-central1 リージョンに 1 つのサーバーレス NEG を作成しました。また、europe-west1 リージョンに 2 つ目の Cloud Run サービスを作成していることを前提としています。作成する 2 番目のサーバーレス NEG は、europe-west1 リージョンのこの Cloud Run サービスを参照します。
この例では、次の手順を完了します。
europe-west1リージョンに 2 つ目のサーバーレス NEG を作成します。- 2 つ目のサーバーレス NEG をバックエンド サービスに接続します。
既存のバックエンド サービスに 2 つ目のサーバーレス NEG を追加する手順は次のとおりです。
コンソール
Google Cloud コンソールの [ロード バランシング] ページに移動します。
バックエンド サービスを編集するロードバランサの名前をクリックします。
[ロードバランサの詳細] ページで、[編集] をクリックします。
[Edit global external Application Load Balancer] ページで、[バックエンドの構成] をクリックします。
[バックエンドの構成] ページで、変更するバックエンド サービスの [編集] をクリックします。
[バックエンド] セクションで、[バックエンドを追加] をクリックします。
[サーバーレス ネットワーク エンドポイント グループ] リストで、[サーバーレス ネットワーク エンドポイント グループの作成] を選択します。
サーバーレス NEG の名前を入力します。
[リージョン] で
europe-west1を選択します。[サーバーレス ネットワーク エンドポイント グループの種類] で [Cloud Run] を選択し、次の操作を行います。
- [サービスを選択] オプションを選択します。
- [サービス] リストで、ロードバランサを作成する Cloud Run サービスを選択します。
[作成] をクリックします。
[新しいバックエンド] ページで、[完了] をクリックします。
[保存] をクリックします。
バックエンド サービスを更新するには、[更新] をクリックします。
ロードバランサを更新するには、[Edit global external Application Load Balancer] ページで [更新] をクリックします。
gcloud
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 番目のサーバーレス 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 トークンの検証が失敗します。
リージョン固有の制約を回避するには:
- 異なるリージョンのサービス デプロイで同じカスタム オーディエンスを構成します。
- カスタム オーディエンスを JWT トークン内のオーディエンスとして使用するように Pub/Sub プッシュ メッセージを構成します。
リージョン範囲でのルーティングを設定する
複数のリージョンからアプリケーションを提供する一般的な理由は、データの局所性に関する要件に対処するためです。たとえば、ヨーロッパのユーザーが送信したリクエストは常にヨーロッパ内に位置するリージョンで処理されるようにするとします。このように設定するには、ヨーロッパのユーザー用とヨーロッパ以外のユーザー用にそれぞれ個別の URL を使用した URL スキームを使用して、ヨーロッパのユーザーをヨーロッパの URL に転送する必要があります。
このようなシナリオでは、URL マップを使用して、特定の URL からのリクエストを対応するリージョンにルーティングします。こうした設定では、あるリージョンを対象とするリクエストが別のリージョンに配信されることは決してありません。したがって、リージョン間での分離が実現されます。一方、リージョンで障害が発生しても、リクエストは別のリージョンにルーティングされません。そのため、この設定でサービスの可用性が向上することはありません。
リージョン ルーティングを設定するには、1 つの転送ルールで異なる複数のリージョンを組み合わせられるようにするために、プレミアム ネットワーク階層を使用する必要があります。
リージョン ルーティングを使用してロードバランサを設定するには:
- 2 つの Cloud Run サービスをそれぞれ異なるリージョンに設定します。2 つの Cloud Run サービスのうち、hello-world-eu をヨーロッパ内のリージョンにデプロイし、hello-world-us を米国内のリージョンにデプロイしたとします。
- 次の設定で外部アプリケーション ロードバランサを作成します。
- ヨーロッパ内に、サーバーレス NEG を使用してバックエンド サービスを設定します。このサーバーレス NEG は、ヨーロッパ内にデプロイされた Cloud Run サービスと同じリージョンに作成する必要があります。
- 米国内に、別のサーバーレス NEG を使用して 2 つ目のバックエンド サービスを設定します。このサーバーレス NEG は、米国内にデプロイされた Cloud Run サービスと同じリージョンに作成する必要があります。
- 1 つの URL セットはヨーロッパ内のバックエンド サービスにルーティングされ、残りすべてのリクエストは米国内のバックエンド サービスにルーティングされるように、適切なホストとパスルールを使用して URL マップを設定します。
- プレミアム ネットワーク階層を使用してフロントエンド構成を設定します。
残りの設定は、上記と同じです。最終的な設定は次のようになります。
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 Functions: ファンクション名をプレースホルダ
<function>に置き換えます。この例では、これで URL マスクがexample.com/<function>になります。 - App Engine: サービス名をプレースホルダ
<service>に置き換えます。サービスにバージョンが関連付けられている場合は、そのバージョンをプレースホルダ<version>に置き換えます。この例では、URL マスクがexample.com/<service>になります。 - API Gateway: ゲートウェイ名をプレースホルダ
<gateway>に置き換えます。この例では、URL マスクがexample.com/<gateway>になります。
- Cloud Run: Cloud Run サービス名をプレースホルダ
（省略可）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 Functions
この表では、example.com という名前のカスタム ドメインがあり、すべての 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 サービスがこのドメインにマッピングされていることを前提としています。
| サービス名、バージョン | カスタム ドメイン 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 を既存のバックエンド サービスに追加するには:
- Google Cloud コンソールの [ロード バランシング] ページに移動します。
[ロード バランシング] ページに移動 - バックエンド サービスを編集するロードバランサの名前をクリックします。
- [ロードバランサの詳細] ページで、[編集 ] をクリックします。
- [Edit global external Application Load Balancer] ページで、[バックエンドの構成] をクリックします。
- [バックエンドの構成] ページで、変更するバックエンド サービスの [編集] をクリックします。
- [バックエンドを追加] をクリックします。
- [サーバーレス ネットワーク エンドポイント グループの作成] を選択します。
- [名前] に「
helloworld-serverless-neg」と入力します。 - [リージョン] で、us-central1 を選択します。
- [サーバーレス ネットワーク エンドポイント グループの種類] で、サーバーレス アプリが作成されたプラットフォーム（またはサービスまたは関数）を選択します。
- [URL マスクを使用] を選択します。
- URL マスクを入力します。URL マスクを作成する方法については、URL マスクの作成をご覧ください。
- [作成] をクリックします。
- [名前] に「
- [新しいバックエンド] で、[完了] をクリックします。
- [更新] をクリックします。
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/<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 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 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 Functions、API Gateway、および App Engine バックエンドを使用するバックエンド サービスでサポートされます。
外部アプリケーション ロードバランサで IAP を有効にする
注: IAP は Cloud CDN と互換性がありません。IAP を有効または無効にするように構成できます（デフォルトは無効です）。有効にした場合、oauth2-client-id と oauth2-client-secret の値を指定する必要があります。
IAP を有効にするには、バックエンド サービスを更新して、--iap=enabled フラグに oauth2-client-id と oauth2-client-secret を追加します。
gcloud compute backend-services update BACKEND_SERVICE_NAME \
--iap=enabled,oauth2-client-id=ID,oauth2-client-secret=SECRET \
--global
Google Cloud Armor を有効にする
Google Cloud Armor は、分散型サービス拒否（DDoS）攻撃からすべての GCLB プロキシ ロードバランサを保護するセキュリティ プロダクトです。Google Cloud Armor は、外部アプリケーション ロードバランサを介してアクセスされるサービスで構成可能なセキュリティ ポリシーも提供します。外部アプリケーション ロードバランサ用の Google Cloud Armor セキュリティ ポリシーについては、Google Cloud Armor セキュリティ ポリシーの概要をご覧ください。
Cloud Functions を使用している場合、internal-and-gclb Ingress 設定を使用すれば、デフォルトの URL に送信されるリクエストをブロックできます。
Cloud Run を使用している場合、上り（内向き）を内部と Cloud Load Balancing に制限することで、デフォルトの URL または Cloud Run を介して設定された他のカスタム ドメインに送信されるリクエストをブロックできます。
App Engine を使用している場合は、上り（内向き）制御を使用すると、ロードバランサ（VPC を使用している場合は VPC）から送信されるリクエストだけをアプリで受信できます。
適切な上り（内向き）設定がないと、ユーザーはサーバーレス アプリケーションのデフォルトの URL を使用して、ロードバランサ、Google Cloud Armor セキュリティ ポリシー、SSL 証明書、（ロードバランサを通過する）秘密鍵をバイパスできます。
省略可: デフォルトのバックエンド セキュリティ ポリシーを構成します。デフォルトのセキュリティ ポリシーでは、ユーザーが構成したしきい値を超えるトラフィックをスロットリングします。デフォルトのセキュリティ ポリシーの詳細については、レート制限の概要をご覧ください。
- Google Cloud Armor のデフォルトのセキュリティ ポリシーを無効にするには、バックエンド セキュリティ ポリシーのリストメニューで
Noneを選択します。 - [セキュリティ] セクションで [デフォルトのセキュリティ ポリシー] を選択します。
- [ポリシー名] フィールドで、自動生成された名前を受け入れるか、セキュリティ ポリシーの名前を入力します。
- [リクエスト数] フィールドで、デフォルトのリクエスト数を受け入れるか、
1～10,000の整数を入力します。 - [間隔] フィールドで、間隔を選択します。
- [キーへの適用] フィールドで、[すべて]、[IP アドレス]、[X-Forwarded-For IP アドレス] のいずれかの値を選択します。これらのオプションの詳細については、レート制限対象のクライアントを特定するをご覧ください。
ロギングとモニタリングを有効にする
外部アプリケーション ロードバランサのバックエンド サービスのログの有効化、無効化、表示を行えます。Google Cloud コンソールを使用する場合、サーバーレス NEG バックエンドを使用するバックエンド サービスではロギングがデフォルトで有効になります。gcloud を使用すると、必要に応じて各バックエンド サービスのロギングを無効にできます。手順については、ロギングをご覧ください。
また、ロードバランサは、モニタリング データを Cloud Monitoring にエクスポートします。モニタリング指標は、ロードバランサの構成、使用状況、パフォーマンスを評価する際に使用できます。指標は、問題のトラブルシューティングや、リソース使用率とユーザー エクスペリエンスの向上にも役立ちます。手順については、モニタリングをご覧ください。
サーバーレス NEG を削除する
バックエンド サービスに接続しているネットワーク エンドポイント グループは削除できません。NEG を削除する前に、NEG がバックエンド サービスから接続解除されていることを確認してください。
Console
- 削除するサーバーレス NEG が現在バックエンド サービスによって使用されていないことを確認するには、負荷分散の詳細設定メニューの [バックエンド サービス] タブに移動します。
[バックエンド サービス] タブに移動 - サーバーレス NEG が使用中の場合、次の操作を行います。
- サーバーレス NEG を使用するバックエンド サービスの名前をクリックします。
- [編集] をクリックします。
- [バックエンド] のリストで をクリックし、バックエンド サービスからサーバーレス NEG バックエンドを削除します。
- [保存] をクリックします。
- Google Cloud コンソールの [ネットワーク エンドポイント グループ] ページに移動します。
[ネットワーク エンドポイント グループ] ページに移動 - 削除するサーバーレス NEG のチェックボックスをオンにします。
- [削除] をクリックします。
- もう一度 [削除] をクリックして確定します。
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
次のステップ
- ロギングとモニタリングの使用
- サーバーレス NEG に関する問題のトラブルシューティング
- ロードバランサの設定をクリーンアップする
- Cloud Run バックエンドを使用した外部 HTTPS ロードバランサに Terraform モジュールを使用する