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

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

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

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

このドキュメントでは、グローバル外部 HTTP(S) ロードバランサ（従来）で外部バックエンドを使用する方法について説明します。高度なトラフィック管理機能を含むグローバル外部 HTTP(S) ロードバランサ、リージョン外部 HTTP(S) ロードバランサ、その他の種類のロードバランサで外部バックエンドを使用することはできません。ただし、Traffic Director で外部バックエンドを使用できます。方法については、Traffic Director とインターネット ネットワーク エンドポイント グループをご覧ください。

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

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

用語

次の用語は、同じ意味または類似の意味を持つため、区別されずに使われることがよくあります

• 外部バックエンド: Google Cloud の外部にあり、インターネット経由で到達可能なバックエンド。インターネット NEG 内のエンドポイント。
• カスタムの送信元: 外部バックエンドと同じです。CDN では、ウェブ コンテンツを配信するバックエンド インスタンスを表す標準用語として「送信元」が使用されます。
• インターネット ネットワーク エンドポイント グループ（NEG）: 外部バックエンドの指定に使用する Google Cloud API リソース。
• 外部エンドポイント: 外部バックエンドと同じです。

このドキュメントでは、インターネット NEG API リソースを指す場合を除いて、外部バックエンドという用語を使用します。

概要

インターネット NEG は、オンプレミス インフラストラクチャ内またはサードパーティ プロバイダから提供されるインフラストラクチャ上のグローバル リソースです。

エンドポイントの種類

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

エンドポイント アドレス	種類	定義	使うタイミング
ホスト名とオプションのポート	INTERNET_FQDN_PORT	外部 HTTP(S) 負荷分散の場合、一般公開で解決可能な完全修飾ドメイン名とオプションのポート、backend.example.com:443 など（デフォルト ポート: HTTP の場合 80、HTTPS の場合 443） Traffic Director の場合、VPC ネットワークの名前解決順序を使用して FQDN が解決されます。	パブリック DNS により完全修飾ドメイン名で外部バックエンドを解決できる場合は、このエンドポイントを外部 HTTP(S) 負荷分散で使用します。 このエンドポイントを Traffic Director とともに使用して、外部サービスにトラフィックを送信します。
IP アドレスとオプションのポート	INTERNET_IP_PORT	公開アクセス可能な IP アドレスとオプションのポート。例: 8.8.8.8、8.8.8.8:443（デフォルト ポート: HTTP の場合は 80、HTTPS の場合は 443）	一般公開の IP アドレスと接続するポートを指定するには、このエンドポイントを外部 HTTP(S) 負荷分散でのみ使用します。

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

以降のセクションでは、外部バックエンドを HTTP(S) ロードバランサで使用する方法を説明します。Traffic Director で外部バックエンドを使用すると、DNS、ヘルスチェック、トラフィック ルーティングの動作が変わります。詳細については、Traffic Director とインターネット ネットワーク エンドポイント グループをご覧ください。

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

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

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

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

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

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

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

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

バックエンド サービス

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

重要: インターネット NEG を使用してバックエンド サービスを構成する場合は、プロトコルとして HTTPS または HTTP/2 を使用することを強くおすすめします。これにより、外部 HTTP(S) ロードバランサとバックエンド間の通信が公共のインターネットで転送される際に、暗号化と認証が行われます。

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

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

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

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

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

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

• インターネット NEG を使用する場合、バックエンド サービスの機能がサポートされます。次のような機能があります。

  • Cloud CDN
  • Google Cloud Armor
  • Identity-Aware Proxy
  • カスタム リクエスト ヘッダー

ヘルスチェック

インターネット NEG を使用するバックエンド サービスは、ヘルスチェックをサポートしていません。Google Cloud は、外部バックエンドのヘルスチェックを提供していません。

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

リクエストの認証

外部 HTTP(S) ロードバランサが外部バックエンドにリクエストを送信できるようにするには:

• dig や nslookup のようなツールを使用して、_cloud-eoips.googleusercontent.com の DNS TXT レコードのクエリを実行します。

  例:

  dig _cloud-eoips.googleusercontent.com txt @8.8.8.8
  

  nslookup -q=TXT _cloud-eoips.googleusercontent.com 8.8.8.8
  

  CIDR（ip4: の後に続く部分）を書き留め、ファイアウォールまたはクラウドのアクセス制御リスト（ACL）でこれらの範囲が許可されていることを確認します。例については、必要な IP 範囲の許可リストの作成をご覧ください。

• カスタム リクエスト ヘッダーを使用して、リクエストが 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）のいずれかと一致すること。

重要: 外部バックエンドを作成する場合: INTERNET_IP_PORT、SAN 検証を含む SSL サーバー証明書の検証は実行されません。この場合、外部バックエンドで HTTPS または HTTP/2 バックエンド プロトコルを使用する場合は、INTERNET_FQDN_PORTエンドポイント タイプを使用して外部バックエンドを定義します。

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-agent が User-Agent に変更され、content-encoding が Content-Encoding に変更されます。

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

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

制限事項

• インターネット NEG は、リージョン外部 HTTP(S) ロードバランサのバックエンドとしては使用できません。
• FQDN が定義された外部バックエンドは、Google Public DNS で解決可能である必要があります。パブリック DNS システムで解決できない名前は、外部バックエンドとして使用できません。
• 外部バックエンドは、公開されたルーティング可能な IPv4 アドレス、または IPv4 に解決できる必要があります。
  • 外部バックエンドを RFC 1918 アドレスにすることはできません。
  • インターネット経由で接続できる必要があります。エンドポイントには、Cloud VPN または Cloud Interconnect 経由以外でも接続できる必要があります。
  • 外部バックエンドが Google API または Google サービスを参照している場合、サービスは HTTP、HTTPS、または HTTP/2 プロトコルを使用して、TCP ポート 80 か 443 経由で接続可能である必要があります。
• インターネット 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 をバックエンド サービスに関連付けることはできません。つまり、引き続き単一のエンドポイントに制限されます。
• 外部バックエンドへのヘルスチェックは行われません。外部バックエンドにアクセスできない場合、または FQDN として指定されているものの解決できない場合、Cloud CDN はユーザー リクエストに応答して 502（不正なゲートウェイ）メッセージを送信します。
• HTTP リクエストの Host ヘッダーに特定の値を必要とする外部バックエンドを使用する場合、Host ヘッダーをその値に設定するようにバックエンド サービスを構成する必要があります。カスタム リクエスト ヘッダーを構成しない場合、バックエンド サービスは、クライアントが Google Cloud の外部 HTTP(S) ロードバランサへの接続に使用した Host ヘッダーを保持します。カスタム リクエスト ヘッダーの概要については、カスタム リクエスト ヘッダーの作成をご覧ください。具体的な例については、外部バックエンドでロードバランサの構成をご覧ください。

割り当て

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

料金

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

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

詳細については、外部バックエンドの Cloud CDN 料金をご覧ください。

次のステップ

• インターネット NEG を使用して外部 HTTP(S) ロードバランサを設定する
• Traffic Director とインターネット ネットワーク エンドポイント グループ
• Traffic Director でのインターネット ネットワーク エンドポイント グループの設定