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

このドキュメントでは、Google Cloud 外部 HTTP(S) の負荷分散の構成に必要なコンセプトについて説明します。

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

ユースケース

外部 HTTP(S) ロードバランサは多くのユースケースに対応しています。このセクションでは、そのいくつかについて説明します。

複数のバックエンド タイプを使用した負荷分散

外部 HTTP(S) 負荷分散は、次のバックエンド タイプをサポートしています。

一般的なユースケースにはサービス間のトラフィックの負荷分散があります。次の例では、外部の IPv4 と IPv6 のクライアントが、同じ基本 URL を使用して、パス /api/video/images で、動画、API、画像の各コンテンツをリクエストできます。

外部 HTTP(S) ロードバランサの URL マップでは、次のことを指定します。

  • パス /api へのリクエストは、VM インスタンス グループまたはゾーン NEG をバックエンドとするバックエンド サービスに送信されます。
  • パス /images へのリクエストは、Cloud Storage をバックエンドとするバックエンド バケットに送信されます。
  • パス /video へのリクエストは、Google Cloud の外部にある、オンプレミスの外部エンドポイントを含むインターネット NEG を指すバックエンド サービスに送信されます。

クライアントがロードバランサの外部 IPv4 または IPv6 アドレスにリクエストを送信すると、ロードバランサは URL マップに従ってリクエストを評価し、正しいサービスにリクエストを送信します。

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

カスタムの送信元を使用した負荷分散図(クリックして拡大)
カスタムの送信元を使用した負荷分散図(クリックして拡大)

バックエンド サービスごとに、オプションで Cloud CDN と Google Cloud Armor を有効にできます。Google Cloud Armor と Cloud CDN を併用している場合、セキュリティ ポリシーが適用されるのは、動的コンテンツやキャッシュミスに関するリクエスト、または CDN オリジン サーバーが宛先であるその他のリクエストに限られます。そのリクエストが CDN オリジン サーバーに到達することをダウンストリーム Google Cloud Armor セキュリティ ポリシーが禁止している場合でも、キャッシュ ヒットが発生しれます。

バックエンド バケットの場合、Cloud CDN はサポートされますが、Google Cloud Armor はサポートされません。

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 ベースのルーティング

クロスリージョン負荷分散

クロスリージョン負荷分散の図

プレミアム ティアで外部 HTTP(S) ロードバランサを構成すると、グローバル外部 IP アドレスが使用され、近接性に基づいて、ユーザーからのリクエストを最も近いバックエンド インスタンス グループまたは NEG にインテリジェントに転送できます。たとえば、北米、ヨーロッパ、アジアでインスタンス グループを設定し、それらをロードバランサのバックエンド サービスに接続すると、VM がヘルスチェックに合格していて十分な容量があると想定(バランシング モードで定義)され、世界中のユーザー リクエストがユーザーに最も近い VM に自動的に送信されます。最も近い VM がすべて異常である場合、または最も近いインスタンス グループがフル稼働していて別のインスタンス グループがフル稼働していない場合、ロードバランサは自動的に、容量があり最も近いリージョンにリクエストを送信します。


コンテンツベースの負荷分散

コンテンツベースの負荷分散の図

HTTP(S) 負荷分散は、URL マップを使用してコンテンツベースの負荷分散をサポートし、要求されたホスト名、リクエストパス、またはその両方に基づいてバックエンド サービスを選択します。たとえば、インスタンス グループまたは NEG のセットを使用して動画コンテンツを処理し、別のセットを使用してその他すべてを処理できます。

Cloud Storage バケットで HTTP(S) 負荷分散を使用することもできます。ロードバランサを設定したら、Cloud Storage バケットを追加できます。


統合されたロードバランサの作成

コンテンツベースの負荷分散とクロスリージョン負荷分散の表現

プレミアム ティアで外部 HTTP(S) ロードバランサを構成して、それぞれが複数のリージョンにバックエンド インスタンス グループまたは NEG を持つ複数のバックエンド サービスを使用して、コンテンツベースとクロスリージョンの両方の負荷分散を提供できます。ユースケースを組み合わせて拡張し、ニーズを満たす外部 HTTP(S) ロードバランサを構成できます。


構成の例

テスト目的で実際に機能するロードバランサを今すぐ構築する場合は、シンプルな外部 HTTP ロードバランサの設定またはシンプルな外部 HTTPS ロードバランサの設定をご覧ください。

コンテンツベースとクロスリージョンの負荷分散を使用するより複雑な例については、HTTPS ロードバランサの作成をご覧ください。

HTTP(S) 負荷分散での接続の仕組み

