HTTP(S) 負荷分散の設定

Google Cloud Platform(GCP)の HTTP(S) 負荷分散は、インスタンスの HTTP(S) リクエストに対してグローバルな負荷分散を提供します。あるセットのインスタンスに一部の URL をルーティングし、別のインスタンスには別の URL をルーティングする URL ルールを構成できます。インスタンス グループに十分な容量があり、リクエストに対して適切である場合、ユーザーの最寄りのインスタンス グループに対してリクエストが常にルーティングされます。最寄りのグループに十分な容量がない場合は、容量が十分ある最寄りのグループにリクエストが送信されます。

HTTP(S) 負荷分散は、IPv4 アドレスと IPv6 アドレスのクライアント トラフィックに対応しています。クライアントの IPv6 リクエストはグローバル負荷分散層で終了し、IPv4 経由でバックエンドに送信されます。

HTTP リクエストは、ポート 80 またはポート 8080 に基づいて負荷分散を行えます。HTTPS リクエストはポート 443 で負荷分散を行えます。

ロードバランサは HTTP/2 から HTTP/1.1 への変換層として機能します。これは、ウェブサーバーが HTTP/1.1 リクエストを常に確認し、これにレスポンスするが、ブラウザからのリクエストは、HTTP/1.0、HTTP/1.1、HTTP/2 のいずれかとなることを意味します。HTTP/2 サーバー push はサポートされていません。

始める前に

HTTP(S) 負荷分散はインスタンス グループを使用してインスタンスを分類します。負荷分散を使用する前にインスタンス グループについて理解しておく必要があります。

構成例

右側に移動して、テスト用の実行ロードバランサを構築する場合は、以下のガイドが、HTTP(S) 負荷分散サービスを使用する、2 つの異なるシナリオになります。これらのシナリオには HTTP(S) 負荷分散の実用的なコンテキストが用意され、固有のニーズに適合する負荷分散をセットアップする方法を示しています。

このページの残りの部分は、ロードバランサを構築、作動させる方法に関して、より詳細に掘り下げます。

リージョンにまたがるロードバランサの作成

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

グローバル IP アドレスを使用することで、近い距離にいるユーザーにトラフィックがインテリジェントにルーティングされるようになります。たとえば、アジア、北米、欧州に十分な容量を持つインスタンスを設定しておけば、世界中のどのユーザーも、それぞれに最も近いバックエンドで自動的にトラフィックを受信できます。最も近いインスタンスに十分な容量がない場合は、リージョン間負荷分散によって、次に最も近いリージョンにトラフィックが転送されます。

リージョン間負荷分散の使用


コンテンツ ベースのロードバランサの作成

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

コンテンツ ベースまたはコンテンツ対応の負荷分散は、HTTP(S) 負荷分散を使用して、受信 HTTP(S) URL に基づく別のインスタンスにトラフィックを分散します。たとえば、一部のインスタンスを動画コンテンツを処理するようにセットアップし、別のインスタンスでその他を処理するように設定することができます。example.com/video のトラフィックを動画サーバーに、example.com/ をデフォルトのサーバーにそれぞれ振り向けるようにロードバランサを構成できます。

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

HTTP(S) 負荷分散は、Google Cloud Storage バケットにも使用できます。コンテンツ ベースのロードバランサを設定すると、ロードバランサに Cloud Storage バケットを追加できます。


複数のバックエンド サービスとリージョンを使用することで、コンテンツ ベースの負荷分散とリージョン間負荷分散を相互に連携して利用できます。上記のシナリオとは別に、個々のニーズに適した負荷分散を構成できます。

基礎知識

HTTP(S) ロードバランサは複数のコンポーネントで構成されています。次の図は、HTTP(S) ロードバランサ全体の構造を示しています。

クロスリージョン負荷分散プログラム(クリックで拡大)

以下のセクションで、ロードバランサの各タイプを設定するために、コンポーネントがそれぞれどのように連携しているかについて説明します。各コンポーネントの詳細については、以下のコンポーネントをご覧ください。

HTTP 負荷分散

HTTP ロードバランサ全体は次のように構成されます。

  1. グローバル転送ルールは受信リクエストをターゲット HTTP プロキシに振り向けます。
  2. ターゲット HTTP プロキシは各リクエストを URL マップと照合し、そのリクエストに適したバックエンド サービスを決定します。
  3. バックエンド サービスは、サービスに関連するバックエンドの提供容量、ゾーン、インスタンスの正常性に基づき、適切なバックエンドに各リクエストを振り向けます。各バックエンド インスタンスの正常性は、HTTP ヘルスチェック、HTTPS ヘルスチェック、HTTP/2 ヘルスチェックで検証されます。バックエンド サービスが HTTPS または HTTP/2 ヘルスチェックを使用するように構成されていると、リクエストは暗号化されてバックエンド インスタンスに届きます。
  4. ロードバランサとインスタンス間のセッションでは、HTTP、HTTPS、HTTP/2 プロトコルを使用できます。HTTPS または HTTP/2 を使用する場合は、バックエンド サービスの各インスタンスが SSL 証明書を持つ必要があります。

