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

ネットワーク エンドポイント グループ（NEG）は、ロードバランサのバックエンド エンドポイントのグループを指定します。サーバーレス NEG は、Cloud Run、App Engine、Cloud Functions、または API Gateway を指すバックエンドです。

サーバーレス NEG は次のいずれかを表します。

• Cloud Run サービスまたはサービスのグループ。
• Cloud Functions の関数または関数のグループ。
• App Engine アプリ（スタンダードまたはフレキシブル）、アプリ内の特定のサービス、アプリの特定のバージョン、またはサービスのグループ。
• API Gateway。サービスの実装に関係なく、すべてのサービスで一貫した REST API を介してサービスへのアクセスを提供します。この機能はプレビュー版です。

重要: サービスのグループが同じサーバーレス NEG に含まれるには、共通の URL パターンが必要です。

サポートされているロードバランサ

次の表に、各アプリケーション ロードバランサでサポートされているサーバーレス プロダクトを示します。サーバーレス NEG は、プロキシ ネットワーク ロードバランサとパススルー ネットワーク ロードバランサではサポートされていません。

サーバーレスなプラットフォーム	アプリケーション ロードバランサ
	リージョン 内部	クロスリージョン 内部	グローバル 外部	従来	リージョン 外部
Cloud Run
App Engine
Cloud Functions

ユースケース

サーバーレス アプリでロードバランサを有効にすると、次のことができます。

• 他のサービスと共有しない 1 つの専用 IPv4 の IP アドレスからサーバーレス アプリを運用できるように構成する。
• 同じドメインで動作する複数のサーバーレス関数またはサービスに 1 つの URL をマッピングする。このドキュメントの URL マスクをご覧ください。
• 他の Google Cloud コンピューティング プラットフォームと URL 空間を共有する。複数のバックエンド サービスを使用することで、1 つのロードバランサが複数のバックエンド タイプにトラフィックを送信できるようになります。ロードバランサは、リクエスト URL のホストまたはパスに基づいて適切なバックエンド サービスを選択します。
• Compute Engine、Google Kubernetes Engine、Cloud Storage で使用する同じ SSL 証明書と秘密鍵を再利用する。同じ証明書を再利用することで、サーバーレス アプリの個別の証明書を管理する必要がなくなります。

グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサ

グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサを設定すると、サーバーレス アプリを既存のクラウド サービスと統合できます。以下のことを行うことができます。

• Google Cloud Armor を使用してサービスを保護する。これは、外部アプリケーション ロードバランサ経由でアクセスするすべてのサービスで利用できるエッジ DDoS 対策 / WAF セキュリティ プロダクトです。この機能には制限事項がいくつかあります。特に Cloud Run と App Engine に関する制限があります。
• サービスで Cloud CDN を使用して配信を最適化できるようにする。Cloud CDN はユーザーの近くにあるコンテンツをキャッシュに保存します。Cloud CDN は、キャッシュの無効化や Cloud CDN 署名付き URL などの機能を提供します。
• Google の Edge インフラストラクチャを使用して、ユーザーの近くで HTTP(S) 接続を終端することでレイテンシを短縮する。

サーバーレス コンピューティング バックエンドを使用してロードバランサを構成する方法については、次のドキュメントをご覧ください。

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

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

リージョン外部アプリケーション ロードバランサ

リージョン外部アプリケーション ロードバランサを使用すると、Cloud Run バックエンドで規制要件またはコンプライアンス要件のあるワークロードを実行できます。たとえば、アプリケーションのネットワーク構成とトラフィックの終端を特定のリージョンに配置する必要がある場合は、地域の適用法令を遵守するため、リージョン外部アプリケーション ロードバランサがよく使用されています。

サーバーレス コンピューティング バックエンドを使用してリージョン外部アプリケーション ロードバランサを構成する方法については、Cloud Run を使用してリージョン外部アプリケーション ロードバランサを設定するをご覧ください。

リージョン内部アプリケーション ロードバランサとクロスリージョン内部アプリケーション ロードバランサ

内部アプリケーション ロードバランサが Cloud Run バックエンドで構成されている場合、次のことが可能になります。

• Cloud Run サービスで、フォールト インジェクション、ヘッダーの書き換え、リダイレクト、トラフィック分割などの高度なトラフィック管理機能を有効にします。
• Compute Engine、GKE、オンプレミスからレガシー サービスを Cloud Run にシームレスに移行し、重み付けベースのトラフィック分割を活用して、ダウンタイムを発生させずにトラフィックを徐々に Cloud Run に移行します。
• VPC Service Controls で Cloud Run サービスを保護します。
• Cloud Run、Compute Engine、GKE で実行されているサービスに対して、ポリシーを適用する内部上り（内向き）ポイントを 1 つ確立します。