外部 HTTP(S) 負荷分散は、Google Front End(GFE)と呼ばれる多数のプロキシによって実装されるサービスです。プロキシは 1 つではありません。プレミアム ティアでは、同じグローバル外部 IP アドレスがさまざまな拠点からアドバタイズされ、トラフィックはクライアントの最も近い GFE に送信されます。

クライアントがいる場所に応じて、複数の GFE がバックエンドへの HTTP(S) 接続を開始できます。GFE から送信されたパケットには、ヘルスチェック プローバーが使用するものと同じ範囲(35.191.0.0/16130.211.0.0/22)の送信元 IP アドレスがあります。

バックエンド サービスの構成に応じて、各 GFE がバックエンドに接続するために使用するプロトコルは HTTP、HTTPS、HTTP/2 のいずれかになります。HTTP または HTTPS の場合の HTTP バージョンは HTTP 1.1 です。HTTP keep-alive は、HTTP 1.1 仕様で指定されているように、デフォルトで有効になっています。GFE は keep-alive タイムアウトを 600 秒に設定しており、構成できません。ですが、バックエンド サービスのタイムアウトを設定することで、リクエスト/レスポンスのタイムアウトを構成できます。詳しくは、タイムアウトと再試行をご覧ください。

HTTP keep-alive は、同じ TCP セッションを効率的に使用しようとしますが、保証はありません。密接に関連していますが、HTTP keep-alive と TCP アイドル タイムアウトは同じではありません。

HTTP 接続と TCP セッションの数は、GFE の接続数、GFE に接続するクライアントの数、バックエンドへのプロトコル、バックエンドのデプロイ場所によって異なります。

詳細については、ソリューション ガイドの HTTP(S) 負荷分散のしくみ: グローバル負荷分散によるアプリケーション容量の最適化をご覧ください。

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

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

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

外部 HTTP(S) ロードバランサを定義するリソースは次のとおりです。

  • 外部転送ルール。外部 IP アドレス、ポート、グローバル ターゲット HTTP(S) プロキシを指定します。クライアントは、IP アドレスとポートを使用してロードバランサに接続します。

  • グローバル ターゲット HTTP(S) プロキシ。クライアントからリクエストを受信します。HTTP(S) プロキシは、URL マップを使用してリクエストを評価し、トラフィックのルーティングを決定します。プロキシは、SSL 証明書を使用して通信の認証を行うこともできます。

  • HTTPS 負荷分散を使用している場合、HTTPS プロキシはグローバル SSL 証明書を使用して、クライアントに ID を提供します。ターゲット HTTP(S) プロキシは、ドキュメント番号までの SSL 証明書をサポートします。

  • HTTP(S) プロキシは、グローバル URL マップを使用し、HTTP 属性(リクエストパス、Cookie、ヘッダーなど)に基づいてルーティングを決めます。このルーティングの決定に基づいて、プロキシは特定のバックエンド サービスやバックエンド バケットにクライアントのリクエストを転送します。URL マップでは、クライアントにリダイレクトを送信するなど、追加のアクションを指定できます。

  • バックエンド サービスまたはバックエンド バケットは、正常なバックエンドにリクエストを分散します。

  • 1 つ以上のバックエンドをバックエンド サービスまたはバックエンド バケットに接続する必要があります。バックエンドは、次のいずれかの構成のインスタンス グループ、NEG、またはバケットにできます。

    • マネージド インスタンス グループ(ゾーン単位またはリージョン単位)
    • 管理対象外のインスタンス グループ(ゾーン単位)
    • ネットワーク エンドポイント グループ(ゾーン単位)
    • ネットワーク エンドポイント グループ(インターネット)
    • Cloud Storage バケット

    インスタンス グループと NEG を同じバックエンド サービスで使用することはできません。

  • グローバル ヘルスチェック。バックエンドの準備状況を定期的に監視します。これにより、処理不能なバックエンドにリクエストが送信されるリスクを軽減できます。

  • バックエンドがヘルスチェック プローブを受け入れるためのファイアウォール

送信元 IP アドレス

各バックエンド仮想マシン(VM)インスタンスまたはコンテナから見たパケットの送信元 IP アドレスは、次の範囲の IP アドレスです。

  • 35.191.0.0/16
  • 130.211.0.0/22

実際の負荷分散トラフィックの送信元 IP アドレスは、ヘルスチェック プローブ IP 範囲と同じです。

