サーバーレス ネットワーク エンドポイント グループの概要

ネットワーク エンドポイント グループ(NEG)は、ロードバランサのバックエンド エンドポイントのグループを指定します。サーバーレス NEG は、Cloud RunApp Engine、または Cloud Functions サービスを指すバックエンドです。

サーバーレス NEG は次のいずれかに相当します。

  • Cloud Run サービス、または同じ URL パターンを共有する複数のサービス。
  • Cloud Functions の関数、または同じ URL パターンを共有する関数のグループ。
  • App Engine アプリ(スタンダードまたはフレキシブル)、アプリ内の特定のサービス、またはアプリの特定のバージョン。

サーバーレス アプリで HTTP(S) 負荷分散を有効にすると、次のことが可能になります。

  • 他のサービスと共有しない 1 つの専用 IPv4 または IPv6 の IP アドレスからサーバーレス アプリを運用できるように構成する。
  • 異なるリージョンで実行されている、複数の機能的に同等なサーバレス サービスに 1 つの URL をマッピングし、ユーザーに最も近いリージョンにリクエストを転送する。これは、Cloud Run(フルマネージド)と Cloud Functions でのみサポートされています。
  • Compute Engine、Google Kubernetes Engine、Cloud Storage で使用する同じ SSL 証明書と秘密鍵を再利用する。これにより、サーバーレス アプリの個別の証明書を管理する必要がなくなります。

HTTP(S) 負荷分散を設定すると、サーバーレス アプリを既存のクラウド サービスと統合することもできます。次のことが可能です。

  • 他の Google Cloud テクノロジーと URL 空間を共有する。複数のバックエンド サービスを使用することで、単一の外部 HTTP(S) ロードバランサは、リクエスト URL のホストまたはパスに基づいて、トラフィックを、Cloud Run(フルマネージド)、App Engine、Cloud Functions、Compute Engine、Google Kubernetes Engine、Cloud Storage に送信できます。
  • Google Cloud Armor を使用してサービスを保護する。これは、外部 HTTP(S) ロードバランサ経由でアクセスするすべてのサービスで利用できるエッジ DDoS 防御 / WAF セキュリティ プロダクトです。この機能には、特に Cloud Run(フルマネージド)と App Engine に関連する制限事項がいくつかあります。
  • サービスで Cloud CDN を使用して配信を最適化できるようにする。Cloud CDN を使用すると、ユーザーの近くにコンテンツをキャッシュ保存できます。Cloud CDN は、キャッシュの無効化や Cloud CDN 署名付き URL などの機能を提供します。
  • Google の Edge インフラストラクチャを使用して、ユーザーの近くで HTTP(S) 接続を終端することでレイテンシを短縮します。

このドキュメントの残りの部分では、HTTP(S) 負荷分散でサーバーレス NEG を使用する方法について説明します。他のタイプのロードバランサでは、サーバーレス NEG を使用できません。

他のタイプの NEG について詳しくは、以下をご覧ください。

エンドポイント タイプ

サーバーレス NEG には、ポートや IP アドレスなどのネットワーク エンドポイントはありません。NEG と同じリージョンにある既存の Cloud Run(フルマネージド)App EngineCloud Functions サービスのみを指します。

サーバーレス NEG を作成するときは、Cloud Run(フルマネージド)App EngineCloud Functions サービスの完全修飾ドメイン名(FQDN)を指定します。エンドポイントのタイプは SERVERLESS です。他のエンドポイント タイプは、サーバーレス NEG ではサポートされません。

1 つのサーバーレス NEG に複数のエンドポイントを設定することはできません。各サーバーレス NEG で使用できるエンドポイントは 1 つのみであるため、ロードバランサはフロントエンドとしてのみ機能し、指定したサーバーレス エンドポイントにトラフィックをプロキシします。ただし、バックエンド サービスに複数のサーバーレス NEG が含まれている場合、ロードバランサはこれらの NEG 間でトラフィックを分散し、リクエストのレイテンシを最小限に抑えます。

ネットワーク階層

スタンダード ティアまたはプレミアム ティアのネットワーク サービスを使用して、ロードバランサでサーバーレス NEG を使用できます。プレミアム ティアは、複数のリージョンでサーバーレス NEG を設定する場合にのみ必要です。

負荷分散コンポーネント

次の図は、HTTP(S) 負荷分散モデルにサーバーレス NEG がどのように収まるかを示しています。

シンプルな HTTPS 負荷分散(クリックして拡大)
サーバーレス アプリの HTTP(S) 負荷分散

転送ルール

転送ルールは、フロントエンドの構成の一部であり、外部 IP アドレス、IP バージョン(IPv4 または IPv6)、プロトコル(HTTP または HTTPS(HTTP/2 を含む))、ポート番号(80 または 443)が含まれます。

ターゲット プロキシ

サーバーレス NEG は、HTTP および HTTPS ターゲット プロキシとのみ使用できます。サーバーレス NEG を使用するサービスは、TCP または SSL ターゲット プロキシとは使用できません。

