このドキュメントでは、内部アプリケーション ロードバランサの構成に必要なコンセプトについて説明します。
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 同一または異なるリージョンの正常なバックエンドへの自動フェイルオーバー。 同じリージョン内の正常なバックエンドへの自動フェイルオーバー。
モードを特定する
Cloud コンソール
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
[ロードバランサ] タブに、ロードバランサのタイプ、プロトコル、リージョンが表示されます。リージョンが空の場合、ロードバランサはクロスリージョン モードになっています。次の表に、ロードバランサのモードを識別する方法を示します。
ロードバランサ モード ロードバランサの種類 アクセスタイプ リージョン リージョン内部アプリケーション ロードバランサ アプリケーション 内部 リージョンを指定 クロスリージョン内部アプリケーション ロードバランサ アプリケーション 内部
gcloud
ロードバランサのモードを確認するには、次のコマンドを実行します。
gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
コマンド出力で、ロード バランシング スキーム、リージョン、ネットワーク ティアを確認します。次の表に、ロードバランサのモードを識別する方法を示します。
>ロードバランサ モード ロード バランシング スキーム 転送ルール クロスリージョン内部アプリケーション ロードバランサ INTERNAL_MANAGED グローバル リージョン内部アプリケーション ロードバランサ INTERNAL_MANAGED リージョン
アーキテクチャとリソース
次の図は、各モードの内部アプリケーション ロードバランサに必要な Google Cloud リソースを示しています。
クロスリージョン
次の図は、同じ VPC ネットワーク内のプレミアム ティアにクロスリージョン内部アプリケーション ロードバランサをデプロイした場合のコンポーネントを示しています。各グローバル転送ルールは、クライアントが接続に使用するリージョン IP アドレスを使用します。
リージョン
この図は、プレミアム ティアにリージョン内部アプリケーション ロードバランサをデプロイした場合のコンポーネントを示しています。
各内部アプリケーション ロードバランサは、次の 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 アドレス、プロキシ専用サブネット --purpose |
クライアントからロードバランサのフロントエンドへのルーティング |
|---|---|---|
| クロスリージョン内部アプリケーション ロードバランサ |
ロード バランシング スキーム:
プロキシ専用サブネット
IP アドレス
|
グローバル アクセスはデフォルトで有効になっており、VPC 内の任意のリージョンのクライアントがロードバランサにアクセスできます。バックエンドは複数のリージョンに配置できます。 |
| リージョン内部アプリケーション ロードバランサ |
ロード バランシング スキーム:
プロキシ専用サブネット
IP アドレス
|
グローバル アクセスを有効にして、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 を示しています。
| ターゲット プロキシ | クロスリージョン内部アプリケーション ロードバランサ | リージョン内部アプリケーション ロードバランサ |
|---|---|---|
| HTTP | グローバル targetHttpProxies |
regionTargetHttpProxies |
| HTTPS | グローバル targetHttpsProxies |
regionTargetHttpsProxies |
SSL 証明書
ターゲット HTTPS プロキシを使用する内部アプリケーション ロードバランサには、ロードバランサの構成の一部として秘密鍵と SSL 証明書が必要です。
次の表に、各モードの内部アプリケーション ロードバランサが必要とする SSL 証明書のタイプを示します。
| ロードバランサ モード | SSL 証明書の種類 |
|---|---|
| リージョン内部アプリケーション ロードバランサ |
Certificate Manager のセルフマネージド証明書と Google マネージド証明書。 Certificate Manager では、次のタイプの Google マネージド証明書がサポートされています。
ロードバランサ認証を使用する Google マネージド証明書はサポートされていません。 |
| クロスリージョン内部アプリケーション ロードバランサ | Certificate Manager のセルフマネージド証明書と Google マネージド証明書。 Certificate Manager では、次のタイプの 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 |
||||||||||
*バックエンド サービス上のバックエンドは、同じタイプ（すべてインスタンス グループまたはすべて同じタイプの NEG）である必要があります。このルールの例外は、GCE_VM_IP_PORT ゾーン NEG とハイブリッド NEG の両方を同じバックエンド サービスで使用して、ハイブリッド アーキテクチャをサポートできることです。
† ゾーン非マネージド インスタンス グループ、ゾーン マネージド インスタンス グループ、リージョン マネージド インスタンス グループの組み合わせは、同じバックエンド サービスでサポートされます。2 つ以上のバックエンド サービスのバックエンドであるマネージド インスタンス グループで自動スケーリングを使用する場合は、複数のシグナルを使用するようにインスタンス グループの自動スケーリング ポリシーを構成します。
‡ ゾーン NEG では GCE_VM_IP_PORT エンドポイントを使用する必要があります。
バックエンドと 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/16130.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 Controller を使用して作成された内部ゲートウェイは、内部アプリケーション ロードバランサの任意のモードを使用できます。ロードバランサのモードは、GatewayClass を選択して制御します。GKE Gateway Controller は常に
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 マップは、同じプロジェクトで定義する必要があります。このプロジェクトは、ホスト プロジェクトまたはサービス プロジェクトにできます。 | 次のいずれかを行います。
各バックエンド サービスは、参照するバックエンドと同じプロジェクトで定義する必要があります。バックエンド サービスに関連するヘルスチェックも、バックエンド サービスと同じプロジェクトで定義する必要があります。 |
共有 VPC ホスト プロジェクトですべてのロード バランシング コンポーネントとバックエンドを作成できますが、このタイプのデプロイではネットワーク管理とサービス開発の責任が分離されません。
サービス プロジェクト内のすべてのロードバランサ コンポーネントとバックエンド
次のアーキテクチャ図は、すべてのロードバランサのコンポーネントとバックエンドがサービス プロジェクト内にある標準の共有 VPC デプロイを示しています。このデプロイタイプは、すべてのアプリケーション ロードバランサでサポートされています。
ロードバランサは、ホスト プロジェクトの IP アドレスとサブネットを使用します。クライアントは、ロードバランサと同じ共有 VPC ネットワークとリージョンにある場合、内部アプリケーション ロードバランサにアクセスできます。クライアントは、ホスト プロジェクト、接続されたサービス プロジェクト、または任意の接続されたネットワークに配置できます。
共有 VPC 環境におけるサーバーレス バックエンド**
サーバーレス NEG バックエンドを使用する内部アプリケーション ロードバランサの場合、バッキング Cloud Run サービス、バックエンド サービス、サーバーレス NEG は同じサービス プロジェクトに存在する必要があります。ロードバランサのフロントエンド コンポーネント（転送ルール、ターゲット プロキシ、URL マップ）は、ホスト プロジェクト、バックエンド コンポーネントと同じサービス プロジェクト、または同じ共有 VPC 環境内のサービス プロジェクトのいずれかに作成できます。
プロジェクト間のサービス参照
このモデルでは、ロードバランサのフロントエンドと URL マップはホスト プロジェクトまたはサービス プロジェクトに存在します。ロードバランサのバックエンド サービスとバックエンドは、共有 VPC 環境のプロジェクト間で分散できます。プロジェクト間のバックエンド サービスは 1 つの URL マップで参照できます。これは、プロジェクト間のサービス参照と呼ばれます。
プロジェクト間のサービス参照を使用すると、組織は 1 つの一元的なロードバランサを構成し、複数の異なるプロジェクトに分散された数百のサービスにトラフィックをルーティングできます。トラフィック ルーティングのルールおよびポリシーはすべて、1 つの URL マップで一元管理できます。ロードバランサをホスト名と SSL 証明書の組み合わせの 1 つと関連付けることもできます。このため、アプリケーションのデプロイに必要なロードバランサの数を最適化することで、管理性の向上や、運用費および必要な割り当て量の削減につながります。
さらに、プロジェクトを部門ごとに分けて、組織内のロールを分離することもできます。サービス オーナーはサービス プロジェクト内のサービス構築に、ネットワーク チームは別のプロジェクト内のロードバランサのプロビジョニングと維持に専念できます。これらのプロジェクトは、プロジェクト間のサービス参照によって接続できます。
サービス オーナーは、サービスの公開に対する自律性を維持し、ロードバランサを介してサービスにアクセスできるユーザーを制御できます。この仕組みは、Compute ロードバランサ サービス ユーザーのロール（roles/compute.loadBalancerServiceUser）という特別な IAM ロールによって実現されます。
プロジェクト間のサービス参照に関する既知の制限事項
- バックエンド サービスにリージョン インターネット NEG バックエンドがある場合、プロジェクト間のバックエンド サービスを参照することはできません。他のバックエンド タイプはすべてサポートされています。
- Google Cloud では、複数のプロジェクトで同じ名前を使用するリソース（バックエンド サービスなど）は区別されません。したがって、プロジェクト間のサービス参照を使用する場合は、組織内のプロジェクト間で一意のバックエンド サービス名を使用することをおすすめします。
例 1: ロードバランサのフロントエンドとバックエンドが別のサービス プロジェクトに存在する
次のデプロイの例では、ロードバランサのフロントエンドと URL マップがサービス プロジェクト A に作成され、URL マップはサービス プロジェクト B のバックエンド サービスを参照しています。
この場合、サービス プロジェクト A のネットワーク管理者またはロードバランサ管理者は、サービス プロジェクト B のバックエンド サービスにアクセスする必要があります。サービス プロジェクト B の管理者は、サービス プロジェクト B のバックエンド サービスを参照するサービス プロジェクト A のロードバランサ管理者に compute.loadBalancerServiceUser IAM ロールを付与します。
例 2: ホスト プロジェクト内のロードバランサのフロントエンドと、サービス プロジェクトのバックエンド
このタイプのデプロイでは、ロードバランサのフロントエンドと URL マップがホスト プロジェクトに作成され、バックエンド サービス（とバックエンド）がサービス プロジェクトに作成されます。
この場合、ホスト プロジェクトのネットワーク管理者またはロードバランサ管理者は、サービス プロジェクトのバックエンド サービスにアクセスする必要があります。サービス プロジェクトの管理者は、サービス プロジェクトのバックエンド サービスを参照するホスト プロジェクト A のロードバランサ管理者に compute.loadBalancerServiceUser IAM ロールを付与します。
タイムアウトと再試行
内部アプリケーション ロードバランサは、次の種類のタイムアウトをサポートします。| タイムアウトの種類と説明 | デフォルト値 | カスタム値のサポート | |
|---|---|---|---|
| クロスリージョン | リージョン | ||
| バックエンド サービスのタイムアウト
リクエストとレスポンスのタイムアウトロードバランサがリクエストの最初のバイトをバックエンドに送信してから、バックエンドが HTTP レスポンスの最後のバイトをロードバランサに返すまでの最長時間を表します。バックエンドがこの時間内に HTTP レスポンス全体をロードバランサに返さなかった場合、残りのレスポンス データは破棄されます。 |
|
||
| クライアント 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 接続の持続時間に依存するのではなく、再試行ロジックを実装する必要があります。
バックエンド サービスのタイムアウトを構成するには、次のいずれかの方法を使用します。
コンソール
ロードバランサのバックエンド サービスの [タイムアウト] フィールドを変更します。
gcloud
gcloud compute backend-services update コマンドを使用して、バックエンド サービス リソースの --timeout パラメータを変更します。
API
regionBackendServices リソースの timeoutSec パラメータを変更します。
クライアント HTTP キープアライブ タイムアウト
クライアント HTTP キープアライブ タイムアウトは、TCP 接続が（ダウンストリーム）クライアントと Envoy プロキシ間でアイドル状態になっている最長時間を表します。リージョン内部アプリケーション ロードバランサとクロスリージョン内部アプリケーション ロードバランサの場合、デフォルト値は 600 秒です。クライアント HTTP キープアライブ タイムアウトは 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 の位置情報ルーティング ポリシーを使用して、リージョンの停止中にロードバランサが応答しているかどうかを検出します。位置情報ポリシーは、クライアント リクエストの送信元に基づいて、次に最も近い使用可能なリージョンにトラフィックをルーティングします。ヘルスチェックは、内部アプリケーション ロードバランサでデフォルトで使用できます。
クロスリージョン内部アプリケーション ロードバランサの場合
複数のリージョンにクロスリージョン内部アプリケーション ロードバランサを設定すると、次のメリットが得られます。
リージョン内のクロスリージョン内部アプリケーション ロードバランサに障害が発生した場合、DNS ルーティング ポリシーは、別のリージョンのクロスリージョン内部アプリケーション ロードバランサにトラフィックを転送します。
高可用性のデプロイ例は次のとおりです。
- VPC ネットワークの
RegionAリージョンとRegionBリージョンにフロントエンド仮想 IP アドレス（VIP）を持つクロスリージョン内部アプリケーション ロードバランサ。クライアントはRegionAリージョンに配置されています。 - 2 つのリージョンのフロントエンド VIP を使用してロードバランサにアクセスできるようにし、DNS ルーティング ポリシーを使用してクライアントに最適な VIP を返すことができます。クライアントが地理的に最も近い VIP を使用するように設定する場合は、位置情報ルーティング ポリシーを使用します。
- DNS ルーティング ポリシーは、リージョンの停止時に VIP が応答していないかどうかを検出し、次に最適な VIP をクライアントに返して、リージョンの停止中でもアプリケーションを維持できます。
高可用性デプロイでのクロスリージョン内部アプリケーション ロードバランサ（クリックして拡大） - VPC ネットワークの
特定のリージョンのバックエンドが停止した場合、クロスリージョン内部アプリケーション ロードバランサのトラフィックは別のリージョンのバックエンドに正常にフェイルオーバーされます。
クロスリージョン フェイルオーバーのデプロイは次のとおりです。
- VPC ネットワークの
RegionAリージョンにフロントエンド VIP アドレスを持つクロスリージョン内部アプリケーション ロードバランサがあります。クライアントもRegionAリージョンにあります。 - Google Cloud リージョンの
RegionAとRegionBのバックエンドを参照するグローバル バックエンド サービス。 RegionAリージョンのバックエンドが停止している場合、トラフィックはRegionBリージョンにフェイルオーバーされます。
クロスリージョン フェイルオーバー デプロイでのクロスリージョン内部アプリケーション ロードバランサ（クリックして拡大） - VPC ネットワークの
WebSocket のサポート
Google Cloud の HTTP(S) ベースのロードバランサは、HTTP または HTTPS をバックエンドへのプロトコルとして使用する場合に、WebSocket プロトコルをサポートします。ロードバランサに、WebSocket 接続のプロキシを構成する必要はありません。
WebSocket プロトコルは、クライアントとロードバランサ間に全二重通信チャネルを提供します。詳細については、RFC 6455 をご覧ください。
WebSocket プロトコルは次のように機能します。
- ロードバランサが、HTTP(S) クライアントからの WebSocket
Upgradeリクエストを認識します。リクエストにはConnection: Upgrade、Upgrade: websocketヘッダーが含まれ、その後に他の WebSocket 関連のリクエスト ヘッダーが続きます。 - バックエンドが WebSocket
Upgradeレスポンスを送信します。バックエンド インスタンスが、Connection: Upgradeヘッダー、Upgrade: websocketヘッダー、その他の WebSocket 関連レスポンス ヘッダーを含む101 switching protocolレスポンスを送信します。 - ロードバランサが、現在の接続期間中、双方向のトラフィックをプロキシします。
バックエンド インスタンスがレスポンス コード 426 または 502 でエラー レスポンスを返した場合、ロードバランサは接続を終了します。
WebSocket のセッション アフィニティは、他のリクエストの場合と同じように機能します。詳細については、セッション アフィニティをご覧ください。
gRPC のサポート
gRPC は、リモート プロシージャ コール用のオープンソース フレームワークです。これは HTTP/2 標準に基づいています。gRPC のユースケースには次のものがあります。
- 低レイテンシでスケーラビリティの高い分散システム
- クラウド サーバーと通信するモバイル クライアントの開発
- 正確かつ効率的で言語に依存しない新しいプロトコルの設計
- 拡張、認証、ロギングを可能にする階層型の設計
Google Cloud アプリケーションで gRPC を使用するには、HTTP/2 経由でエンドツーエンドでリクエストをプロキシする必要があります。手順は次のとおりです。
- HTTPS ロードバランサを構成します。
- ロードバランサからバックエンドへのプロトコルとして 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 をバックエンドにネゴシエートできます。
制限事項
リージョンの 1 つのゾーン内のクライアントからのリクエストが、クライアントと同じゾーンにあるバックエンドに送信される保証はありません。セッション アフィニティによってゾーン間の通信は減少しません。
内部アプリケーション ロードバランサは、次の機能に対応していません。
内部アプリケーション ロードバランサは、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 プラグインまたはコールアウトを構成します。