インターネット ネットワーク エンドポイント グループの概要

ネットワーク エンドポイント グループ(NEG)は、ロードバランサのバックエンド エンドポイントのセットを定義します。インターネット NEG は、Google Cloud の外部にあるバックエンドです。Google Cloud 外部 HTTP(S) ロードバランサのバックエンド サービスとして、インターネット NEG をバックエンドとして使用できます。これは、Google Cloud 外部でホストされる送信元からコンテンツを提供し、外部 HTTP(S) ロードバランサをフロントエンドとして使用する場合に必要です。

これには、以下のメリットがあります。

  • Google Edge インフラストラクチャを使用してユーザー接続を終了できます。
  • カスタムの送信元に接続を転送できます。
  • カスタムの送信元に Cloud CDN を使用できます。
  • Google のプライベート バックボーンを通じてパブリック エンドポイントへトラフィックを転送することで、信頼性が向上し、クライアントとサーバー間のレイテンシが減少します。

このドキュメントでは、外部 HTTP(S) 負荷分散でインターネット ネットワーク エンドポイント グループを使用する方法について説明します。他の種類のロードバランサではインターネット NEG を使用できません。

「カスタムの送信元」、「外部エンドポイント」、「インターネット エンドポイント」という用語はいずれも同じ意味を持つため、互いに置き換えて使用できます。このドキュメントでは、internet endpoint を含むリソースとして internet NEG という用語を使用します。

ゾーン NEG の詳細については、ゾーン ネットワーク エンドポイント グループの概要をご覧ください。

サーバーレス NEG については、サーバーレス ネットワーク エンドポイント グループの概要をご覧ください。

概要

インターネット ネットワーク エンドポイント グループ(NEG)はグローバル リソースであり、オンプレミス インフラストラクチャ内またはサードパーティ プロバイダが提供するインフラストラクチャ内でホストされます。

外部 HTTP(S) ロードバランサのバックエンド サービスでインターネット NEG をバックエンドとして使用し、インターネット NEG を Cloud CDN の送信元として割り当てることができます。

エンドポイントの種類

インターネット ネットワーク エンドポイント グループを作成する場合、ネットワーク エンドポイントの種類として INTERNET_FQDN_PORT または INTERNET_IP_PORT を指定します。

