内部 HTTP(S) 負荷分散の概要

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)です。これらのバックエンドは、ロードバランサと同じリージョンに配置する必要があります。
レイヤ 7 ベースの負荷分散を使用した内部サービス(クリックして拡大)
レイヤ 7 ベースの負荷分散を使用した内部サービス(クリックして拡大)

内部 HTTP(S) 負荷分散に固有の制限については、制限事項のセクションをご覧ください。

Google Cloud の各種ロードバランサの違いについては、次のドキュメントをご覧ください。

ユースケース

内部 HTTP(S) 負荷分散には多くのユースケースがあります。このセクションでは、そのいくつかについて説明します。その他の例については、トラフィック管理のユースケースをご覧ください。

3 層ウェブサービス

内部 HTTP(S) 負荷分散を使用して、従来の 3 層ウェブサービスをサポートできます。次の例は、3 種類の Google Cloud ロードバランサを使用して 3 つの層をスケーリングする方法を示しています。それぞれの層で、トラフィックの種類に応じてロードバランサのタイプが決まります。

  • ウェブ層: インターネットから入ってきたトラフィックが、外部の HTTP(S) ロードバランサによって負荷分散されます。

  • アプリケーション層: リージョン内部の HTTP(S) ロードバランサを使用して、アプリケーション層がスケーリングされます。

  • データベース層: データベース層は、内部 TCP / UDP ロードバランサを使用してスケーリングされます。

次の図に、トラフィックがどのようにそれぞれの層を通過するのかを示します。

  1. 外部 HTTP(S) ロードバランサは、インターネットから入ってきたトラフィックを複数のリージョンにまたがるウェブ フロントエンド インスタンス グループに配信します。
  2. フロントエンドが、リージョン内部の一連の HTTP(S) ロードバランサに HTTP(S) トラフィックを配信します。
  3. 内部 HTTP(S) ロードバランサが、トラフィックをミドルウェア インスタンス グループに配信します。
  4. ミドルウェア インスタンス グループが、トラフィックを内部 TCP / UDP ロードバランサに送り、トラフィックをデータ ストレージ クラスタに負荷分散します。
多層アプリケーションにおける内部層でのレイヤ 7 ベースのルーティング(クリックして拡大)
多層アプリにおける内部層でのレイヤ 7 ベースのルーティング

パスベース ルーティングによる負荷分散

一般的なユースケースの 1 つとして、サービス間のトラフィックのロード バランシングがあります。この例では、内部クライアントが動画と画像のコンテンツをリクエストしています。同じベース URL(mygcpservice.internal)を使用してますが、パスは異なります(/video/images)。

内部 HTTP(S) 負荷分散の URL マップに従い、パス /video に対するリクエストは動画のバックエンド サービスに送信され、/images に対するリクエストは画像のバックエンド サービスに送信されます。次の例では、動画と画像のバックエンド サービスは Compute Engine VM で処理されていますが、GKE Pod を使用して処理することもできます。

内部クライアントがロードバランサの内部 IP アドレスにリクエストを送信すると、ロードバランサはこのロジックに従ってリクエストを評価し、適切なバックエンド サービスにリクエストを送信します。

このユースケースは次の図のようになります。

レイヤ 7 ベースの負荷分散を使用した内部(マイクロ)サービス(クリックして拡大)
レイヤ 7 ベースの負荷分散を使用した内部(マイクロ)サービス

レガシー サービスのモダナイゼーション

内部 HTTP(S) 負荷分散は、レガシー アプリケーションのモダナイゼーションに効果的なツールです。

このようなアプリケーションとして、簡単に更新できない規模の大きいモノリシック アプリケーションがあります。この場合、レガシー アプリケーションの前に内部 HTTP(S) ロードバランサをデプロイできます。次に、ロードバランサのトラフィック制御機能を使用して、レガシー アプリケーションの機能に代わる新しいマイクロサービスにトラフィックのサブセットを転送します。

まず始めに、デフォルトですべてのトラフィックがレガシー アプリケーションにルーティングされるように、ロードバランサの URL マップを構成します。これにより、既存の動作が維持されます。レガシー アプリケーションに代わる新しいサービスがデプロイされたら、URL マップを更新し、トラフィックの一部をこの新しいサービスにルーティングします。

ここで、レガシー アプリケーションに動画処理機能があり、内部クライアントが /video にリクエストを送信したときに、この機能が処理される場合について考えてみましょう。この動画サービスは、次のようにマイクロサービスに分割できます。

  1. レガシー アプリケーションの前に内部 HTTP(S) 負荷分散を追加します。
  2. レガシー アプリケーションに代わる動画処理マイクロサービスを作成します。
  3. ロードバランサの URL マップを更新し、パス /video に対するすべてのリクエストをレガシー アプリケーションではなく、新しいマイクロサービスにルーティングします。

別の代替サービスを開発する場合も、この URL マップを更新します。時間の経過とともに、レガシー アプリケーションにルーティングされるリクエストが少なくなっていきます。最終的には、レガシー アプリケーションが提供するすべての機能に代替サービスが存在する状態になります。この時点で、レガシー アプリケーションを廃止できます。

