内部アプリケーション ロードバランサの概要

このドキュメントでは、内部アプリケーション ロードバランサの構成に必要なコンセプトについて説明します。

Google Cloud 内部アプリケーション ロードバランサは、プロキシベースのレイヤ 7 ロードバランサです。これを使用すると、1 つの内部 IP アドレスの背後でサービスを実行し、スケールできます。この内部アプリケーション ロードバランサは、Compute Engine、Google Kubernetes Engine（GKE）、Cloud Run などのさまざまな Google Cloud プラットフォームでホストされているバックエンドに HTTP/HTTPS のトラフィックを分散します。詳しくは、ユースケースをご覧ください。

運用モード

内部アプリケーション ロードバランサは、次のモードで構成できます。

• クロスリージョン内部アプリケーション ロードバランサこれは、オープンソースの Envoy プロキシでマネージド サービスとして実装されるマルチ リージョン ロードバランサです。クロスリージョン モードを使用すると、グローバルに分散しているバックエンド サービスにトラフィックを負荷分散できます。たとえば、最も近いバックエンドにトラフィックを転送するトラフィック管理ができます。このロードバランサは高可用性も実現します。バックエンドを複数のリージョンに配置すると、単一リージョンにおける障害を回避できます。1 つのリージョンのバックエンドが停止した場合に、トラフィックを別のリージョンにフェイルオーバーできます。

• リージョン内部アプリケーション ロードバランサ。これは、オープンソースの Envoy プロキシでマネージド サービスとして実装されるリージョン ロードバランサです。リージョン モードでは、すべてのクライアントとバックエンドが指定されたリージョンに配置されるため、リージョンのコンプライアンスが必要な場合に役立ちます。このロードバランサを使用すると、HTTP(S) パラメータに基づく豊富なトラフィック制御機能が使用できます。ロードバランサの構成を終えると、トラフィックのニーズに応じて Envoy プロキシが自動的に割り当てられます。

  次の表に、リージョン モードとクロスリージョン モードの重要な違いを示します。

  機能	クロスリージョン内部アプリケーション ロードバランサ	リージョン内部アプリケーション ロードバランサ
  ロードバランサの仮想 IP アドレス（VIP）	特定の Google Cloud リージョンのサブネットから割り振られます。 複数のリージョンの VIP アドレスは、同じグローバル バックエンド サービスを共有できます。DNS ベースのグローバル ロード バランシングを構成するには、DNS ルーティング ポリシーを使用して、クライアント リクエストを最も近い VIP アドレスに転送します。	特定の Google Cloud リージョンのサブネットから割り振られます。
  クライアント アクセス	常にグローバルにアクセス可能VPC 内の任意の Google Cloud リージョンのクライアントがロードバランサにトラフィックを送信できます。	デフォルトでは、グローバルにアクセス可能ではありません。 必要に応じて、グローバル アクセスを有効にすることができます。
  ロードバランスされたバックエンド	グローバル バックエンド。 ロードバランサは、任意のリージョンのバックエンドにトラフィックを送信できます。	リージョン バックエンド。 ロードバランサは、ロードバランサのプロキシと同じリージョンにあるバックエンドにのみトラフィックを送信できます。
  High availability and failover	同一または異なるリージョンの正常なバックエンドへの自動フェイルオーバー。	同じリージョン内の正常なバックエンドへの自動フェイルオーバー。

モードを特定する

アーキテクチャとリソース

次の図は、内部アプリケーション ロードバランサに必要な Google Cloud リソースを示しています。

内部アプリケーション ロードバランサのデプロイには、次のリソースが必要です。

プロキシ専用サブネット

上の図では、プロキシ専用サブネットには、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。内部アプリケーション ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを 1 つ作成する必要があります。

次の表に、リージョン モードとクロスリージョン モードでのプロキシ専用サブネットの違いを示します。

ロードバランサ モード	プロキシ専用サブネットの --purpose フラグの値
クロスリージョン内部アプリケーション ロードバランサ	GLOBAL_MANAGED_PROXY リージョン ロードバランサとクロスリージョン ロードバランサで同じサブネットを共有することはできません ロードバランサが構成される各リージョンで、クロスリージョンの Envoy ベースのロードバランサにはプロキシ専用サブネットが必要です。同じリージョンとネットワークにあるクロスリージョン ロードバランサ プロキシは、同じプロキシ専用サブネットを共有します。
リージョン内部アプリケーション ロードバランサ	REGIONAL_MANAGED_PROXY リージョン ロードバランサとクロスリージョン ロードバランサで同じサブネットを共有することはできません リージョンと VPC ネットワーク内のすべてのリージョン Envoy ベースのロードバランサは、同じプロキシ専用サブネットを共有します。

さらに、

• プロキシ専用サブネットは Envoy プロキシにのみ使用され、バックエンドには使用されません。
• リージョンと VPC ネットワーク内のすべての内部アプリケーション ロードバランサのバックエンド VM またはエンドポイントは、プロキシ専用サブネットからの接続を受信します。
• 内部アプリケーション ロードバランサの仮想 IP アドレスは、プロキシ専用サブネットにはありません。ロードバランサの IP アドレスは、後述する内部マネージド転送ルールで定義します。

転送ルールと IP アドレス

転送ルールは、IP アドレス、ポート、プロトコルに基づいて、ターゲット プロキシとバックエンド サービスからなるロード バランシング構成にトラフィックをルーティングします。

IP アドレスの指定。各転送ルールは、アプリケーションの DNS レコードで使用できる単一のリージョン IP アドレスを参照します。使用できる静的 IP アドレスを予約するか、Cloud Load Balancing から割り当てます。推奨されているのは静的 IP アドレスの予約です。静的アドレスを予約しない場合、転送ルールを削除して新しく作り直すたびに DNS レコードを編集して、新しく割り当てられたエフェメラル IP アドレスに直す必要があるからです。

クライアントは IP アドレスとポートを使用してロードバランサの Envoy プロキシに接続します。転送ルールの IP アドレスはロードバランサの IP アドレスです（仮想 IP アドレスまたは VIP と呼ぶこともあります）。ロードバランサに接続するクライアントは、HTTP バージョン 1.1 以降を使用する必要があります。サポートされているプロトコルの一覧については、ロードバランサの機能をご覧ください。

