Google Cloud 内部 HTTP(S) ロードバランサは、プロキシベースのリージョン レイヤ 7 ロードバランサであり、内部 IP アドレスの背後でサービスを実行し、スケーリングできます。
内部 HTTP(S) ロードバランサは、Compute Engine、Google Kubernetes Engine（GKE）、Cloud Run でホストされているバックエンドに HTTP / HTTPS のトラフィックを分散します。ロードバランサには、内部 IP アドレスを使用して Virtual Private Cloud（VPC）ネットワークの特定のリージョンでのみアクセスできます。
内部 HTTP(S) ロードバランサは、オープンソースの Envoy プロキシをベースにしたマネージド サービスです。HTTP(S) パラメータに基づく、さまざまなトラフィック制御機能を使用できるようになっています。ロードバランサを構成すると、トラフィックの要件に応じて Envoy プロキシが自動的に割り当てられます。
内部 HTTP(S) ロードバランサは、次のものから構成されます。
- クライアントがトラフィックを送信する内部 IP アドレス。この IP アドレスにアクセスできるのは、ロードバランサと同じリージョンにあるクライアントだけです。内部クライアントのリクエストは、ネットワークとリージョンの内部に保持されます。
- ロードバランサがトラフィックを転送する 1 つ以上のバックエンド サービス。バックエンドは、Compute Engine VM、Compute Engine VM のグループ（インスタンス グループ）、Cloud Run アプリケーション、または GKE ノード（ネットワーク エンドポイント グループ、NEG）です。これらのバックエンドは、ロードバランサと同じリージョンに配置する必要があります。
内部 HTTP(S) ロードバランサに固有の制限については、制限事項のセクションをご覧ください。
他の各種 Google Cloud ロードバランサとの相違点については、次のドキュメントをご覧ください。
ユースケース
内部 HTTP(S) ロードバランサは多くのユースケースに対応しています。このセクションでは、そのいくつかについて説明します。その他の例については、トラフィック管理のユースケースをご覧ください。
3 層ウェブサービス
内部 HTTP(S) ロードバランサを使用して、従来の 3 層ウェブサービスをサポートできます。次の例は、3 種類の Google Cloud ロードバランサを使用して 3 つの層をスケーリングする方法を示しています。それぞれの層で、トラフィックの種類に応じてロードバランサのタイプが決まります。
ウェブ層: インターネットから入ってきたトラフィックが、外部の HTTP(S) ロードバランサによって負荷分散されます。
アプリケーション層: リージョン内部の HTTP(S) ロードバランサを使用して、アプリケーション層がスケーリングされます。
データベース層: データベース層は、内部 TCP / UDP ロードバランサを使用してスケーリングされます。
次の図に、トラフィックがどのようにそれぞれの層を通過するのかを示します。
- 外部 HTTP(S) ロードバランサは、インターネットから入ってきたトラフィックを複数のリージョンにまたがるウェブ フロントエンド インスタンス グループに配信します。
- フロントエンドが、リージョン内部の一連の HTTP(S) ロードバランサに HTTP(S) トラフィックを配信します。
- 内部 HTTP(S) ロードバランサが、トラフィックをミドルウェア インスタンス グループに配信します。
- ミドルウェア インスタンス グループが、トラフィックを内部 TCP / UDP ロードバランサに送り、トラフィックをデータ ストレージ クラスタに負荷分散します。
パスベース ルーティングによる負荷分散
一般的なユースケースの一つとして、サービス間のトラフィックのロード バランシングがあります。この例では、内部クライアントが動画と画像のコンテンツをリクエストしています。同じベース URL（mygcpservice.internal）を使用してますが、パスは異なります（/video と /images）。
内部 HTTP(S) 負荷分散の URL マップに従い、パス /video に対するリクエストは動画のバックエンド サービスに送信され、/images に対するリクエストは画像のバックエンド サービスに送信されます。次の例では、動画と画像のバックエンド サービスは Compute Engine VM で処理されていますが、GKE Pod を使用して処理することもできます。
内部クライアントがロードバランサの内部 IP アドレスにリクエストを送信すると、ロードバランサはこのロジックに従ってリクエストを評価し、適切なバックエンド サービスにリクエストを送信します。
このユースケースは次の図のようになります。
レガシー サービスのモダナイゼーション
内部 HTTP(S) ロードバランサは、レガシー アプリケーションのモダナイゼーションに効果的なツールです。
このようなアプリケーションとして、簡単に更新できない規模の大きいモノリシック アプリケーションがあります。この場合、レガシー アプリケーションの前に内部 HTTP(S) ロードバランサをデプロイできます。次に、ロードバランサのトラフィック制御機能を使用して、レガシー アプリケーションの機能に代わる新しいマイクロサービスにトラフィックのサブセットを転送します。
まず始めに、デフォルトですべてのトラフィックがレガシー アプリケーションにルーティングされるように、ロードバランサの URL マップを構成します。これにより、既存の動作が維持されます。レガシー アプリケーションに代わる新しいサービスがデプロイされたら、URL マップを更新し、トラフィックの一部をこの新しいサービスにルーティングします。
ここで、レガシー アプリケーションに動画処理機能があり、内部クライアントが /video にリクエストを送信したときに、この機能が処理される場合について考えてみましょう。この動画サービスは、次のようにマイクロサービスに分割できます。
- レガシー アプリケーションの前に内部 HTTP(S) ロードバランサを追加します。
- レガシー アプリケーションに代わる動画処理マイクロサービスを作成します。
- ロードバランサの URL マップを更新し、パス
/videoに対するすべてのリクエストをレガシー アプリケーションではなく、新しいマイクロサービスにルーティングします。
別の代替サービスを開発する場合も、この URL マップを更新します。時間の経過とともに、レガシー アプリケーションにルーティングされるリクエストが少なくなっていきます。最終的には、レガシー アプリケーションが提供するすべての機能に代替サービスが存在する状態になります。この時点で、レガシー アプリケーションを廃止できます。
グローバル アクセスが有効な 3 層ウェブサービス
グローバル アクセスを有効にすると、ウェブ層クライアント VM を別のリージョンに配置できます。
この多層アプリケーションの例のフローは、次のとおりです。
- グローバルに利用可能な、インターネットに接続したウェブ層が、HTTP(S) ロードバランサを使用してトラフィックをロード バランシングする。
us-east1リージョンの内部バックエンド ロード バランシングされたデータベース層に、グローバル ウェブ層がアクセスする。europe-west1リージョンのウェブ層の一部であるクライアント VM が、us-east1にある内部ロードバランスされたデータベース層にアクセスする。
ハイブリッド接続でのロード バランシング
Cloud Load Balancing は、オンプレミス データセンターや他のパブリック クラウドなどの Google Cloud の外部に拡張され、ハイブリッド接続で到達可能なエンドポイントへのトラフィックをロード バランシングできます。
次の図は、内部 HTTP(S) ロードバランサを使用したハイブリッド デプロイメントを示しています。
Private Service Connect
内部 HTTP(S) ロードバランサを使用して、サポートされているリージョンの Google API とサービスにリクエストを送信できます。詳細については、バックエンド経由で Google API にアクセスするをご覧ください。
GKE アプリケーションのロード バランシング
GKE でアプリケーションを構築する場合は、組み込みの GKE Gateway Controller または GKE Ingress コントローラを使用することをおすすめします。GKE ユーザーに代わって Google Cloud ロードバランサをデプロイします。これは、このページで説明しているスタンドアロンのロード バランシング アーキテクチャと同じですが、ライフサイクルが GKE によって完全に自動化、制御される点で異なります。
関連する GKE のドキュメント:
- 内部 HTTP(S) ロードバランサに Gateway を使用する
- 内部 Gateway を構成する
- 内部 HTTP(S) ロードバランサに Ingress を使用する
- 内部 HTTP(S) ロードバランサに Ingress を構成する
アーキテクチャとリソース
次の図は、内部 HTTP(S) ロードバランサに必要な Google Cloud リソースを示しています。
各内部 HTTP(S) ロードバランサは、次の Google Cloud 構成リソースを使用します。
プロキシ専用サブネット
上の図では、プロキシ専用サブネットには、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。内部 HTTP(S) ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを 1 つ作成する必要があります。リージョンと VPC ネットワーク内のすべての内部 HTTP(S) ロードバランサは、同一のプロキシ専用サブネットを共有します。これは、リージョンと VPC ネットワーク内のすべての内部 HTTP(S) ロードバランサが Envoy プロキシのプールを共有するためです。さらに、
- プロキシ専用サブネットは Envoy プロキシにのみ使用され、バックエンドには使用されません。
- リージョンと VPC ネットワーク内のすべての内部 HTTP(S) ロードバランサのバックエンド VM またはエンドポイントは、プロキシ専用サブネットからの接続を受信します。
- 内部 HTTP(S) ロードバランサの IP アドレスは、プロキシ専用サブネットにはありません。ロードバランサの IP アドレスは、後述する内部マネージド転送ルールで定義します。
転送ルールと IP アドレス
内部マネージド転送ルール。内部 IP アドレス、ポート、リージョン ターゲット HTTP(S) プロキシを指定します。クライアントは IP アドレスとポートを使用してロードバランサの Envoy プロキシに接続します。転送ルールの IP アドレスはロードバランサの IP アドレスです（仮想 IP アドレスまたは VIP と呼ぶこともあります）。
内部 HTTP(S) ロードバランサに接続するクライアントは、HTTP バージョン 1.1 以降を使用する必要があります。サポートされているプロトコルの一覧については、ロードバランサの機能をご覧ください。
転送ルールに関連付けられた内部 IP アドレスは、同じネットワークとリージョンにある任意のサブネットから取得できます。次の条件に注意してください。
- IP アドレスは、バックエンド インスタンス グループと同じサブネットから取得できます（必須ではありません）。
- IP アドレスは、
--purposeフラグがREGIONAL_MANAGED_PROXYに設定されている予約済みプロキシ専用サブネットから取得しないでください。 - 内部 IP アドレスを複数の転送ルールと共有する場合は、IP アドレスの
--purposeフラグをSHARED_LOADBALANCER_VIPに設定します。
内部 HTTP(S) ロードバランサで使用する各転送ルールは、1 つの TCP ポートのみを参照できます。HTTP ロードバランサの場合、ポート 80 または 8080 を使用します。HTTPS ロードバランサの場合、ポート 443 を使用します。
転送ルールとグローバル アクセス
内部 HTTP(S) ロードバランサの転送ルールは、グローバル アクセスが有効になっている場合でもリージョン ルールになります。グローバル アクセスを有効にすると、リージョンの内部転送ルールの allowGlobalAccess フラグが true に設定されます。
ターゲット プロキシ
リージョン ターゲット 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 アドレスを記録する場合があります。
SSL 証明書
ターゲット HTTPS プロキシを使用する内部 HTTP(S) ロードバランサには、ロードバランサの構成の一部として秘密鍵と SSL 証明書が必要です。これらのロードバランサは、セルフマネージドのリージョン Compute Engine SSL 証明書を使用します。
SSL 証明書と Google Cloud プロキシ ロードバランサの詳細については、SSL 証明書の概要をご覧ください。
URL マップ
HTTP(S) プロキシは、リージョン URL マップを使用し、HTTP 属性（リクエストパス、Cookie、ヘッダーなど）に基づいてルーティングを決定します。このルーティングの決定に基づいて、プロキシは特定のリージョン バックエンド サービスにクライアントのリクエストを転送します。URL マップには、ヘッダーの書き換え、クライアントへのリダイレクトの送信、タイムアウト ポリシーの構成など、追加のアクションを指定できます。
バックエンド サービス
リージョン バックエンド サービスは、Compute Engine VM を含むインスタンス グループ、GKE コンテナを含む NEG、サポートされている Google API とサービスを指す Private Service Connect NEG など、正常なバックエンドにリクエストを配信します。
バックエンド サービスは、HTTP、HTTPS または HTTP/2 の各プロトコルをサポートします。HTTP/2 は TLS でのみサポートされます。クライアントとバックエンドで同じリクエスト プロトコルを使用する必要はありません。たとえば、クライアントは HTTP/2 を使用してロードバランサにリクエストを送信できます。また、ロードバランサはこれらのトラフィックを HTTP/1.1 でバックエンドに送信できます。
1 つ以上のバックエンドをバックエンド サービスに接続する必要があります。内部 HTTP(S) ロードバランサのスコープはグローバルではなくリージョンであるため、クライアントとバックエンドの VM またはエンドポイントはすべて同じリージョン内になければなりません。バックエンドは、次のいずれかの構成のインスタンス グループまたは NEG になります。
- マネージド インスタンス グループ（ゾーン単位またはリージョン単位）
- 非マネージド インスタンス グループ（ゾーン単位）
- ネットワーク エンドポイント グループ
インスタンス グループと NEG を同じバックエンド サービスで使用することはできません。
バックエンドと VPC ネットワーク
すべてのバックエンドは同じ VPC ネットワークとリージョンに配置する必要があります。VPC ネットワーク ピアリングで接続された VPC ネットワークであっても、異なる VPC ネットワークにバックエンドを配置することはできません。ピアリングされた VPC ネットワーク内のクライアント システムがロードバランサにアクセスする方法については、内部 HTTP(S) ロードバランサと接続されたネットワークをご覧ください。
バックエンドのサブセット化
バックエンドのサブセット化は、各プロキシ インスタンスにバックエンドのサブセットを割り当てることで、パフォーマンスとスケーラビリティを向上させるオプションの機能です。
デフォルトでは、バックエンドのサブセット化は無効になっています。この機能を有効にする方法については、内部 HTTP(S) ロードバランサのバックエンドのサブセット化をご覧ください。
ヘルスチェック
各バックエンド サービスは、ロードバランサからの接続を受信するバックエンドの稼働状況を定期的に監視するヘルスチェックを指定します。これにより、処理不能なバックエンドにリクエストが送信されるリスクを軽減できます。ヘルスチェックでは、アプリケーション自体が動作するかどうかはチェックされません。
ファイアウォール ルール
内部 HTTP(S) ロードバランサには、次のファイアウォール ルールが必要です。
- Google の中央のヘルスチェック範囲からのトラフィックを許可する上り（内向き）許可ルール。
35.191.0.0/16130.211.0.0/22
- プロキシ専用サブネットからのトラフィックを許可するための上り（内向き）許可ルール
クライアント アクセス
デフォルトでは、クライアントはロードバランサと同じリージョンに存在する必要があります。クライアントは、同じネットワークまたは、VPC ネットワーク ピアリングを使用して接続された VPC ネットワークに配置できます。グローバル アクセスを有効にして、任意のリージョンのクライアントがロードバランサにアクセスできるようにします。
次の表にクライアント アクセスの概要を示します。
| グローバル アクセスが無効な場合 | グローバル アクセスが有効な場合 |
|---|---|
| クライアントはロードバランサと同じリージョンになければなりません。また、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。 | クライアントはどのリージョンにでも配置できます。ただし、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。 |
| オンプレミス クライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを介してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、ロードバランサと同じリージョンになければなりません。 | オンプレミス クライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを使用してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、どのリージョンにでも配置できます。 |
共有 VPC のアーキテクチャ
内部 HTTP(S) ロードバランサは、共有 VPC を使用するネットワークをサポートします。組織は、共有 VPC を使用して複数のプロジェクトのリソースを共通の VPC ネットワークに接続できるため、そのネットワークの内部 IP を使用して、安全で効率的な相互通信を行うことができます。共有 VPC についてまだよく理解していない場合は、共有 VPC の概要のドキュメントをご覧ください。
共有 VPC ネットワーク内で内部 HTTP(S) ロードバランサを構成するには、多くの方法があります。デプロイの種類に関係なく、ロードバランサのすべてのコンポーネントを同じ組織に配置する必要があります。
| サブネットと IP アドレス | フロントエンド コンポーネント | バックエンド コンポーネント |
|---|---|---|
共有 VPC ホスト プロジェクトで必要なネットワークとサブネット（プロキシ専用サブネットを含む）を作成します。 ロードバランサの内部 IP アドレスは、ホスト プロジェクトまたはサービス プロジェクトのいずれかで定義できますが、ホスト プロジェクト内の目的の共有 VPC ネットワークのサブネットを使用する必要があります。アドレス自体は、参照先サブネットのプライマリ IP 範囲から取得します。 |
リージョン外部 IP アドレス、転送ルール、ターゲット HTTP(S) プロキシ、関連付けられた URL マップは、同じプロジェクトで定義する必要があります。このプロジェクトは、ホスト プロジェクトまたはサービス プロジェクトにできます。 | 次のいずれかを行います。
各バックエンド サービスは、参照するバックエンドと同じプロジェクトで定義する必要があります。バックエンド サービスに関連するヘルスチェックも、バックエンド サービスと同じプロジェクトで定義する必要があります。 |
共有 VPC ホスト プロジェクトですべてのロード バランシング コンポーネントとバックエンドを作成できますが、このモデルではネットワーク管理とサービス開発の責任が分離されません。
クライアントは、ロードバランサと同じ共有 VPC ネットワークとリージョンにある場合、内部 HTTP(S) ロードバランサにアクセスできます。クライアントは、ホスト プロジェクト、接続されたサービス プロジェクト、または任意の接続されたネットワークに配置できます。
共有 VPC 環境におけるサーバーレス バックエンド
サーバーレス NEG バックエンドを使用する内部 HTTP(S) ロードバランサの場合、バッキング Cloud Run サービス、バックエンド サービス、サーバーレス NEG は同じサービス プロジェクトに存在する必要があります。ロードバランサのフロントエンド コンポーネント（転送ルール、ターゲット プロキシ、URL マップ）は、ホスト プロジェクト、バックエンド コンポーネントと同じサービス プロジェクト、または同じ共有 VPC 環境内のサービス プロジェクトのいずれかに作成できます。
プロジェクト間のサービス参照
このモデルでは、ロードバランサのフロントエンドと URL マップはホスト プロジェクトまたはサービス プロジェクトに存在します。ロードバランサのバックエンド サービスとバックエンドは、共有 VPC 環境のプロジェクト間で分散できます。プロジェクト間のバックエンド サービスは 1 つの URL マップで参照できます。これはプロジェクト間のサービス参照と呼ばれます。
プロジェクト間のサービス参照を使用すると、組織は 1 つの一元的なロードバランサを構成し、複数の異なるプロジェクトに分散された数百のサービスにトラフィックをルーティングできます。トラフィック ルーティングのルールおよびポリシーはすべて、1 つの URL マップで一元管理できます。ロードバランサをホスト名と SSL 証明書の組み合わせの 1 つと関連付けることもできます。このため、アプリケーションのデプロイに必要なロードバランサの数を最適化することで、管理性の向上や、運用費および必要な割り当て量の削減につながります。
さらに、プロジェクトを部門ごとに分けて、組織内のロールを分離することもできます。サービス オーナーはサービス プロジェクト内のサービス構築に、ネットワーク チームは別のプロジェクト内のロードバランサのプロビジョニングと維持に専念できます。これらのプロジェクトは、プロジェクト間のサービス参照によって接続できます。
サービス オーナーは、サービスの公開に対する自律性を維持し、ロードバランサを介してサービスにアクセスできるユーザーを制御できます。この仕組みは、Compute ロードバランサ サービス ユーザーのロール（roles/compute.loadBalancerServiceUser）という特別な IAM ロールによって実現されます。
プロジェクト間のサービス参照は、インスタンス グループ、サーバーレス NEG、他のサポートされているバックエンド タイプで使用できます。
例 1: ロードバランサのフロントエンドとバックエンドが別のサービス プロジェクトに存在する
次のデプロイの例では、ロードバランサのフロントエンドと URL マップがサービス プロジェクト A に作成され、URL マップはサービス プロジェクト B のバックエンド サービスを参照しています。
この場合、サービス プロジェクト A のネットワーク管理者またはロードバランサ管理者は、サービス プロジェクト B のバックエンド サービスにアクセスする必要があります。サービス プロジェクト B の管理者は、サービス プロジェクト B のバックエンド サービスを参照するサービス プロジェクト A のロードバランサ管理者に compute.loadBalancerServiceUser IAM ロールを付与します。
例 2: ホスト プロジェクト内のロードバランサのフロントエンドと、サービス プロジェクトのバックエンド
このタイプのデプロイでは、ロードバランサのフロントエンドと URL マップがホスト プロジェクトに作成され、バックエンド サービス（とバックエンド）がサービス プロジェクトに作成されます。
この場合、ホスト プロジェクトのネットワーク管理者またはロードバランサ管理者は、サービス プロジェクトのバックエンド サービスにアクセスする必要があります。サービス プロジェクトの管理者は、サービス プロジェクトのバックエンド サービスを参照するホスト プロジェクト A のロードバランサ管理者に compute.loadBalancerServiceUser IAM ロールを付与します。
サービス プロジェクト内のすべてのロードバランサ コンポーネントとバックエンド
このモデルでは、ロードバランサのすべてのコンポーネントとバックエンドがサービス プロジェクトに存在します。このデプロイモデルは、すべての HTTP(S) ロードバランサでサポートされています。
ロードバランサは、ホスト プロジェクトの IP アドレスとサブネットを使用します。
タイムアウトと再試行
内部 HTTP(S) ロードバランサには、次のタイムアウトがあります。構成可能な HTTP バックエンド サービス タイムアウト。ロードバランサがバックエンドから完全な HTTP レスポンスが返されるまで待機する時間です。バックエンド サービス タイムアウトのデフォルト値は 30 秒です。指定できるタイムアウト値の範囲は 1～2,147,483,647 秒です。
たとえば、500 MB のファイルをダウンロードする場合、バックエンド サービスのタイムアウトの値がデフォルト値の 30 秒であれば、ロードバランサはバックエンドが 500 MB ファイル全体を 30 秒以内で配信すると想定します。バックエンドが完全な HTTP レスポンスを送信するのに十分でない時間をバックエンド サービスのタイムアウトに構成することもできます。この状況では、少なくともロードバランサが HTTP レスポンス ヘッダーを受け取った場合、ロードバランサは完全なレスポンス ヘッダーと、バックエンド サービスのタイムアウト内で取得できる可能な限り多くのレスポンス本文を返します。
バックエンド サービスのタイムアウトは、Envoy とバックエンド間の処理のため、リクエストの最初のバイトからレスポンスの最後のバイトまでの最大時間に設定する必要があります。WebSocket を使用している場合は、バックエンド サービスのタイムアウトを WebSocket の最大時間（アイドルまたはアクティブ）に設定する必要があります。
次のいずれかの状況では、タイムアウトを長くすることを検討してください。
- バックエンドが HTTP レスポンスを返すのに時間がかかることが予想される場合。
- 接続が WebSocket にアップグレードされた場合。
設定するバックエンド サービスのタイムアウトはベスト エフォート型の目標です。ただし、基礎となる TCP 接続が、タイムアウトの間にオープン状態になっているとは限りません。
バックエンド サービスのタイムアウトは任意の値に設定できますが、1 日（86,400 秒）を超える値に設定しても、ロードバランサはその期間 TCP 接続を継続するわけではありません。Google は、ソフトウェアの更新と定期的なメンテナンスで Envoy プロキシを定期的に再起動しますが、バックエンド サービスのタイムアウトはそれをオーバーライドしません。バックエンド サービスのタイムアウトを長くするほど、Google が Envoy のメンテナンスで TCP 接続を終了する可能性が高くなります。このようなイベントの影響を減らすため、再試行ロジックの実装をおすすめします。
バックエンド サービス タイムアウトは、HTTP のアイドル（キープアライブ）タイムアウトではありません。バックエンドからの入出力（IO）は、クライアントの速度が遅い場合（ブラウザの接続が遅い場合など）にブロックされる可能性があります。この待機時間は、バックエンド サービス タイムアウトにはカウントされません。
バックエンド サービスのタイムアウトを構成するには、次のいずれかの方法を使用します。
- Google Cloud コンソール: ロードバランサのバックエンド サービスの [タイムアウト] フィールドを変更します。
- Google Cloud CLI:
gcloud compute backend-services updateコマンドを使用して、バックエンド サービス リソースの--timeoutパラメータを変更します。 - API: グローバルまたはリージョンのバックエンド サービス リソースの
timeoutSecパラメータを変更します。
- HTTP キープアライブ タイムアウト。この値は 10 分（600 秒）に固定されています。この値は、バックエンド サービスを変更しても構成できません。バックエンドによって接続が早期に閉じられないようにするには、バックエンドによって使用されているウェブサーバー ソフトウェアでキープアライブ タイムアウトを 600 秒より長い時間に構成する必要があります。このタイムアウトは WebSocket には適用されません。次の表は、一般的なウェブサーバー ソフトウェアのキープアライブ タイムアウトを変更するために必要な変更を示します。
ウェブサーバー ソフトウェア パラメータ デフォルト設定 推奨される設定 Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620 nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;
- ストリーム アイドル タイムアウト。この値は 5 分（300 秒）に固定されています。この値は構成できません。アクティビティがない状態が 5 分継続すると、HTTP ストリームがアイドル状態になります。
再試行数
再試行回数は、URL マップの再試行ポリシーを使用して構成できます。デフォルトの再試行回数（numRetries）は 1 回です。デフォルトのタイムアウト（perTryTimeout）は 30 秒です。perTryTimeout は最大で 24 時間に構成できます。
再試行ポリシーがない場合、HTTP 本文のない、失敗したリクエスト（GET リクエストなど）が HTTP 502、503、または 504 レスポンスを返すと、1 回再試行されます。HTTP POST リクエストは再試行されません。
再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。
詳細については、内部 HTTP(S) ロードバランサのロギングとモニタリングをご覧ください。
接続されたネットワークへのアクセス
接続ネットワークから VPC ネットワーク内の内部 HTTP(S) ロードバランサにアクセスする方法は、次のとおりです。
- VPC ネットワーク ピアリング
- Cloud VPN と Cloud Interconnect
詳細な例については、内部 HTTP(S) ロードバランサと接続されたネットワークをご覧ください。
フェイルオーバー
バックエンドが異常な状態になった場合、トラフィックは同じリージョン内の正常なバックエンドに自動的にリダイレクトされます。すべてのバックエンドが異常な状態の場合、ロードバランサは HTTP 503 Service Unavailable レスポンスを返します。
WebSocket のサポート
Google Cloud の HTTP(S) ベースのロードバランサは、HTTP または HTTPS をバックエンドへのプロトコルとして使用する場合、WebSocket プロトコルをネイティブにサポートします。ロードバランサに、WebSocket 接続のプロキシを構成する必要はありません。
WebSocket プロトコルは、クライアントとサーバー間で全二重の通信チャネルを提供します。HTTP(S) リクエストによってチャネルが開始されます。プロトコルの詳細については、RFC 6455 をご覧ください。
ロードバランサで HTTP(S) クライアントからの WebSocket Upgrade リクエストが認識され、続いてバックエンド インスタンスから Upgrade の正常終了のレスポンスが送られた場合、現在の接続の存続期間の間、ロードバランサによって双方向トラフィックがプロキシされます。バックエンド インスタンスから Upgrade の正常終了のレスポンスが返されない場合、ロードバランサによって接続が閉じられます。
WebSocket 接続のタイムアウトは、ロードバランサの構成可能なバックエンド サービス タイムアウトによって異なります。デフォルトは 30 秒です。このタイムアウトは、WebSocket 接続が使用中かどうかに関係なく WebSocket 接続に適用されます。
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 のみを受け入れます。
内部 HTTP(S) ロードバランサが HTTPS をバックエンド サービス プロトコルとして使用する場合は、TLS 1.0、1.1、1.2、1.3 をバックエンドにネゴシエートできます。
制限事項
リージョンの 1 つのゾーン内のクライアントからのリクエストが、クライアントと同じゾーンにあるバックエンドに送信される保証はありません。セッション アフィニティによってゾーン間の通信は減少しません。
内部 HTTP(S) ロードバランサは次の機能に対応していません。
内部 HTTP(S) ロードバランサは、TLS でのみ HTTP/2 をサポートします。
内部 HTTP(S) ロードバランサに接続するクライアントは、HTTP バージョン 1.1 以降を使用する必要があります。HTTP 1.0 はサポートされていません。
プロキシ専用サブネットで IP アドレスが不足していても、Google Cloud は警告を表示しません。
内部 HTTP(S) ロードバランサが使用する内部転送ルールには、ポートが 1 つだけ必要です。
内部 HTTP(S) ロードバランサは Cloud Trace をサポートしていません。
共有 VPC 環境で Cloud Run と内部 HTTP(S) ロードバランサを使用する場合、サービス プロジェクトのスタンドアロン VPC ネットワークは、他のサービス（同じ共有 VPC 環境内のサービス プロジェクト内）にデプロイされた他の Cloud Run サービスにトラフィックを送信できます。これは既知の問題であり、この形式のアクセスは今後ブロックされます。
次のステップ
- Compute Engine VM で実行するサービスのロード バランシングを構成する。Compute Engine VM に内部 HTTP(S) ロードバランサを設定するをご覧ください。
- 共有 VPC 設定でロード バランシングを構成する。共有 VPC を使用した内部 HTTP(S) ロードバランサを設定するをご覧ください。
- GKE Pod で実行するサービスのロード バランシングを構成する。GKE Gateway のデプロイ、スタンドアロン NEG を使用したコンテナ ネイティブのロード バランシング、内部 HTTP(S) ロードバランサをスタンドアロン NEG に接続するのセクションをご覧ください。
- Private Service Connect を使用して内部 HTTP(S) ロードバランサを構成する。コンシューマ HTTP(S) サービス コントロールを使用した Private Service Connect の構成をご覧ください。
- プロキシ専用サブネットのリソースを管理する。プロキシ専用サブネットをご覧ください。
- 内部 HTTP(S) ロードバランサでバックエンドのサブセット化を構成する。バックエンドのサブセット化をご覧ください。