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(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 ヘルスチェックで検証されます。バックエンド サービスが HTTPS を使用するように設定されていると、リクエストは暗号化されてバックエンド インスタンスに届きます。

HTTPS 負荷分散

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

  • ターゲット HTTP プロキシではなくターゲット HTTPS プロキシを使用します。
  • ロードバランサ用の署名済みの SSL 証明書が少なくとも 1 つ必要です。
  • クライアント SSL セッションはロードバランサで終了します。ロードバランサとインスタンス間のセッションは、HTTPS(推奨)または HTTP のいずれかとなります。HTTPS の場合、インスタンスごとに証明書が必要です。

コンポーネント

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

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

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

ターゲット プロキシ

ターゲット プロキシはクライアントからの HTTP(S) 接続を終了し、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-forward-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 証明書

URL マップで定義されたバックエンド サービスに受信 HTTPS リクエストを安全にルーティングするため、ターゲット HTTPS プロキシで SSL 証明書が使用されます。ターゲット HTTPS プロキシには最大 10 個の SSL 証明書を保存できます。

バックエンド サービス

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

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

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

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

バックエンド バケット

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

ファイアウォール ルール

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

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

負荷分散アルゴリズム

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

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

セッション アフィニティ

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

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

WebSocket プロキシ サポート

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

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

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

接続が使用中かどうかに関わらず、接続のデフォルト タイムアウトは 30 秒です。それよりも長時間の接続が必要な場合は、バックエンド サービスの timeout 値(API の timeoutSec)を増やします。

HTTP(S) ロードバランサの一方のクライアント IP が設定されているか、セッション アフィニティ Cookie が生成されていると、インスタンスがヘルスチェックに合格し、容量があれば、クライアントからのすべての WebSocket 接続が同じバックエンド インスタンスに送信されます。

インターフェース

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 のみを受け入れます。バックエンド プロトコルが HTTPS の場合、バックエンド サービスと TLS 1.0、1.1、1.2 のみで通信を行います。

タイムアウトと再試行

HTTP(S) 負荷分散のデフォルトのレスポンス タイムアウトは 30 秒です。これは固定のタイムアウトであり、アイドル タイムアウトではありません。WebSocket などより長時間の接続が必要な場合は、この値を適切な値にまで増やします。

HTTP(S) 負荷分散の TCP セッション タイムアウトは、デフォルトで 10 分(600 秒)です。接続が途中で切断されないように、ターゲット サービスのキープアライブ タイムアウトがこれよりも大きいことを確認します。nginx など一部のウェブサーバーでは、デフォルトのタイムアウトがこれよりも小さいことがあります。

HTTP(S) 負荷分散は、失敗した GET リクエストは再試行しますが、失敗した POST リクエストは再試行しません。

不正なリクエスト処理

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 マップのログだけを確認するには、[GCE URL マップ] を選択して、必要な URL マップを選択します。

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

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

ログの内容

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

  • 重大度、プロジェクト ID、プロジェクト番号、タイムスタンプなど、ほとんどの GCP ログで表示される一般情報。
  • HttpRequest ログフィールド
  • structPayload 内の statusDetails フィールド。このフィールドは、ロードバランサが行った、HTTP のステータスを戻した理由を説明する文字列を保持しています。以下のテーブルには、これらのログの文字列の詳しい説明が記載されています。

statusDetail HTTP 正常終了メッセージ

statusDetails(正常終了) 意味 共通のレスポンス コード
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
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

モニタリング

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 (Beta)](*)です。
  5. [条件を保存] をクリックします。
  6. ポリシー名を入力し、[Save Policy] をクリックします。

(*)アルファ版ユーザー以外は、ベータ版のみを使用してください。アルファ版はサポートが終了しているため、アルファ版ユーザーは既存のモニタリングをベータ版に移行する必要があります。サポート終了に関する詳細を通知するメールがアルファ版ユーザー全員に送信されます。

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

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

  1. Google Cloud Platform Console で Stackdriver にアクセスします。
    Stackdriver に移動
  2. [ダッシュボード] > [ダッシュボードの作成] を選択します。
  3. [Add Chart] をクリックします。
  4. グラフにタイトルを付けます。
  5. 指標とフィルタを選択します。指標の場合は、リソースタイプが [HTTP(S) Load Balancer (Beta)](*)です。
  6. [保存] をクリックします。

(*)アルファ版ユーザー以外は、ベータ版のみを使用してください。アルファ版はサポートが終了しているため、アルファ版ユーザーは既存のモニタリングをベータ版に移行する必要があります。サポート終了に関する詳細を通知するメールがアルファ版ユーザー全員に送信されます。

指標報告の頻度と保持

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

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

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

指標 説明
リクエスト数 HTTP(S) ロードバランサによって処理されるリクエストの数
リクエスト バイト数 ユーザーから HTTP(S) ロードバランサにリクエストとして送信されたバイト数
レスポンス バイト数 HTTP(S) ロードバランサからユーザーにレスポンスとして送信されたバイト数
総レイテンシ ロードバランサ プロキシが最初のリクエスト バイトを受信してから、最後のレスポンス バイトで要求側のクライアントからの ACK を受信するまでのレイテンシの分布。通常、Stackdriver ビューでは 95 パーセンタイルに縮小されます。
例: ロードバランサが、英国から 1 秒間に 1 件のリクエスト(全部で 100ms のレイテンシ)と、米国から 1 秒間に 9 件のリクエスト(全部で 50ms のレイテンシ)を処理しています。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 ZONE ユーザー リクエストを処理したインスタンス グループの Google Cloud Platform ゾーン(例: us-central1-aeurope-west1-basia-east1-c)。
PROXY CONTINENT ユーザーの HTTP(S) 接続を終端した HTTP(S) プロキシの大陸(例: AmericaEuropeAsia)。
INSTANCE GROUP ユーザー リクエストを処理したインスタンス グループの名前。

使用可能なインスタンス グループが存在しない場合やリクエストが別のエンティティによって処理された場合は、インスタンス グループではなく、次の値のいずれかが表示されます。
  • FRONTEND_5XX - 内部エラーまたは健全なバックエンドの不足が原因で、プロキシがインスタンス グループをリクエストに割り当てることができませんでした。代わりに、プロキシは要求者に 5xx レスポンスを返しました。
  • SERVED_FROM_BACKEND_BUCKET - リクエストがインスタンス グループではなく、バックエンド バケットによって処理されました。
  • SERVED_FROM_CACHE - リクエストがプロキシのキャッシュによって処理されたため、バックエンドは割り当てられませんでした。
BACKEND SERVICE ユーザー リクエストを処理したバックエンド サービスの名前。
MATCHED URL RULE ユーザー HTTP(S) リクエストのプレフィックスと一致する URL マップパス ルール(最大 50 文字)。

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

注意点と制限事項

  • 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.

外出先でもリソースをモニタリング

Google Cloud Console アプリを入手して、プロジェクトの管理にお役立てください。

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

Compute Engine ドキュメント