転送ルールに関連付けられた内部 IP アドレスは、バックエンドと同じネットワークとリージョンにあるサブネットから取得できます。

ポートの指定。アプリケーション ロードバランサの転送ルールでは、1～65535 の単一ポートを参照できます。複数のポートをサポートするには、複数の転送ルールを構成する必要があります。IP アドレス、ポート、プロトコルの組み合わせが各転送ルールで一意である限り、複数の転送ルールを構成して、同じ内部 IP アドレス（VIP）を使用し、同じターゲット HTTP(S) プロキシを参照できます。これにより、共有 URL マップを持つ単一のロードバランサを複数のアプリケーションのプロキシとして使用できます。

内部アプリケーション ロードバランサが使用する転送ルール、IP アドレス、ロード バランシング スキームのタイプは、ロードバランサのモードによって異なります。

ロードバランサ モード	転送ルール、IP アドレス、プロキシ専用サブネット --purpose	クライアントからロードバランサのフロントエンドへのルーティング
クロスリージョン内部アプリケーション ロードバランサ	グローバル転送ルール リージョン IP アドレス ロード バランシング スキーム INTERNAL_MANAGED プロキシ専用サブネット --purpose GLOBAL_MANAGED_PROXY IP アドレス --purpose: SHARED_LOADBALANCER_VIP	グローバル アクセスはデフォルトで有効になっており、VPC 内の任意のリージョンのクライアントがロードバランサにアクセスできます。バックエンドは複数のリージョンに配置できます。
リージョン内部アプリケーション ロードバランサ	リージョン転送ルール リージョン IP アドレス ロード バランシング スキーム INTERNAL_MANAGED プロキシ専用サブネット --purpose REGIONAL_MANAGED_PROXY IP アドレス --purpose: SHARED_LOADBALANCER_VIP	グローバル アクセスを有効にして、VPC 内の任意のリージョンのクライアントがロードバランサにアクセス可能にできます。また、バックエンドもロードバランサと同じリージョンに存在する必要があります。

転送ルールと VPC ネットワーク

このセクションでは、外部アプリケーション ロードバランサで使用される転送ルールを VPC ネットワークに関連付ける方法について説明します。

ロードバランサ モード	VPC ネットワークの関連付け
クロスリージョン内部アプリケーション ロードバランサ リージョン内部アプリケーション ロードバランサ	リージョン内部 IPv4 アドレスは常に VPC ネットワーク内に存在します。転送ルールを作成するときに、内部 IP アドレスを取得するサブネットを指定する必要があります。このサブネットは、プロキシ専用サブネットが作成されたリージョンと VPC ネットワークに存在する必要があります。このため、暗黙的なネットワークの関連付けが存在します。

ターゲット プロキシ

ターゲット HTTP(S) プロキシは、クライアントからの HTTP(S) 接続を終端します。HTTP(S) プロキシは、URL マップを参照してトラフィックをバックエンドに転送する方法を決定します。ターゲット HTTPS プロキシは、SSL 証明書を使用してクライアントに対して自身を認証します。

ロードバランサは、元のクライアント リクエストの Host ヘッダーを保持します。また、ロードバランサは X-Forwarded-For ヘッダーに 2 つの IP アドレスを追加します。

• ロードバランサに接続するクライアントの IP アドレス
• ロードバランサの転送ルールの IP アドレス

受信リクエストに X-Forwarded-For ヘッダーがない場合、ヘッダーの値はこの 2 つの IP アドレスだけです。リクエストに X-Forwarded-For ヘッダーがある場合、ロードバランサへのリクエスト中にプロキシによって記録された IP アドレスなどの他の情報は 2 つの IP アドレスの前に保持されます。ロードバランサは、このヘッダーの最後の 2 つの IP アドレスより前の IP アドレスを確認しません。

バックエンド サーバーとしてプロキシを実行している場合、このプロキシは通常、より多くの情報を X-Forwarded-For ヘッダーに追加するため、ソフトウェアでこれを考慮する必要がある場合があります。ロードバランサからプロキシされたリクエストは、プロキシ専用サブネットの IP アドレスから送信されます。バックエンド インスタンスのプロキシでは、このアドレスに加えて、バックエンド インスタンスの独自の IP アドレスを記録する場合があります。

アプリケーションで処理する必要があるトラフィックの種類に応じて、ターゲット HTTP プロキシまたはターゲット HTTPS プロキシを使用して、ロードバランサを構成できます。

次の表に、内部アプリケーション ロードバランサに必要なターゲット プロキシ API を示します。

ロードバランサ モード	ターゲット プロキシ
クロスリージョン内部アプリケーション ロードバランサ	グローバルtargetHttpProxies グローバルtargetHttpsProxies
リージョン内部アプリケーション ロードバランサ	regionTargetHttpProxies regionTargetHttpsProxies

SSL 証明書

ターゲット HTTPS プロキシを使用する内部アプリケーション ロードバランサには、ロードバランサの構成の一部として秘密鍵と SSL 証明書が必要です。

次の表に、各モードの内部アプリケーション ロードバランサが必要とする SSL 証明書のタイプを示します。

ロードバランサ モード	SSL 証明書の種類
リージョン内部アプリケーション ロードバランサ	Compute Engine リージョン SSL 証明書 Certificate Manager のセルフマネージド証明書と Google マネージド証明書。 Certificate Manager では、次のタイプの Google マネージド証明書がサポートされています。 プロジェクトごとの DNS 認証を使用するリージョン Google マネージド証明書。詳細については、リージョン Google マネージド証明書をデプロイするをご覧ください。 プライベート Certificate Authority Service を使用するリージョン Google マネージド証明書。詳細については、CA Service を使用してリージョン Google マネージド証明書をデプロイするをご覧ください。 ロードバランサ認証を使用する Google マネージド証明書はサポートされていません。
クロスリージョン内部アプリケーション ロードバランサ	Certificate Manager のセルフマネージド証明書と Google マネージド証明書。 Certificate Manager では、次のタイプの Google マネージド証明書がサポートされています。 パブリック DNS による DNS 認証。詳細については、DNS 認証を使用して Google マネージド証明書を作成するをご覧ください。 プライベート Certificate Authority Service。詳細については、CA Service インスタンスによって発行された Google マネージド証明書を作成するをご覧ください。 ロードバランサ認証を使用した Google マネージド証明書はサポートされていません。 Compute Engine SSL 証明書はサポートされていません。