サーバーレス コンピューティング バックエンドを使用してリージョン内部アプリケーション ロードバランサを構成する方法については、Cloud Run を使用してリージョン内部アプリケーション ロードバランサを設定するをご覧ください。

このページの残りの部分では、アプリケーション ロードバランサでサーバーレス NEG を使用する方法について説明します。他のタイプの NEG の詳細については、ネットワーク エンドポイント グループの概要をご覧ください。

エンドポイントの種類

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

サーバーレス NEG を作成するときは、Cloud Run、App Engine、API Gateway、Cloud Functions サービスの完全修飾ドメイン名（FQDN）を指定します。エンドポイントのタイプは SERVERLESS です。他のエンドポイント タイプは、サーバーレス NEG ではサポートされません。

1 つのサーバーレス NEG に複数のエンドポイントを設定することはできません。エンドポイントは、サーバーレス アプリケーションまたは URL マスクのいずれかを参照します。ロードバランサはサーバーレス コンピューティング アプリケーションのフロントエンドとして機能し、指定されたエンドポイントにトラフィックをプロキシします。ただし、バックエンド サービスが異なるリージョンに複数のサーバーレス NEG が存在する場合、ロードバランサはトラフィックを最も近いリージョンの NEG に送信し、リクエストのレイテンシを最小限に抑えます。

ネットワーク ティア

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

リージョン外部アプリケーション ロードバランサは常にスタンダード ティアです。

クロスリージョン内部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサは常にプレミアム ティアです。

ロード バランシングのコンポーネント

サーバーレス NEG バックエンドを使用するロードバランサには、バックエンド サービス専用の特別な構成が必要です。フロントエンドの構成は、他のプロキシベースの Google Cloud ロードバランサと同じです。また、内部アプリケーション ロードバランサには、ユーザーに代わって Envoy プロキシを実行するためのプロキシ専用サブネットが必要です。

次の図は、サーバーレス NEG のデプロイ例を示しています。

グローバル外部

この図は、サーバーレス NEG がグローバル外部アプリケーション ロードバランサ アーキテクチャにどのように適合するかを示しています。

サーバーレス アプリ用のグローバル外部アプリケーション ロードバランサ（クリックして拡大）

リージョン外部

次の図は、サーバーレス NEG がリージョン外部アプリケーション ロードバランサ アーキテクチャにどのように適合するかを示しています。

サーバーレス アプリ用のリージョン外部アプリケーション ロードバランサ（クリックして拡大）

リージョン内部

この図は、サーバーレス NEG がリージョン内部アプリケーション ロードバランサ モデルにどのように適合するかを示しています。

サーバーレス アプリ用のリージョン内部アプリケーション ロードバランサ（クリックして拡大）

クロスリージョン

この図は、サーバーレス NEG がクロスリージョン内部アプリケーション ロードバランサ モデルにどのように適合するかを示しています。

Cloud Run をデプロイしたクロスリージョン内部アプリケーション ロードバランサ（クリックして拡大）

フロントエンド コンポーネント

サーバーレス NEG バックエンドによるロード バランシングに、特別なフロントエンド構成は必要ありません。転送ルールは、IP アドレス、ポート、プロトコルに基づいてトラフィックをターゲット プロキシに転送するために使用されます。ターゲット プロキシはクライアントからの接続を終端します。

URL マップは、アプリケーション ロードバランサが適切なバックエンド サービスへのリクエストの URL ベースの転送を設定するために使用します。

これらの各コンポーネントの詳細については、特定のロードバランサの概要にあるアーキテクチャのセクションをご覧ください。

• 外部アプリケーション ロードバランサ
• 内部アプリケーション ロードバランサ

バックエンド サービス

バックエンド サービスは、ロードバランサに構成情報を提供します。ロードバランサは、バックエンド サービスからの情報を使用して、受信トラフィックを接続されている 1 つまたは複数のバックエンドに振り向けます。サーバーレス NEG は、特定のロードバランサのバックエンドとして使用できます。

ロードバランサのタイプに応じて、次の制限が適用されます。