URL マップ

外部 HTTP(S) ロードバランサの転送選択は、URL マップに基づいています。URL マップの場合、ターゲット HTTP(S) プロキシは、URL マップのリクエスト ホスト名とパスをチェックして、使用するバックエンド サービスを決定します。ロードバランサは URL マップで複数のバックエンド サービスを参照できます。各バックエンド サービスは、異なるバックエンド タイプに関連付けることができます。たとえば、サーバーレス NEG 用のバックエンド サービスと、Compute Engine インスタンス グループ用の別のバックエンド サービスを使用できます。

バックエンド サービス

サーバーレス NEG は、ロードバランサのバックエンド サービスのバックエンドとして使用できます。バックエンド サービスは複数のサーバーレス NEG によってサポートできます。ただし、各サーバーレス NEG が指すことができるのは、Cloud Run(フルマネージド)サービス、App Engine サービス、Cloud Functions サービスのいずれか 1 つの FQDN、もしくは同じドメインで複数のサービスを指す URL マスクのいずれかのみです。

URL マスクは、ユーザー リクエストを正しいサービスにマッピングする方法をサーバーレス NEG バックエンドに指示する URL スキーマ テンプレートです。URL マスクは、アプリケーションにカスタム ドメインを使用し、同じドメインで Cloud Run(フルマネージド)、Cloud Functions、App Engine という複数のサービスを使用する場合に便利です。このような場合は、Cloud Run(フルマネージド)、App Engine、Cloud Functions のサービスごとに個別のサーバーレス NEG を作成する代わりに、カスタム ドメイン(例: example.com/<service>)用の汎用 URL マスクで NEG を作成し、NEG がリクエストの URL からサービス名を抽出できるようにします。詳細と例については、URL マスクをご覧ください。

サーバーレス NEG をバックエンドとして追加する場合は、追加の制限事項があります。詳細については、制限事項をご覧ください。

URL マスク

URL マスクは、アプリケーションが Cloud Run(フルマネージド)、Cloud Functions、App Engine の複数のサービスで構成されている場合に、サーバーレス NEG を構成しやすくするオプション機能です。サーバーレス NEG バックエンドは、1 つの Cloud Run(フルマネージド)(または App Engine または Cloud Functions)サービスを指すことも、複数のサービスを指す URL マスクを指すこともできます。

URL マスクは、URL スキーマのテンプレートです。サーバーレス NEG はこのテンプレート(例えば、example.com/<service>)を使用して、受信リクエストの URL からサービス名を抽出し、そのリクエストを適切なサービスにマッピングします。

URL マスクが役立つのは、サーバーレス アプリが Google Cloud から割り当てられるデフォルトのアドレスではなく、カスタム ドメインにマッピングされている場合です。example.com などのカスタム ドメインを使用すると、Cloud Run(フルマネージド)、Cloud Functions、App Engine という複数のサービスを、同じドメインの異なるサブドメインまたはパスにデプロイできます。このような場合は、Cloud Run(フルマネージド)、App Engine、Cloud Functions のサービスごとに個別のサーバーレス NEG バックエンドを作成する代わりに、カスタム ドメイン(例: example.com/<service>)用の汎用 URL マスクで単一のサーバーレス NEG を作成し、NEG がリクエストの URL からサービス名を抽出できるようにします。

次の図は、URL マスクを使用してユーザー リクエストをさまざまなサービスにマッピングする、単一のバックエンド サービスとサーバーレス NEG を持つ外部 HTTP(S) ロードバランサを示しています。

サーバーレス アプリへのトラフィックの分散(クリックして拡大)
URL マスクを使用してトラフィックを異なるサービスに配信する

URL マスクは、アプリケーションのサービスで予測可能な URL スキーマを使用する場合に最適です。URL マップの代わりに URL マスクを使用する利点は、login サービスと search サービス用に別々のサーバーレス NEG を作成する必要がないことです。また、アプリケーションに新しいサービスを追加するたびにロードバランサの構成を変更する必要もありません。

サーバーレス NEG の URL マスクを作成して構成する方法については、サーバーレス NEG の設定をご覧ください。

制限事項

  • サーバーレス NEG に、IP アドレスやポートなどのネットワーク エンドポイントを設定することはできません。
  • サーバーレス NEG は、NEG が作成されているのと同じリージョンにある Cloud Run(フルマネージド)、App Engine、または Cloud Functions サービスのみを指すことができます。
  • サーバーレス NEG バックエンドを使用するロードバランサは、NEG が指す Cloud Run(フルマネージド)、App Engine、または Cloud Functions サービスと同じプロジェクトに作成する必要があります。
  • Cloud Monitoring は、サーバーレス NEG バックエンドではサポートされていません。他のタイプのバックエンドを使用するバックエンド サービスには影響しません。
  • サーバーレス NEG で構成された外部 HTTP(S) ロードバランサは、基盤となるサーバーレス リソース(App Engine、Cloud Functions、Cloud Run(フルマネージド)サービスなど)が想定どおりに動作しているかどうかを検出できません。つまり、あるリージョンのサービスがエラーを返しても、そのリージョンの Cloud Run(フルマネージド)、Cloud Functions、または App Engine インフラストラクチャ全体が正常に動作している場合、外部 HTTP(S) ロードバランサが他のリージョンにトラフィックを自動的に転送することはありません。ユーザー トラフィックを転送する前に、サービスの新しいバージョンを入念にテストしてください。