URL マップ

ターゲット HTTP(S) プロキシは、URL マップを使用して、HTTP 属性（リクエストパス、Cookie、ヘッダーなど）に基づいてルーティングを決定します。このルーティングの決定に基づいて、プロキシは特定のバックエンド サービスにクライアントのリクエストを転送します。URL マップには、ヘッダーの書き換え、クライアントへのリダイレクトの送信、タイムアウト ポリシーの構成など、追加のアクションを指定できます。

次の表に、各モードで内部アプリケーション ロードバランサが必要とする URL マップのタイプを示します。

ロードバランサ モード	URL マップのタイプ
クロスリージョン内部アプリケーション ロードバランサ	グローバル URL マップ
リージョン内部アプリケーション ロードバランサ	リージョン URL マップ

バックエンド サービス

バックエンド サービスは、ロードバランサに構成情報を提供して、Compute Engine インスタンス グループやネットワーク エンドポイント グループ（NEG）などのバックエンドにリクエストを転送できるようにします。バックエンド サービスの詳細については、バックエンド サービスの概要をご覧ください。

バックエンド サービスのスコープ

次の表に、内部アプリケーション ロードバランサで使用されるバックエンド サービス リソースとスコープを示します。

ロードバランサ モード	バックエンド サービス リソース
クロスリージョン内部アプリケーション ロードバランサ	backendServices（グローバル）
リージョン内部アプリケーション ロードバランサ	regionBackendServices（地域別）

バックエンドへのプロトコル

アプリケーション ロードバランサのバックエンド サービスは、次のいずれかのプロトコルを使用してバックエンドにリクエストを送信する必要があります。

• HTTP: HTTP/1.1 を使用し、TLS は使用しません。
• HTTPS: HTTP/1.1 と TLS を使用
• HTTP/2: HTTP/2 と TLS を使用します（暗号化なしの HTTP/2 はサポートされていません）。

ロードバランサは、バックエンドとの通信に指定したバックエンド サービス プロトコルのみを使用します。指定されたバックエンド サービス プロトコルを使用してバックエンドと通信できない場合、ロードバランサは別のプロトコルにフォールバックしません。

バックエンド サービス プロトコルは、クライアントがロードバランサとの通信に使用するプロトコルと一致する必要はありません。たとえば、クライアントは HTTP/2 を使用してロードバランサにリクエストを送信できますが、ロードバランサは HTTP/1.1（HTTP または HTTPS）を使用してバックエンドと通信できます。

バックエンド

次の表に、各モードで内部アプリケーション ロードバランサがサポートするバックエンド機能を示します。

ロードバランサ モード	バックエンド サービスでサポートされるバックエンド*						バックエンド バケットのサポート	Google Cloud Armor のサポート	Cloud CDN のサポート	IAP のサポート	Service Extensions のサポート
	インスタンス グループ†	ゾーン NEG‡	インターネット NEG	サーバーレス NEG	ハイブリッド NEG	Private Service Connect NEG
クロスリージョン内部アプリケーション ロードバランサ				Cloud Run
リージョン内部アプリケーション ロードバランサ				Cloud Run

バックエンドと VPC ネットワーク

バックエンドを配置するロケーションの制限は、バックエンドのタイプによって異なります。

• インスタンス グループ、ゾーン NEG、ハイブリッド接続 NEG の場合、すべてのバックエンドはバックエンド サービスと同じプロジェクトとリージョンに配置する必要があります。ただし、ロードバランサは、バックエンド サービスと同じプロジェクトで別の VPC ネットワークを使用するバックエンドを参照できます（この機能はプレビュー版です）。 ロードバランサの VPC ネットワークとバックエンド VPC ネットワーク間の接続は、VPC ネットワーク ピアリング、Cloud VPN トンネル、Cloud Interconnect VLAN アタッチメント、または Network Connectivity Center フレームワークを使用して構成できます。

  バックエンド ネットワークの定義

  • ゾーン NEG とハイブリッド NEG の場合、NEG の作成時に VPC ネットワークを明示的に指定します。
  • マネージド インスタンス グループの場合、VPC ネットワークはインスタンス テンプレートで定義されます。
  • 非マネージド インスタンス グループの場合、インスタンス グループの VPC ネットワークは、インスタンス グループに追加された最初の VM の nic0 インターフェースの VPC ネットワークと一致するように設定されます。

  バックエンド ネットワークの要件

  バックエンド ネットワークは、次のいずれかのネットワーク要件を満たしている必要があります。

  • バックエンドの VPC ネットワークは、転送ルールの VPC ネットワークと完全に一致する必要があります。

  • バックエンドの VPC ネットワークは、VPC ネットワーク ピアリングを使用して転送ルールの VPC ネットワークに接続する必要があります。転送ルールの VPC ネットワークのプロキシ専用サブネットと、バックエンド インスタンスまたはエンドポイントで使用されるサブネットとの通信を許可するには、サブネット ルート交換を構成する必要があります。

• バックエンドの VPC ネットワークと転送ルールの VPC ネットワークは、同じ Network Connectivity Center ハブの VPC スポークである必要があります。インポート フィルタとエクスポート フィルタでは、転送ルールの VPC ネットワークのプロキシ専用サブネットと、バックエンド インスタンスまたはエンドポイントで使用されるサブネットとの通信を許可する必要があります。

• 他のすべてのバックエンド タイプの場合、すべてのバックエンドを同じ VPC ネットワークとリージョンに配置する必要があります。

バックエンドとネットワーク インターフェース

インスタンス グループのバックエンドを使用する場合、パケットは常に nic0 に配信されます。別の NIC にパケットを送信する場合は、NEG バックエンドを使用します。

ゾーン NEG バックエンドを使用する場合、パケットは NEG のエンドポイントで表されるネットワーク インターフェースに送信されます。NEG エンドポイントは、NEG に明示的に定義された VPC ネットワークと同じ VPC ネットワークに存在する必要があります。