• グローバル外部アプリケーション ロードバランサで使用されるグローバル バックエンド サービスには、複数のサーバーレス NEG を接続できますが、サーバーレス NEG はリージョンごとに 1 つだけ接続されます。
• リージョン内部アプリケーション ロードバランサとリージョン外部アプリケーション ロードバランサで使用されるリージョン バックエンド サービスには、1 つのサーバーレス NEG のみを接続できます。
• クロスリージョン内部アプリケーション ロードバランサで使用されるグローバル バックエンド サービスには、Cloud Run サービスのみを接続できます。

各サーバーレス NEG は次のいずれかを指すことができます。

• 単一の関数またはサービスの FQDN
• 同じドメインで動作する複数の関数やサービスを指す URL マスク

URL マスクは、ユーザー リクエストを正しいサービスにマッピングする方法をサーバーレス NEG バックエンドに指示する URL スキーマ テンプレートです。URL マスクは、アプリケーションにカスタム ドメインを使用し、同じドメインで複数のサービスを使用する場合に便利です。関数またはサービスごとに個別のサーバーレス NEG を作成する代わりに、カスタム ドメイン用の汎用 URL マスクを使用した NEG を作成できます。詳細と例については、URL マスクをご覧ください。

サーバーレス NEG をバックエンドとして追加する際のその他の制限については、制限事項をご覧ください。

サーバーレス NEG の外れ値検出

外れ値検出は、サーバーレス NEG が接続されたグローバル バックエンド サービスで有効にできるオプションの構成です。外れ値検出分析は、クロスリージョン内部アプリケーション ロードバランサとグローバル外部アプリケーション ロードバランサでのみ使用できます。従来のアプリケーション ロードバランサでは使用できません。外れ値検出分析では、HTTP レスポンス パターンに基づいて異常なサーバーレス NEG を特定し、新しいリクエストのほとんどを異常なサービスから正常なサービスにルーティングすることでエラー率を減らします。外れ値検出アルゴリズムの仕組みと制限事項については、次の例をご覧ください。

あるバックエンド サービスには 2 つのサーバーレス NEG が接続されていて、1 つは REGION_A リージョンに、もう 1 つは REGION_B リージョンに存在するとします。REGION_A リージョンのグローバル外部アプリケーション ロードバランサに対するバックエンドとして機能するサーバーレス NEG が応答しない場合、外れ値検出によってサーバーレス NEG が異常として識別されます。外れ値検出の分析に基づいて、新しいリクエストの一部が REGION_B リージョンのサーバーレス NEG に送信されます。

検出されたサーバーエラーの種類に応じて、次のいずれかの方法で外れ値検出を有効にできます。

• 連続する 5xx エラー。5xx シリーズの HTTP ステータス コードはエラーになります。
• 連続するゲートウェイ エラー。502、503、504 の HTTP ステータス コードのみがエラーになります。

外れ値検出を有効にした後でも、一部のリクエストが正常でないサービスに送信され、5XX エラーがクライアントに返される場合があることに留意します。これは、外れ値検出アルゴリズム（ロード バランシング プールからエンドポイントが除外されてプールに戻る）の結果が、ロードバランサのプロキシ インスタンスごとに独立して実行されるためです。ほとんどの場合、バックエンド サービスから受信したトラフィックは複数のプロキシ インスタンスにより処理されます。したがって、正常でないエンドポイントが検出され、一部のプロキシのみによってそれが排除される可能性があり、その間、他のプロキシが同じ異常なエンドポイントにリクエストを送信し続ける可能性があります。

エラー率をさらに低減するには、より積極的な外れ値検出パラメータを構成します。排除のしきい値（outlierDetection.baseEjectionTime）には、より大きな値を構成することをおすすめします。たとえば、outlierDetection.baseEjectionTime を 180 秒に設定し、QPS が継続して 100 を超えると、エラー率は 5% 未満になることがテストで示されます。外れ値検出 API の詳細については、グローバル バックエンド サービス API ドキュメントの outlierDetection をご覧ください。

バックエンド サービスにサーバーレス NEG が接続されている場合、次の outlierDetection フィールドはサポートされません。

• outlierDetection.enforcingSuccessRate
• outlierDetection.successRateMinimumHosts
• outlierDetection.successRateRequestVolume
• outlierDetection.successRateStdevFactor

外れ値検出を構成する方法については、サーバーレス バックエンドを使用してグローバル外部アプリケーション ロードバランサを設定する : 外れ値検出の有効化をご覧ください。