ハイブリッド接続でのロード バランシング

Cloud Load Balancing は、オンプレミス データセンターや他のパブリック クラウドなどの Google Cloud の外部に拡張され、ハイブリッド接続で到達可能なエンドポイントへのトラフィックをロード バランシングできます。

次の図は、内部 HTTP(S) ロードバランサを使用したハイブリッド デプロイメントを示しています。

内部 HTTP(S) ロード バランシングによるハイブリッド接続(クリックして拡大)
内部 HTTP(S) ロード バランシングによるハイブリッド接続(クリックして拡大)

Private Service Connect

内部 HTTP(S) ロード バランシングを使用して、サポートされているリージョンの Google API とサービスにリクエストを送信できます。詳細については、Private Service Connect を使用してコンシューマ HTTP(S) サービス コントロールで Google API にアクセスするをご覧ください。

GKE アプリケーションのロード バランシング

GKE でアプリケーションを構築する場合は、組み込みの GKE Ingress コントローラを使用することをおすすめします。このコントローラは GKE ユーザーに代わって Google Cloud ロードバランサをデプロイします。これは、このページで説明しているスタンドアロンのロード バランシング アーキテクチャと同じですが、ライフサイクルが GKE によって完全に自動化、制御される点で異なります。

関連する GKE のドキュメント:

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

次の図は、内部 HTTP(S) ロードバランサに必要な Google Cloud リソースを示しています。

内部 HTTP(S) 負荷分散コンポーネント(クリックして拡大)
内部 HTTP(S) 負荷分散コンポーネント

各内部 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) プロキシは、クライアントからの 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 証明書

Transport Layer Security(TLS)は、ネットワーク通信を保護するために SSL 証明書で使用される暗号化プロトコルです。

Google Cloud は SSL 証明書を使用して、クライアントからロードバランサに転送されるデータのプライバシーとセキュリティを保護します。HTTPS ベースのロード バランシングを使用している場合は、ターゲット HTTPS プロキシに 1 つ以上の SSL 証明書をインストールする必要があります。

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) ロードバランサには、次のファイアウォール ルールが必要です。

共有 VPC のアーキテクチャ

内部 HTTP(S) ロード バランシングでは、共有 VPC を使用するネットワークがサポートされます。共有 VPC を使用すると、ネットワーク管理者とサービス デベロッパーの責任を明確に分離できます。開発チームはサービス プロジェクトでのサービスの構築に集中し、ネットワーク インフラストラクチャ チームはロード バランシングのプロビジョニングと管理を行うことができます。また、ネットワーク管理者は、内部 IP アドレスを安全かつ効率的に管理できます。共有 VPC についてまだよく理解していない場合は、共有 VPC の概要のドキュメントをご覧ください。

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

サブネットと IP アドレス 転送ルール ターゲット プロキシと URL マップ バックエンド コンポーネント
共有 VPC ホスト プロジェクトで必要なネットワーク、サブネット(プロキシ専用サブネットを含む)、内部 IP アドレスを作成します。 転送ルールは、ホスト プロジェクトまたはサービス プロジェクトで定義できます。 ターゲット プロキシと URL マップは、転送ルールと同じプロジェクトで定義する必要があります。

バックエンド サービスとバックエンドは、必要な数のサービス プロジェクトで作成できます。1 つの URL マップで複数のプロジェクトのバックエンド サービスを参照できます。このタイプのデプロイは、プロジェクト間のサービス参照と呼ばれます。このユースケースはプレビュー版です。

また、すべてのロードバランサ コンポーネントとそのバックエンドを単一のサービス プロジェクト内に作成することもできます。

各バックエンド サービスは、参照するバックエンド インスタンスと同じプロジェクトで定義する必要があります。これらのインスタンスは、バックエンドとしてバックエンド サービスに接続されたインスタンス グループ内に存在する必要があります。バックエンド サービスに関連するヘルスチェックも、バックエンド サービスと同じプロジェクトで定義する必要があります。

ホスト プロジェクトに必要なネットワーク、サブネット、IP アドレスを作成します。次に、ロードバランサ コンポーネントに対して次のいずれかを行います。

このいずれのデプロイモデルでも、クライアントがロードバランサと同じ共有 VPC ネットワークとリージョンにある場合、クライアントはロードバランサにアクセスできます。クライアントは、ホスト プロジェクト、接続されたサービス プロジェクト、または任意の接続されたネットワークに配置できます。

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

このモデルでは、ロードバランサのフロントエンドと URL マップはホスト プロジェクトまたはサービス プロジェクトに存在します。ロードバランサのバックエンド サービスとバックエンドは、共有 VPC 環境のプロジェクト間で分散できます。プロジェクト間のバックエンド サービスは 1 つの URL マップで参照できます。これはプロジェクト間のサービス参照と呼ばれます。