バックエンドのサブセット化

バックエンドのサブセット化は、リージョン内部の アプリケーション ロードバランサでサポートされている機能で、各プロキシ インスタンスにバックエンドのサブセットを割り当てることでパフォーマンスとスケーラビリティを向上させます。

デフォルトでは、バックエンドのサブセット化は無効になっています。この機能を有効にする方法については、内部アプリケーション ロードバランサのバックエンドのサブセット化をご覧ください。

ヘルスチェック

各バックエンド サービスは、ロードバランサからの接続を受信するバックエンドの稼働状況を定期的に監視するヘルスチェックを指定します。これにより、処理不能なバックエンドにリクエストを送信するリスクが軽減されます。ヘルスチェックでは、アプリケーション自体が動作するかどうかはチェックされません。

ヘルスチェック プローブでは、上り（内向き）許可ファイアウォール ルールを作成してヘルスチェック プローブがバックエンド インスタンスに到達できるようにする必要があります。通常、ヘルスチェック プローブは Google の一元化されたヘルスチェックの仕組みにより発信されます。ただし、ハイブリッド NEG の場合、ヘルスチェックはプロキシ専用サブネットから開始します。詳細については、ハイブリッド NEG の概要の分散 Envoy ヘルスチェックをご覧ください。

ヘルスチェック プロトコル

必須ではなく、常に可能というわけでもありませんが、バックエンド サービスのプロトコルに一致するプロトコルでのヘルスチェックを使用することをおすすめします。たとえば、バックエンドに対する HTTP/2 の接続性を最も正確にテストできるのは HTTP/2 ヘルスチェックです。一方、ハイブリッド NEG バックエンドを使用する内部アプリケーション ロードバランサは、gRPC ヘルスチェックをサポートしていません。サポートされているヘルスチェック プロトコルの一覧については、ロード バランシング機能をご覧ください。

次の表に、内部アプリケーション ロードバランサでサポートされているヘルスチェックのスコープを示します。

ロードバランサ モード	ヘルスチェックのタイプ
クロスリージョン内部アプリケーション ロードバランサ	グローバル
リージョン内部アプリケーション ロードバランサ	リージョン

ヘルスチェックの詳細については、以下をご覧ください。

• ヘルスチェックの概要
• ヘルスチェックの作成

ファイアウォール ルール

内部アプリケーション ロードバランサには、次のファイアウォール ルールが必要です。

• Google の中央のヘルスチェック範囲からのトラフィックを許可する上り（内向き）許可ルール。
  • 35.191.0.0/16
  • 130.211.0.0/22

  バックエンドへの IPv6 トラフィックの場合:

  • 2600:2d00:1:b029::/64
• プロキシ専用サブネットからのトラフィックを許可するための上り（内向き）許可ルール

これらの範囲については、ファイアウォール ルールの要件にいくつかの例外があります。

• ハイブリッド NEG では、Google のヘルスチェック プローブ範囲を許可リストに登録する必要はありません。ただし、1 つのバックエンド サービスでハイブリッド NEG とゾーン NEG の組み合わせを使用している場合は、ゾーン NEG の Google ヘルスチェック プローブ範囲を許可リストに登録する必要があります。
• リージョン インターネット NEG の場合、ヘルスチェックは省略可能です。リージョン インターネット NEG を使用するロードバランサからのトラフィックは、プロキシ専用サブネットから発信され、Cloud NAT を使用して手動で、または自動的に割り振られた NAT IP アドレスに NAT 変換されます。このトラフィックには、ヘルスチェック プローブと、ロードバランサからバックエンドへのユーザー リクエストの両方が含まれます。詳細については、リージョン NEG: 下り（外向き）に Cloud NAT を使用するをご覧ください。

クライアント アクセス

クライアントは、同じネットワークまたは、VPC ネットワーク ピアリングを使用して接続された VPC ネットワークに配置できます。

クロスリージョン内部アプリケーション ロードバランサの場合、グローバル アクセスはデフォルトで有効になっています。VPC 内の任意のリージョンのクライアントがロードバランサにアクセスできます。

リージョン内部アプリケーション ロードバランサの場合、クライアントは、デフォルトでロードバランサと同じリージョンに存在しなければなりません。グローバル アクセスを有効にして、VPC 内の任意のリージョンのクライアントがロードバランサにアクセス可能にできます。

次の表に、リージョン内部アプリケーション ロードバランサのクライアント アクセスの概要を示します。

グローバル アクセスが無効な場合	グローバル アクセスが有効な場合
クライアントはロードバランサと同じリージョンになければなりません。また、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。	クライアントはどのリージョンにでも配置できます。ただし、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。
オンプレミス クライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを介してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、ロードバランサと同じリージョンになければなりません。	オンプレミス クライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを使用してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、どのリージョンにでも配置できます。

GKE サポート

GKE は、内部アプリケーション ロードバランサを次の方法で使用します。

• GKE Gateway コントローラを使用して作成された内部 Gateway は、内部アプリケーション ロードバランサの任意のモードを使用できます。ロードバランサのモードは、GatewayClass を選択して制御します。GKE Gateway コントローラは常に GCE_VM_IP_PORT ゾーン NEG バックエンドを使用します。

• GKE Ingress コントローラを使用して作成された内部 Ingress は、常にリージョン内部アプリケーション ロードバランサです。GKE Ingress コントローラは常に GCE_VM_IP_PORT ゾーン NEG バックエンドを使用します。

• GKE Services によって作成および管理される GCE_VM_IP_PORT ゾーン NEG を、アプリケーション ロードバランサまたはプロキシ ネットワーク ロードバランサのバックエンドとして使用できます。詳細については、スタンドアロン ゾーン NEG によるコンテナ ネイティブのロード バランシングをご覧ください。

共有 VPC のアーキテクチャ

内部アプリケーション ロードバランサは、共有 VPC を使用するネットワークをサポートします。組織は、共有 VPC を使用して複数のプロジェクトのリソースを共通の VPC ネットワークに接続できるため、そのネットワークの内部 IP を使用して、安全で効率的な相互通信を行うことができます。共有 VPC についてまだよく理解していない場合は、共有 VPC の概要のドキュメントをご覧ください。