HTTPS 負荷分散

HTTPS ロードバランサの構造は、上述の HTTP ロードバランサと基本的には同じですが、次の点が異なります。

  • HTTPS ロードバランサは、ターゲット HTTP プロキシではなくターゲット HTTPS プロキシを使用します。
  • HTTPS ロードバランサでは、ロードバランサのターゲット HTTPS プロキシに署名済みの SSL 証明書が少なくとも 1 つインストールされている必要があります。
  • クライアント SSL セッションはロードバランサで終端します。
  • HTTPS ロードバランサでは、QUIC トランスポート レイヤ プロトコルがサポートされます。

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

  • クライアントは、HTTP 1.1 または HTTP/2 プロトコルを使用してロードバランサと通信できます。
  • HTTPS を使用すると、最近のクライアントはデフォルトで HTTP/2 になります。これは、グローバルな HTTPS ロードバランサではなくクライアント上で制御されます。
  • ロードバランサ自体の構成を変更することで、HTTP/2 を無効にすることはできません。ただし、一部のクライアントは、HTTP/2 ではなく HTTP 1.1 を使用するように構成できます。たとえば、curl では --http1.1 パラメータを使用します。

コンポーネント

グローバル転送ルールとアドレス

グローバル転送ルールは、トラフィックを IP アドレス、ポート、プロトコル別に、ターゲット プロキシと URL マップ、1 つ以上のバックエンドで構成される負荷分散構成にルーティングします。

各グローバル転送ルールは、使用するアプリケーションの DNS レコードで使用できる単一のグローバル IP アドレスを提供します。DNS ベースの負荷分散は必要ありません。使用対象の IP アドレスを指定するか、Google Compute Engine を利用して使用する IP アドレスを割り当てることができます。

ターゲット プロキシ

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

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

  • Via: 1.1 google(リクエストとレスポンス)
  • X-Forwarded-Proto: [http | https](リクエストのみ)
  • X-Forwarded-For: <unverified IP(s)>, <immediate client IP>, <global forwarding rule external IP>, <proxies running in GCP> (リクエストのみ)
    リクエストが経由する中間経路で追加される IP アドレスのカンマ区切りのリスト。X-Forwarded-For ヘッダーにデータを追加するプロキシを GCP 内で実行している場合、使用するソフトウェアでそれらのプロキシの存在と数を考慮する必要があります。<immediate client IP> と <global forwarding rule external IP> の項目のみがロードバランサによって提供されます。リスト内のその他のすべての項目は検証されずに通過します。<immediate client IP> の項目は、ロードバランサに直接属するクライアントです。<global forwarding rule external IP> の項目は、ロードバランサの転送ルールの外部 IP アドレスです。それよりも項目が多い場合、リスト内の最初の項目が元のクライアントのアドレスになります。<immediate client IP> より前の項目は、ロードバランサにリクエストを転送する他のプロキシを表します。
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (リクエストのみ)
    Stackdriver Trace のパラメータ。

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

URL マップ

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

SSL 証明書

HTTPS 負荷分散を使用する場合は、ターゲット HTTPS プロキシに 1 つ以上の SSL 証明書をインストールする必要があります。最大 10 個の SSL 証明書をインストールできます。これらの証明書は、ロードバランサとクライアント間の通信を認証するためにターゲット HTTPS プロキシによって使用されます。

SSL 証明書のインストールについて詳しくは、SSL 証明書をご覧ください。

ロードバランサからバックエンドの間で HTTPS または HTTP/2 を使用する場合は、各 VM インスタンスに SSL 証明書をインストールする必要があります。VM インスタンスに SSL 証明書をインストールするには、ご使用のアプリケーションのドキュメントに記載された指示に従ってください。これらの証明書は、自己署名にすることができます。

SSL ポリシー

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

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

バックエンド サービス

バックエンド サービスによって、受信トラフィックが 1 つ以上の関連バックエンドに振り向けられます。各バックエンドは、1 つのインスタンス グループと、追加の提供容量メタデータから構成されます。バックエンド提供容量は、CPU または秒あたりのリクエスト数(RPS)に基づいて設定できます。

各バックエンド サービスは、使用可能なインスタンスに対して実行されるヘルスチェックも指定します。

HTTP(S) 負荷分散は、Compute Engine Autoscaler をサポートします。これで、ユーザーがバックエンド サービスのインスタンス グループで自動スケーリングを実行することができます。詳細については、HTTP 負荷分散提供容量に基づくスケーリングをご覧ください。

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

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

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

バックエンド VM に対して HTTP/2 を使用する場合は、HTTP/2 ヘルスチェックを使用します。

Google Cloud Platform アプリケーションでの gRPC の使用

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

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

Google Cloud Platform アプリケーションで 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 経由でバックエンド インスタンスにプロキシされます。

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

バックエンド バケット