バックエンドから見たトラフィックの送信元 IP アドレスは、ロードバランサの Google Cloud の外部 IP アドレスではありません。つまり、2 つの HTTP、SSL、または TCP セッションがあります。

  • セッション 1: 元のクライアントからロードバランサ(GFE)へのもの。

    • 送信元 IP アドレス: オリジナルのクライアント(クライアントが NAT の背後にある場合は外部 IP アドレス)。
    • 宛先 IP アドレス: ロードバランサの IP アドレス。
  • セッション 2: ロードバランサ(GFE)からバックエンド VM またはコンテナへのもの。

    • 送信元 IP アドレス: 35.191.0.0/16 または 130.211.0.0/22 いずれかの範囲の IP アドレス。

      実際の送信元アドレスは予測できません。

    • 宛先 IP アドレス: Virtual Private Cloud(VPC)ネットワーク内のバックエンド VM またはコンテナの内部 IP アドレス。

ロードバランサとのクライアント通信

  • クライアントは HTTP 1.1 または HTTP/2 プロトコルを使用してロードバランサと通信できます。
  • 最近のクライアントは、HTTPS を使用するとデフォルトで HTTP/2 になります。この制御は HTTPS ロードバランサではなくクライアント上で行われます。
  • ロードバランサで構成を変更することで、HTTP/2 を無効にすることはできません。ただし、一部のクライアントは、HTTP/2 ではなく HTTP 1.1 を使用するように構成できます。たとえば、curl では、--http1.1 パラメータを使用します。
  • HTTPS ロードバランサは、クライアント証明書ベースの認証(別名: 相互 TLS 認証)をサポートしていません。

オープンポート

外部 HTTP(S) ロードバランサはリバース プロキシのロードバランサです。ロードバランサによって受信接続が終端され、ロードバランサからバックエンドへの新しい接続が開かれます。リバース プロキシ機能は、Google Front Ends(GFE)が提供します。

ファイアウォール ルールの設定では、GFE からバックエンドへのトラフィックをブロックしますが、GFE への受信トラフィックはブロックしません。

外部 HTTP(S) のロードバランサには、同じアーキテクチャで実行される他の Google サービスをサポートする多数のオープンポートが含まれます。Google Cloud の外部 HTTP(S) ロードバランサの外部 IP アドレスに対してセキュリティ スキャンまたはポートスキャンを実行すると、他のポートも開いているように見えます。

このことは、外部 HTTP(S) ロードバランサには影響しません。外部 HTTP(S) ロードバランサの定義で使用される外部の転送ルールは、TCP ポート 80、8080、および 443 しか参照できず、トラフィックの TCP 宛先ポートが異なれば、ロードバランサのバックエンドに転送されることはないからです。

コンポーネント

外部 HTTP(S) ロードバランサのコンポーネントは次のとおりです。

転送ルールとアドレス

転送ルールは、IP アドレス、ポート、プロトコルに基づいて、ターゲット プロキシ、URL マップ、1 つ以上のバックエンド サービスからなる負荷分散構成にトラフィックを転送します。

各転送ルールでは、アプリケーションの DNS レコードで使用できる単一の IP アドレスを指定します。DNS ベースの負荷分散は必要ありません。使用する IP アドレスを自分で指定することも、Cloud Load Balancing で割り当てられる IP アドレスを使用することもできます。

  • HTTP ロードバランサの転送ルールは、TCP ポート 80 と 8080 のみを参照できます。
  • HTTPS ロードバランサの転送ルールは、TCP ポート 443 のみを参照できます。

外部 HTTP(S) ロードバランサに必要な転送ルールのタイプは、ロードバランサが含まれるネットワーク サービス階層によって異なります。

  • プレミアム ティア内の外部 HTTP(S) ロードバランサは、グローバル外部転送ルールを使用します。
  • スタンダード ティアの外部 HTTP(S) ロードバランサは、リージョン外部転送ルールを使用します。

ターゲット プロキシ

ターゲット プロキシは、クライアントからの HTTP(S) 接続を終端します。1 つ以上の転送ルールがトラフィックをターゲット プロキシに振り向け、ターゲット プロキシが URL マップを参照してバックエンドにトラフィックを転送する方法を決定します。

プロキシは、次のように HTTP リクエスト ヘッダー / レスポンス ヘッダーを設定します。

  • Via: 1.1 google(リクエストとレスポンス)
  • X-Forwarded-Proto: [http | https](リクエストのみ)
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options>(リクエストのみ)
    Cloud Trace のパラメータが含まれます。

デフォルトのヘッダーでニーズが満たされない場合は、カスタム リクエスト ヘッダーとカスタム レスポンス ヘッダーを作成できます。この機能の詳細については、カスタム ヘッダーの作成をご覧ください。

プロキシでは、リクエストまたはレスポンスのヘッダー名の大文字と小文字の区別の保持が保証されません。たとえば、Server: Apache/1.0 レスポンス ヘッダーはクライアントで server: Apache/1.0 として表示される場合があります。