共有 VPC ネットワーク内で内部アプリケーション ロードバランサを構成するには、多くの方法があります。デプロイの種類に関係なく、ロードバランサのすべてのコンポーネントを同じ組織に配置する必要があります。

サブネットと IP アドレス	フロントエンド コンポーネント	バックエンド コンポーネント
共有 VPC ホスト プロジェクトで必要なネットワークとサブネット（プロキシ専用サブネットを含む）を作成します。 ロードバランサの内部 IP アドレスは、ホスト プロジェクトまたはサービス プロジェクトのいずれかで定義できますが、ホスト プロジェクト内の目的の共有 VPC ネットワークのサブネットを使用する必要があります。アドレス自体は、参照先サブネットのプライマリ IP 範囲から取得します。	リージョン内部 IP アドレス、転送ルール、ターゲット HTTP(S) プロキシ、関連付けられた URL マップは、同じプロジェクトで定義する必要があります。このプロジェクトは、ホスト プロジェクトまたはサービス プロジェクトにできます。	次のいずれかを行います。 バックエンド サービスとバックエンド（インスタンス グループ、サーバーレス NEG、その他のサポートされているバックエンド タイプ）を、フロントエンド コンポーネントと同じサービス プロジェクトに作成します。 必要な数のサービス プロジェクトで、バックエンド サービスとバックエンド（インスタンス グループ、サーバーレス NEG、その他のサポートされているバックエンド タイプ）を作成します。1 つの URL マップで複数のプロジェクトのバックエンド サービスを参照できます。このタイプのデプロイは、プロジェクト間のサービス参照と呼ばれます。 各バックエンド サービスは、参照するバックエンドと同じプロジェクトで定義する必要があります。バックエンド サービスに関連するヘルスチェックも、バックエンド サービスと同じプロジェクトで定義する必要があります。

共有 VPC ホスト プロジェクトですべてのロード バランシング コンポーネントとバックエンドを作成できますが、このタイプのデプロイではネットワーク管理とサービス開発の責任が分離されません。

サービス プロジェクト内のすべてのロードバランサ コンポーネントとバックエンド

次のアーキテクチャ図は、すべてのロードバランサのコンポーネントとバックエンドがサービス プロジェクト内にある標準の共有 VPC デプロイを示しています。このデプロイタイプは、すべてのアプリケーション ロードバランサでサポートされています。

ロードバランサは、ホスト プロジェクトの IP アドレスとサブネットを使用します。クライアントは、ロードバランサと同じ共有 VPC ネットワークとリージョンにある場合、内部アプリケーション ロードバランサにアクセスできます。クライアントは、ホスト プロジェクト、接続されたサービス プロジェクト、または任意の接続されたネットワークに配置できます。

共有 VPC 環境におけるサーバーレス バックエンド

サーバーレス NEG バックエンドを使用する内部アプリケーション ロードバランサの場合、バッキング Cloud Run サービス、バックエンド サービス、サーバーレス NEG は同じサービス プロジェクトに存在する必要があります。ロードバランサのフロントエンド コンポーネント（転送ルール、ターゲット プロキシ、URL マップ）は、ホスト プロジェクト、バックエンド コンポーネントと同じサービス プロジェクト、または同じ共有 VPC 環境内のサービス プロジェクトのいずれかに作成できます。

プロジェクト間のサービス参照

プロジェクト間サービス参照は、ロードバランサのフロントエンドと URL マップが 1 つのプロジェクトにあり、ロードバランサのバックエンド サービスとバックエンドが別のプロジェクトにあるデプロイモデルです。

プロジェクト間のサービス参照を使用すると、組織は 1 つの一元的なロードバランサを構成し、複数の異なるプロジェクトに分散された数百のサービスにトラフィックをルーティングできます。トラフィック ルーティングのルールおよびポリシーはすべて、1 つの URL マップで集中管理できます。ロードバランサをホスト名と SSL 証明書の組み合わせの 1 つと関連付けることもできます。このため、アプリケーションのデプロイに必要なロードバランサの数を最適化することで、管理性の向上や、運用費および必要な割り当て量の削減につながります。

さらに、プロジェクトを部門ごとに分けて、組織内のロールを分離することもできます。サービス オーナーはサービス プロジェクト内のサービス構築に、ネットワーク チームは別のプロジェクト内のロードバランサのプロビジョニングおよび維持に専念できます。これらのプロジェクトは、プロジェクト間のサービス参照によって接続できます。

サービス オーナーは、サービスの公開に対する自律性を維持し、ロードバランサを介してサービスにアクセスできるユーザーを制御できます。この仕組みは、Compute ロードバランサ サービス ユーザーのロール（roles/compute.loadBalancerServiceUser）という特別な IAM ロールによって実現されます。

内部アプリケーション ロードバランサの場合、プロジェクト間のサービス参照は共有 VPC 環境内でのみサポートされます。

（プロジェクト間のサービス参照の有無にかかわらず）内部アプリケーション ロードバランサの共有 VPC を構成する方法については、共有 VPC を使用して内部アプリケーション ロードバランサを設定するをご覧ください。

プロジェクト間のサービス参照に関する既知の制限事項

• バックエンド サービスにリージョン インターネット NEG バックエンドがある場合、プロジェクト間のバックエンド サービスを参照することはできません。他のバックエンド タイプはすべてサポートされています。
• Google Cloud では、複数のプロジェクトで同じ名前を使用するリソース（バックエンド サービスなど）は区別されません。したがって、プロジェクト間のサービス参照を使用する場合は、組織内のプロジェクト間で一意のバックエンド サービス名を使用することをおすすめします。

例 1: ロードバランサのフロントエンドとバックエンドが別のサービス プロジェクトに存在する

次の共有 VPC デプロイの例では、ロードバランサのフロントエンドと URL マップがサービス プロジェクト A に作成され、URL マップはサービス プロジェクト B のバックエンド サービスを参照しています。