バックエンド バケットは、受信トラフィックを Google Cloud Storage バケットに振り向けます。既存のロードバランサにバケットを追加する例については、Cloud Storage バケットをコンテンツベースの負荷分散に追加するをご覧ください。

ファイアウォール ルール

130.211.0.0/2235.191.0.0/16 からのトラフィックがインスタンスに到達することを許可するファイアウォール ルールを作成する必要があります。これらは、ロードバランサがバックエンド インスタンスへの接続に使用する IP アドレス範囲です。このルールは、ロードバランサとヘルス チェッカーの両方からのトラフィックを許可します。このルールでは、グローバル転送ルールで使用するよう構成されているポート上のトラフィックを許可する必要があります。また、ヘルス チェッカーでも同じポートを使用するように構成することを推奨します。ヘルス チェッカーが異なるポートを使用している場合には、このポート用に別のファイアウォール ルールを作成する必要があります。

ファイアウォール ルールは、ネットワークのエッジではなく、インスタンス レベルでトラフィックのブロックまたは許可を行います。ロードバランサ自体へのトラフィックはブロックできません。

ある特定の時点での外部 IP アドレスを調べる必要がある場合は、Google Compute Engine のよくある質問の手順に従ってください。

負荷分散アルゴリズム

HTTP(S) 負荷分散には、インスタンスのロードの設定方法として 2 つの方法が用意されています。バックエンド サービス オブジェクトの balancingMode プロパティは、1 秒あたりのリクエスト数(RPS)モードと CPU 使用率モードのどちらかを選択します。どちらのモードも最大値を指定できるようになっています。HTTP ロードバランサは、ロードを制限値よりも低く抑えようとしますが、フェイルオーバー イベントまたはロードスパイク イベント中に制限値を超えたショート バーストが発生する場合があります。

受信リクエストは、容量が残っていれば、ユーザーの最寄りのリージョンに送信されます。1 つのリージョンのバックエンドで複数のゾーンが構成されている場合は、各ゾーンのインスタンス グループに、各グループの容量に応じてトラフィックが分散されます。ゾーン内ではラウンドロビン アルゴリズムを使用して、リクエストがインスタンスを越えて均等に分散されます。ラウンドロビン分散はセッション アフィニティを構成してオーバーライドできます。

セッション アフィニティ

セッション アフィニティを設定すると、インスタンスが正常で容量が十分ある限り、同じクライアントからのすべてのリクエストが同じ仮想マシンのインスタンスに送信されます。

GCP HTTP(S) 負荷分散には次の 2 つの種類のセッション アフィニティが用意されています。

WebSocket プロキシ サポート

HTTP(S) ロードバランサは、WebSocket プロトコルをネイティブでサポートしています。WebSocket を使用してクライアントと通信を行うバックエンドは、HTTP(S) ロードバランサをフロントエンドで使用し、スケーリングと可用性を向上させることができます。ロードバランサに、WebSocket 接続のプロキシを構成する必要はありません。

WebSocket プロトコルは RFC 6455 で定義され、クライアントとサーバー間で全二重の通信チャネルを提供します。このチャネルは HTTP(S) リクエストから開始します。

HTTP(S) ロードバランサが HTTP(S) クライアントからの WebSocket アップグレード リクエストを認識し、バックエンド インスタンスからアップグレード成功のレスポンスが返されると、現在の接続期間中、ロードバランサが両方向のトラフィックのプロキシとして機能します。バックエンドからアップグレード成功のレスポンスが返されないと、ロードバランサが接続を終了します。

WebSocket 接続のタイムアウトは、ロードバランサの構成可能なレスポンス タイムアウトによって異なります。デフォルトは 30 秒です。このタイムアウトは、その接続が使用されているかどうかにかかわらず、すべての WebSocket 接続に適用されます。レスポンス タイムアウトとその構成方法について詳しくは、タイムアウトと再試行をご覧ください。

HTTP(S) ロードバランサに対してクライアント IP または生成された Cookie セッション アフィニティを構成している場合は、バックエンド インスタンスがヘルスチェックに合格し、その処理能力に余裕がある限り、クライアントからのすべての WebSocket 接続が同じバックエンド インスタンスに送信されます。

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

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

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

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

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

QUIC オーバーライドを指定しない場合、QUIC がいつ使用されるかを Google が管理できます。オーバーライドが指定されていないと、Google は 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 を有効にする前に、上記の動作がワークロードに対して許容できることを確認してください。

インターフェース

HTTP(S) 負荷分散サービスは、次のインターフェースを通じて構成および更新できます。

  • gcloud コマンドライン ツール: Cloud SDK に含まれているコマンドライン ツール。HTTP(S) 負荷分散のドキュメントでは、タスクの実行時にこのツールをよく利用します。ツールの完全な概要については、gcloud ツールガイドをご覧ください。負荷分散に関連するコマンドについては、gcloud compute コマンド グループをご覧ください。

    すべての gcloud コマンドでは、--help フラグを使用して詳細なヘルプを表示できます。

    gcloud compute http-health-checks create --help
    
  • Google Cloud Platform Console: 負荷分散タスクは、Google Cloud Platform Console から実行できます。

  • REST API: すべての負荷分散タスクは Google Compute Engine API を使用して実行できます。使用可能なリソースとメソッドについては、API リファレンス ドキュメントをご覧ください。