Host ヘッダー

ロードバランサが HTTP リクエストを行うと、ロードバランサは元のリクエストの Host ヘッダーを保持します。

X-Forwarded-For ヘッダー

ロードバランサは X-Forwarded-For ヘッダーに次の 2 つの IP アドレスを追加します。

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

  • ロードバランサの IP アドレス

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

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

URL マップ

URL マップは、URL に基づいてリクエストが適切なバックエンド サービスにルーティングされる際に使用される一致パターンを定義します。デフォルトのバックエンド サービスは、指定されたホストまたはパスのマッチング ルールに一致しないリクエストを処理するように定義されています。クロスリージョン負荷分散の例など、URL ルールを定義せず、デフォルトのサービスのみに依存する状況もあります。コンテンツベースのトラフィック ルーティングでは、URL マップを使用して URL を調べることで、トラフィックを分割し、リクエストを各種のバックエンド セットに送信できます。

SSL 証明書

HTTPS ベースの負荷分散を使用している場合は、ターゲット HTTPS プロキシに 1 つ以上の SSL 証明書をインストールする必要があります。

ターゲット HTTPS プロキシではこれらの証明書を使用して、ロードバランサとクライアントとの間の通信を保護します。

SSL 証明書の上限と割り当てについては、負荷分散の割り当てページの SSL 証明書をご覧ください。

最高レベルのセキュリティを実現するには、HTTPS ロードバランサのデプロイにエンドツーエンドの暗号化を使用します。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。

Google がユーザー トラフィックを暗号化する方法に関する一般的な情報については、Google Cloud での転送中の暗号化ホワイト ペーパーをご覧ください。

SSL ポリシー

SSL ポリシーを使用すると、HTTPS ロードバランサが HTTPS クライアントとネゴシエートする際に使用する SSL の機能を制御できます。

デフォルトでは、HTTPS 負荷分散は、優れたセキュリティと幅広い互換性を提供する一連の SSL 機能を使用します。アプリケーションの中には、HTTPS または SSL 接続に使用される SSL のバージョンおよび暗号をより詳細に管理しなければならないものがあります。ロードバランサがネゴシエートに使用する SSL 機能を制御する SSL ポリシーを定義し、ターゲット HTTPS プロキシに SSL ポリシーを関連付けることができます。

TLS の終端ロケーションに対する地理的制御

HTTPS ロードバランサは、クライアントとロードバランサ間のレイテンシを最小にするため、グローバルに分散されているロケーションで TLS を終端します。どこで TLS を終端するかを地理的に制御する必要がある場合は、Google Cloud ネットワーク負荷分散を代わりに使用し、ニーズに適したリージョンにあるバックエンドで TLS を終端する必要があります。

バックエンド サービス

バックエンド サービスは、ロードバランサに構成情報を提供します。外部 HTTP(S) ロードバランサには 1 つ以上のバックエンド サービスが必要です。複数のバックエンド サービスを構成することもできます。

ロードバランサは、バックエンド サービスからの情報を使用して、受信トラフィックを接続されている 1 つまたは複数のバックエンドに振り向けます。

バックエンド サービスのバックエンドは、インスタンス グループまたはネットワーク エンドポイント グループ(NEG)のいずれかとなりますが、両方を組み合わせることはできません。バックエンド インスタンス グループまたは NEG を追加する場合は、リクエストの分散方法とターゲット容量を定義する、分散モードを指定します。詳細については、負荷分散アルゴリズムをご覧ください。

HTTP(S) 負荷分散は Cloud Load Balancing のオートスケーラーをサポートします。これにより、バックエンド サービス内のインスタンス グループに対して自動スケーリングを実行できるようになります。詳しくは、HTTP(S) 負荷分散処理能力に基づくスケーリングをご覧ください。

バックエンド サービスでコネクション ドレインを有効にすると、トラフィックを処理しているインスタンスが停止した場合、手動で削除された場合、オートスケーラーによって削除された場合に、ユーザーに対する中断を最小限に抑えることができます。詳細については、コネクション ドレインを有効にするをご覧ください。

外部 HTTP(S) ロードバランサに関連付けられているバックエンド サービスへの変更は瞬時には行われません。変更内容がネットワーク全体に反映されるまでに数分かかることがあります。

異なるネットワーク サービス階層でのロードバランサの動作