注: サーバーレス NEG の外れ値分析は、Identity-Aware Proxy（IAP）が有効になっているバックエンド サービスでは構成できません。これは、IAP 対応のバックエンド サービスでの外れ値検出分析プロセスでは、正常でないサーバーレス サービスが特定できないためです。そのため、新しいリクエストを正常なサーバーレス サービスにルーティングできません。

URL マスク

サーバーレス NEG バックエンドは、1 つの Cloud Run（該当する場合は App Engine または Cloud Functions）サービスを指すことも、複数のサービスを指す URL マスクを指すこともできます。URL マスクは、URL スキーマのテンプレートです。サーバーレス NEG はこのテンプレートを使用して、リクエストを適切なサービスにマッピングします。

URL マスクは、サーバーレス アプリケーションが Cloud Run、Cloud Functions、App Engine の複数のサービスで構成されている場合に、サーバーレス NEG を構成しやすくするオプション機能です。内部アプリケーション ロードバランサで使用されるサーバーレス NEG は、Cloud Run サービスを指す URL マスクのみを使用できます。

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

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

URL マスクを使用してトラフィックを異なるサービスに配信（クリックして拡大）

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

制限事項

• サーバーレス NEG に、IP アドレスやポートなどのネットワーク エンドポイントを設定することはできません。
• サーバーレス NEG は、NEG が作成されているリージョンにあるサーバーレス アプリケーションのみを指すことができます。
• サーバーレス NEG バックエンドを使用しているロードバランサの場合、サーバーレス NEG は NEG が指す背後の Cloud Run、App Engine、API Gateway、または Cloud Functions サービスと同じプロジェクトに作成する必要があります。サーバーレス NEG と同じプロジェクトにないサービスを接続すると、リクエストが失敗することがあります。
• サーバーレス NEG で構成されたロードバランサは、基盤となるサーバーレス アプリやサービスが期待どおりに動作しているかどうかを検出できません。つまり、サービスがエラーを返しても、ロードバランサはそのサービスにトラフィックを転送します。ユーザー トラフィックを転送する前に、サービスの新しいバージョンを入念にテストしてください。

バックエンド サービスの制限事項

サーバーレス NEG バックエンドを使用するバックエンド サービスには、次の制限が適用されます。

• グローバル外部アプリケーション ロードバランサが使用するグローバル バックエンド サービスには、リージョンごとに 1 つのサーバーレス NEG のみを含めることができます。1 つのバックエンド サービスで複数のサーバーレス NEG を組み合わせるには、すべての NEG が異なるリージョンで機能的に同等のデプロイを表す必要があります。たとえば、NEG は、異なるリージョンにデプロイされた同じ Cloud Run、App Engine、または Cloud Functions サービスを指すことができます。
• クロスリージョン内部アプリケーション ロードバランサで使用されるグローバル バックエンド サービスには、Cloud Run サービスを 1 つだけ接続できます。
• リージョン バックエンド サービスには、サーバーレス NEG を 1 つだけ接続できます。
• 共有 VPC デプロイでのプロジェクト間のサービス参照は、サーバーレス NEG を含む構成でサポートされています。この機能を使用するには、ロードバランサのバックエンド コンポーネント（バックエンド サービスとサーバーレス NEG）とは異なるプロジェクトにロードバランサのフロントエンド コンポーネント（IP アドレス、転送ルール、ターゲット プロキシ、URL マップ）を作成します。バックエンド サービス、関連するサーバーレス NEG、バッキング サーバーレス サービス（Cloud Run、App Engine、API Gateway、または Cloud Functions）は、常に同じプロジェクトに作成する必要があります。
• バックエンド サービスのタイムアウト設定は、サーバーレス NEG バックエンドを使用するバックエンド サービスには適用されません。バックエンド サービスの resource.timeoutSec プロパティを変更しようとすると、次のエラーが発生します。Timeout sec is not supported for a backend service with Serverless network endpoint groups
  サーバーレス NEG バックエンドを使用するバックエンド サービスの場合、デフォルトのタイムアウトは 60 分です。このタイムアウトは構成できません。アプリケーションで長時間の接続が必要な場合は、失敗時にリクエストを再試行するようにクライアントを構成します。