TLS サポート

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

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

タイムアウトと再試行

HTTP(S) 負荷分散には次の 2 種類のタイムアウトがあります。

  • 構成可能なレスポンス タイムアウト。これはロードバランサがバックエンドからの完全なレスポンスの返送を待機する時間の長さを表します。アイドル(キープアライブ)タイムアウトではありません。このタイムアウトを構成するには、バックエンド サービスのタイムアウト設定を変更します。デフォルト値は 30 秒です。次の場合は、このタイムアウトを長くすることを検討してください。

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

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

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

HTTP(S) 負荷分散は、レスポンス タイムアウトに達したときなど、特定の状況で失敗した GET リクエストを再試行します。失敗した POST リクエストは再試行されません。再試行回数は 2 回に制限されています。再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。詳しくは、ロギングをご覧ください。

不正なリクエスト処理

HTTP(S) ロードバランサは、いくつかの理由により、クライアントのリクエストがバックエンドに到達しないようにブロックします。その一部は HTTP/1.1 適合のために厳密であり、それ以外は、予期しないデータがバックエンドに渡されることを回避するためです。

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

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

また、ロードバランサは、以下のいずれかが真の場合にも、リクエストをブロックします。

  • リクエスト URL とヘッダーの組み合わせが 15 キロバイトより長い。
  • リクエスト メソッドは本文を許可しないが、リクエストに本文がある。
  • リクエストにアップグレード ヘッダーが含まれている。
  • HTTP のバージョンが不明。

ロギング

各 HTTP(S) リクエストは、一時的に Stackdriver Logging によって記録されます。アルファ版のテスト段階で導入されている場合、ログは自動的に行われ、有効にする必要はありません。

ログの表示方法

ログを表示するには、ログビューアに移動します。

HTTP(S) ログはまず転送ルールでインデックス化され、次に URL マップでインデックス化されます。

  • すべてのログを表示するには、最初のプルダウン メニューで [Cloud HTTP ロードバランサ] > [すべての forwarding_rule_name] の順に選択します。
  • 転送ルールを 1 つだけ確認するには、一覧から単一の転送ルール名を選択します。
  • 転送ルールで使用される 1 つの URL マップのログだけを確認するには、転送ルールをハイライト表示して、必要な URL マップを選択します。

通常、ブール型のログフィールドは、フィールドの値が true の場合にのみ表示されます。ブール フィールドの値が false の場合、そのフィールドはログから省略されます。

ログフィールドには UTF-8 エンコードが適用されます。UTF-8 文字以外の文字は、疑問符に置き換えられます。

Cloud HTTP(S) ロードバランサ リソースログ(resource.type=http_load_balancer)の Stackdriver ログベースの指標のエクスポートを構成できます。作成される指標は、「Google Cloud HTTP 負荷分散ルール(ログベースの指標)」リソース(l7_lb_rule)に基づきます。これは、https_lb_rule リソースではなく Stackdriver Monitoring ダッシュボードで使用できます。

ログの内容

HTTP(S) 負荷分散ログエントリには、HTTP(S) トラフィックのモニタリングおよびデバッグに役立つ情報が含まれています。ログエントリには次のタイプの情報が含まれています。

  • 重大度、プロジェクト ID、プロジェクト番号、タイムスタンプなど、ほとんどの GCP ログで表示される一般情報。
  • HttpRequest ログフィールド。ただし、HTTP(S) 負荷分散 Stackdriver ログでは HttpRequest.protocol にはデータは入力されません。
  • トレース ID とスパン ID は、バックエンドに送信された X-Cloud-Trace-Context からログに記録されます。trace フィールドは「projects/[PROJECT_ID]/traces/[TRACE_ID]」としてフォーマットされます。spanId フィールドはスパン ID 値ですが、16 文字の 16 進文字列としてフォーマットされます。
  • structPayload 内の statusDetails フィールド。このフィールドは、ロードバランサが行った、HTTP のステータスを戻した理由を説明する文字列を保持しています。以下のテーブルには、これらのログの文字列の詳しい説明が記載されています。

statusDetail HTTP 正常終了メッセージ

statusDetails(正常終了) 意味 共通のレスポンス コード
byte_range_caching HTTP リクエストがバイト範囲キャッシュを使用して提供されました。 任意のキャッシュ可能なレスポンス コード
response_from_cache HTTP リクエストがキャッシュから提供されました。 任意のキャッシュ可能なレスポンス コード
response_from_cache_validated リターンコードは、バックエンドによって検証されたキャッシュ済みエントリから設定されました。 任意のキャッシュ可能なレスポンス コード
response_sent_by_backend HTTP リクエストは、バックエンドに正常にプロキシされました。 VM バックエンドからの戻り値(任意のレスポンス コード)