HTTP(S) 負荷分散は、プレミアム ティアのネットワーク サービスを使用すると、グローバル サービスとなります。1 つのリージョンに複数のバックエンド サービスを設定できます。また、複数のリージョンにバックエンド サービスを作成できます。これらはすべて同じグローバル ロードバランサによって処理されます。トラフィックは、次のようにバックエンド サービスに割り当てられます。

  1. ユーザー リクエストを受信すると、負荷分散サービスによってソース IP アドレスからリクエストの大まかな送信元が判別されます。
  2. 負荷分散サービスは、バックエンド サービスが所有しているインスタンスの場所、それらの総容量、現在の総使用量を認識します。
  3. ユーザーに最も近いインスタンスに使用可能な容量がある場合、リクエストはその最も近いインスタンスのセットに転送されます。
  4. 指定されたリージョンに着信したリクエストは、そのリージョン内の使用可能なすべてのバックエンド サービスとインスタンスに、均等に分散されます。ただし、負荷が非常に小さい場合は分散が不均等に見える場合もあります。
  5. 指定されたリージョン内に使用可能な容量を持つ正常なインスタンスがない場合、ロードバランサは代替手段として、使用可能な容量を持つ次に近いリージョンにリクエストを送信します。

HTTP(S) 負荷分散は、スタンダード ティアのネットワーク サービスを使用すると、リージョン サービスとなります。バックエンド インスタンス グループまたは NEG はすべて、ロードバランサの外部 IP アドレスと転送ルールで使用されるリージョンに配置されている必要があります。

ヘルスチェック

各バックエンド サービスでは、使用可能な各インスタンスに対してどのヘルスチェックが実行されるかも指定します。ヘルスチェック プローブが正常に機能するには、130.211.0.0/22 および 35.191.0.0/16 からのトラフィックがインスタンスに到達できるようにファイアウォール ルールを作成する必要があります。

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

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

外部 HTTP(S) ロードバランサのバックエンド サービスを構成する際には、バックエンド サービスがバックエンドと通信するために使用するプロトコルを設定します。HTTP、HTTPS、HTTP/2 を選択できます。指定したプロトコルのみがロードバランサで使用されます。指定されたプロトコルでバックエンドへの接続をネゴシエートできない場合、ロードバランサは他のプロトコルへのフォールバックを行いません。

HTTP/2 を使用する場合は、TLS を使用する必要があります。暗号化されていない HTTP/2 はサポートされません。

必須ではありませんが、ベスト プラクティスとしてバックエンド サービスのプロトコルと一致するプロトコルでのヘルスチェックを使用することをおすすめします。たとえば、バックエンドに対する HTTP/2 の接続性を最も正確にテストできるのは HTTP/2 ヘルスチェックです。

Google Cloud アプリケーションで gRPC を使用する

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

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

Google Cloud アプリケーションで gRPC を使用するには、HTTP/2 経由でエンドツーエンドでリクエストをプロキシする必要があります。外部 HTTP(S) ロードバランサでこれを行うには:

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

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

ロードバランサとバックエンド インスタンス間で HTTP/2 を使用するように構成された外部 HTTP(S) ロードバランサでは、一部のクライアントとの HTTPS のネゴシエーションや、セキュアでない HTTP リクエストの受け入れが可能です。これらの HTTP または HTTPS のリクエストはロードバランサによって変換され、リクエストは HTTP/2 経由でバックエンド インスタンスにプロキシされます。

Google Kubernetes Engine Ingress で HTTP/2 を使用するか、Ingress で gRPC と HTTP/2 を使用して、外部 HTTP(S) ロードバランサを構成する場合は、Ingress による HTTP/2 を使用した負荷分散をご覧ください。

HTTP/2 の問題のトラブルシューティングについては、バックエンドへの HTTP/2 の問題のトラブルシューティングをご覧ください。

HTTP/2 の制限の詳細については、HTTP/2 の制限をご覧ください。

バックエンド バケット

バックエンド バケットは、Cloud Storage バケットに着信トラフィックを振り向けます。

次の図に示すように、ストレージ バケットへの /static のパスと他のすべてのバックエンドへのすべてのリクエストへトラフィックを送信するようにロードバランサを設定できます。

HTTP(S) 負荷分散を使用してさまざまなタイプのバックエンドにトラフィックを分散する
HTTP(S) 負荷分散を使用してさまざまなタイプのバックエンドにトラフィックを分散する(クリックして拡大)

バケットを既存のロードバランサに追加する方法を示す例については、バックエンド バケットを使用したロードバランサの設定をご覧ください。

ファイアウォール ルール

バックエンド インスタンスは、ロードバランサの GFE / ヘルスチェック範囲からの接続を許可する必要があります。つまり、130.211.0.0/2235.191.0.0/16 からのトラフィックがバックエンド インスタンスまたはエンドポイントに到達することを許可するファイアウォール ルールを作成する必要があります。これらの IP アドレス範囲は、ヘルスチェック パケットと、バックエンドに送信されるすべての負荷分散されたパケットのソースとして使用されます。

