Cloud Run、App Engine、または Cloud Run functions を使用して従来のアプリケーション ロードバランサを設定する

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

• App Engine
• Cloud Run functions
• Cloud Run

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

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

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

始める前に

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

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

このページで説明する手順では、Cloud Run、Cloud Run functions、または 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 ロールを持っている必要があります。

外部 IP アドレスを予約する

サービスが稼働し始めたので、ロードバランサにユーザーが接続する際に使用するグローバル静的外部 IP アドレスを設定します。

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

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 バックエンドのみを使用する場合、ヘルスチェックを許可するファイアウォール ルールを作成する必要はありません。

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

ロードバランサが作成されたら、ロードバランサに関連付けられた 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 アドレスで始めることもできます。

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. プレミアム ネットワーク サービス ティアを使用してフロントエンド構成を設定します。

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

このセクションでは、このページで前述したロードバランサの設定に基づき、同じリージョンにある 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 を追加する手順は次のとおりです。

マルチリージョンの 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 マスクからパスを完全に省略できます。

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

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

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

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

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 を有効または無効にするように構成できます（デフォルトは無効です）。有効にした場合、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 証明書、（ロードバランサを通過する）秘密鍵をバイパスできます。

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

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

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

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

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

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

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

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

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

次のステップ

• ロギングとモニタリングの使用
• サーバーレス NEG に関する問題のトラブルシューティング
• ロードバランサの設定をクリーンアップする
• Cloud Run バックエンドを使用した外部 HTTPS ロードバランサに Terraform モジュールを使用する