このページでは、リクエストをサーバーレス バックエンドにルーティングする外部アプリケーション ロードバランサを作成する方法を説明します。ここでのサーバーレスという用語は、次のサーバーレス コンピューティング プロダクトを指します。
- App Engine
- Cloud Run 関数
- Cloud Run
外部アプリケーション ロードバランサと API Gateway の統合により、サーバーレス バックエンドは Cloud Load Balancing のすべての機能を活用できるようになります。トラフィックを API Gateway にルーティングするように外部アプリケーション ロードバランサを構成するには、API Gateway の外部アプリケーション ロードバランサ スタートガイドをご覧ください。API Gateway の外部アプリケーション ロードバランサ サポートはプレビュー版です。
サーバーレス NEG を使用すると、外部アプリケーション ロードバランサを適用した Google Cloud サーバーレス アプリを使用できます。サーバーレス NEG バックエンドを使用してロードバランサを構成した後は、そのロードバランサへのリクエストがサーバーレス アプリのバックエンドにルーティングされるようになります。
サーバーレス NEG の詳細については、サーバーレス NEG の概要をご覧ください。
従来のアプリケーション ロードバランサの既存のユーザーで、グローバル外部アプリケーション ロードバランサで新しいデプロイを計画する場合は、移行の概要をご覧ください。始める前に
- App Engine、Cloud Run 関数、または Cloud Run のサービスをデプロイする。
- まだ行っていない場合は、Google Cloud CLI をインストールする。
- 権限を構成する。
- 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 アドレスを設定します。
コンソール
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 レコードが必要です。また、前の手順で作成したロードバランサの IP アドレス(
example-ip
)を指すようにドメインの DNS A レコードを更新する必要があります。詳しい手順については、Google マネージド証明書をご覧ください。自己署名証明書。この段階でドメインを設定したくない場合は、テスト用に自己署名 SSL 証明書を使用できます。
この例では、SSL 証明書リソースがすでに作成されていることを前提としています。
SSL 証明書リソース(または Google マネージド証明書で必要とされるドメイン)を作成せずにこのプロセスをテストする場合、このページの手順を使用して代わりに HTTP ロードバランサを設定できます。
ロードバランサを作成する
次の図では、ロードバランサがサーバーレス NEG バックエンドを使用して、リクエストをサーバーレス Cloud Run サービスに転送しています。この例では、Cloud Run Python クイックスタートを使用して Cloud Run サービスをデプロイしています。
サーバーレス NEG バックエンドを使用するバックエンド サービスではヘルスチェックがサポートされません。したがって、ロードバランサでサーバーレス NEG バックエンドのみを使用する場合、ヘルスチェックを許可するファイアウォール ルールを作成する必要はありません。
Console
構成を開始する
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
- [ロードバランサを作成] をクリックします。
- [ロードバランサの種類] で [アプリケーション ロードバランサ(HTTP / HTTPS)] を選択し、[次へ] をクリックします。
- [インターネット接続または内部] で [インターネット接続(外部)] を選択し、[次へ] をクリックします。
- [グローバルまたはシングル リージョンのデプロイ] で [グローバル ワークロードに最適] を選択し、[次へ] をクリックします。
- [ロードバランサの世代] で [グローバル外部アプリケーション ロードバランサ] を選択し、[次へ] をクリックします。
- [構成] をクリックします。
基本構成
- ロードバランサの名前に「
serverless-lb
」と入力します。 - ウィンドウを開いたままにして続行します。
フロントエンドの構成
- [フロントエンドの構成] をクリックします。
- [名前] に名前を入力します。
-
HTTPS ロードバランサを作成するには、SSL 証明書(
gcloud compute ssl-certificates list
)が必要です。前述のように、Google マネージド証明書を使用することをおすすめします。
- [完了] をクリックします。
外部アプリケーション ロードバランサを構成するには、各フィールドを次のように指定します。
以下のオプションが次の値で構成されていることを確認します。
プロパティ | 値(値を入力するか、指定されたオプションを選択) |
---|---|
プロトコル | 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 秒です。 |
バックエンドの構成
- [バックエンドの構成] をクリックします。
- [バックエンド サービスとバックエンド バケット] リストで、[バックエンド サービスを作成] をクリックします。
- [名前] に名前を入力します。
- [バックエンド タイプ] で、[サーバーレス ネットワーク エンドポイント グループ] を選択します。
- [プロトコル] は変更せず、そのままにします。このパラメータは無視されます。
- [バックエンド] セクションの [新しいバックエンド] で、[サーバーレス ネットワーク エンドポイント グループを作成] を選択します。
- [名前] に名前を入力します。
- [リージョン] で、[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_MANAGED \ --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 証明書リソースを作成するには、次のコマンドを実行します。 セルフマネージド SSL 証明書リソースを作成するには、次のコマンドを実行します。gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \ --domains DOMAIN
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 \ --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 マップの名前。
- 受信リクエストをプロキシに転送する転送ルールを作成します。
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.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 を作成します。
- プレミアム Network Service Tiers を使用してフロントエンド構成を設定します。
- 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 コンソールで、[ロード バランシング] ページに移動します。
バックエンド サービスを編集するロードバランサの名前をクリックします。
[ロードバランサの詳細] ページで、[
編集] をクリックします。[グローバル外部アプリケーション ロードバランサの編集] ページで、[バックエンドの構成] をクリックします。
[バックエンドの構成] ページで、変更するバックエンド サービスの [
編集] をクリックします。[バックエンド] セクションで、[バックエンドを追加] をクリックします。
[サーバーレス ネットワーク エンドポイント グループ] リストで、[サーバーレス ネットワーク エンドポイント グループの作成] を選択します。
サーバーレス NEG の名前を入力します。
[リージョン] で
europe-west1
を選択します。[サーバーレス ネットワーク エンドポイント グループの種類] では、[Cloud Run] を選択し、次の操作を行います。
- [サービスの選択] オプションを選択します。
- [サービス] リストで、ロードバランサを作成する Cloud Run サービスを選択します。
[作成] をクリックします。
[新しいバックエンド] ページで、[完了] をクリックします。
[保存] をクリックします。
バックエンド サービスを更新するには、[更新] をクリックします。
ロードバランサを更新するには、[グローバル外部アプリケーション ロードバランサの編集] ページで [更新] をクリックします。
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 Run 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 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 を既存のバックエンド サービスに追加するには:
- Google Cloud Console の [Cloud Load Balancing] ページに移動します。
[負荷分散] ページに移動 - バックエンド サービスを編集するロードバランサの名前をクリックします。
- [ロードバランサの詳細] ページで、[編集] をクリックします。
- [Edit global external Application Load Balancer] ページで、[Backend configuration] をクリックします。
- [バックエンドの構成] ページで、変更するバックエンド サービスの [編集] をクリックします。
- [バックエンドを追加] をクリックします。
- [サーバーレス ネットワーク エンドポイント グループの作成] を選択します。
- [名前] に「
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 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-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 コンソール、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 証明書、(ロードバランサを通過する)秘密鍵をバイパスできます。
省略可: デフォルトのバックエンド セキュリティ ポリシーを構成します。デフォルトのセキュリティ ポリシーでは、ユーザーが構成したしきい値を超えるトラフィックをスロットリングします。デフォルトのセキュリティ ポリシーの詳細については、レート制限の概要をご覧ください。
- Google Cloud Armor のデフォルトのセキュリティ ポリシーを無効にするには、バックエンド セキュリティ ポリシーのリストメニューで
None
を選択します。 - [セキュリティ] セクションで [デフォルトのセキュリティ ポリシー] を選択します。
- [ポリシー名] フィールドで、自動生成された名前を受け入れるか、セキュリティ ポリシーの名前を入力します。
- [リクエスト数] フィールドで、デフォルトのリクエスト数を受け入れるか、
1
~10,000
の整数を入力します。 - [間隔] フィールドで、間隔を選択します。
- [キーへの適用] フィールドで、[すべて]、[IP アドレス]、[X-Forwarded-For IP アドレス] のいずれかの値を選択します。これらのオプションの詳細については、レート制限対象のクライアントを特定するをご覧ください。
ロギングとモニタリングを有効にする
外部アプリケーション ロードバランサのバックエンド サービスのログの有効化、無効化、表示を行えます。Google Cloud コンソールを使用する場合、サーバーレス NEG バックエンドを使用するバックエンド サービスではロギングがデフォルトで有効になります。gcloud
を使用すると、必要に応じて各バックエンド サービスのロギングを無効にできます。手順については、ロギングをご覧ください。
また、ロードバランサは、モニタリング データを Cloud Monitoring にエクスポートします。モニタリング指標は、ロードバランサの構成、使用状況、パフォーマンスを評価する際に使用できます。指標は、問題のトラブルシューティングや、リソース使用率とユーザー エクスペリエンスの向上にも役立ちます。手順については、モニタリングをご覧ください。
クライアント HTTP キープアライブ タイムアウトを更新する
前の手順で作成したロードバランサは、クライアント HTTP キープアライブ タイムアウトのデフォルト値で構成されています。クライアントの HTTP キープアライブ タイムアウトを更新するには、次の操作を行います。
コンソール
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
- 変更するロードバランサの名前をクリックします。
- [ 編集] をクリックします。
- [フロントエンドの構成] をクリックします。
- [高度な機能] を開きます。[HTTP キープアライブ タイムアウト] にタイムアウト値を入力します。
- [更新] をクリックします。
- 変更を確認するには、[確認と完了] をクリックして、[更新] をクリックします。
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
)。このメソッドは、502
、503
、504
の HTTP ステータス コードのみエラーとみなされます。
既存のバックエンド サービスで外れ値検出を有効にするには、次の操作を行います。外れ値検出を有効にした後でも、一部のリクエストが正常でないサービスに送信され、5xx
ステータス コードがクライアントに返される場合があることに注意してください。エラー率をさらに低減するには、外れ値検出パラメータ用により積極的な値を構成します。詳しくは、outlierDetection
フィールドをご覧ください。
コンソール
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
バックエンド サービスを編集するロードバランサの名前をクリックします。
[ロードバランサの詳細] ページで、[
編集] をクリックします。[Edit global external Application Load Balancer] ページで、[バックエンドの構成] をクリックします。
[バックエンドの構成] ページで、変更するバックエンド サービスの [
編集] をクリックします。下にスクロールして [高度な構成] セクションを開きます。
[外れ値検出] セクションで、[有効にする] チェックボックスをオンにします。
[
編集] をクリックして外れ値検出を構成します。以下のオプションが次の値で構成されていることを確認します。
プロパティ 値 連続するエラー 5 間隔 1000 ベースの排出時間 30000 最大排出率 50 連続するエラーの適用 100 この例では、外れ値検出分析が 1 秒ごとに実行されます。Envoy プロキシが連続して受信した HTTP
5xx
ステータス コードの数が 5 以上の場合、バックエンド エンドポイントは Envoy プロキシのロード バランシング プールから 30 秒間除外されます。適用の割合が 100% に設定されている場合、バックエンド サービスでは、外れ値検出分析が実行されるたびに、これらの特定の Envoy プロキシのロード バランシング プールから正常でないエンドポイントが排出されます。除外条件が満たされると、ロード バランシング プールからバックエンド エンドポイントの最大 50% が排出されます。[保存] をクリックします。
バックエンド サービスを更新するには、[更新] をクリックします。
ロードバランサを更新するには、[Edit global external Application Load Balancer] ページで [更新] をクリックします。
gcloud
バックエンド サービスを YAML ファイルにエクスポートします。
gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME.yaml --global
BACKEND_SERVICE_NAME
は、バックエンド サービスの名前に置き換えます。outlierDetection
セクションの次の YAML 構成でハイライト表示されているように、バックエンド サービスの YAML 構成を編集して、外れ値検出のフィールドを追加します。この例では、外れ値検出分析が 1 秒ごとに実行されます。Envoy プロキシが連続して受信した HTTP
5xx
ステータス コードの数が 5 以上の場合、バックエンド エンドポイントは Envoy プロキシのロード バランシング プールから 30 秒間除外されます。適用の割合が 100% に設定されている場合、バックエンド サービスでは、外れ値検出分析が実行されるたびに、これらの特定の Envoy プロキシのロード バランシング プールから正常でないエンドポイントが排出されます。除外条件が満たされると、ロード バランシング プールからバックエンド エンドポイントの最大 50% が排出されます。name: BACKEND_SERVICE_NAME backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME - balancingMode: UTILIZATION capacityScaler: 1.0 group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2 outlierDetection: baseEjectionTime: nanos: 0 seconds: 30 consecutiveErrors: 5 enforcingConsecutiveErrors: 100 interval: nanos: 0 seconds: 1 maxEjectionPercent: 50 port: 80 selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME sessionAffinity: NONE timeoutSec: 30 ...
次のように置き換えます。
BACKEND_SERVICE_NAME
: バックエンド サービスの名前PROJECT_ID
: オブジェクトの IDREGION_A
とREGION_B
: ロードバランサを構成したリージョンSERVERLESS_NEG_NAME
: 最初のサーバーレス NEG の名前SERVERLESS_NEG_NAME_2
: 2 番目のサーバーレス NEG の名前
最新の構成をインポートして、バックエンド サービスを更新します。
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME.yaml --global
バックエンド サービスで外れ値検出が有効になりました。
サーバーレス NEG を削除する
バックエンド サービスに接続しているネットワーク エンドポイント グループは削除できません。NEG を削除する前に、NEG がバックエンド サービスから接続解除されていることを確認してください。
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 モジュールを使用する