• バックエンド サービスで組み合わせたすべてのサーバーレス NEG も、同じタイプのバックエンドを使用する必要があります。つまり、Cloud Run サーバーレス NEG は、他の Cloud Run サーバーレス NEG とのみ組み合わせることができ、App Engine サーバーレス NEG は App Engine サーバーレス NEG とのみ組み合わせることができます。
• サーバーレス NEG と他のタイプの NEG を同じバックエンド サービスで混在させることはできません。たとえば、同じバックエンド サービスから GKE クラスタと Cloud Run サービスに転送することはできません。
• サーバーレス NEG に転送するバックエンド サービスを設定する場合、特定のフィールドが制限されます。
  • 分散モードは指定できません。つまり、RATE、UTILIZATION、CONNECTION の値はロードバランサのトラフィック分散に影響しません。
  • ヘルスチェックはサーバーレス バックエンドではサポートされていません。したがって、サーバーレス NEG バックエンドを含むバックエンド サービスは、ヘルスチェックで構成できません。ただし、外れ値検出を有効にして、異常なサーバーレス サービスを特定し、新しいリクエストを正常なサーバーレス サービスにルーティングすることもできます。
• サーバーレス NEG バックエンドのバックエンド サービスを変更するのに、gcloud compute backend-services edit を使用することはできません。代わりに gcloud compute backend-services update コマンドを使用します。

ロードバランサとサーバーレス バックエンドのタイプに応じて、追加の制限が適用されます。

リージョン内部アプリケーション ロードバランサとリージョン外部アプリケーション ロードバランサの制限事項

• リージョン内部アプリケーション ロードバランサまたはリージョン外部アプリケーション ロードバランサで使用されるサーバーレス NEG は、Cloud Run サービスのみを参照できます。
• サーバーレス NEG を使用しているプロジェクトの場合、リージョン外部アプリケーション ロードバランサまたはリージョン内部アプリケーション ロードバランサで構成されたサーバーレス NEG に送信されるトラフィックの秒間クエリ数（QPS）の上限は、プロジェクトごとに 5,000 QPS です。この上限は、プロジェクト内のすべてのリージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサで集計されます。これはロードバランサごとの上限ではありません。

クロスリージョン内部アプリケーション ロードバランサの制限事項

• クロスリージョン内部アプリケーション ロードバランサで使用されるサーバーレス NEG は、Cloud Run サービスのみを指すことができます。

グローバル外部アプリケーション ロードバランサの制限事項

このセクションでは、グローバル外部アプリケーション ロードバランサを使用してサーバーレス NEG を構成するときに発生する制限事項について説明します。

App Engine の制限事項

• App Engine フレキシブル環境バックエンドを備えたグローバル外部アプリケーション ロードバランサでは、プロジェクト間のサービス参照を使用できません。App Engine スタンダード環境がサポートされています。

Cloud Run の制限事項

• サーバーレス NEG を使用する外部アプリケーション ロードバランサは、Cloud Run for Anthos をサポートしていません。
• 外部アプリケーション ロードバランサは、Cloud Run サービスへの認証済みリクエストをサポートしていません。

Cloud Functions の制限事項

• IAP は Cloud Functions では機能しません。

App Engine の制限事項

• マルチリージョンの負荷分散は App Engine ではサポートされていません。これは、App Engine がプロジェクトごとに 1 つのリージョンを必要とするためです。
• リクエストパスで使用できる IAP ポリシーは 1 つだけです。たとえば、バックエンド サービスですでに IAP ポリシーを設定している場合は、App Engine アプリに別の IAP ポリシーを設定しないでください。

• アプリがロードバランサ（および使用している場合は VPC）から送信されたリクエストのみを受信するように、上り（内向き）制御を使用することをおすすめします。使用しない場合、ユーザーはアプリの App Engine URL を使用して、ロードバランサ、Google Cloud Armor セキュリティ ポリシー、SSL 証明書、ロードバランサを経由して渡される秘密鍵をバイパスできます。

API Gateway の制限事項

詳細については、サーバーレス NEG と API Gateway の制限をご覧ください。

料金

サーバーレス NEG を使用するロードバランサの料金情報については、すべてのネットワーキングの料金: Cloud Load Balancing をご覧ください。

次のステップ

• Cloud Run、App Engine、または Cloud Functions を使用してグローバル外部アプリケーション ロードバランサを設定する
• Cloud Run、App Engine、または Cloud Functions を使用して従来のアプリケーション ロードバランサを設定する
• Cloud Run バックエンドを使用してリージョン外部アプリケーション ロードバランサを設定する
• Cloud Run バックエンドを使用してリージョン内部アプリケーション ロードバランサを設定する
• Cloud Run でクロスリージョン内部アプリケーション ロードバランサを設定する