プロジェクト間のサービス参照により、サービス デベロッパーと管理者は、一元管理されたロードバランサを介したサービスの公開を自律的に管理できます。サービス プロジェクト管理者は、compute.loadBalancerServiceUser IAM ロールを使用してプロジェクト内のバックエンド サービスへのアクセスを許可します。

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

プロジェクト間サービス参照の例 1: 異なるサービス プロジェクトのロードバランサのフロントエンドとバックエンド

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

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

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

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

このタイプのデプロイでは、ロードバランサのフロントエンドと URL マップがホスト プロジェクトに作成され、バックエンド サービス(とバックエンド)がサービス プロジェクトに作成されます。

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

ホスト プロジェクト内のロードバランサのフロントエンドと URL マップ
ホスト プロジェクト内のロードバランサのフロントエンドと URL マップ

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

このモデルでは、ロードバランサのすべてのコンポーネントとバックエンドがサービス プロジェクトに存在します。このデプロイモデルは、すべての HTTP(S) ロードバランサでサポートされています。

ロードバランサは、ホスト プロジェクトの IP アドレスとサブネットを使用します。

共有 VPC ネットワークでの内部 HTTP(S) ロードバランサ
共有 VPC ネットワークでの内部 HTTP(S) ロードバランサ

ホスト プロジェクト内でのロードバランサとバックエンド

このモデルでは、共有 VPC ネットワーク、ロードバランサのコンポーネント、バックエンドはすべてホスト プロジェクトに存在します。このモデルでは、ネットワーク管理とサービス開発の責任は分離されていません。

このモデルの構成は、スタンドアロン VPC ネットワークでロードバランサを構成する場合と同じです。

タイムアウトと再試行

内部 HTTP(S) ロード バランシングには次の 3 種類のタイムアウトがあります。
  • 構成可能な HTTP バックエンド サービス タイムアウト。ロードバランサがバックエンドから完全な HTTP レスポンスが返されるまで待機する時間です。バックエンド サービス タイムアウトのデフォルト値は 30 秒です。指定できるタイムアウト値の範囲は 1~2,147,483,647 秒です。

    たとえば、バックエンド サービスのタイムアウトの値がデフォルト値の 30 秒である場合、バックエンドにはリクエストに応答するための時間が 30 秒あります。ロードバランサは、バックエンドが接続を閉じるか、レスポンス ヘッダーをロードバランサに送信する前にタイムアウトになると、HTTP GET リクエストを 1 回再試行します。バックエンドがレスポンス ヘッダーを送信する場合、またはバックエンドに送信されるリクエストが HTTP GET リクエストでない場合、ロードバランサは再試行しません。バックエンドがまったく応答しない場合、ロードバランサは HTTP 5xx レスポンスをクライアントに返します。これらのロードバランサでは、バックエンドがリクエストに応答するまでの時間を増減する場合は、タイムアウト値を変更します。

    バックエンド サービスのタイムアウトは、Envoy とバックエンド間の処理のため、リクエストの最初のバイトからレスポンスの最後のバイトまでの最大時間に設定する必要があります。WebSocket を使用している場合は、バックエンド サービスのタイムアウトを WebSocket の最大時間(アイドルまたはアクティブ)に設定する必要があります。

    次のいずれかの状況では、タイムアウトを長くすることを検討してください。

    • バックエンドが HTTP レスポンスを返すのに時間がかかることが予想される場合。
    • 接続が WebSocket にアップグレードされた場合。

    設定するバックエンド サービスのタイムアウトはベスト エフォート型の目標です。ただし、基礎となる TCP 接続が、タイムアウトの間にオープン状態になっているとは限りません。

    バックエンド サービスのタイムアウトは任意の値に設定できますが、1 日(86,400 秒)を超える値に設定しても、ロードバランサはその期間 TCP 接続を継続するわけではありません。継続する場合もあれば、そうでない場合もあります。Google は、ソフトウェアの更新と定期的なメンテナンスで Envoy プロキシを定期的に再起動しますが、バックエンド サービスのタイムアウトはそれをオーバーライドしません。バックエンド サービスのタイムアウトを長くするほど、Google が Envoy のメンテナンスで TCP 接続を終了する可能性が高くなります。このようなイベントの影響を減らすため、再試行ロジックの実装をおすすめします。

    詳細については、バックエンド サービスの設定をご覧ください。

    バックエンド サービス タイムアウトは、HTTP のアイドル(キープアライブ)タイムアウトではありません。バックエンドからの入出力(IO)は、クライアントの速度が遅い場合(ブラウザの接続が遅い場合など)にブロックされる可能性があります。この待機時間は、バックエンド サービス タイムアウトにはカウントされません。

  • 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 リクエストは再試行されません。このデフォルトの動作は、retryConditions=["gateway-error"] の場合と同じです。

再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 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 経由でエンドツーエンドでリクエストをプロキシする必要があります。手順は次のとおりです。

  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 のみを受け入れます。

内部 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 サービスにトラフィックを送信できます。これは既知の問題であり、この形式のアクセスは今後ブロックされます。

次のステップ