この場合、サービス プロジェクト A のネットワーク管理者またはロードバランサ管理者は、サービス プロジェクト B のバックエンド サービスにアクセスする必要があります。サービス プロジェクト B の管理者は、サービス プロジェクト B のバックエンド サービスを参照するサービス プロジェクト A のロードバランサ管理者に compute.loadBalancerServiceUser IAM ロールを付与します。

例 2: ホスト プロジェクト内のロードバランサのフロントエンドと、サービス プロジェクトのバックエンド

次の例は、ロードバランサのフロントエンドと URL マップがホスト プロジェクトに作成され、バックエンド サービス（とバックエンド）がサービス プロジェクトに作成される共有 VPC デプロイの例です。

この場合、ホスト プロジェクトのネットワーク管理者またはロードバランサ管理者は、サービス プロジェクトのバックエンド サービスにアクセスする必要があります。サービス プロジェクトの管理者は、サービス プロジェクトのバックエンド サービスを参照するホスト プロジェクト A のロードバランサ管理者に compute.loadBalancerServiceUser IAM ロールを付与します。

タイムアウトと再試行

内部アプリケーション ロードバランサは、次の種類のタイムアウトをサポートします。

タイムアウトの種類と説明	デフォルト値	カスタム値のサポート
		クロスリージョン	リージョン
バックエンド サービスのタイムアウト リクエストとレスポンスのタイムアウトロードバランサがリクエストの最初のバイトをバックエンドに送信してから、バックエンドが HTTP レスポンスの最後のバイトをロードバランサに返すまでの最長時間を表します。バックエンドがこの時間内に HTTP レスポンス全体をロードバランサに返さなかった場合、残りのレスポンス データは破棄されます。	バックエンド サービスのサーバーレス NEG の場合: 60 分 バックエンド サービスの他のバックエンド タイプの場合: 30 秒
クライアント HTTP キープアライブ タイムアウト クライアントとロードバランサのマネージド Envoy プロキシの間の TCP 接続がアイドル状態である最長時間（同じ TCP 接続が複数の HTTP リクエストに使用される場合があります）。	10 分（600 秒）
バックエンド HTTP キープアライブ タイムアウト ロードバランサのマネージド Envoy プロキシとバックエンド間の TCP 接続がアイドル状態である最長時間（同じ TCP 接続が複数の HTTP リクエストに使用される場合があります）。	10 分（600 秒）

バックエンド サービスのタイムアウト

構成可能なバックエンド サービス タイムアウトは、バックエンドが HTTP リクエストを処理し、対応する HTTP レスポンスを返すまでロードバランサが待機する最長時間を表します。サーバーレス NEG を除き、バックエンド サービスのタイムアウトのデフォルト値は 30 秒です。

たとえば、500 MB のファイルをダウンロードする場合、バックエンド サービスのタイムアウトの値が 90 秒であれば、ロードバランサはバックエンドが 500 MB ファイル全体を 90 秒以内で配信すると想定します。バックエンド サービスのタイムアウトには、バックエンドが完全な HTTP レスポンスを送信するのに十分でない時間を構成することもできます。この状況では、少なくともロードバランサがバックエンドから HTTP レスポンス ヘッダーを受け取った場合、ロードバランサは完全なレスポンス ヘッダーと、バックエンド サービスのタイムアウト内で取得できる可能な限り多くのレスポンス本文を返します。

バックエンド サービスのタイムアウトは、HTTP レスポンスを処理するためにバックエンドが待機する必要のある最長時間に設定する必要があります。バックエンドで実行されているソフトウェアが HTTP リクエストを処理し、レスポンス全体を返すためにさらに時間が必要な場合は、バックエンド サービスのタイムアウト値を増やす必要があります。

バックエンド サービスのタイムアウトは、1～2,147,483,647 秒の値を受け入れます。ただし、あまりに大きい値は実用的な構成オプションではありません。また、バックエンド サービスがタイムアウトになるまで基盤となる TCP 接続が維持されるとは限りません。クライアント システムでは、TCP 接続の持続時間に依存するのではなく、再試行ロジックを実装する必要があります。

内部アプリケーション ロードバランサで使用される WebSocket 接続の場合、アクティブな WebSocket 接続はバックエンド サービスのタイムアウトに従いません。アイドル状態の WebSocket 接続は、バックエンド サービスのタイムアウト後に終了します。

Google Cloud では、サービスを提供する Envoy ソフトウェア タスクを定期的に再起動したり、その数を変更しています。バックエンド サービスのタイムアウト値が長いほど、Envoy タスクの再起動または置換によって TCP 接続が終了する可能性が高くなります。

バックエンド サービスのタイムアウトを構成するには、次のいずれかの方法を使用します。

クライアント HTTP キープアライブ タイムアウト

クライアント HTTP キープアライブ タイムアウトは、TCP 接続が（ダウンストリーム）クライアントと Envoy プロキシ間でアイドル状態になっている最長時間を表します。デフォルトのクライアント HTTP キープアライブ タイムアウト値は 600 秒です。タイムアウトは 5 ～ 600 秒の値で構成できます。

HTTP キープアライブ タイムアウトは TCP アイドル タイムアウトとも呼ばれています。

ロードバランサのクライアント HTTP キープアライブ タイムアウトは、ダウンストリーム クライアントまたはプロキシで使用される HTTP キープアライブ（TCP アイドル）タイムアウトよりも大きくする必要があります。ダウンストリーム クライアントの HTTP キープアライブ（TCP アイドル）タイムアウトがロードバランサのクライアント HTTP キープアライブ タイムアウトよりも大きい場合、競合状態が発生する可能性があります。ダウンストリーム クライアントから見ると、確立済みの TCP 接続が、ロードバランサで許可されている時間よりも長くアイドル状態になる可能性があります。つまり、ロードバランサが TCP 接続が閉じられたとみなすと、ダウンストリーム クライアントはパケットを送信できます。その場合、ロードバランサは TCP reset（RST）パケットで応答します。

バックエンド HTTP キープアライブ タイムアウト

内部アプリケーション ロードバランサは、（ダウンストリーム）クライアントと Envoy プロキシ間の最初の TCP 接続と、Envoy プロキシとバックエンド間の 2 番目の TCP 接続を使用するプロキシです。