statusDetail HTTP 異常終了メッセージ

statusDetails(異常終了) 意味 共通のレスポンス コード
aborted_request_due_to_backend_early_response 本文付きリクエストは、エラーコード付き早期レスポンスを送信するバックエンドのために、中止されました。レスポンスはクライアントに転送されました。リクエストは終了しました。 4XX または 5XX
backend_503_propagated_as_error バックエンドは、ロードバランサが再試行でから回復することができないことを意味する 503 を送信しました。 503
backend_connection_closed_after_partial_response_sent バックエンドの接続は、クライアントに部分的レスポンスが送られた後、予期せず閉じました。 VM バックエンドからの戻り値(任意のレスポンス コード)。0 は、バックエンドが完全なレスポンス ヘッダーを送信していないことを意味します。
backend_connection_closed_before_data_sent_to_client バックエンドは、レスポンスがクライアントにプロキシされる前に、予期せずロードバランサへの接続を閉じました。これは、VM インスタンス上で動作するサードパーティのロードバランサなど別のエンティティにロードバランサがトラフィックを送信していて、そのエンティティの TCP タイムアウトが HTTP ロードバランサのタイムアウトである 10 分(600 秒)よりも短い場合に発生します。手動でターゲット サービスの TCP タイムアウト(キープアライブ)を 600 秒よりも大きな値に設定することで、問題が解決する可能性があります。 502
backend_early_response_with_non_error_status バックエンドは、リクエスト本文全体を受信する前に、リクエストに対するエラー以外のレスポンス(1XX または 2XX)を送信しました。 502
backend_response_corrupted バックエンドによって送信された HTTP レスポンス本文は、チャンクされた転送エンコードが無効であったか、そうでなければ破壊されています。 任意のレスポンス コード。破損の特性によって異なります。多くの場合、502 です。
backend_timeout バックエンドは、レスポンスを生成中にタイムアウトしました。 502
body_not_allowed クライアントは、本文付き HTTP リクエストが送信しましたが、使用される HTTP メソッドは本文を許可していません。 400
byte_range_caching_aborted ロードバランサは、すでにクライアントに送信された部分レスポンスと一致しないバイト範囲レスポンスを送信元サーバーが送信したため、レスポンスを中止しました。これは、一部の VM インスタンスが、同じリソースの他のインスタンスと異なる ETag ヘッダーまたは Last-Modified ヘッダーを返すことによって発生する可能性があります。 2XX
cache_lookup_failed_after_partial_response ロードバランサは、内部エラーのため、キャッシュから完全なレスポンスを提供することができませんでした。 2XX
client_disconnected_after_partial_response ロードバランサが部分的レスポンスを送信した後で、クライアントへの接続が切断されました。 VM バックエンドからの戻り値(任意のレスポンス コード)
client_disconnected_before_any_response ロードバランサが、何らのレスポンスも送信する前に、クライアントへの接続が切断されました。 0
client_timed_out ロードバランサは、要求またはレスポンスのいずれかをプロキシ処理する間に、進捗がないため、クライアント接続をアイドル状態にしました。 0
error_uncompressing_gzipped_body gzip で圧縮された HTTP レスポンスの解凍エラーが発生しました。 503
failed_to_connect_to_backend ロードバランサは、バックエンドに接続できませんでした。 502
failed_to_pick_backend ロードバランサは、リクエストを処理するための正常なバックエンドを選択することができませんでした。 502
headers_too_long リクエスト ヘッダーが、許容最大値より大きいです。 413
http_version_not_supported サポートされていない HTTP バージョンです。現状、HTTP 0.9、1.0、1.1、2.0 のみがサポートされます。 400
http2_server_push_canceled_invalid_response_code ロードバランサは、バックエンドが無効なレスポンス コードを返したため、HTTP/2 サーバーの push をキャンセルしました。 http2 を使用してバックエンドに接続している場合にのみ発生。クライアントは、INTERNAL_ERROR を含む RST_STREAM を受信します。
internal_error ロードバランサの内部エラーです。 400
invalid_http2_client_header_format クライアントからの HTTP/2 ヘッダーが無効です。 400
malformed_chunked_body リクエストの本文のチャンク エンコードが不適切です。 411
required_body_but_no_content_length HTTP リクエストは本文を要求していますが、リクエスト ヘッダーにコンテンツ長が含まれていないか、または転送エンコーディングされたチャンク形式ヘッダーです。 400 または 403
secure_url_rejected https:// URL 付きのリクエストが、プレーン テキスト HTTP/1.1 接続を介して受信されました。 400
unsupported_method クライアントは、指名されていない HTTP リクエスト メソッドを指定しました。 400
upgrade_header_rejected クライアントの HTTP リクエストにはアップグレード ヘッダーが含まれ、拒否されました。 400
uri_too_long HTTP リクエスト URI が許容最大長を超えていました。 414
websocket_closed WebSocket 接続が切断されました。
websocket_handshake_failed WebSocket がハンドシェイクできませんでした。 501