エンドポイント アドレス 種類 定義 使うタイミング
ホスト名とオプションのポート INTERNET_FQDN_PORT 一般公開された解決可能な完全修飾ドメイン名とオプションのポート。例: backend.example.com:443(デフォルト ポート: HTTP の場合は 80、HTTPS の場合は 443 パブリック DNS を持つ完全修飾ドメイン名で外部の送信元を解決できる場合は、このエンドポイントを使用します。
IP アドレスとオプションのポート INTERNET_IP_PORT 公開アクセス可能な IP アドレスとオプションのポート。例: 8.8.8.88.8.8.8:443(デフォルト ポート: HTTP の場合は 80、HTTPS の場合は 443 接続先となる一般公開 IP アドレスとポートを指定するには、このエンドポイントを使用します。

インターネット NEG には複数のエンドポイントを指定できません。インターネット ネットワーク エンドポイント グループはエンドポイントの種類 GCE_VM_IP_PORT をサポートしません。

負荷分散のコンポーネントと仕様

プレミアム ティアのネットワーク サービスを利用して、ロードバランサのインターネット ネットワーク エンドポイント グループを使用できます。

ただし、各インターネット NEG では 1 つのインターネット エンドポイントしか使用できないため、負荷分散は実際には実行されません。つまり、レートや使用率などの負荷分散モードは使用できません。ロードバランサはフロントエンドとしてのみ機能し、トラフィックを指定されたインターネット エンドポイントにプロキシします。

転送選択は、URL マップに基づいて行われます。ターゲット HTTP(S) プロキシの場合、使用されるバックエンド サービスは、URL マップでリクエストのホスト名とパスを確認して決定されます。HTTP(S) ロードバランサには、URL マップから参照される複数のバックエンド サービスを設定できます。

  • 各外部 HTTP(S) ロードバランサには、適切なターゲット プロキシ オブジェクトにトラフィックを転送する独自のグローバル外部転送ルールがあります。

  • URL マップがインターネット NEG を含むバックエンド サービスにリクエストを送信すると、バックエンド サービスはそのインターネット NEG にトラフィックを転送します。

次の図は、複数の種類のバックエンド(1 つはインターネット NEG)を使用する外部 HTTP(S) ロードバランサを示しています。

負荷分散のインターネット ネットワーク エンドポイント グループ(クリックして拡大)
負荷分散のインターネット ネットワーク エンドポイント グループ(クリックして拡大)

バックエンド サービス

前のセクションで示したように、インターネット NEG は、外部 HTTP(S) ロードバランサのバックエンド サービスでサポートされるバックエンドの種類の 1 つです。Google のグローバル エッジ インフラストラクチャを使用して、カスタムの送信元の前でユーザーのリクエストを着信できます。

インターネット NEG をバックエンド サービスのバックエンドとして追加する場合:

  • バックエンド サービスでは、バックエンドとしてゾーン NEG またはインスタンス グループを使用できません。バックエンド サービス上のバックエンドはすべて同じ種類である必要があります。

  • 同じバックエンド サービスに追加できるインターネット NEG バックエンドは 1 つのみです。

  • インターネット NEG に追加できるエンドポイントは 1 つのみです。

  • バックエンド サービスではヘルスチェックを参照できません。

  • バックエンド サービスの負荷分散スキームは、EXTERNAL である必要があり、そのプロトコルは HTTPHTTPSHTTP2 のいずれかである必要があります。

  • インターネット NEG をバックエンドとして使用する場合に、バックエンド サービスの機能がサポートされます。該当する機能には次のものが含まれます。

ヘルスチェック

インターネット NEG をバックエンドとして使用するバックエンド サービスでは、ヘルスチェックはサポートされません。Google Cloud は、インターネット エンドポイントまたはカスタムの送信元向けのヘルスチェックを提供していません。

インターネット エンドポイントが到達不能になった場合、または構成されたホスト名(FQDN)が解決されない場合、外部 HTTP(S) ロードバランサは HTTP 502(不正なゲートウェイ)レスポンスをクライアントに返します。

リクエストの認証

外部 HTTP(S) ロードバランサがインターネット NEG にリクエストを送信できるようにするには、次のようにします。

  • dig や nslookup などのツールを使用して、_cloud-eoips.googleusercontent.com の DNS TXT レコードのクエリを実行します。CIDR(ip4: の後に続く部分)を書き留め、ファイアウォールまたはクラウドのアクセス制御リスト(ACL)でこれらの範囲が許可されていることを確認します。
  • カスタム リクエスト ヘッダーを使用して、リクエストが Google Cloud 外部 HTTP(S)ロードバランサから発行されたことを示すカスタム ヘッダーを設定できます。
    • たとえば、16 バイト以上の暗号論的乱数を共有キーとして使用できます。
  • Identity-Aware Proxy(IAP)を有効にして、リクエスト ヘッダーの署名済み JWT が Google によって署名されており、aud(オーディエンス)クレームに外部 HTTP(S) ロードバランサが定義されるプロジェクト番号が含まれていることを確認することもできます。IAP は Cloud CDN との互換性がありません。

SSL サーバー証明書の検証と SAN 検証

HTTPS または HTTP/2 をバックエンド プロトコルとして使用する場合は、INTERNET_FQDN_PORT を使用してインターネット エンドポイントを作成することを強くおすすめします。

INTERNET_FQDN_PORT を使用してインターネット エンドポイントを作成すると、ロードバランサによってインターネット エンドポイントが提示する SSL サーバー証明書が検証され、次の点が検証されます。

  • 証明書が既知の CA によって署名されていること。
  • 証明書の有効期限が切れていないこと。
  • 証明書の署名が有効であること。
  • 構成された FQDN が、証明書内のサブジェクト代替名(SAN)のいずれかと一致すること。

SSL Server Name Indication(SNI)拡張機能のサポート

SNI は、バックエンド プロトコルとして HTTPS または HTTP/2 で INTERNET_FQDN_PORT を使用する場合のみサポートされます。この場合、ロードバランサと外部エンドポイント間の SSL handshake 中の client hello 内で、構成された FQDN が SNI に送信されます。INTERNET_IP_PORT としてエンドポイントを構成している場合、IP アドレス リテラルは SNI ペイロードの HostName フィールドで許可されないため、SNI は送信されません。

FQDN エンドポイントの IP アドレス解決方法

INTERNET_FQDN_PORT エンドポイントが複数の IP アドレスを返す DNS レコードを指す場合、IP アドレスは次のように解決されます。

  • 外部 HTTP(S) ロードバランサは、DNS レスポンスの最初の IP アドレスへの接続を試みます。その IP アドレスに到達できない場合、ロードバランサは HTTP 502(不正なゲートウェイ)レスポンスを返します。これは、DNS レスポンスからの他の IP アドレスに到達できる場合も当てはまります。

  • 外部 HTTP(S) ロードバランサは、インターネット上のクライアントに最も近い Google Cloud リージョンの DNS リゾルバを使用します。INTERNET_FQDN_PORT エンドポイントの DNS レコードがクライアントのロケーションに応じて異なる IP アドレスを返す場合は、ロードバランサが各 IP アドレスにアクセスできることを確認します。

Google の DNS リゾルバ インフラストラクチャで使用される IP 範囲とロケーションの詳細については、Google Public DNS のドキュメントをご覧ください。

ログ

インターネット エンドポイントにプロキシされたリクエストは、他の HTTP(S) 負荷分散バックエンドのリクエストと同様の方法で Cloud Logging にログを記録されます。詳細については、HTTP(S) 負荷分散のロギングとモニタリングをご覧ください。

インターネット エンドポイントで Cloud CDN を有効にすると、キャッシュ ヒットもログに記録されます。

ヘッダー処理

外部 HTTP(S) ロードバランサがインターネット エンドポイントへのリクエストをプロキシすると、HTTP ヘッダーは次のように調整されます。

  • 一部のヘッダーは統合されます。同じヘッダーキー(例: Via)を持つ複数のインスタンスがある場合は、ロードバランサはそれらの値を 1 つのヘッダーキーを持つ、1 つのカンマ区切りのリストにまとめます。値をカンマ区切りのリストで表すことができるヘッダーのみが統合されます。その他のヘッダー(Set-Cookie など)は統合されません。

  • バックエンド サービスのプロトコルが HTTP または HTTPS の場合、ヘッダーはプロパーケースで表示されます。

    • ヘッダーのキーの最初の文字とハイフン(-)の後に続くすべての文字は、HTTP/1.1 クライアントとの互換性を維持するために大文字になります。たとえば、user-agentUser-Agent に変更され、content-encodingContent-Encoding に変更されます。

    • TE転送エンコード)、Accept-CHクライアント ヒント)などの特定のヘッダーは、標準の混合文字表現に一致するように変換されます。

  • いくつかのヘッダーが追加されるか、値が追加されます。外部 HTTP(S) ロードバランサは、ViaX-Forwarded-For のような特定のヘッダーを常に追加、または変更します。