ロードバランサの 2 番目の TCP 接続は、リクエストごとに終了せず、複数の HTTP リクエストとレスポンスを処理できるように、開いている状態を維持する場合があります。バックエンド HTTP キープアライブ タイムアウトは、ロードバランサとバックエンド間の TCP アイドル タイムアウトを定義します。バックエンド HTTP キープアライブ タイムアウトは WebSocket には適用されません。

バックエンド キープアライブ タイムアウトは 10 分（600 秒）に固定されており、変更できません。ロードバランサのバックエンド キープアライブ タイムアウトは、バックエンドで実行されているソフトウェアで使用されるキープアライブ タイムアウトよりも短くする必要があります。これにより、バックエンドのオペレーティング システムが TCP reset（RST）で TCP 接続を終了する可能性のある競合状態を回避できます。ロードバランサのバックエンド キープアライブ タイムアウトは構成できないため、HTTP キープアライブ（TCP アイドル）タイムアウト値が 600 秒を超えるようにバックエンド ソフトウェアを構成する必要があります。

次の表は、一般的なウェブサーバー ソフトウェアの、キープアライブ タイムアウト値を変更するために必要な変更を示します。

ウェブサーバー ソフトウェア	パラメータ	デフォルト設定	推奨される設定
Apache	KeepAliveTimeout	KeepAliveTimeout 5	KeepAliveTimeout 620
nginx	keepalive_timeout	keepalive_timeout 75s;	keepalive_timeout 620s;

再試行数

再試行を構成するには、URL マップで再試行ポリシーを使用します。デフォルトの再試行回数（numRetries）は 1 回です。構成可能な perTryTimeout の最大値は 24 時間です。

再試行ポリシーがない場合、HTTP 本文のないリクエスト（GET リクエストなど）が HTTP 502、503、または 504 のレスポンスを返したときに 1 回だけ再試行されます。

HTTP POST リクエストは再試行されません。

再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。

詳細については、内部アプリケーション ロードバランサのロギングとモニタリングをご覧ください。

接続ネットワークへのアクセス

クライアントが接続ネットワークから VPC ネットワーク内の内部アプリケーション ロードバランサにアクセスする方法は、次のとおりです。

• VPC ネットワーク ピアリング
• Cloud VPN と Cloud Interconnect

詳細な例については、内部アプリケーション ロードバランサと接続ネットワークをご覧ください。

フェイルオーバー

バックエンドが異常な状態になると、トラフィックは正常なバックエンドに自動的にリダイレクトされます。

次の表に、各モードでのフェイルオーバーの動作を示します。

ロードバランサ モード	フェイルオーバーの動作	すべてのバックエンドが異常な場合の動作
クロスリージョン内部アプリケーション ロードバランサ	同じリージョンまたは他のリージョン内の正常なバックエンドへの自動フェイルオーバー。 トラフィックは、構成されたトラフィック分散に基づいて、複数のリージョンにまたがる正常なバックエンド間で分散されます。	HTTP 503 を返す
リージョン内部アプリケーション ロードバランサ	同じリージョン内の正常なバックエンドへの自動フェイルオーバー。 Envoy プロキシは、構成されたトラフィック分散に基づいて、リージョン内の正常なバックエンドにトラフィックを送信します。	HTTP 503 を返す

高可用性とクロスリージョン フェイルオーバー

リージョン内部アプリケーション ロードバランサの場合

高可用性を実現するには、アプリケーションのトラフィックを最も適切にサポートするリージョンに、複数のリージョン内部アプリケーション ロードバランサをデプロイします。次に、Cloud DNS の位置情報ルーティング ポリシーを使用して、リージョンの停止中にロードバランサが応答しているかどうかを検出します。位置情報ポリシーは、クライアント リクエストの送信元に基づいて、次に最も近い使用可能なリージョンにトラフィックをルーティングします。ヘルスチェックは、内部アプリケーション ロードバランサでデフォルトで使用できます。

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

複数のリージョンにクロスリージョン内部アプリケーション ロードバランサを設定すると、次のメリットが得られます。

1. リージョン内のクロスリージョン内部アプリケーション ロードバランサに障害が発生した場合、DNS ルーティング ポリシーは、別のリージョンのクロスリージョン内部アプリケーション ロードバランサにトラフィックを転送します。

   高可用性のデプロイ例は次のとおりです。

   • VPC ネットワークの RegionA リージョンと RegionB リージョンにフロントエンド仮想 IP アドレス（VIP）を持つクロスリージョン内部アプリケーション ロードバランサ。クライアントは RegionA リージョンに配置されています。
   • 2 つのリージョンのフロントエンド VIP を使用してロードバランサにアクセスできるようにし、DNS ルーティング ポリシーを使用してクライアントに最適な VIP を返すことができます。クライアントが地理的に最も近い VIP を使用するように設定する場合は、位置情報ルーティング ポリシーを使用します。
   • DNS ルーティング ポリシーは、リージョンの停止時に VIP が応答していないかどうかを検出し、次に最適な VIP をクライアントに返して、リージョンの停止中でもアプリケーションを維持できます。

   

2. 特定のリージョンのバックエンドが停止した場合、クロスリージョン内部アプリケーション ロードバランサのトラフィックは別のリージョンのバックエンドに正常にフェイルオーバーされます。

   クロスリージョン フェイルオーバーのデプロイは次のとおりです。

   • VPC ネットワークの RegionA リージョンにフロントエンド VIP アドレスを持つクロスリージョン内部アプリケーション ロードバランサがあります。クライアントも RegionA リージョンにあります。
   • Google Cloud リージョンの RegionA と RegionB のバックエンドを参照するグローバル バックエンド サービス。
   • RegionAリージョンのバックエンドがダウンしている場合、トラフィックはRegionBリージョンにフェイルオーバーします。

   

WebSocket のサポート

Google Cloud の HTTP(S) ベースのロードバランサは、HTTP または HTTPS をバックエンドへのプロトコルとして使用する場合に、WebSocket プロトコルをサポートします。ロードバランサに、WebSocket 接続のプロキシを構成する必要はありません。

WebSocket プロトコルは、クライアントとロードバランサ間に全二重通信チャネルを提供します。詳細については、RFC 6455 をご覧ください。