このファイアウォール ルールに構成するポートは、以下のバックエンド インスタンスまたはエンドポイントへのトラフィックを許可する必要があります。

  • 各転送ルールで使用されるポートを許可する
  • それぞれのバックエンド サービスに構成された各ヘルスチェックで使用されるポートを許可する

ファイアウォール ルールは、Google Front End(GFE)プロキシではなく、VM インスタンス レベルで実装されます。Google Cloud ファイアウォール ルールを使用して、トラフィックがロードバランサに到達しないようにすることはできません。

ヘルスチェック プローブの詳細と、130.211.0.0/2235.191.0.0/16 からのトラフィックを許可する必要がある理由については、プローブ IP 範囲とファイアウォール ルールをご覧ください。

リターンパス

Google Cloud では、VPC ネットワークで定義されていない特殊なルートがヘルスチェックに使用されます。詳細については、ロードバランサのリターンパスをご覧ください。

負荷分散アルゴリズム

バックエンド インスタンス グループまたは NEG をバックエンド サービスに追加する場合は、バックエンドの負荷とターゲット容量を測定する方法を定義する分散モードを指定します。外部 HTTP(S) 負荷分散は、以下の 2 つの分散モードをサポートします。

  • インスタンス グループまたは NEG の場合、RATE は 1 秒あたりのリクエスト(クエリ)の最大数(RPS、QPS)の目標です。すべてのバックエンドが容量を超えると、目標最大 RPS / QPS を超過する場合があります。

  • UTILIZATION はインスタンス グループ内の VM のバックエンド使用率です。

Google Front End(GFE)はバックエンド インスタンスにリクエストを送信する前に、どのバックエンド インスタンスがリクエストを受信できるかを推定します。この容量の見積もりは、リクエストの到着と同時に行われるのではなく、事前に行われます。GFE は、利用可能な容量に関する情報を定期的に受け取り、それに応じて受信リクエストを分散します。

容量の意味は、分散モードによって異なります。RATE モードの場合は比較的単純です。GFE は 1 秒あたりに割り当てることができるリクエスト数を正確に決定します。UTILIZATION ベースの負荷分散はより複雑です。ロードバランサはインスタンスの現在の使用率をチェックし、各インスタンスが処理できるクエリ負荷を見積もります。この推定値は、インスタンスの使用率とトラフィック パターンの変化に応じて変化します。

容量の見積もりと事前の割り当ての両方の要素が、インスタンス間の分散に影響します。そのため、Cloud Load Balancing の動作は、2 つのインスタンス間でリクエストを正確に 50:50 に分散する単純なラウンドロビン ロードバランサとは異なります。Google Cloud 負荷分散は、リクエストごとにバックエンド インスタンスの選択を最適化します。

詳細については、トラフィック分散をご覧ください。

分散モードの詳細については、分散モードをご覧ください。

Network Service Tiers

外部 HTTP(S) ロードバランサがプレミアム ティアにある場合、ユーザーに最も近いリージョンのバックエンドに容量があれば、ロードバランサに送信されたリクエストは、そのリージョンのバックエンド インスタンス グループまたは NEG に送信されます(使用可能な容量は、ロードバランサの分散モードで構成されます)。

外部 HTTP(S) ロードバランサがスタンダード ティアにある場合、バックエンド インスタンス グループまたは NEG はすべて、ロードバランサの外部 IP アドレスと転送ルールで使用されるリージョンに配置されている必要があります。

リージョンとゾーン

リージョンの選択後:

  • リージョン内の複数のゾーンでバックエンドを構成する場合、外部 HTTP(S) ロードバランサは、バックエンド インスタンスの容量とセッション アフィニティに応じて、可能な限り均等にリクエストを分散しようとします。

  • ゾーン内では、外部 HTTP(S) ロードバランサは使用可能な容量とセッション アフィニティに応じて、負荷分散アルゴリズムを使用してリクエストを分散しようとします。

セッション アフィニティ

セッション アフィニティでは、構成した分散モードに基づいてバックエンドが良好な状態で容量があれば、特定のクライアントから同じバックエンドにリクエストを送信するための、ベストエフォート型の試行を行います。

Google Cloud HTTP(S) 負荷分散には、次の 3 種類のセッション アフィニティがあります。

  • なし。ロードバランサにセッション アフィニティが設定されていません。
  • クライアント IP アフィニティは、同じクライアント IP アドレスからのリクエストを同じバックエンドに送信します。
  • Cookie アフィニティは、最初のリクエストが行われたときにクライアント Cookie を設定し、その Cookie を含むリクエストを同じバックエンドに送信します。