サーバーレス NEG バックエンドを使用するバックエンド サービスに関連する制限事項

  • バックエンド サービスに含めることができるサーバーレス NEG はリージョンごとに 1 つのみです。1 つのバックエンド サービスで複数のサーバーレス NEG を組み合わせる場合は、すべての NEG が異なるリージョンで機能的に同等のデプロイを表す必要があります。たとえば、NEG は、異なるリージョンにデプロイされた同じ Cloud Run(フルマネージド)、App Engine、または Cloud Functions サービスを指すことができます。
  • サーバーレス NEG バックエンド サービスのデフォルトのバックエンド サービス タイムアウト(30 秒)は変更できません。バックエンド サービスの構成を変更してタイムアウトを(resource.timeoutSec プロパティの設定により)長くしようとすると、Timeout sec is not supported for a backend service with Serverless network endpoint groups というエラーが発生します。
  • バックエンド サービスで組み合わせたすべてのサーバーレス NEG も、同じタイプのバックエンドを使用する必要があります。つまり、Cloud Run(フルマネージド)サーバーレス NEG は他の Cloud Run(フルマネージド)サーバーレス NEG とのみ組み合わせることができ、App Engine サーバーレス NEG は App Engine サーバーレス NEG とのみ組み合わせることができる、といったことになります。
  • サーバーレス NEG と他のタイプの NEG(ゾーン NEG やインターネット NEG)を同じバックエンド サービスで混在させることはできません。たとえば、同じバックエンド サービスから GKE クラスタと Cloud Run(フルマネージド)サービスに転送することはできません。
  • サーバーレス NEG に転送するバックエンド サービスを設定する場合、特定のフィールドが制限されます。
    • 分散モードは指定できません。つまり、RATEUTILIZATIONCONNECTION の値はロードバランサのトラフィック分散に影響しません。
    • ヘルスチェックはサーバーレス バックエンドではサポートされていません。したがって、サーバーレス NEG バックエンドを含むバックエンド サービスは、ヘルスチェックで構成できません。
  • サーバレス NEG バックエンドのバックエンド サービスを変更するのに、gcloud compute backend-services editを使用することはできません。代わりに gcloud compute backend-services update コマンドを使用します。

使用しているサーバーレス コンピューティング プラットフォームによっては、追加の制限が適用される場合があります。

Cloud Run(フルマネージド)の制限事項

  • Identity-Aware Proxy(IAP)は、Cloud Run(フルマネージド)では動作しません。
  • Google Cloud が Cloud Run(フルマネージド)サービスに自動的に割り当てる URL を無効にすることはできません。Cloud Run(フルマネージド)サービスのデフォルト URL をすでに持っているユーザーは、ロードバランサをバイパスして、サービス URL に直接アクセスできます。つまり、ロードバランサを使用して Google Cloud Armor セキュリティ ポリシーを構成できますが、デフォルトの URL を持つユーザーはこれらのポリシーを回避できます。

Cloud Functions の制限事項

  • IAP は Cloud Functions では機能しません。
  • Google Cloud が Cloud Functions の関数に自動的に割り当てる URL を無効にすることはできません。ただし、internal-and-gclb Ingress 設定を使用すると、内部トラフィックと、外部 HTTP(S) ロードバランサによって公開されるパブリック IP に送信されるトラフィックのみを許可できます。cloudfunctions.net または Cloud Functions で設定されたその他のカスタム ドメインへ送信されるトラフィックはブロックされます。これにより、ユーザーは、外部 HTTP(S) ロードバランサを介して設定されたアクセス制御(Google Cloud Armor セキュリティ ポリシーなど)を回避できなくなります。

App Engine の制限事項

  • マルチリージョンの負荷分散は App Engine ではサポートされていません。これは、App Engine がプロジェクトごとに 1 つのリージョンを必要とするためです。
  • リクエストパスで使用できる IAP ポリシーは 1 つだけです。たとえば、バックエンド サービスですでに IAP ポリシーを設定している場合は、App Engine アプリに別の IAP ポリシーを設定しないでください。
  • アプリがロードバランサ(および使用している場合は VPC)から送信されたリクエストのみを受信するように、上り(内向き)制御を使用することをおすすめします。使用しない場合、ユーザーはアプリの App Engine URL を使用して、ロードバランサ、Google Cloud Armor セキュリティ ポリシー、SSL 証明書、ロードバランサを経由して渡される秘密鍵をバイパスできます。

料金

サーバーレス NEG を使用する外部 HTTP(S) ロードバランサの料金情報については、ネットワークの料金をご覧ください。

次のステップ