制限事項

  • FQDN が定義されたインターネット エンドポイントは、Google Public DNS で解決可能である必要があります。
  • インターネット エンドポイントは、公開されたルーティング可能な IPv4 アドレス、または IPv4 に解決できる必要があります。
    • インターネット エンドポイントは、RFC 1918 アドレスにすることはできません。
    • インターネット経由で接続できる必要があります。エンドポイントには、Cloud VPN または Cloud Interconnect 経由以外でも接続できる必要があります。
    • インターネット エンドポイントが Google API または Google サービスを参照している場合、サービスは「HTTP,HTTPSorHTTP/2」プロトコルを使用して、TCP ポート 80443 経由で接続可能である必要があります。
  • インターネット NEG は、デフォルトの階層であるプレミアム ティアのネットワーク サービスでのみ使用できます。詳細については、Network Service Tiers のドキュメントをご覧ください。
  • INTERNET_IP_PORT エンドポイントには IP:{optional port}、INTERNET_FQDN_PORT には FQDN:{optional port} を使用する必要があります。
  • エンドポイントの種類が INTERNET_FQDN_PORT または INTERNET_IP_PORT の NEG を使用する場合、NEG に追加できるエンドポイントは 1 つのみです。つまり、backendService でネットワーク エンドポイントの種類が INTERNET_FQDN_PORT または INTERNET_IP_PORT の NEG を使用した場合、複数の NEG を backendService に接続することはできません。
  • 負荷分散は、インターネット エンドポイントでは現在サポートされていません。リクエストはエンドポイントにのみプロキシされます。Google Edge インフラストラクチャはユーザー接続を終了し、接続をインターネット エンドポイントに転送します。
  • Cloud CDN を有効にせずにインターネット NEG を使用できます。しかし、この構成でも複数の NEG をバックエンド サービスに関連付けることはできません。つまり、引き続き単一のエンドポイントに制限されます。
  • インターネット NEG のヘルスチェックは行われません。インターネット エンドポイントにアクセスできない場合、または FQDN として指定されているものの解決できない場合、Cloud CDN はユーザー リクエストに応答して 502(不正なゲートウェイ)メッセージを送信します。
  • HTTP リクエストの Host ヘッダーに特定の値を必要とするカスタム送信元を使用する場合、Host ヘッダーをその値に設定するようにバックエンド サービスを構成する必要があります。カスタム リクエスト ヘッダーを構成しない場合、バックエンド サービスは、クライアントが Google Cloud 外部 HTTP(S)ロードバランサへの接続に使用した Host ヘッダーを保持します。カスタム リクエスト ヘッダーの概要については、カスタム リクエスト ヘッダーの作成をご覧ください。具体的な例については、カスタムの送信元を持つロードバランサの構成をご覧ください。

割り当て

既存のネットワーク エンドポイント グループ割り当てで許可されている数の外部ネットワーク エンドポイントを持つ NEG を構成できます。詳細については、NEG バックエンドと、NEG あたりのエンドポイント数をご覧ください。

料金

インターネット NEG のエンドポイント(種類は INTERNET_FQDN_PORTINTERNET_IP_PORT)への下り(外向き)トラフィックは、プレミアム ティア ネットワーキングのインターネット下り(外向き)レートで課金されます。

ソースはクライアントのロケーションに基づき、宛先は公開エンドポイントのロケーションに基づきます。

詳細については、カスタムの送信元の Cloud CDN 料金をご覧ください。

次のステップ