セッション アフィニティを使用する場合は、UTILIZATION よりも RATE 分散モードを推奨します。セッション アフィニティは、分散モードが [リクエスト数/秒](RPS)に設定されている場合に最も機能を発揮します。

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

HTTPS 負荷分散の QUIC プロトコルのサポート

HTTPS 負荷分散では、ロードバランサとクライアントの間の接続で QUIC プロトコルがサポートされます。QUIC は、TCP と同様の輻輳制御および SSL / TLS と同等のセキュリティを HTTP/2 に提供するトランスポート レイヤ プロトコルであり、パフォーマンスが向上しています。QUIC では、クライアント接続の開始が迅速になり、多重化されたストリームにおけるヘッドオブライン ブロッキングがなくなり、クライアントの IP アドレスが変更されたときの接続の移行がサポートされます。

QUIC はクライアントとロードバランサ間の接続に影響を与えるものの、ロードバランサとバックエンド間の接続には影響を与えません。

ターゲット プロキシの QUIC オーバーライド設定では、次のいずれかを有効にできます。

  • 可能であれば、ロードバランサに対して QUIC をネゴシエートする。
  • ロードバランサに対して常に QUIC を無効にする。

QUIC のオーバーライド設定の値を指定しなかった場合は、QUIC が使用されるタイミングを Google が管理できます。Google は、gcloud コマンドライン ツール--quic-override フラグが ENABLE に設定されているか、REST APIquicOverride フラグが ENABLE に設定されているのみ、QUICK を有効化します。

QUIC サポートの有効化と無効化については、ターゲット プロキシをご覧ください。QUIC サポートを有効化または無効化するには:

QUIC のネゴシエートの仕組み

QUIC を有効にすると、ロードバランサはその QUIC 機能をクライアントにアドバタイズでき、QUIC をサポートするクライアントは HTTPS ロードバランサとの QUIC 接続の確立を試行できるようになります。適切に実装されたクライアントは、QUIC 接続を確立できない場合は常に HTTPS または HTTP/2 にフォールバックします。このフォールバックにより、ロードバランサで QUIC を有効または無効にしても、ロードバランサのクライアントへの接続機能は中断されません。

HTTPS ロードバランサで QUIC が有効になっているときに、クライアントが QUIC をネゴシエートせずに HTTPS または HTTP/2 にフォールバックすることがあります。次のような場合です。

  • HTTPS ロードバランサによってサポートされている QUIC バージョンと互換性のないバージョンの QUIC をクライアントがサポートしている場合
  • QUIC が機能できない方法で、UDP トラフィックがブロックされているかレート制限されていると、ロードバランサで検出された場合
  • バグ、脆弱性、その他の問題に対応して HTTPS ロードバランサで QUIC が一時的に無効になっている場合

このような状況のために接続が HTTPS または HTTP/2 にフォールバックした場合は、ロードバランサの障害としてカウントされません。

QUIC を有効にする前に、上記の動作がワークロードに対して許容できることを確認してください。

SSL 証明書

ターゲット HTTPS プロキシでは、1 つ以上の SSL 証明書を参照する必要があります。

これらの証明書は、Google Front End(GFE)とクライアント間の通信を保護するために、ターゲット HTTPS プロキシによって使用されます。この証明書は、セルフマネージド SSL 証明書または Google マネージド SSL 証明書のいずれかとなります。

SSL 証明書の上限と割り当てについては、負荷分散の割り当てページの SSL 証明書をご覧ください。

セキュリティを最大限に高めるために、GFE からバックエンドへのトラフィックを暗号化することもできます。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。

Google がユーザー トラフィックを暗号化する方法に関する一般的な情報については、Google Cloud での転送中の暗号化ホワイト ペーパーをご覧ください。

TLS サポート

デフォルトでは、HTTPS ターゲット プロキシは、クライアントの SSL リクエストを終端するときに TLS 1.0、1.1、1.2、1.3 のみを受け入れます。SSL ポリシーを使用してこのデフォルトの動作を変更し、ロードバランサがクライアントと SSL をネゴシエートする方法を制御できます。

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

タイムアウトと再試行