IP ブラックリスト / ホワイトリストのロギング

ログビューアの次のログエントリは、HTTP(S) IP ブラックリスト / ホワイトリストのロギング用で、jsonPayload の次の構造が含まれます。HTTP リクエストの詳細は、httpRequest メッセージに表示されます。

  • status_details(文字列) - レスポンス コードのテキスト記述
  • enforced_security_policy - 実際に適用されたセキュリティ ポリシー ルール
    • outcome(文字列) - ACCEPTDENYUNKNOWN_OUTCOME
    • configured_action(文字列) - outcome と同じ
    • name(文字列) - セキュリティ ポリシーの名前
    • priority(数値) - 一致するルールの優先度
  • preview_security_policy - リクエストがプレビュー用に構成されたルールに該当した場合に構成されます(プレビュー ルールが適用済みのルールよりも優先される場合にのみ表示されます)
    • outcome(文字列) - ACCEPTDENYUNKNOWN_OUTCOME
    • configured_action(文字列) - outcome と同じ
    • name(文字列) - セキュリティ ポリシーの名前
    • priority(数値) - 一致するルールの優先度

Stackdriver Logging API を使用して、HTTP(S) ロードバランサのログを操作できます。この Logging API は、特定のフィールドが設定されたログをインタラクティブにフィルタし、一致するログを Stackdriver Console、Google Cloud Storage、BigQuery、Cloud Pub/Sub にエクスポートする方法を提供します。Stackdriver Logging API の詳細については、ログの表示をご覧ください。

モニタリング

HTTP(S) 負荷分散は、モニタリング データを Stackdriver にエクスポートします。モニタリング指標は、HTTP(S) ロードバランサの構成、使用率、およびパフォーマンスを評価したり、問題をトラブルシュートしたり、リソースの使用率やユーザー エクスペリエンスを向上させるために使用できます。

Stackdriver の事前に定義されたダッシュボードに加えて、カスタム ダッシュボードを作成して、アラートをセットアップし、Stackdriver Monitoring API を通して指標を照会することができます。

Stackdriver Monitoring ダッシュボードの表示

  1. Google Cloud Platform Console で Stackdriver にアクセスします。
    Stackdriver に移動
  2. [Resources] > [Google Cloud Load Balancers] を選択します。
  3. ロードバランサの名前をクリックします。

左側のペインでは、この HTTP(S) ロードバランサのさまざまな詳細を確認できます。右側のペインでは時系列のグラフを表示できます。[Breakdowns] リンクをクリックすると、特定の内訳が表示されます。

Stackdriver アラートの定義

Stackdriver アラートは、さまざまな HTTP(S) 負荷分散指標に基づいて定義できます。

  1. Google Cloud Platform Console で Stackdriver にアクセスします。
    Stackdriver に移動
  2. [Alerting] > [Create a Policy] を選択します。
  3. [Add Condition] をクリックし、条件タイプを選択します。
  4. 指標とフィルタを選択します。指標のリソースタイプは HTTP(S) Load Balancer です。
  5. [Save Condition] をクリックします。
  6. ポリシー名を入力し、[Save Policy] をクリックします。

Stackdriver カスタム ダッシュボードの定義

HTTP(S) 負荷分散指標に基づくカスタム Stackdriver ダッシュボードを作成することができます。

  1. Google Cloud Platform Console で Stackdriver にアクセスします。
    Stackdriver に移動
  2. [Dashboards] > [Create Dashboard] を選択します。
  3. [Add Chart] をクリックします。
  4. グラフにタイトルを付けます。
  5. 指標とフィルタを選択します。指標のリソースタイプは HTTP(S) Load Balancer です。
  6. [Save] をクリックします。

指標報告の頻度と保持

HTTP(S) ロードバランサの指標は、1 分単位のバッチで Stackdriver にエクスポートされます。モニタリング データは 6 週間保持されます。ダッシュボードは、1H、6H、1D、1W、および 6W のデフォルト間隔のデータ分析を提供します。6W から 1 分までの任意の間隔で手動で分析を要求できます。

HTTP(S) ロードバランサのモニタリング指標

HTTP(S) ロードバランサの次の指標が Stackdriver に報告されます。