WebSocket プロトコルは次のように機能します。

1. ロードバランサが、HTTP(S) クライアントからの WebSocket Upgrade リクエストを認識します。リクエストには Connection: Upgrade、Upgrade: websocket ヘッダーが含まれ、その後に他の WebSocket 関連のリクエスト ヘッダーが続きます。
2. バックエンドが WebSocket Upgrade レスポンスを送信します。バックエンド インスタンスが、Connection: Upgrade ヘッダー、Upgrade: websocket ヘッダー、その他の WebSocket 関連レスポンス ヘッダーを含む 101 switching protocol レスポンスを送信します。
3. ロードバランサが、現在の接続期間中、双方向のトラフィックをプロキシします。

バックエンド インスタンスがレスポンス コード 426 または 502 でエラー レスポンスを返した場合、ロードバランサは接続を終了します。

WebSocket のセッション アフィニティは、他のリクエストの場合と同じように機能します。詳細については、セッション アフィニティをご覧ください。

gRPC のサポート

gRPC は、リモート プロシージャ コール用のオープンソース フレームワークです。これは HTTP/2 標準に基づいています。gRPC のユースケースには次のものがあります。

• 低レイテンシでスケーラビリティの高い分散システム
• クラウド サーバーと通信するモバイル クライアントの開発
• 正確かつ効率的で言語に依存しない新しいプロトコルの設計
• 拡張、認証、ロギングを可能にする階層型の設計

Google Cloud アプリケーションで gRPC を使用するには、HTTP/2 経由でエンドツーエンドでリクエストをプロキシする必要があります。手順は次のとおりです。

1. HTTPS ロードバランサを構成します。
2. ロードバランサからバックエンドへのプロトコルとして HTTP/2 を有効にします。

ロードバランサは、ALPN TLS 拡張を使用して SSL handshake の一部としてクライアントと HTTP/2 をネゴシエートします。

ロードバランサは、ロードバランサとバックエンド インスタンスの間で HTTP/2 を使用するように構成されたロードバランサで、一部のクライアントと HTTPS をネゴシエートしたり安全でない HTTP リクエストを受け入れたりすることもあります。これらの HTTP または HTTPS リクエストはロードバランサによって変換され、リクエストは HTTP/2 経由でバックエンド インスタンスにプロキシされます。

バックエンドで TLS を有効にする必要があります。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。

TLS サポート

デフォルトでは、HTTPS ターゲット プロキシは、クライアントの SSL リクエストを終端するときに TLS 1.0、1.1、1.2、1.3 のみを受け入れます。

ロードバランサが HTTPS をバックエンド サービス プロトコルとして使用する場合は、TLS 1.0、1.1、1.2、1.3 をバックエンドにネゴシエートできます。

相互 TLS のサポート

相互 TLS（mTLS）は、クライアントとサーバーの間の相互認証のための業界標準プロトコルです。これにより、クライアントとサーバーの両方が、信頼できる認証局（CA）によって発行された有効な証明書を保持していることを確認することで、相互に認証されます。サーバーのみが認証される標準の TLS とは異なり、mTLS では、クライアントとサーバーの両方が証明書を提示し、通信を確立する前に両方の ID を確認する必要があります。

すべてのアプリケーション ロードバランサは mTLS をサポートしています。mTLS では、ロードバランサはクライアントに対し、TLS handshake 中にクライアント ID を認証する証明書を送信するようリクエストします。Certificate Manager トラストストアを構成して、ロードバランサがクライアント証明書の信頼チェーンの検証に使用できます。

mTLS の詳細については、相互 TLS 認証をご覧ください。

制限事項

• リージョンの 1 つのゾーン内のクライアントからのリクエストが、クライアントと同じゾーンにあるバックエンドに送信される保証はありません。セッション アフィニティによってゾーン間の通信は減少しません。

• 内部アプリケーション ロードバランサは、次の機能に対応していません。

  • Cloud CDN
  • Cloud Storage バケット
  • Google マネージド SSL 証明書

• 内部アプリケーション ロードバランサは、TLS でのみ HTTP/2 をサポートします。

• 内部アプリケーション ロードバランサに接続するクライアントは、HTTP バージョン 1.1 以降を使用する必要があります。HTTP 1.0 はサポートされていません。

• プロキシ専用サブネットで IP アドレスが不足していても、Google Cloud は警告を表示しません。

• 内部アプリケーション ロードバランサが使用する内部転送ルールには、ポートを 1 つだけ設定する必要があります。

• 内部アプリケーション ロードバランサは Cloud Trace をサポートしていません。

• 共有 VPC 環境で Cloud Run と内部アプリケーション ロードバランサを使用する場合、サービス プロジェクトのスタンドアロン VPC ネットワークは、他のサービス（同じ共有 VPC 環境内のサービス プロジェクト内）にデプロイされた他の Cloud Run サービスにトラフィックを送信できます。これは既知の問題であり、この形式のアクセスは今後ブロックされます。

• バックエンド サービスがタイムアウトになるまで基盤となる TCP 接続が維持されるとは限りません。クライアント システムでは、TCP 接続が長時間持続することに依存するのではなく、再試行ロジックを実装する必要があります。

次のステップ

• 共有 VPC 設定でロード バランシングを構成する。共有 VPC を使用した内部アプリケーション ロードバランサを設定するをご覧ください。

• GKE Pod で実行するサービスのロード バランシングを構成する。GKE Gateway のデプロイ、スタンドアロン NEG を使用したコンテナ ネイティブのロード バランシング、内部アプリケーション ロードバランサをスタンドアロン NEG に接続するのセクションをご覧ください。

• プロキシ専用サブネットのリソースを管理する。プロキシ専用サブネットをご覧ください。

• リージョン内部アプリケーション ロードバランサでバックエンドのサブセット化を構成する。バックエンドのサブセット化をご覧ください。

• Private Service Connect を使用してリージョン内部アプリケーション ロードバランサを構成するには、コンシューマ HTTP(S) サービス コントロールを使用した Private Service Connect の構成をご覧ください。

• ロード バランシング データパスにカスタム ロジックを挿入するには、Service Extensions プラグインまたはコールアウトを構成します。