HTTP(S) 負荷分散には次の 2 種類のタイムアウトがあります。
  • 構成可能な HTTP バックエンド サービス タイムアウト。ロードバランサがバックエンドから完全な HTTP レスポンスが返されるまで待機する時間です。バックエンド サービス タイムアウトのデフォルト値は 30 秒です。次のいずれかの状況では、タイムアウトを長くすることを検討してください。

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

    ロードバランサ経由で送信される WebSocket トラフィックのバックエンド サービスのタイムアウトは、アイドル状態かどうかにかかわらず、WebSocket 接続をオープン状態に保てる最長時間として解釈されます。詳細については、バックエンド サービスの設定をご覧ください。

  • TCP セッション タイムアウト。この値は 10 分(600 秒)に固定されています。このセッション タイムアウトは keep-alive タイムアウトまたはアイドル タイムアウトと呼ばれることもあります。バックエンド サービスの設定の変更では、セッション タイムアウトの値は構成できません。バックエンドによって接続が早期に閉じられないようにするには、バックエンドによって使用されているウェブサーバー ソフトウェアで keep-alive タイムアウトを 600 秒より長い時間に構成する必要があります。このタイムアウトは WebSocket には適用されません

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

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

ロードバランサは、バックエンド サービス タイムアウトに達したときなど、特定の状況で失敗した GET リクエストを再試行します。失敗した POST リクエストは再試行されません。再試行回数は 2 回に制限されています。再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。

GFE は、バックエンド インスタンスの 80% 以上が正常でない場合、再試行を行いません。グループ内に存在するバックエンド インスタンスが 1 つだけで、そのバックエンド インスタンスへの接続が失敗した場合、正常でないバックエンド インスタンスの割合が 100% になるため、GFE はリクエストを再試行しません。詳細については、HTTP(S) 負荷分散のロギングとモニタリングをご覧ください。

WebSocket プロトコルは Ingress でもサポートされています。

不正なリクエストとレスポンスの処理

外部 HTTP(S) ロードバランサは、いくつかの理由により、クライアント リクエストとバックエンド レスポンスのいずれについても、相手方のバックエンドまたはクライアントに到達しないようにブロックすることがあります。厳密に HTTP/1.1 を遵守するためという理由もあれば、バックエンド間での予期しないデータのやり取りを避けるという理由もあります。無効にできるチェックはありません。

ロードバランサは、HTTP/1.1 への適合のために以下をブロックします。

  • 要求の最初の行を解析できない。
  • ヘッダーに : 区切り文字がない。
  • ヘッダーまたは最初の行に無効な文字が含まれている。
  • コンテンツの長さが有効な数値でない、または、複数のコンテンツ長ヘッダーがある。
  • 複数の転送エンコーディング キーがある、または、認識されない転送エンコーティング値がある。
  • チャンク化されていない本文があり、コンテンツの長さが指定されていない。
  • 本文のチャンクが解析できない。なんらかのデータがバックエンドに到達するのはこの場合のみです。ロードバランサは、解析不能なチャンクを受信すると、クライアントとバックエンドへの接続を閉じます。

次のいずれかが該当する場合、ロードバランサはリクエストをブロックします。

  • リクエスト ヘッダーとリクエスト URL の合計サイズが、外部 HTTP(S) 負荷分散のリクエストのヘッダーサイズの上限を超えている。
  • リクエスト メソッドが本文を許可していないにもかかわらず、リクエストに本文がある。
  • リクエストに Upgrade ヘッダーが含まれており、WebSocket 接続の有効化に Upgrade ヘッダーが使用されない。
  • HTTP のバージョンが不明。

ロードバランサは、次のいずれかに該当する場合、バックエンドからのレスポンスをブロックします。

  • レスポンス ヘッダーの合計サイズが、外部 HTTP(S) 負荷分散の最大レスポンス ヘッダーのサイズの上限を超えている。
  • HTTP のバージョンが不明。

仕様と制限事項

  • HTTP(S) 負荷分散は、HTTP/1.1 100 Continue レスポンスをサポートしています。

HTTP/2 の制限事項

  • ロードバランサとインスタンスの間の接続に HTTP/2 を使用する場合は、HTTP(S) の場合よりもインスタンスへの TCP 接続数を大幅に増やす必要があります。HTTP/2 では、HTTP(S) などでの接続数を減らすための最適化を提供する接続プールは現在のところ使用できません。
  • ロードバランサとバックエンドの間の HTTP/2 では、HTTP/2 接続の単一ストリームを介した WebSocket プロトコルの実行(RFC 8441)はサポートされていません。
  • ロードバランサとバックエンドの間の HTTP/2 では、サーバー push がサポートされていません。
  • gRPC エラー率とリクエスト数は Google Cloud API または Cloud Console で確認できません。gRPC エンドポイントがエラーを返した場合、ロードバランサ ログとモニタリング データに「OK 200」という HTTP レスポンス コードが記録されます。

Cloud CDN の使用に関する制限

  • Identity-Aware Proxy または Cloud CDN を同じバックエンド サービスで有効にできません。これを行おうとすると、構成プロセスは失敗します。

次のステップ