このドキュメントでは、Google Cloud 外部 HTTP(S) のロード バランシングの構成に必要なコンセプトについて説明します。
外部 HTTP(S) ロード バランシングは、プロキシベースのレイヤ 7 ロードバランサであり、単一の外部 IP アドレスの背後でサービスを実行し、スケーリングできます。外部 HTTP(S) ロード バランシングは、さまざまな Google Cloud プラットフォーム（Compute Engine、Google Kubernetes Engine（GKE）、Cloud Storage など）でホストされているバックエンドや、インターネットまたはハイブリッド接続を介して接続された外部バックエンドに、HTTP / HTTPS のトラフィックを分散します。詳しくは、ユースケースをご覧ください。
運用モード
外部 HTTP(S) ロード バランシングは、次のモードで構成できます。
- グローバル外部 HTTP(S) ロードバランサ。これは、Google Front End（GFE）でマネージド サービスとして実装されるグローバル ロードバランサです。オープンソースの Envoy プロキシを使用して、トラフィックのミラーリング、重み付けに基づくトラフィック分割、リクエスト / レスポンス ベースのヘッダー変換など、高度なトラフィック管理機能をサポートします。
- グローバル外部 HTTP(S) ロードバランサ（従来）。これは、プレミアム ティアではグローバル、スタンダード ティアではリージョンとして構成できる、従来の外部 HTTP(S) ロードバランサです。このロードバランサは、Google Front End（GFE）に実装されます。GFE はグローバルに分散し、Google のグローバル ネットワークとコントロール プレーンを使用して連携します。
- リージョン外部 HTTP(S) ロードバランサ。これは、オープンソースの Envoy プロキシでマネージド サービスとして実装されるリージョン ロードバランサです。これには、トラフィックのミラーリング、重み付けベースのトラフィック分割、リクエスト / レスポンス ベースのヘッダー変換など、高度なトラフィック管理機能が含まれています。
| ロードバランサ モード | おすすめのユースケース | 機能 |
|---|---|---|
| グローバル外部 HTTP(S) ロードバランサ | このロードバランサは、複数のリージョンにグローバルに分散したユーザーまたはバックエンド サービスがある外部 HTTP(S) ワークロードに使用します。 |
|
| グローバル外部 HTTP(S) ロードバランサ（従来） | このロードバランサは、プレミアム ティアでグローバル、スタンダード ティアではリージョンとして構成できます。 プレミアム Network Service Tiers では、このロードバランサがマルチリージョン ロード バランシングを行い、容量のある最も近い正常なバックエンドにトラフィックを導き、HTTP(S) トラフィックを可能な限りユーザーの近くで終了させます。 スタンダード ネットワーク サービス ティアでは、ロード バランシングはリージョン単位で処理されます。 |
|
| リージョン外部 HTTP(S) ロードバランサ | このロードバランサには、既存のグローバル外部 HTTP(S) ロードバランサ（従来）の機能の多くに加え、高度なトラフィック管理機能が含まれています。 このロードバランサは、1 つの位置情報のみからコンテンツを配信する場合（コンプライアンスで規制されている場合など）や、スタンダード ネットワーク サービス ティアが必要な場合に使用します。 |
|
モードの識別
Cloud コンソール
- Google Cloud コンソールで、[ロード バランシング] ページに移動します。
[ロード バランシング] に移動 - [ロードバランサ] タブに、ロードバランサのタイプ、プロトコル、リージョンが表示されます。リージョンが空の場合、ロードバランサはグローバルです。次の表に、ロードバランサのモードを識別する方法を示します。
ロードバランサ モード ロード バランシングのタイプ リージョン ネットワーク ティア グローバル外部 HTTP(S) ロードバランサ HTTP(S) PREMIUM グローバル外部 HTTP(S) ロードバランサ（従来） HTTP(S)（従来） STANDARD または PREMIUM リージョン外部 HTTP(S) ロードバランサ HTTP(S) リージョンを指定 STANDARD
gcloud
ロードバランサのモードを確認するには、次のコマンドを実行します。
gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
コマンド出力で、ロード バランシング スキーム、リージョン、ネットワーク ティアを確認します。次の表に、ロードバランサのモードを識別する方法を示します。
ロードバランサ モード ロード バランシング スキーム 転送ルール ネットワーク ティア グローバル外部 HTTP(S) ロードバランサ EXTERNAL_MANAGED グローバル PREMIUM グローバル外部 HTTP(S) ロードバランサ（従来） EXTERNAL グローバル STANDARD または PREMIUM リージョン外部 HTTP(S) ロードバランサ EXTERNAL_MANAGED リージョンを指定 STANDARD
アーキテクチャ
HTTP(S) ロード バランシングのデプロイには、次のリソースが必要です。
リージョン外部 HTTP(S) ロードバランサの場合のみ、プロキシ専用サブネットを使用して、ロードバランサをバックエンドに読み込みます。
外部転送ルールで、外部 IP アドレス、ポート、ターゲット HTTP(S) プロキシを指定します。クライアントは、IP アドレスとポートを使用してロードバランサに接続します。
ターゲット HTTP(S) プロキシで、クライアントからのリクエストを受信します。HTTP(S) プロキシは、URL マップを使用してリクエストを評価し、トラフィックのルーティングを決定します。プロキシは、SSL 証明書を使用して通信の認証を行うこともできます。
HTTP(S) プロキシは、URL マップを使用し、HTTP 属性（リクエストパス、Cookie、ヘッダーなど）に基づいてルーティングを決定します。このルーティングの決定に基づいて、プロキシは特定のバックエンド サービスやバックエンド バケットにクライアントのリクエストを転送します。URL マップでは、クライアントにリダイレクトを送信するなど、追加のアクションを指定できます。
バックエンド サービスは、正常なバックエンドにリクエストを分散します。グローバル外部 HTTP(S) ロードバランサは、バックエンド バケットもサポートしています。
- 1 つ以上のバックエンドをバックエンド サービスまたはバックエンド バケットに接続する必要があります。
ヘルスチェックで、バックエンドの準備状況を定期的に監視します。これにより、処理不能なバックエンドにリクエストが送信されるリスクを軽減できます。
バックエンドがヘルスチェック プローブを受け入れるためのファイアウォール ルール。リージョン外部 HTTP(S) ロードバランサには、プロキシ専用サブネットからのトラフィックがバックエンドに到達できるように、追加のファイアウォール ルールが必要です。
グローバル
次の図は、グローバル外部 HTTP(S) ロードバランサのデプロイのコンポーネントを示しています。このアーキテクチャは、高度なトラフィック管理機能を含むグローバル外部 HTTP(S) ロードバランサと、プレミアム ティアのグローバル外部 HTTP(S) ロードバランサ（従来）の両方に適用されます。
リージョン
次の図は、リージョン外部 HTTP(S) ロードバランサのデプロイのコンポーネントを示しています。
プロキシ専用サブネット
プロキシ専用サブネットは、リージョン外部 HTTP(S) ロードバランサの場合のみ必要です。
プロキシ専用サブネットには、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。リージョン外部 HTTP(S) ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを 1 つ作成する必要があります。このプロキシ専用サブネットの --purpose フラグは REGIONAL_MANAGED_PROXY に設定されています。同じリージョンと VPC ネットワーク内にあるすべてのリージョン Envoy ベースのロードバランサは、同じプロキシ専用サブネットの Envoy プロキシのプールを共有します。さらに、
- プロキシ専用サブネットは Envoy プロキシにのみ使用され、バックエンドには使用されません。
- リージョンと VPC ネットワーク内のすべてのリージョン外部 HTTP(S) ロードバランサのバックエンド VM またはエンドポイントは、プロキシ専用サブネットからの接続を受信します。
- リージョン外部 HTTP(S) ロードバランサの IP アドレスは、プロキシ専用サブネットにはありません。ロードバランサの IP アドレスは、後述する外部マネージド転送ルールで定義します。
以前に --purpose=INTERNAL_HTTPS_LOAD_BALANCER でプロキシ専用サブネットを作成した場合は、VPC ネットワークと同じリージョンで他の Envoy ベースのロードバランサを作成する前に、サブネットの目的を REGIONAL_MANAGED_PROXY に移行する必要があります。
転送ルールとアドレス
転送ルールは、IP アドレス、ポート、プロトコルに基づいて、ターゲット プロキシ、URL マップ、1 つ以上のバックエンド サービスからなる負荷分散構成にトラフィックをルーティングします。
各転送ルールでは、アプリケーションの DNS レコードで使用できる単一の IP アドレスを指定します。DNS ベースの負荷分散は必要ありません。使用する IP アドレスを自分で指定することも、Cloud Load Balancing で割り当てられる IP アドレスを使用することもできます。
- HTTP ロードバランサの転送ルールは、TCP ポート 80 と 8080 のみを参照できます。
- HTTPS ロードバランサの転送ルールは、TCP ポート 443 のみを参照できます。
外部 HTTP(S) ロードバランサが使用する転送ルール、IP アドレス、ロード バランシング スキームのタイプは、ロードバランサのモードやロードバランサがどのネットワーク サービス ティアに属しているかによって異なります。
| ロードバランサ モード | Network Service Tiers | 転送ルール、IP アドレス、ロード バランシング スキーム | インターネットからロードバランサのフロントエンドへの転送 |
|---|---|---|---|
| グローバル外部 HTTP(S) ロードバランサ | プレミアム ティア |
ロード バランシング スキーム: |
インターネット上のクライアントに最も近い GFE にルーティングされるリクエスト。 |
| グローバル外部 HTTP(S) ロードバランサ（従来） | プレミアム ティア |
ロード バランシング スキーム: |
インターネット上のクライアントに最も近い GFE にルーティングされるリクエスト。 |
| スタンダード ティア |
ロード バランシング スキーム: |
ロードバランサのリージョン内の GFE に転送されるリクエスト。 | |
| リージョン外部 HTTP(S) ロードバランサ | スタンダード ティア |
ロード バランシング スキーム: |
ロードバランサと同じリージョン内の Envoy プロキシにルーティングされるリクエスト。 |
各モードの HTTP(S) ロード バランシング転送ルールでサポートされるプロトコルの完全な一覧については、ロードバランサの機能をご覧ください。
ターゲット プロキシ
ターゲット プロキシは、クライアントからの HTTP(S) 接続を終端します。1 つ以上の転送ルールがトラフィックをターゲット プロキシに振り向け、ターゲット プロキシが URL マップを参照してバックエンドにトラフィックを転送する方法を決定します。
プロキシでは、リクエストまたはレスポンスのヘッダー名の大文字と小文字の区別の保持が保証されません。たとえば、Server: Apache/1.0 レスポンス ヘッダーはクライアントで server: Apache/1.0 として表示される場合があります。
次の表に、各モードで HTTP(S) ロード バランシングに必要なターゲット プロキシのタイプを示します。
| ロードバランサ モード | ターゲット プロキシのタイプ | プロキシ追加ヘッダー | サポートされるカスタム ヘッダー | Cloud Trace のサポート |
|---|---|---|---|---|
| グローバル外部 HTTP(S) ロードバランサ | グローバル HTTP、 グローバル HTTPS |
プロキシは、次のように HTTP リクエスト ヘッダー / レスポンス ヘッダーを設定します。
|
バックエンド サービスまたはバックエンド バケットで構成されている Cloud CDN ではサポートされていない |
|
| グローバル外部 HTTP(S) ロードバランサ（従来） | グローバル HTTP、 グローバル HTTPS |
プロキシは、次のように HTTP リクエスト ヘッダー / レスポンス ヘッダーを設定します。
|
バックエンド サービスまたはバックエンド バケットで構成されている | |
| リージョン外部 HTTP(S) ロードバランサ | リージョン HTTP、 リージョン HTTPS |
|
Host ヘッダー
ロードバランサが HTTP リクエストを行うと、ロードバランサは元のリクエストの Host ヘッダーを保持します。
X-Forwarded-For ヘッダー
ロードバランサは、1 つのカンマで区切られた 2 つの IP アドレスを次の順序で X-Forwarded-For ヘッダーに追加します。
- ロードバランサに接続するクライアントの IP アドレス
- ロードバランサの転送ルールの IP アドレス
受信リクエストに X-Forwarded-For ヘッダーがない場合、ヘッダーの値はこの 2 つの IP アドレスだけです。
X-Forwarded-For: <client-ip>,<load-balancer-ip>
リクエストに X-Forwarded-For ヘッダーが含まれている場合、ロードバランサは、指定された値を <client-ip>,<load-balancer-ip> の前に保持します。
X-Forwarded-For: <supplied-value>,<client-ip>,<load-balancer-ip>
ロードバランサのバックエンドで HTTP リバース プロキシ ソフトウェアを実行すると、ソフトウェアが X-Forwarded-For ヘッダーの末尾に次の IP アドレスのいずれかまたは両方を追加します。
バックエンドに接続されている Google Front End（GFE）の IP アドレス。これらの IP アドレスの範囲は
130.211.0.0/22と35.191.0.0/16です。バックエンド システム自体の IP アドレス
したがって、ロードバランサのバックエンドの後のアップストリーム プロセスは、次の形式の X-Forwarded-For ヘッダーを受け取る可能性があります。
<existing-values>,<client-ip>,<load-balancer-ip><GFE-IP><backend-IP>
URL マップ
URL マップは、URL に基づいてリクエストが適切なバックエンド サービスにルーティングされる際に使用される一致パターンを定義します。デフォルトのバックエンド サービスは、指定されたホストまたはパスのマッチング ルールに一致しないリクエストを処理するように定義されています。マルチリージョン負荷分散の例など、URL ルールを定義せず、デフォルトのサービスのみに依存する状況もあります。リクエストのルーティングでは、URL マップを使用して URL を調べることで、トラフィックを分割し、リクエストを各種のバックエンド セットに送信できます。
グローバル外部 HTTP(S) ロードバランサとリージョン外部 HTTP(S) ロードバランサで使用する URL マップは、ヘッダーに基づくトラフィック ステアリング、重み付けに基づくトラフィック分割、リクエスト ミラーリングなどの高度なトラフィック管理機能をサポートしています。詳しくは以下をご覧ください。
次の表に、各モードで HTTP(S) ロード バランシングに必要な URL マップの種類を示します。
| ロードバランサ モード | URL マップのタイプ |
|---|---|
| グローバル外部 HTTP(S) ロードバランサ | グローバル |
| グローバル外部 HTTP(S) ロードバランサ（従来） | グローバル（サポートされている機能のサブネットのみ） |
| リージョン外部 HTTP(S) ロードバランサ | リージョン |
SSL 証明書
ターゲット HTTPS プロキシを使用する外部 HTTP(S) ロードバランサには、ロードバランサの構成の一部として秘密鍵と SSL 証明書が必要です。Google Cloud には、秘密鍵と SSL 証明書をターゲット HTTPS プロキシに割り当てるための構成方法が 2 つあります。1 つは Compute Engine SSL 証明書、もう 1 つは証明書マネージャーです。各構成の詳細については、SSL 証明書の概要で証明書の構成方法をご覧ください。
Google Cloud では、セルフマネージドと Google マネージドの 2 種類の証明書タイプが用意されています。各タイプの詳細については、SSL 証明書の概要で証明書のタイプをご覧ください。
外部 HTTP(S) ロードバランサ モードにより、サポートされている構成方法と証明書タイプが決まります。詳細については、SSL 証明書の概要で証明書と Google Cloud ロードバランサをご覧ください。
SSL ポリシー
SSL ポリシーでは、Google Cloud ロードバランサがクライアントと SSL のネゴシエートするときに使用する一連の SSL 機能を指定します。
デフォルトでは、HTTPS ロード バランシングは、優れたセキュリティと幅広い互換性を提供する一連の SSL 機能を使用します。アプリケーションの中には、HTTPS または SSL 接続に使用される SSL のバージョンおよび暗号をより詳細に管理しなければならないものがあります。SSL ポリシーを定義して、ロードバランサがクライアントと SSL をネゴシエートする際に使用する一連の SSL 機能を指定できます。また、その SSL ポリシーをターゲット HTTPS プロキシに適用できます。
次の表に、各モードでのロードバランサに対する SSL ポリシーのサポートを示します。
| ロードバランサ モード | サポートされる SSL ポリシー |
|---|---|
| グローバル外部 HTTP(S) ロードバランサ | |
| グローバル外部 HTTP(S) ロードバランサ（従来） | |
| リージョン外部 HTTP(S) ロードバランサ |
バックエンド サービスとバケット
バックエンド サービスは、ロードバランサに構成情報を提供します。ロードバランサは、バックエンド サービスからの情報を使用して、受信トラフィックを接続されている 1 つまたは複数のバックエンドに振り向けます。バックエンド サービスと Compute Engine バックエンドを使用してロードバランサを設定する方法の例については、Compute Engine バックエンドを使用した外部 HTTP(S) ロードバランサの設定をご覧ください。
バックエンド バケットは、Cloud Storage バケットに着信トラフィックを振り向けます。バケットを外部 HTTP(S) ロードバランサに追加する方法を示す例については、バックエンド バケットを使用したロードバランサの設定をご覧ください。
次の表に、各モードでの HTTP(S) ロード バランシングでサポートされるバックエンド機能を示します。
|
ロードバランサ モード |
バックエンド サービスでサポートされるバックエンド | バックエンド バケットのサポート | Google Cloud Armor のサポート | Cloud CDN のサポート | IAP のサポート | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| インスタンス グループ | ゾーン NEG | インターネット NEG | サーバーレス NEG | ハイブリッド NEG | Private Service Connect NEG | |||||
| グローバル外部 HTTP(S) ロードバランサ | ||||||||||
| グローバル外部 HTTP(S) ロードバランサ（従来） |
プレミアム ティアを使用する場合 |
|
||||||||
| リージョン外部 HTTP(S) ロードバランサ | ||||||||||
詳しくは以下をご覧ください。
バックエンドと VPC ネットワーク
バックエンドを配置するロケーションの制限は、ロードバランサの種類によって異なります。
- グローバル外部 HTTP(S) ロードバランサとグローバル外部 HTTP(S) ロードバランサ（従来）の場合、すべてのバックエンドは同じプロジェクトに配置する必要がありますが、異なる VPC ネットワークに配置できます。GFE プロキシ システムはそれぞれの VPC ネットワーク内のバックエンドと直接通信するため、異なる VPC ネットワークを VPC ネットワーク ピアリングで接続する必要はありません。
- リージョン外部 HTTP(S) ロードバランサの場合、すべてのバックエンドを同じ VPC ネットワークとリージョンに配置する必要があります。
バックエンドへのプロトコル
ロードバランサのバックエンド サービスを構成する際には、バックエンド サービスがバックエンドと通信するために使用するプロトコルを設定します。HTTP、HTTPS、HTTP/2 を選択できます。指定したプロトコルのみがロードバランサで使用されます。指定されたプロトコルでバックエンドへの接続をネゴシエートできない場合、ロードバランサは他のプロトコルへのフォールバックを行いません。
HTTP/2 を使用する場合は、TLS を使用する必要があります。暗号化されていない HTTP/2 はサポートされません。
サポートされているプロトコルの一覧については、ロード バランシング機能: ロードバランサからバックエンドへのプロトコルをご覧ください。
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 のセッション アフィニティは、他のリクエストの場合と同じように機能します。詳細については、セッション アフィニティをご覧ください。
Google Cloud アプリケーションで 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 を有効にする必要があります。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。
Google Kubernetes Engine Ingress で HTTP/2 を使用するか、Ingress で gRPC と HTTP/2 を使用して、外部 HTTP(S) ロードバランサを構成する場合は、Ingress による HTTP/2 を使用したロード バランシングをご覧ください。
HTTP/2 の問題のトラブルシューティングについては、バックエンドへの HTTP/2 の問題のトラブルシューティングをご覧ください。
HTTP/2 の制限の詳細については、HTTP/2 の制限をご覧ください。
ヘルスチェック
各バックエンド サービスは、ロードバランサからの接続を受信するバックエンドの稼働状況を定期的に監視するヘルスチェックを指定します。これにより、処理不能なバックエンドにリクエストが送信されるリスクを軽減できます。ヘルスチェックでは、アプリケーション自体が動作するかどうかはチェックされません。
ヘルスチェック プローブでは、上り（内向き）許可ファイアウォール ルールを作成してヘルスチェック プローブがバックエンド インスタンスに到達できるようにする必要があります。通常、ヘルスチェック プローブは Google の一元化されたヘルスチェックの仕組みにより発信されます。
1 つの例外は、ハイブリッド NEG バックエンドを使用するリージョン外部 HTTP(S) ロードバランサです。これは、ヘルスチェックがプロキシ専用サブネットから発信されます。詳しくは、ハイブリッド NEG の概要をご覧ください。
ヘルスチェック プロトコル
必須ではなく、常に可能というわけでもありませんが、バックエンド サービスのプロトコルに一致するプロトコルでヘルスチェックを使用することをおすすめします。たとえば、バックエンドに対する HTTP/2 の接続性を最も正確にテストできるのは HTTP/2 ヘルスチェックです。一方、ハイブリッド NEG バックエンドを使用するリージョン外部 HTTP(S) ロードバランサは、gRPC ヘルスチェックをサポートしていません。サポートされているヘルスチェック プロトコルの一覧については、ロード バランシング機能をご覧ください。
次の表に、各モードの HTTP(S) ロード バランシングでサポートされるヘルスチェックの範囲を示します。
| ロードバランサ モード | ヘルスチェックのタイプ |
|---|---|
| グローバル外部 HTTP(S) ロードバランサ | グローバル |
| グローバル外部 HTTP(S) ロードバランサ（従来） | グローバル |
| リージョン外部 HTTP(S) ロードバランサ | リージョン |
ヘルスチェックの詳細については、以下をご覧ください。
ファイアウォール ルール
HTTP(S) ロード バランシングには、次のファイアウォール ルールが必要です。
- グローバル外部 HTTP(S) ロードバランサの場合、上り（内向き）許可ルールによって、バックエンドに到達するように Google Front End（GFE）からのトラフィックが許可されます。
リージョン外部 HTTP(S) ロードバランサの場合、上り（内向き）許可ルールによって、バックエンドに到達するようにプロキシ専用サブネットからのトラフィックが許可されます。 - ヘルスチェック プローブ範囲からのトラフィックを許可する上り（内向き）許可ルール。ヘルスチェック プローブの詳細と、プローブからのトラフィックを許可する必要がある理由については、プローブ IP 範囲とファイアウォール ルールをご覧ください。
ファイアウォール ルールは GFE プロキシではなく、VM インスタンス レベルで実装されます。Google Cloud ファイアウォール ルールを使用して、トラフィックがロードバランサに到達しないようにすることはできません。グローバル外部 HTTP(S) ロードバランサとグローバル外部 HTTP(S) ロードバランサ（従来）の場合、Google Cloud Armor を使用してこれを実現できます。
これらのファイアウォール ルールのポートは、次のように構成する必要があります。
各バックエンド サービスのヘルスチェックのための宛先ポートへのトラフィックを許可します。
インスタンス グループのバックエンドの場合: バックエンド サービスの名前付きポートと、各インスタンス グループの名前付きポートに関連付けられたポート番号とのマッピングによって、構成するポートを決定します。同じバックエンド サービスに割り当てられたインスタンス グループ間でポート番号が異なる可能性があります。
GCE_VM_IP_PORTNEG バックエンドの場合: エンドポイントのポート番号へのトラフィックを許可します。
次の表は、ファイアウォール ルールに必要な送信元 IP アドレス範囲をまとめたものです。
| ロードバランサ モード | ヘルスチェックのソース範囲 | リクエストのソース範囲 |
|---|---|---|
| グローバル外部 HTTP(S) ロードバランサ |
|
GFE トラフィックのソースはバックエンド タイプによって異なります。
|
| グローバル外部 HTTP(S) ロードバランサ（従来） |
|
GFE トラフィックのソースはバックエンド タイプによって異なります。
|
| リージョン外部 HTTP(S) ロードバランサ |
現在、ハイブリッド NEG のヘルスチェック プローブは、Google の一元化されたヘルスチェック メカニズムから発信されています。Google のヘルスチェック範囲から発信されたトラフィックがハイブリッド エンドポイントに到達することを許可できず、代わりにプライベート IP アドレスからヘルスチェック プローブを発信する場合は、Google アカウント担当者に依頼して、プロジェクトを分散 Envoy ヘルスチェックの許可リストに登録してください。 |
構成するプロキシ専用サブネット。 |
共有 VPC アーキテクチャ
HTTP(S) ロード バランシングでは、共有 VPC を使用するネットワークがサポートされます。組織は、共有 VPC を使用して複数のプロジェクトのリソースを共通の VPC ネットワークに接続できるため、そのネットワークの内部 IP を使用して、安全で効率的な相互通信を行うことができます。共有 VPC についてまだよく理解していない場合は、共有 VPC の概要のドキュメントをご覧ください。
共有 VPC ネットワーク内で外部 HTTP(S) ロード バランシングを構成するには、多くの方法があります。デプロイの種類に関係なく、ロードバランサのすべてのコンポーネントを同じ組織に配置する必要があります。
| ロードバランサ | フロントエンド コンポーネント | バックエンド コンポーネント |
|---|---|---|
| グローバル外部 HTTP(S) ロードバランサ、 グローバル外部 HTTP(S) ロードバランサ（従来） |
グローバル外部 IP アドレス、転送ルール、ターゲット HTTP(S) プロキシ、関連する URL マップは、バックエンドと同じホストまたはサービス プロジェクトで定義する必要があります。 | グローバル バックエンド サービスは、バックエンド（インスタンス グループまたは NEG）と同じホストまたはサービス プロジェクトで定義する必要があります。バックエンド サービスに関連するヘルスチェックも、バックエンド サービスと同じプロジェクトで定義する必要があります。 |
| リージョン外部 HTTP(S) ロードバランサ | 共有 VPC ホスト プロジェクトで、必要なネットワークとプロキシ専用サブネットを作成します。 リージョン外部 IP アドレス、転送ルール、ターゲット HTTP(S) プロキシ、関連付けられた URL マップは、同じプロジェクトで定義する必要があります。このプロジェクトは、ホスト プロジェクトまたはサービス プロジェクトにできます。 |
次のいずれかを行います。
各バックエンド サービスは、参照するバックエンドと同じプロジェクトで定義する必要があります。バックエンド サービスに関連するヘルスチェックも、バックエンド サービスと同じプロジェクトで定義する必要があります。 |
共有 VPC ホスト プロジェクトですべてのロード バランシング コンポーネントとバックエンドを作成できますが、このモデルではネットワーク管理とサービス開発の責任が分離されません。
共有 VPC 環境におけるサーバーレス バックエンド
サーバーレス NEG バックエンドを使用するロードバランサの場合、バックエンド Cloud Run、Cloud Functions、App Engine サービスはサーバーレス NEG と同じプロジェクト内に存在する必要があります。
また、プロジェクト間のサービス参照をサポートするリージョン外部 HTTP(S) ロードバランサの場合、バックエンド サービス、サーバーレス NEG、Cloud Run サービスは常に同じサービス プロジェクトに存在する必要があります。
プロジェクト間のサービス参照
このモデルでは、ロードバランサのフロントエンドと URL マップはホスト プロジェクトまたはサービス プロジェクトに存在します。ロードバランサのバックエンド サービスとバックエンドは、共有 VPC 環境のプロジェクト間で分散できます。プロジェクト間のバックエンド サービスは 1 つの URL マップで参照できます。これはプロジェクト間のサービス参照と呼ばれます。
プロジェクト間のサービス参照を使用すると、組織は 1 つの一元的なロードバランサを構成し、複数の異なるプロジェクトに分散された数百のサービスにトラフィックをルーティングできます。トラフィック ルーティングのルールおよびポリシーはすべて、1 つの URL マップで一元管理できます。ロードバランサをホスト名と SSL 証明書の組み合わせの 1 つと関連付けることもできます。このため、アプリケーションのデプロイに必要なロードバランサの数を最適化することで、管理性の向上や、運用費および必要な割り当て量の削減につながります。
さらに、プロジェクトを部門ごとに分けて、組織内のロールを分離することもできます。サービス オーナーはサービス プロジェクト内のサービス構築に、ネットワーク チームは別のプロジェクト内のロードバランサのプロビジョニングと維持に専念できます。これらのプロジェクトは、プロジェクト間のサービス参照によって接続できます。
サービス オーナーは、サービスの公開に対する自律性を維持し、ロードバランサを介してサービスにアクセスできるユーザーを制御できます。この仕組みは、Compute ロードバランサ サービス ユーザーのロール（roles/compute.loadBalancerServiceUser）という特別な IAM ロールによって実現されます。
プロジェクト間のサービス参照は、インスタンス グループ、サーバーレス NEG、他のサポートされているバックエンド タイプで使用できます。サーバーレス NEG を使用している場合は、ロードバランサのフロントエンドを作成する VPC ネットワークに VM を作成する必要があります。VM の作成方法については、Cloud Run でリージョン外部 HTTP(S) ロードバランサを設定するをご覧ください。
グローバル外部 HTTP(S) ロードバランサとグローバル外部 HTTP(S) ロードバランサ（従来）には、プロジェクト間のサービス参照はサポートされていません。
例 1: ロードバランサのフロントエンドとバックエンドが別のサービス プロジェクトに存在する
次のデプロイの例では、ロードバランサのフロントエンドと URL マップがサービス プロジェクト A に作成され、URL マップはサービス プロジェクト B のバックエンド サービスを参照しています。
この場合、サービス プロジェクト A のネットワーク管理者またはロードバランサ管理者は、サービス プロジェクト B のバックエンド サービスにアクセスする必要があります。サービス プロジェクト B の管理者は、サービス プロジェクト B のバックエンド サービスを参照するサービス プロジェクト A のロードバランサ管理者に compute.loadBalancerServiceUser IAM ロールを付与します。
例 2: ホスト プロジェクト内のロードバランサのフロントエンドと、サービス プロジェクトのバックエンド
このタイプのデプロイでは、ロードバランサのフロントエンドと URL マップがホスト プロジェクトに作成され、バックエンド サービス（とバックエンド）がサービス プロジェクトに作成されます。
この場合、ホスト プロジェクトのネットワーク管理者またはロードバランサ管理者は、サービス プロジェクトのバックエンド サービスにアクセスする必要があります。サービス プロジェクトの管理者は、サービス プロジェクトのバックエンド サービスを参照するホスト プロジェクト A のロードバランサ管理者に compute.loadBalancerServiceUser IAM ロールを付与します。
サービス プロジェクト内のすべてのロードバランサ コンポーネントとバックエンド
このモデルでは、ロードバランサのすべてのコンポーネントとバックエンドがサービス プロジェクトに存在します。このデプロイモデルは、すべての HTTP(S) ロードバランサでサポートされています。
ロードバランサのコンポーネントとバックエンドは同じ VPC ネットワークを使用する必要があります。
HTTP(S) ロード バランシングでの接続の仕組み
グローバル外部 HTTP(S) ロードバランサ接続
グローバル外部 HTTP(S) ロードバランサは、Google Front End（GFE）という多くのプロキシによって実装されます。プロキシは 1 つではありません。プレミアム ティアでは、同じグローバル外部 IP アドレスがさまざまな拠点からアドバタイズされ、クライアントのリクエストは、クライアントの最も近い GFE に送信されます。
クライアントがいる場所に応じて、複数の GFE がバックエンドへの HTTP(S) 接続を開始できます。GFE から送信されたパケットには、ヘルスチェック プローバーが使用するものと同じ範囲（35.191.0.0/16 と 130.211.0.0/22）の送信元 IP アドレスがあります。
バックエンド サービスの構成に応じて、各 GFE がバックエンドに接続するために使用するプロトコルは HTTP、HTTPS、HTTP/2 のいずれかになります。HTTP または HTTPS 接続の場合、使用される HTTP バージョンは HTTP 1.1 です。
HTTP キープアライブは、HTTP 1.1 仕様で指定されているように、デフォルトで有効になっています。HTTP キープアライブは、同じ TCP セッションを効率的に使用しようとしますが、保証はありません。GFE はキープアライブ タイムアウトを 600 秒に設定しており、構成はできません。ですが、バックエンド サービスのタイムアウトを設定することで、リクエスト/レスポンスのタイムアウトを構成できます。HTTP キープアライブと TCP アイドル タイムアウトは密接に関連していますが、同じではありません。詳しくは、タイムアウトと再試行をご覧ください。
HTTP 接続と TCP セッションの数は、GFE の接続数、GFE に接続するクライアントの数、バックエンドへのプロトコル、バックエンドのデプロイ場所によって異なります。
詳細については、ソリューション ガイドの HTTP(S) ロード バランシングの仕組み: グローバル ロード バランシングによるアプリケーション容量の最適化をご覧ください。
リージョン外部 HTTP(S) ロードバランサ接続
リージョン外部 HTTP(S) ロードバランサは、Envoy プロキシに実装されたマネージド サービスです。リージョン外部 HTTP(S) ロードバランサは、プロキシ専用サブネットという共有サブネットを使用して、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスをプロビジョニングします。このプロキシ専用サブネットの --purpose フラグは REGIONAL_MANAGED_PROXY に設定されています。特定のネットワークとリージョン内のリージョン Envoy ベースのロードバランサはすべて、このサブネットを共有します。
クライアントは、ロードバランサの IP アドレスとポートを使用してロードバランサに接続します。クライアント リクエストは、クライアントと同じリージョン内のプロキシ専用サブネットに転送されます。ロードバランサは、クライアント リクエストを終了して、プロキシ専用サブネットからバックエンドへの新しい接続を開きます。したがって、ロードバランサから送信されたパケットには、プロキシ専用サブネットからの送信元 IP アドレスがあります。
バックエンド サービスの構成に応じて、Envoy プロキシがバックエンドに接続するために使用するプロトコルは HTTP、HTTPS、HTTP/2 のいずれかになります。HTTP または HTTPS の場合の HTTP バージョンは HTTP 1.1 です。HTTP キープアライブは、HTTP 1.1 仕様で指定されているように、デフォルトで有効になっています。Envoy プロキシは、キープアライブ タイムアウトを 600 秒に設定しており、構成はできません。ですが、バックエンド サービスのタイムアウトを設定することで、リクエスト/レスポンスのタイムアウトを構成できます。詳しくは、タイムアウトと再試行をご覧ください。
ロードバランサとのクライアント通信
- クライアントは HTTP 1.1 または HTTP/2 プロトコルを使用してロードバランサと通信できます。
- 最近のクライアントは、HTTPS を使用するとデフォルトで HTTP/2 になります。この制御は HTTPS ロードバランサではなくクライアント上で行われます。
- ロードバランサで構成を変更することで、HTTP/2 を無効にすることはできません。ただし、一部のクライアントは、HTTP/2 ではなく HTTP 1.1 を使用するように構成できます。たとえば、
curlでは、--http1.1パラメータを使用します。 - HTTP(S) ロード バランシングは、
HTTP/1.1 100 Continueレスポンスをサポートしています。
各モードの HTTP(S) ロード バランシング転送ルールでサポートされるプロトコルの完全な一覧については、ロードバランサの機能をご覧ください。
クライアント パケットの送信元 IP アドレス
バックエンドから見たパケットの送信元 IP アドレスは、ロードバランサの Google Cloud の外部 IP アドレスではありません。つまり、2 つの TCP 接続があります。
グローバル外部 HTTP(S) ロードバランサの場合:接続 1: 元のクライアントからロードバランサ（GFE）への接続。
- 送信元 IP アドレス: オリジナルのクライアント（クライアントが NAT の背後にある場合や外部プロキシの場合は外部 IP アドレス）。
- 宛先 IP アドレス: ロードバランサの IP アドレス。
接続 2: ロードバランサ（GFE）からバックエンド VM またはエンドポイントへの接続。
送信元 IP アドレス: ファイアウォール ルールで指定された範囲の IP アドレス。
宛先 IP アドレス: VPC ネットワーク内のバックエンド VM またはコンテナの内部 IP アドレス。
接続 1: 元のクライアントからロードバランサ（プロキシ専用サブネット）への接続。
- 送信元 IP アドレス: オリジナルのクライアント（クライアントが NAT の背後にある場合や外部プロキシの場合は外部 IP アドレス）。
- 宛先 IP アドレス: ロードバランサの IP アドレス。
接続 2: ロードバランサ（プロキシ専用サブネット）からバックエンド VM またはエンドポイントへの接続。
送信元 IP アドレス: ロードバランサと同じリージョン、同じネットワークにデプロイされたすべての Envoy ベースのロードバランサ間で共有されるプロキシ専用サブネットの IP アドレス。
宛先 IP アドレス: VPC ネットワーク内のバックエンド VM またはコンテナの内部 IP アドレス。
リターンパス
グローバル外部 HTTP(S) ロードバランサの場合、Google Cloud は VPC ネットワークで定義されていない特殊なルートをヘルスチェックに使用します。詳細については、ロードバランサのリターンパスをご覧ください。
リージョン外部 HTTP(S) ロードバランサの場合、Google Cloud はオープンソースの Envoy プロキシを使用してロードバランサへのクライアント リクエストを終了します。ロードバランサは TCP セッションを終了し、リージョンのプロキシ専用サブネットからバックエンドへの新しい TCP セッションを開きます。VPC ネットワーク内で定義されたルートによって、Envoy プロキシからバックエンドへの通信と、バックエンドから Envoy プロキシへの通信が容易になります。
オープンポート
このセクションは、GFE を使用して実装されるグローバル外部 HTTP(S) ロードバランサにのみ適用されます。
GFE には、同じアーキテクチャで実行される他の Google サービスをサポートするための複数のオープンポートがあります。GFE で開かれる可能性のあるポートの一覧を確認するには、転送ルール: ポートの仕様をご覧ください。GFE で実行されている他の Google サービス用に他のオープンポートが存在する可能性もあります。
GFE ベースのロードバランサの IP アドレスに対してポートスキャンを実行することは、次の理由により、監査の観点からは役立ちません。
通常、ポートスキャン（たとえば
nmapを使用）では、TCP SYN プローブを実行するときにレスポンス パケットや TCP RST パケットは想定されません。ロードバランサがプレミアム ティアの IP アドレスを使用する場合、GFE は、転送ルールを構成するポートとポート 80 および 443 に対してのみ、SYN プローブへのレスポンスとして SYN-ACK パケットを送信します。GFE は、ロードバランサの IP アドレスと、転送ルールで構成されている宛先ポートにパケットが送信された場合にのみ、パケットをバックエンドに送信します。パケットが別のロードバランサの IP アドレスや、転送ルールに構成されていないポートのロードバランサの IP アドレスに送信された場合、ロードバランサのバックエンドへのパケット送信は発生しません。GFE は、Google Cloud Armor などのセキュリティ機能を実装しています。Google Cloud Armor の構成がなくても、Google のインフラストラクチャと GFE は DDoS 攻撃と SYN フラッドに対して多層防御を提供します。ロードバランサの IP アドレスに送信されたパケットには Google のフリートの任意の GFE が応答可能ですが、ロードバランサの IP アドレスと宛先ポートの組み合わせをスキャンすると、TCP 接続ごとに 1 つの GFE のみが検査されます。ロードバランサの IP アドレスは、単一のデバイスまたはシステムに割り当てられていません。したがって、GFE ベースのロードバランサの IP アドレスをスキャンしても、Google のフリート内のすべての GFE がスキャンされるわけではありません。
以下では、この点を考慮し、バックエンド インスタンスのセキュリティをより効果的に監査する方法を説明します。
セキュリティ監査担当者は、ロードバランサの構成で転送ルールの構成を検査する必要があります。転送ルールは、ロードバランサがパケットを受け入れてバックエンドに転送する宛先ポートを定義しています。GFE ベースのロードバランサの場合、1 つの外部転送ルールで参照できる宛先 TCP ポートは 1 つだけです。TCP ポート 443 を使用するロードバランサの場合、接続を QUIC（HTTP/3）にアップグレードすると、UDP ポート 443 が使用されます。
セキュリティ監査担当者は、バックエンド VM に適用されるファイアウォール ルールの構成を検査する必要があります。ファイアウォール ルールの設定では、GFE からバックエンド VM へのトラフィックをブロックしますが、GFE への受信トラフィックはブロックしません。ベスト プラクティスについては、ファイアウォール ルールのセクションをご覧ください。
TLS 終端
次の表は、各モードの外部 HTTP(S) ロードバランサによる TLS 終端の処理方法をまとめたものです。
| ロードバランサ モード | TLS 終端 |
|---|---|
| グローバル外部 HTTP(S) ロードバランサ | TLS は、世界中のあらゆる場所にある GFE で終端されます。 |
| グローバル外部 HTTP(S) ロードバランサ（従来） | TLS は、世界中のあらゆる場所にある GFE で終端されます。 |
| リージョン外部 HTTP(S) ロードバランサ | TLS は、ユーザーが選択したリージョンのプロキシ専用サブネットにある Envoy プロキシで終端されます。TLS を終端するリージョンを地理的に制御する必要がある場合は、このロードバランサ モードを使用してください。 |
タイムアウトと再試行
外部 HTTP(S) ロード バランシングには次のタイムアウトがあります。構成可能な HTTP バックエンド サービス タイムアウト。ロードバランサがバックエンドから完全な HTTP レスポンスが返されるまで待機する時間です。バックエンド サービス タイムアウトのデフォルト値は 30 秒です。指定できるタイムアウト値の範囲は 1～2,147,483,647 秒です。
たとえば、500 MB のファイルをダウンロードする場合、バックエンド サービスのタイムアウトの値がデフォルト値の 30 秒であれば、ロードバランサはバックエンドが 500 MB ファイル全体を 30 秒以内で配信すると想定します。バックエンドが完全な HTTP レスポンスを送信するのに十分でない時間をバックエンド サービスのタイムアウトに構成することもできます。この状況では、少なくともロードバランサが HTTP レスポンス ヘッダーを受け取った場合、ロードバランサは完全なレスポンス ヘッダーと、バックエンド サービスのタイムアウト内で取得できる可能な限り多くのレスポンス本文を返します。
バックエンド サービスのタイムアウトは、プロキシ（GFE またはマネージド Envoy）とバックエンド間の処理のため、リクエストの最初のバイトからレスポンスの最後のバイトまでの最大時間に設定する必要があります。WebSocket を使用している場合は、バックエンド サービスのタイムアウトを WebSocket の最大時間（アイドルまたはアクティブ）に設定する必要があります。
次のいずれかの状況では、タイムアウトを長くすることを検討してください。
- バックエンドが HTTP レスポンスを返すのに時間がかかることが予想される場合。
jsonPayload.statusDetailclient_timed_outの HTTP408レスポンスが返された場合。- 接続が WebSocket にアップグレードされた場合。
設定するバックエンド サービスのタイムアウトはベスト エフォート型の目標です。ただし、基礎となる TCP 接続が、タイムアウトの間にオープン状態になっているとは限りません。
バックエンド サービスのタイムアウトは任意の値に設定できますが、1 日（86,400 秒）を超える値に設定しても、ロードバランサはその期間 TCP 接続を継続するわけではありません。Google はソフトウェアの更新と定期的なメンテナンスのために GFE と Envoy ソフトウェアのタスクを定期的に再起動していますが、バックエンド サービスのタイムアウトはそれをオーバーライドしません。バックエンド サービスのタイムアウトを長くするほど、Google がメンテナンスで TCP 接続を終了する可能性が高くなります。このようなイベントの影響を減らすため、再試行ロジックの実装をおすすめします。
バックエンド サービス タイムアウトは、HTTP のアイドル（キープアライブ）タイムアウトではありません。バックエンドからの入出力（IO）は、クライアントの速度が遅い場合（ブラウザの接続が遅い場合など）にブロックされる可能性があります。この待機時間は、バックエンド サービス タイムアウトにはカウントされません。
バックエンド サービスのタイムアウトを構成するには、次のいずれかの方法を使用します。
- Google Cloud コンソール: ロードバランサのバックエンド サービスの [タイムアウト] フィールドを変更します。
- Google Cloud CLI:
gcloud compute backend-services updateコマンドを使用して、バックエンド サービス リソースの--timeoutパラメータを変更します。 - API: グローバルまたはリージョンのバックエンド サービス リソースの
timeoutSecパラメータを変更します。
リージョン外部 HTTP(S) ロードバランサの場合、URL マップの
routeActions.timeoutパラメータはバックエンド サービスのタイムアウトをオーバーライドできます。バックエンド サービスのタイムアウトは、routeActions.timeoutのデフォルト値として使用されます。
- バックエンド バケットをグローバル外部 HTTP(S) ロードバランサおよびグローバル外部 HTTP(S) ロードバランサ（従来）と使用する場合は、次の 2 つのタイムアウトを使用できます。
- 6 分に固定されたアイドル タイムアウト。バックエンド バケットの HTTP ストリームは、アクティビティがない状態が 6 分続くとアイドル状態とみなされます。
- ロードバランサと Cloud Storage の両方で要した完全なレスポンスの処理時間を含む、もう 1 つのタイムアウト。このタイムアウトは 24 時間に固定されています。
- HTTP キープアライブ タイムアウト。この値は 10 分（600 秒）に固定されています。この値は、バックエンド サービスを変更しても構成できません。バックエンドによって接続が早期に閉じられないようにするには、バックエンドによって使用されているウェブサーバー ソフトウェアでキープアライブ タイムアウトを 600 秒より長い時間に構成する必要があります。このタイムアウトは WebSocket には適用されません。次の表は、一般的なウェブサーバー ソフトウェアのキープアライブ タイムアウトを変更するために必要な変更を示します。
ウェブサーバー ソフトウェア パラメータ デフォルト設定 推奨される設定 Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620 nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;
再試行数
再試行ロジックのための HTTP(S) ロード バランシングのサポートは、外部 HTTP(S) ロードバランサのモードによって異なります。
| ロードバランサ モード | 再試行ロジック |
|---|---|
| グローバル外部 HTTP(S) ロードバランサ |
URL マップの再試行ポリシーを使用して構成できます。デフォルトの再試行回数（ 再試行ポリシーがない場合、HTTP 本文のないリクエスト（GET リクエストなど）が HTTP 502、503、または 504 レスポンス（ 再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。 |
| グローバル外部 HTTP(S) ロードバランサ（従来） |
接続の再試行に関する再試行ポリシーは変更できません。 HTTP POST リクエストは再試行されません。 80% 以上のバックエンドが正常である限り、HTTP GET リクエストは常に 1 回再試行されます。グループ内に存在するバックエンド インスタンスが 1 つだけで、そのバックエンド インスタンスへの接続が失敗した場合、正常でないバックエンド インスタンスの割合が 100% になるため、GFE はリクエストを再試行しません。 ロードバランサは、バックエンド サービス タイムアウトに達したときなど、特定の状況で失敗した GET リクエストを再試行します。リクエストの再試行回数は リクエストが失敗すると、ロードバランサは HTTP 502 レスポンスを合成します。 |
| リージョン外部 HTTP(S) ロードバランサ |
URL マップの再試行ポリシーを使用して構成できます。デフォルトの再試行回数（ 再試行ポリシーがない場合、HTTP 本文のないリクエスト（GET リクエストなど）が HTTP 502、503、または 504 レスポンスを返すと、1 回再試行されます。HTTP POST リクエストは再試行されません。 再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。 |
WebSocket プロトコルは GKE Ingress でもサポートされています。
不正なリクエストとレスポンスの処理
ロードバランサは、いくつかの理由により、クライアント リクエストとバックエンド レスポンスのいずれについても、相手方のバックエンドまたはクライアントに到達しないようにブロックすることがあります。厳密に HTTP/1.1 を遵守するためという理由もあれば、バックエンド間での予期しないデータのやり取りを避けるという理由もあります。無効にできるチェックはありません。
ロードバランサは、HTTP/1.1 への適合のために以下をブロックします。
- 要求の最初の行を解析できない。
- ヘッダーに
:区切り文字がない。 - ヘッダーまたは最初の行に無効な文字が含まれている。
- コンテンツの長さが有効な数値でない、または、複数のコンテンツ長ヘッダーがある。
- 複数の転送エンコーディング キーがある、または、認識されない転送エンコーティング値がある。
- チャンク化されていない本文があり、コンテンツの長さが指定されていない。
- 本文のチャンクが解析できない。なんらかのデータがバックエンドに到達するのはこの場合のみです。ロードバランサは、解析不能なチャンクを受信すると、クライアントとバックエンドへの接続を閉じます。
次のいずれかが該当する場合、ロードバランサはリクエストをブロックします。
- リクエスト ヘッダーとリクエスト URL の合計サイズが、外部 HTTP(S) 負荷分散のリクエストのヘッダーサイズの上限を超えている。
- リクエスト メソッドが本文を許可していないにもかかわらず、リクエストに本文がある。
- リクエストに
Upgradeヘッダーが含まれており、WebSocket 接続の有効化にUpgradeヘッダーが使用されない。 - HTTP のバージョンが不明。
ロードバランサは、次のいずれかに該当する場合、バックエンドからのレスポンスをブロックします。
- レスポンス ヘッダーの合計サイズが、外部 HTTP(S) 負荷分散の最大レスポンス ヘッダーのサイズの上限を超えている。
- HTTP のバージョンが不明。
トラフィック分散
バックエンド インスタンス グループまたは NEG をバックエンド サービスに追加する場合は、バックエンドの負荷とターゲット容量を測定する方法を定義する分散モードを指定します。外部 HTTP(S) 負荷分散は、以下の 2 つの分散モードをサポートします。
インスタンス グループまたは NEG の場合、
RATEは 1 秒あたりのリクエスト（クエリ）の最大数（RPS、QPS）の目標です。すべてのバックエンドが容量を超えると、目標最大 RPS / QPS を超過する場合があります。UTILIZATIONはインスタンス グループ内の VM のバックエンド使用率です。
バックエンド間でのトラフィックの分散方法は、ロードバランサのモードによって異なります。
グローバル外部 HTTP(S) ロードバランサ
Google Front End（GFE）はバックエンド インスタンスにリクエストを送信する前に、どのバックエンド インスタンスがリクエストを受信できるかを推定します。この容量の見積もりは、リクエストの到着と同時に行われるのではなく、事前に行われます。GFE は、利用可能な容量に関する情報を定期的に受け取り、それに応じて受信リクエストを分散します。
容量の意味は、分散モードによって異なります。RATE モードの場合は比較的単純です。GFE は 1 秒あたりに割り当てることができるリクエスト数を正確に決定します。UTILIZATION ベースの負荷分散はより複雑です。ロードバランサはインスタンスの現在の使用率をチェックし、各インスタンスが処理できるクエリ負荷を見積もります。この推定値は、インスタンスの使用率とトラフィック パターンの変化に応じて変化します。
容量の見積もりと事前の割り当ての両方の要素が、インスタンス間の分散に影響します。そのため、Cloud Load Balancing の動作は、2 つのインスタンス間でリクエストを正確に 50:50 に分散する単純なラウンドロビン ロードバランサとは異なります。Google Cloud Load Balancing は、リクエストごとにバックエンド インスタンスの選択を最適化します。
グローバル外部 HTTP(S) ロードバランサ（従来）の場合、ロード バランシング モードを使用して、最も優先するバックエンド（インスタンス グループまたは NEG）を選択します。トラフィックは、ラウンドロビン方式によりバックエンド内のインスタンスまたはエンドポイント間で分散されます。
グローバル外部 HTTP(S) ロードバランサの場合、ロード バランシングは 2 層になります。分散モードでは、各バックエンド（インスタンス グループまたは NEG）に送信するトラフィックの重みまたは割合を決定します。さらに、ロード バランシング ポリシー（LocalityLbPolicy）により、グループ内のインスタンスまたはエンドポイントにトラフィックを分散する方法が決まります。詳細については、ロード バランシングの局所性ポリシー（リージョン バックエンド サービスの API ドキュメント）をご覧ください。
リージョン外部 HTTP(S) ロードバランサ
リージョン外部 HTTP(S) ロードバランサの場合、トラフィック分散はロード バランシング モードとロード バランシングの局所性ポリシーに基づきます。
分散モードでは、各グループ（インスタンス グループまたは NEG）に送信するトラフィックの重みと割合を決定します。ロード バランシングの局所性ポリシー（LocalityLbPolicy）により、グループ内のバックエンドのロード バランシング方法が決まります。
トラフィックを受信すると、バックエンド サービスはバックエンドの分散モードに従ってバックエンド（インスタンス グループまたは NEG）にトラフィックを転送します。バックエンドが選択されると、ロード バランシングの局所性ポリシーに従って、バックエンド グループ内のインスタンスまたはエンドポイント間でトラフィックが分散されます。
詳しくは以下をご覧ください。
リクエストの分散方法
トラフィックがリージョン単位で分散されるかグローバルに分散されるかは、ロードバランサ モードと Network Service Tiers がどのように使用されているかによって異なります。
プレミアム ティアの場合:
- Google は、全世界のあらゆる拠点からロードバランサの IP アドレスをアドバタイズします。各ロードバランサの IP アドレスはグローバル エニーキャストです。
- 複数のリージョンにバックエンドを持つバックエンド サービスを構成した場合、Google Front End（GFE）は、ユーザーに最も近いリージョンの正常なバックエンド インスタンス グループまたは NEG にリクエストを転送しようとします。このプロセスについては、このページで詳しく説明します。
スタンダード ティアの場合:
Google は、転送ルールのリージョンに関連付けられた接続拠点からロードバランサの IP アドレスをアドバタイズします。ロードバランサは、リージョン外部 IP アドレスを使用します。
バックエンドは、転送ルールと同じリージョンに構成できます。ここで説明するプロセスは引き続き適用されますが、ロードバランサは対象の 1 つのリージョン内に存在する正常なバックエンドにのみリクエストを転送します。
リクエストの分散プロセス:
分散モードとターゲットの選択により、各ゾーンGCE_VM_IP_PORT NEG、ゾーン インスタンス グループ、またはリージョン インスタンス グループのゾーンの観点からバックエンドの完全性が定義されます。ゾーン内の分散はグローバル外部 HTTP(S) ロードバランサ（従来）のコンシステント ハッシュで行われます。これは、グローバル外部 HTTP(S) ロードバランサとリージョン外部 HTTP(S) ロードバランサのロード バランシング局所性ポリシーを使用して構成できます。
GFE ベースのグローバル外部 HTTP(S) ロードバランサは、受信リクエストを分散するために次のプロセスを使用します。
- 転送ルールの外部 IP アドレスは、Google ネットワークの境界にあるエッジルーターによってアドバタイズされます。各アドバタイズは、レイヤ 3/4 ロード バランシング システム（Maglev）へのネクストホップを一覧表示します。
- Maglev システムは、最初のレイヤの Google Front End（GFE）にトラフィックを転送します。最初のレイヤの GFE は、必要に応じて TLS を終了し、このプロセスに従ってトラフィックを 2 番目のレイヤの GFE にルーティングします。
- URL マップでバックエンド サービスが選択されます。
- バックエンド サービスがインスタンス グループまたは
GCE_VM_IP_PORTNEG バックエンドを使用する場合、最初のレイヤの GFE は、インスタンス グループまたは NEG を含むリージョン内か、またはその近くに配置された 2 番目のレイヤの GFE を優先します。 - ハイブリッド NEG、サーバーレス NEG、インターネット NEG のバックエンド バケットとバックエンド サービスの場合、最初のレイヤの GFE は 2 番目の GFE をリージョンのサブセットで選択します。これにより、2 つの GFE 間のラウンドトリップ時間が最小化されます。
2 番目のレイヤの GFE の優先は保証されず、Google のネットワーク条件とメンテナンスに基づいて動的に変更される可能性があります。
2 番目のレイヤの GFE は、ヘルスチェックのステータスと実際のバックエンド容量の使用率を認識します。
- 2 番目のレイヤの GFE は、リージョン内のゾーンのバックエンドにリクエストを転送します。
- プレミアム ティアの場合は、2 番目のレイヤの GFE が、異なるリージョンのゾーンにあるバックエンドにリクエストを送信する可能性があります。この動作はスピルオーバーと呼ばれます。
- スピルオーバーは、2 番目のレイヤの GFE に認識されるすべてのバックエンドが容量の上限に達した場合か、正常ではない場合に可能です。
- 2 番目のレイヤの GFE には、別のリージョンのゾーンに存在する利用可能な正常なバックエンドに関する情報があります。
バックエンドにリクエストを分散する場合、GFE はゾーンレベルで動作します。
1 秒あたりのリクエスト数が少ない場合は、2 番目のレイヤの GFE がリージョン内で 1 つのゾーンを他のゾーンよりも優先する場合があります。これは、想定されている正常な設定です。ロードバランサが秒単位でより多くのリクエストを受信するまで、リージョン内のゾーン間での分散は行われません。
スピルオーバーには次の 2 つの原則が適用されます。
通常、2 番目のレイヤの GFE は、バックエンドのロケーションのサブセットを提供するように構成されています。
スピルオーバー動作は、使用可能なすべての Google Cloud ゾーンを使い切るわけではありません。特定のゾーンまたはリージョン全体のバックエンドからトラフィックを転送する必要がある場合は、容量スケーラーをゼロに設定する必要があります。ヘルスチェックに失敗するようにバックエンドを構成しても、2 番目のレイヤの GFE が別のリージョンのゾーンにバックエンドをスピルオーバーする保証はありません。
セッション アフィニティ
セッション アフィニティでは、構成した分散モードに基づいてバックエンドが良好な状態で容量があれば、特定のクライアントから同じバックエンドにリクエストを送信するための、ベストエフォート型の試行を行います。
セッション アフィニティを使用する場合は、UTILIZATION よりも RATE 分散モードを推奨します。セッション アフィニティは、分散モードが [リクエスト数/秒]（RPS）に設定されている場合に最も機能を発揮します。
HTTP(S) ロード バランシングには、次のタイプのセッション アフィニティがあります。
- なし。ロードバランサにセッション アフィニティが設定されていません。
- クライアント IP アフィニティ
- 生成された Cookie アフィニティ
- ヘッダー フィールド アフィニティ
- HTTP Cookie アフィニティ
次の表に、HTTP(S) ロード バランシングの各モードでサポートされるセッション アフィニティのオプションを示します。
| ロードバランサ モード | セッション アフィニティのオプション | ||||
|---|---|---|---|---|---|
| なし | クライアント IP | 生成された Cookie | ヘッダー フィールド | HTTP Cookie | |
| グローバル外部 HTTP(S) ロードバランサ | |||||
| グローバル外部 HTTP(S) ロードバランサ（従来） | |||||
| リージョン外部 HTTP(S) ロードバランサ | |||||
HTTP/2 サポート
HTTP/2 最大同時ストリーム数
HTTP/2 の SETTINGS_MAX_CONCURRENT_STREAMS 設定は、ピアが開始し、エンドポイントが受け入れるストリームの最大数を表します。Google Cloud ロードバランサはクライアントへのストリームを開始しないため、HTTP/2 クライアントにより Google Cloud ロードバランサにアドバタイズされた値は、事実上無意味になります。
ロードバランサが HTTP/2 を使用して、VM で実行されているサーバーと通信する場合、ロードバランサはサーバーによってアドバタイズされる SETTINGS_MAX_CONCURRENT_STREAMS 値を受け入れます。値ゼロがアドバタイズされると、ロードバランサはリクエストをサーバーに転送できないため、エラーが発生する可能性があります。
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 または Google Cloud コンソールで確認できません。gRPC エンドポイントがエラーを返した場合、ロードバランサ ログとモニタリング データに
OK 200という HTTP レスポンス コードが記録されます。
HTTP/3 と Google QUIC のサポート
HTTP/3 は次世代のインターネット プロトコルです。これは、元の Google QUIC プロトコルから開発され、IETF QUIC プロトコル上に構築されます。HTTP/3 は、外部 HTTP(S) ロードバランサ、Cloud CDN、クライアントの間でサポートされます。
特に、以下の点に注意してください。
- IETF QUIC は、TCP と同様の輻輳制御および SSL / TLS と同等のセキュリティを HTTP/2 に提供するトランスポート レイヤ プロトコルであり、パフォーマンスが向上しています。
- HTTP/3 は IETF QUIC の上に構築されたアプリケーション レイヤで、QUIC を使用して多重化、混雑制御、損失検出、再送を処理します。
- HTTP/3 では、クライアント接続の開始が迅速になり、多重化されたストリームにおけるヘッドオブライン ブロッキングがなくなるとともに、クライアントの IP アドレスが変更されたときの接続の移行がサポートされます。
- HTTP/3 はクライアントとロードバランサ間の接続に影響を与えるものの、ロードバランサとバックエンド間の接続には影響を与えません。
- HTTP/3 接続は、BBR 輻輳制御アルゴリズムを使用します。
ロードバランサで HTTP/3 を有効にすると、ウェブページの読み込み時間の改善、動画の再バッファリングの低減、レイテンシが高い接続スループットの改善が可能です。
次の表に、各モードでの HTTP(S) ロード バランシングの HTTP/3 サポートを示します。
| ロードバランサ モード | HTTP/3 サポート |
|---|---|
| グローバル外部 HTTP(S) ロードバランサ（常にプレミアム ティア） | |
| プレミアム ティアのグローバル外部 HTTP(S) ロードバランサ（従来） | |
| スタンダード ティアのグローバル外部 HTTP(S) ロードバランサ（従来） | |
| リージョン外部 HTTP(S) ロードバランサ（常にスタンダード ティア） |
HTTP/3 のネゴシエート方法
HTTP/3 が有効になっている場合、ロードバランサはこのサポートをクライアントにアドバタイズし、HTTP/3 をサポートするクライアントは HTTPS ロードバランサとの HTTP/3 接続の確立を試行できるようにします。
- 適切に実装されたクライアントは、HTTP/3 接続を確立できない場合は常に HTTPS または HTTP/2 にフォールバックします。
- HTTP/3 をサポートするクライアントは、HTTP/3 サポートのキャッシュに保存された以前の情報を使用して、将来的に不要なラウンドトリップを節約します。
- このフォールバックにより、ロードバランサで HTTP/3 を有効または無効にしても、ロードバランサのクライアントへの接続機能は中断されません。
サポートは Alt-Svc HTTP レスポンス ヘッダーでアドバタイズされます。外部 HTTP(S) ロードバランサの targetHttpsProxy リソースで HTTP/3 が ENABLE として構成されている場合、ロードバランサからのレスポンスには、次の alt-svc ヘッダー値が含まれます。
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000, h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000, quic=":443"; ma=2592000; v="46,43"
HTTP/3 が明示的に DISABLE に設定されている場合、レスポンスに alt-svc レスポンス ヘッダーは含まれません。
HTTPS ロードバランサで HTTP/3 が有効になっているときに、クライアントが HTTP/3 をネゴシエートせずに HTTPS または HTTP/2 にフォールバックすることがあります。次に例を示します。
- HTTPS ロードバランサによってサポートされている HTTP/3 バージョンと互換性のないバージョンの HTTP/3 をクライアントがサポートしている場合
- HTTP/3 が機能できない方法で、UDP トラフィックがブロックされているかレート制限されていると、ロードバランサで検出された場合
- クライアントは HTTP/3 をまったくサポートしていないため、HTTP/3 接続のネゴシエーションを試行しません。
接続が HTTPS または HTTP/2 にフォールバックした場合は、ロードバランサの障害としてカウントされません。
HTTP/3 を有効にする前に、前述の動作がワークロードに対して許容できることを確認してください。
HTTP/3 を構成する
quicOverride を ENABLE に設定することで、ロードバランサに HTTP/3 サポートを明示的に有効にできます。
HTTP/3 を有効にすると、ロードバランサはそれをクライアントにアドバタイズします。それをサポートするクライアントは、ロードバランサを使用して HTTP/3 バージョンをネゴシエートできるようになります。HTTP/3 をサポートしていないクライアントは、HTTP/3 接続のネゴシエートを行いません。破損しているクライアント実装が特定されている場合を除き、HTTP/3 を明示的に無効にする必要はありません。
HTTP(S) ロード バランシングには、次の表に示すように HTTP/3 を構成する方法が 3 つあります。
| quicOverride 値 | 動作 |
|---|---|
NONE |
HTTP/3 のサポートはクライアントにアドバタイズされます。 |
ENABLE |
HTTP/3 と Google QUIC のサポートは、クライアントにアドバタイズされています。HTTP/3 はより高い優先度でアドバタイズされます。両方のプロトコルをサポートするクライアントは、Google QUIC ではなく HTTP/3 を使用する必要があります。 注: TLS 0-RTT（別名 TLS 早期データ）は、クライアントが Google QUIC によってネゴシエートされた場合に暗黙的にサポートされますが、HTTP/3 が使用されている場合はサポートされません。 |
DISABLE |
クライアントへの HTTP/3 と Google QUIC のアドバタイジングを明示的に無効にします。 |
HTTP/3 を明示的に有効または無効にする手順は次のとおりです。
Console: HTTPS
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
編集するロードバランサを選択します。
[フロントエンドの構成] をクリックします。
編集するフロントエンドの IP アドレスとポートを選択します。HTTP/3 の構成を編集するには、IP アドレスとポートが HTTPS（ポート 443）である必要があります。
HTTP/3 を有効にする
- [QUIC ネゴシエーション] プルダウンを選択します。
- このフロントエンドで HTTP/3 を明示的に有効にするには、[有効] を選択します。
- IPv4 と IPv6 を表す複数のフロントエンド ルールが存在する場合は、各ルールで HTTP/3 を有効にします。
HTTP/3 を無効にする
- [QUIC ネゴシエーション] プルダウンを選択します。
- このフロントエンドの HTTP/3 を明示的に無効にするには、[無効] を選択します。
- IPv4 と IPv6 を表す複数のフロントエンド ルールが存在する場合は、ルールごとに HTTP/3 を無効にします。
gcloud: HTTPS
次のコマンドを実行する前に、SSL 証明書ごとにそのリソースを作成する必要があります。
gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
--global \
--quic-override=QUIC_SETTING
QUIC_SETTING を次のいずれかに置き換えます。
NONE（デフォルト）: HTTP/3 がアドバタイズされるタイミングを Google が制御できるようにします。現在、
NONEを選択すると、HTTP/3 はクライアントにアドバタイズされますが、Google QUIC はアドバタイズされません。Google Cloud コンソールでは、このオプションは [自動（デフォルト）] と表示されます。
ENABLE: HTTP/3 と Google QUIC をクライアントにアドバタイズします。DISABLE: HTTP/3 または Google QUIC をクライアントにアドバタイズしません。
API: HTTPS
POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride
{
"quicOverride": QUIC_SETTING
}
QUIC_SETTING を次のいずれかに置き換えます。
NONE（デフォルト）: HTTP/3 がアドバタイズされるタイミングを Google が制御できるようにします。現在、
NONEを選択すると、HTTP/3 はクライアントにアドバタイズされますが、Google QUIC はアドバタイズされません。Google Cloud コンソールでは、このオプションは [自動（デフォルト）] と表示されます。
ENABLE: HTTP/3 と Google QUIC をクライアントにアドバタイズします。DISABLE: HTTP/3 または Google QUIC をクライアントにアドバタイズしません。
制限事項
- HTTPS ロードバランサは、クライアント証明書ベースの認証（別名: 相互 TLS 認証）をサポートしていません。
- HTTPS ロードバランサは、SSL 接続を終了する際に
close_notify終了アラートを送信しません。つまり、ロードバランサは SSL シャットダウンを実行する代わりに、TCP 接続を閉じます。 - HTTPS ロードバランサでは、証明書の共通名（
CN）属性またはサブジェクト代替名（SAN）属性に含まれるドメインで小文字のみがサポートされます。ドメイン名に大文字を含む証明書は、ターゲット プロキシでプライマリ証明書として設定されている場合にのみ返されます。 - HTTPS ロードバランサは、インターネット NEG バックエンド対応のロードバランサを除き、バックエンドへの接続時に Server Name Indication（SNI）拡張機能を使用しません。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。
- 共有 VPC 環境の Cloud Run でリージョン外部 HTTP(S) ロードバランサを使用する場合、サービス プロジェクトのスタンドアロン VPC ネットワークは、同じ共有 VPC 環境内の他のサービス プロジェクトにデプロイされた他の Cloud Run サービスにトラフィックを送信できます。これは既知の問題であり、この形式のアクセスは今後ブロックされます。
- WAF 用の reCAPTCHA Enterprise と Google Cloud Armor の統合は、グローバル外部 HTTP(S) ロードバランサ（従来）でのみサポートされています。高度なトラフィック管理機能を備えたグローバル外部 HTTP(S) ロードバランサではサポートされていません。
次のステップ
- 外部 HTTP(S) ロードバランサをデプロイする方法については、Compute Engine バックエンドがある外部 HTTP(S) ロードバランサの設定をご覧ください。
- リージョン外部 HTTP(S) ロードバランサをデプロイする方法については、Compute Engine バックエンドがあるリージョン外部 HTTP(S) ロードバランサの設定をご覧ください。
- グローバル外部 HTTP(S) ロードバランサ（従来）の既存のユーザーで、グローバル外部 HTTP(S) ロードバランサで新しいデプロイを計画する場合は、グローバル外部 HTTP(S) ロードバランサへの移行を計画するをご覧ください。
- Terraform を使用して外部 HTTP(S) ロード バランシングの設定を自動化する方法については、外部 HTTP(S) ロードバランサの Terraform モジュールの例をご覧ください。
- グローバル外部 HTTP(S) ロードバランサで使用可能な高度なトラフィック管理機能を構成する方法については、グローバル外部 HTTP(S) ロードバランサのトラフィック管理の概要をご覧ください。
- リージョン外部 HTTP(S) ロードバランサで使用可能な高度なトラフィック管理機能を構成する方法については、リージョン外部 HTTP(S) ロードバランサのトラフィック管理の概要をご覧ください。
- Google PoP のロケーションを確認するには、GFE のロケーションをご覧ください。
- 容量管理については、「ロード バランシングによる処理能力の管理」チュートリアルとグローバル ロード バランシングによるアプリケーションの処理能力の改善をご覧ください。
- ウェブサイトの提供について詳しくは、ウェブサイトの提供をご覧ください。
- Certificate Manager を使用して SSL 証明書をプロビジョニングして管理する方法については、Certificate Manager の概要をご覧ください。