指標 説明
リクエスト数 HTTP(S) ロードバランサによって処理されるリクエストの数
リクエスト バイト数 ユーザーから HTTP(S) ロードバランサにリクエストとして送信されたバイト数
レスポンス バイト数 HTTP(S) ロードバランサからユーザーにレスポンスとして送信されたバイト数
総レイテンシ ロードバランサ プロキシが最初のリクエスト バイトを受信してから、最後のレスポンス バイトで要求側のクライアントからの ACK を受信するまでのレイテンシの分布。総レイテンシはリクエスト / レスポンスによって測定されるので、`Connection:keep-alive` を使った同じ接続上のリクエスト間の休止は測定に影響しません。通常、Stackdriver ビューでは 95 パーセンタイルに縮小されます。
例: ロードバランサが、英国から 1 秒間に 1 件のリクエスト(全部で 100 ms のレイテンシ)と、米国から 1 秒間に 9 件のリクエスト(全部で 50 ms のレイテンシ)を処理しています。1 分間では、英国から 60 件、米国から 540 件のリクエストが発生することになります。モニタリング指標には、すべてのディメンションにわたる分散が保存されます。この場合、以下を要求することができます。
  • 平均全体レイテンシ(300/600) - 50ms
  • 平均英国レイテンシ(30/60) - 100ms
  • 95 パーセンタイル全体レイテンシ(570/600) - 100ms
  • その他
フロントエンド RTT(*) クライアントとプロキシ間の接続ごとに測定された平滑化された RTT の分布(プロキシの TCP スタックによって測定)。通常、Stackdriver ビューでは 95 パーセンタイルに縮小されます。
バックエンド レイテンシ(*) プロキシがバックエンドに最初のリクエスト バイトを送信してから、バックエンドから最後のレスポンス バイトを受信するまでのレイテンシの分布。通常、Stackdriver ビューでは 95 パーセンタイルに縮小されます。
レスポンス コード クラス比 各レスポンス コード クラス(2XX、4XX、...)に含まれている HTTP(S) ロードバランサ レスポンスの総数の割合。Stackdriver では、この値をデフォルト ダッシュボード経由でしか取得できません。カスタム ダッシュボードでは取得できません。それに関するアラートを API 経由で設定できます。

(*)フロントエンド RTT とバックエンド レイテンシの合計が総レイテンシ以下であるという保証はありません。これは、HTTP レスポンスが ACK された時点でプロキシからクライアントへのソケット上の RTT をポーリングしますが、これらの測定値の一部をカーネルからの報告に依存しており、指定した HTTP レスポンスの RTT 測定値がカーネルで保持されていることを保証できないためです。最終結果は、現在の HTTP リクエストの実際のタイミングに影響を与えない過去の HTTP レスポンス、SYN / ACK、および SSL ハンドシェイクの影響も受ける、平滑化された RTT 値です。

HTTP(S) ロードバランサ指標のディメンションのフィルタ処理

指標は、HTTP(S) ロードバランサごとに集計されます。集計された指標は、次のディメンション(*)でフィルタ処理することができます。

特性 説明
BACKEND SCOPE 接続を処理したバックエンド サービスのインスタンス グループの GCP スコープ(リージョンまたはゾーン)。

使用可能なインスタンス グループが存在しない場合やリクエストが別のエンティティによって処理された場合は、バックエンド サービスのインスタンス グループのリージョンまたはゾーンではなく、次の値のいずれかが表示されます。
  • FRONTEND_5XX - 内部エラーまたは健全なバックエンドの不足が原因で、プロキシがインスタンス グループをリクエストに割り当てることができませんでした。代わりに、プロキシは要求者に 5xx レスポンスを返しました。
  • SERVED_FROM_BACKEND_BUCKET - リクエストがバックエンド サービスのインスタンス グループではなく、バックエンド バケットによって処理されました。
  • SERVED_FROM_CACHE - リクエストがプロキシ キャッシュによって処理されたため、バックエンドは割り当てられませんでした。
BACKEND ZONE インスタンス グループがゾーン インスタンス グループの場合、ユーザー リクエストを処理したインスタンス グループの GCP ゾーン(例: us-central1-aeurope-west1-basia-east1-c)。
BACKEND REGION インスタンス グループがリージョン インスタンス グループの場合、ユーザー リクエストを処理したインスタンス グループの GCP リージョン(例: us-central1europe-west1asia-east1)。
PROXY CONTINENT ユーザーの HTTP(S) 接続を終端した HTTP(S) プロキシの大陸(例: AmericaEuropeAsia)。
INSTANCE GROUP ユーザー リクエストを処理したインスタンス グループの名前。

使用可能なインスタンス グループが存在しない場合やリクエストが別のエンティティによって処理された場合は、インスタンス グループではなく、次の値のいずれかが表示されます。
  • FRONTEND_5XX - プロキシがバックエンドを選択する前に内部エラーが発生しました。プロキシからクライアントに 5xx が返されました。
  • INVALID_BACKEND - リクエストを割り当て可能な正常なバックエンドが見つからなかったため、プロキシからリクエスト送信元に 5xx レスポンスが返されました。
  • SERVED_FROM_BACKEND_BUCKET - リクエストがバックエンド サービスのインスタンス グループではなく、バックエンド バケットによって処理されました。
  • SERVED_FROM_CACHE - リクエストがプロキシ キャッシュによって処理されたため、バックエンドは割り当てられませんでした。
BACKEND SERVICE ユーザー リクエストを処理したバックエンド サービスの名前。
MATCHED URL RULE ユーザー HTTP(S) リクエストのプレフィックスと一致する URL マップパス ルール(最大 50 文字)。
FORWARDING RULE リクエストを送信するためにクライアントに使用された転送ルールの名前。

(*)現在、「レスポンス コード クラス比」指標は、ロードバランサ全体でのみ入手可能で、これ以上の内訳は入手できません。

注意点と制限事項

  • HTTP(S) 負荷分散では、HTTP/1.1 100 Continue レスポンスがサポートされています。
  • 負荷分散インスタンスが、Compute Engine によって提供されたオペレーティング システムの公開イメージを実行している場合は、オペレーティング システム内のファイアウォール ルールは、負荷分散トラフィックを許可するように自動的に構成されます。カスタム イメージを使用している場合は、オペレーティング システムのファイアウォールを手動で構成する必要があります。このことは、HTTP(S) ロードバランサ構成の一環として作成する必要がある GCP ファイアウォール ルールとは別のものです。
  • 負荷分散ではインスタンスの同期が維持されません。Deployment Manager などを使用して独自のメカニズムをセットアップし、インスタンスに一貫した構成とデータを持たせるようにする必要があります。
  • HTTP(S) 負荷分散では、ボディを含む HTTP DELETE をロードバランサに送信する動作はサポートされていません。そのようなリクエストを行うと、エラー メッセージ [Error 400 (Bad Request)!! Your client has issued a malformed or illegal request.] が返されます。DELETE リクエストは本文なしの形式のみがサポートされています。

トラブルシューティング

負荷分散トラフィックに元のクライアントの送信元アドレスが含まれていない

ロードバランサからインスタンスへのトラフィックは、130.211.0.0/2235.191.0.0/16 の範囲の IP アドレスを持っています。負荷分散インスタンスのログを見ても、元のクライアントの送信元アドレスは記録されていません。この範囲の送信元アドレスが記録されます。

自分の Cloud Storage バケットでオブジェクトを表示すると権限エラーが発生する

負荷分散を通じてオブジェクトを提供するには、Cloud Storage オブジェクトが一般公開されている必要があります。一般読み取り可能になるように、提供するオブジェクトの権限を更新してください。

URL から予期した Cloud Storage オブジェクトが提供されない

提供される Cloud Storage オブジェクトは、URL マップとリクエストした URL に基づいて決まります。URL マップでリクエストパスがバックエンド バケットにマッピングしている場合、URL マップで指定されている Cloud Storage バケットにリクエストのフルパスが追加され、Cloud Storage オブジェクトが決まります。

たとえば、/static/*gs://[EXAMPLE_BUCKET] にマッピングした場合、https://<GCLB IP or Host>/static/path/to/content.jpg がリクエストされると、gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg を提供しようとします。そのオブジェクトが存在しない場合は、オブジェクトの代わりに次のエラー メッセージが返されます。


NoSuchKey
The specified key does not exist.

圧縮が機能しない

HTTP(S) 負荷分散はレスポンスの圧縮や解凍を行いませんが、gzipDEFLATE などのツールで圧縮された、バックエンド サービスによって生成されるレスポンスを提供できます。

HTTP(S) 負荷分散から提供されたレスポンスが圧縮されていない場合には、インスタンスで実行されているウェブサーバー ソフトウェアでレスポンスの圧縮が構成されていることを確認してください。デフォルトでは、リクエストに Via ヘッダーが含まれている場合、一部のウェブサーバー ソフトウェアはリクエストの圧縮を自動的に無効にします。Via ヘッダーが存在する場合、リクエストはプロキシによって転送されています。これはプロキシであるため、HTTP(S) 負荷分散は、HTTP 仕様での要件に従って Via ヘッダーを各リクエストに追加します。圧縮を有効にするには、ウェブサーバーのデフォルトの構成を変更し、リクエストに Via ヘッダーがある場合でもレスポンスを圧縮するように設定します。

nginx ウェブサーバー ソフトウェアを使用している場合に、圧縮を有効にするには nginx.conf 構成ファイルに変更を加えます。このファイルの場所は、nginx をインストールした場所によって異なります。多くの Linux ディストリビューションでは、このファイルは /etc/nginx/nginx.conf に保存されています。HTTP(S) 負荷分散で nginx 圧縮を有効にするには、nginx.conf の http セクションに次の 2 行を追加します。

gzip_proxied any;
gzip_vary on;

最初の行を追加すると、HTTP(S) 負荷分散などのプロキシから転送されたリクエストでも圧縮が有効になります。2 番目の行により、レスポンスに Vary: Accept-Encoding ヘッダーが追加されます。Vary: Accept-Encoding は、圧縮可能なリソースの圧縮バリアントと非圧縮バリアントに別々のキャッシュ エントリを維持するように、Cloud CDN などのキャッシュ プロキシに通知します。

nginx.conf を変更した後で新しい設定を使用するには、nginx を再起動する必要があります。多くの Linux ディストリビューションでは、sudo service nginx restart または /etc/init.d/nginx restart を実行して nginx を再起動します。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Compute Engine ドキュメント