外部アプリケーション ロードバランサに関する問題のトラブルシューティング

このガイドでは、外部アプリケーション ロードバランサの構成に関する問題のトラブルシューティングについて説明します。問題を調べる前に、次のページをよくお読みください。

ネットワーク アナライザに関する一般的な問題のトラブルシューティング

ネットワーク アナライザは、VPC ネットワーク構成を自動的にモニタリングし、最適ではない構成と構成ミスの両方を検出します。ネットワーク障害を特定し、根本原因の情報と考えられる解決策を提供します。ネットワーク アナライザによって自動的に検出されるさまざまな構成ミスのシナリオについては、ネットワーク アナライザのドキュメントでロードバランサの分析情報をご覧ください。

ネットワーク アナライザは、Network Intelligence Center の一部として Google Cloud Console でご利用いただけます。

ネットワーク アナライザに移動

バックエンドの負荷分散モードに互換性がない

ロードバランサを作成するときに、次のエラーが表示される場合があります。

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

これは、2 つの異なるロードバランサで同じバックエンドを使用しようとしたが、互換性のある負荷分散モードがバックエンドにない場合に発生します。

詳しくは以下をご覧ください。

接続に関する一般的な問題のトラブルシューティング

原因不明の 5XX エラー

ロードバランサ プロキシとそのバックエンド間の通信問題に起因するエラーの場合、ロードバランサは HTTP エラー レスポンス コード（5XX）を生成し、そのエラー レスポンス コードをクライアントに返します。すべての HTTP 5XX エラーがロードバランサで生成されるわけではありません。たとえば、バックエンドが HTTP 5XX レスポンスをロードバランサに送信すると、ロードバランサはそのレスポンスをクライアントにリレーします。HTTP 5XX レスポンスがバックエンドからリレーされたか、またはロードバランサ プロキシによって生成されたかを確認するには、ロードバランサのログの statusDetails フィールドを参照してください。

statusDetails がログ文字列 response_sent_by_backend を返す場合、ロードバランサは、バックエンドから送信されたレスポンス コードのみをリレーします。この場合は、バックエンドでの HTTP エラー レスポンスのトラブルシューティングを行う必要があります。

statusDetails がログ文字列 response_sent_by_backend と一致しない HTTP エラー レスポンスの場合:

  • グローバル外部アプリケーション ロードバランサとリージョン外部アプリケーション ロードバランサは、503（サービス利用不可）や 504（ゲートウェイ タイムアウト）などの意味のある HTTP レスポンス エラーコードを生成します。

  • 従来のアプリケーション ロードバランサは、常に HTTP レスポンス エラーコード 502 を使用します。

バックエンド サービスの追加や削除など、グローバル外部アプリケーション ロードバランサの構成が変更されると、HTTP レスポンスのエラーコード 502 がユーザーに短時間表示されることがあります。このような構成変更は GFE にグローバルに反映されますが、statusDetails フィールドがログ文字列 failed_to_pick_backend と一致するログエントリが表示されます。

ロードバランサの構成を完了してから HTTP 5XX エラーが数分以上続く場合は、次の手順で HTTP 5XX レスポンスのトラブルシューティングを行います。

  1. ヘルスチェックを許可するように構成されたファイアウォール ルールがあることを確認します。このようなルールがない場合は、通常、ロードバランサ ログに failed_to_pick_backend に一致する statusDetails があります。これは、ロードバランサが、リクエストを処理するための正常なバックエンドを選択できなかったことを示します。

  2. ヘルスチェック トラフィックがバックエンド VM に到達していることを確認します。これを行うには、ヘルスチェックのロギングを有効にし、成功したログエントリを検索します。

    新しいロードバランサの場合、ヘルスチェックが正常であったことを示すログエントリがなかったとしても、ヘルスチェックのトラフィックがバックエンドに到達していないことを意味するわけではありません。この場合、バックエンドの初期ヘルス状態が UNHEALTHY から別の状態にまだ変化していないことを意味している可能性があります。ヘルスチェック プローバーがバックエンドから HTTP 200 OK レスポンスを受け取った後ではじめて、ヘルスチェックが正常であったことを示すログエントリが生成されます。

  3. バックエンドのソフトウェアが実行されていることを確認します。これを行うには、5xx レスポンスがロードバランサによって処理されているかどうか、またはバックエンドから生成されているかどうかをチェックします。次の操作を行います。

    1. Cloud Logging を使用してロードバランサのログを表示します。5xx レスポンス コードのみを検索するクエリを作成できます。

    2. statusDetails フィールドの値を確認します。

      • 条件 statusDetails が成功メッセージ（例: response_sent_by_backend）を返す場合は、それがバックエンドの HTTP 502 レスポンスを処理しているバックエンドです。バックエンドでログを確認し、バックエンドで実行されているサービスに応じてさらにトラブルシューティングを行います。
      • statusDetails がエラー メッセージを返す場合、5xx レスポンスに関連する一般的なエラーについては、次の解決策をご覧ください。
      statusDetail エラー メッセージ 考えられる原因と解決策
      failed_to_connect_to_backend

      ロードバランサが、バックエンドとの接続を確立できなかった。これは、バックエンドで実行されているサービスが、バックエンド サービスで定義されたポートをリッスンしていないことを示している可能性があります。

      推奨:

      • サービスポートを使用するようにヘルスチェックのポートを設定します。これにより、実際のトラフィックを処理できるようになる前に、バックエンドが異常な状態であることを判断できます。
      • 次のコマンドを使用して、バックエンド サービスの名前付きポートでサービスが実行されていることを確認します。
        $ netstat -tnl | grep PORT
      failed_to_pick_backend

      ロードバランサがバックエンドを選択できなかった。これは、すべてのバックエンドが異常な状態であることを示している可能性があります。ヘルスチェックに正しいファイアウォール ルールを構成していることを確認します。
      backend_connection_closed_before_data_sent_to_client バックエンドが、レスポンスがクライアントにプロキシされる前に、予期せずロードバランサへの接続を閉じた。これは、ロードバランサが別のエンティティにトラフィックを送信している場合に発生する可能性があります。他のエンティティは、ロードバランサのタイムアウトよりも短い TCP タイムアウトが設定されたサードパーティ ロードバランサであることが考えられます。詳細については、タイムアウトと再試行をご覧ください。
      backend_timeout バックエンドの応答に過度に長い時間を要した。バックエンド サービスのタイムアウトが過剰に低い値に設定されているため、指定したサービスが応答していない可能性があります。バックエンド サービスのタイムアウト値を引き上げることを検討するか、サービスが応答するのに非常に長い時間を要している理由を調査してください。

  4. バックエンド インスタンスで実行されている HTTP サーバー ソフトウェアのキープアライブ構成パラメータが、ロードバランサーのキープアライブ タイムアウト（10分（600秒）固定で構成不可）を下回っていないことを確認します。

    HTTP リクエストの送信中または完全な HTTP レスポンスが受信される前に、バックエンドへの接続が予期せず終了すると、ロードバランサは HTTP 5XX レスポンス コードを生成します。これは、バックエンド インスタンスで実行されているウェブサーバー ソフトウェアのキープアライブ構成パラメータが、ロードバランサの固定されたキープアライブ タイムアウトよりも小さいために発生している可能性があります。各バックエンドの HTTP サーバー ソフトウェアのキープアライブ タイムアウト構成が 10 分より少し大きく設定されていることを確認します（推奨値は 620 秒）。

HTTP 408 エラーを解決する

HTTP トラフィックの場合、クライアントがリクエストの送信を完了できる最大時間は、バックエンド サービス タイムアウトと同じです。HTTP 408 レスポンスが jsonPayload.statusDetail client_timed_out で表示されている場合は、クライアントからのリクエストがプロキシされている間、またはバックエンドからのレスポンスがプロキシされた間に、進捗がなかったことを意味します。問題の原因がクライアントのパフォーマンスの問題である場合は、バックエンド サービスのタイムアウトを増やすことでこの問題を解決できます。

ロードバランスされたトラフィックに元のクライアントの送信元アドレスが含まれていない

バックエンドから見たパケットの送信元 IP アドレスは、ロードバランサの外部 IP アドレスではありません。外部アプリケーション ロードバランサなどのプロキシベースのロードバランサは、2 つの TCP 接続を使用してクライアントからバックエンドにトラフィックを送信します。

  • 接続 1: 元のクライアントからロードバランサ（GFE またはプロキシ専用サブネット）への接続
  • 接続 2: ロードバランサ（GFE またはプロキシ専用サブネット）からバックエンド VM またはエンドポイントへの接続

各接続の送信元 IP アドレスと宛先 IP アドレスは、使用している外部アプリケーション ロードバランサのタイプによって異なります。詳細については、クライアント パケットの送信元 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.

圧縮が機能しない

外部アプリケーション ロードバランサは、レスポンスそのものを圧縮または解凍しませんが、バックエンド サービスによって生成され、gzip や DEFLATE などのツールを使用して圧縮されるレスポンスを提供できます。

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

外部のアプリケーション ロードバランサ経由でプロキシ送信される圧縮レスポンスを提供するように nginx バックエンドを構成するには:

外部のアプリケーション ロードバランサ経由でプロキシ送信される圧縮レスポンスを提供するように Apache バックエンドを構成するには:

異常なバックエンドのトラブルシューティング

バックエンドに接続する HTTP/2 に関する問題のトラブルシューティング

バックエンド インスタンスが正常であり、HTTP/2 プロトコルをサポートしていることを確認します。これを確認するには、HTTP/2 を使用してバックエンド インスタンスへの接続をテストします。VM が HTTP/2 仕様準拠の暗号スイートを使用していることを確認します。たとえば、特定の TLS 1.2 暗号スイートは HTTP/2 では使用できません。TLS 1.2 暗号スイートのブラックリストをご覧ください。

VM が HTTP/2 プロトコルを使用していることを確認したら、ファイアウォールの設定でヘルスチェッカーとロードバランサが通過できることを確認します。

ファイアウォールの設定に問題がない場合は、VM の正しいポートに接続するようにロードバランサを構成します。

外部バックエンドとインターネット NEG に関する問題のトラブルシューティング

問題を調べる前に、次のページをよくお読みください。

トラフィックがエンドポイントに到達しない

サービスを構成すると、次の場合に外部アプリケーション ロードバランサを介して新しいエンドポイントにアクセスできるようになります。

  • エンドポイントは、インターネット NEG に接続されている。
  • 関連付けられた FQDN は、DNS で正常に解決できる（FQDN エンドポイント タイプを使用している場合）。
  • エンドポイントには、インターネット経由でアクセスできる。

トラフィックがエンドポイントに到達できず、502 エラーコードが返される場合は、dig や nslookup などのツールを使用して _cloud-eoips.googleusercontent.com DNS TXT レコードをクエリします。CIDR（ip4: の後に続く部分）をメモし、ファイアウォールまたはクラウドのアクセス制御リスト（ACL）でこれらの範囲が許可されていることを確認します。

外部バックエンドを構成した後、外部バックエンドへのリクエストが 5xx エラーで失敗する

  • Loggingを確認します。
  • 外部バックエンドの正しい IP:Port または FQDN:Port でネットワーク エンドポイント グループが構成されていることを確認します。
  • FQDN を使用している場合は、Google Public DNS で解決できることを確認してください。FQDN がこれらの手順またはウェブ インターフェースを直接使用して Google Public DNS を介して解決できることを確認できます。
  • 外部 IP でのみロードバランサにアクセスし、送信元ウェブサーバーがホスト名を想定している場合は、カスタムのリクエスト ヘッダーを構成することにより、有効な HTTP ホストヘッダーをバックエンドに送信していることを確認します。
  • HTTPS または HTTP2 を介するバックエンドへの通信（バックエンド サービスの protocol フィールドで設定）が INTERNET_FQDN_PORT 外部バックエンドのエンドポイントとして構成されている場合は、送信元が有効な TLS（SSL）証明書を示し、構成された FQDN が証明書の SAN（サブジェクト代替名）リスト内の SAN と一致していることを確認します。有効な証明書とは、パブリック認証局によって署名され、有効期限が切れていないものと定義されています。
  • INTERNET_FQDN_PORT 外部バックエンドのエンドポイントを使用している場合は、自己署名証明書は、ロードバランサで受け入れられず、拒否されます。
  • INTERNET_IP_PORT タイプのエンドポイントで HTTPS や HTTP/2 を使用している場合は、SSL 証明書の検証と SAN チェックは行われません。つまり、自己署名証明書を使用できます。SSL を使用している場合は、INTERNET_FQDN_PORT エンドポイントを使用して、サーバー証明書と SAN を検証できるようにすることをおすすめします。

外部バックエンドからのレスポンスが Cloud CDN によってキャッシュに保存されない

以下の点を確認してください。

  • enableCDN を true に設定して、外部バックエンドを指す NEG を含むバックエンド サービスで Cloud CDN をすでに有効にしている。
  • 外部バックエンドによって提供されるレスポンスが、Cloud CDN のキャッシュ要件を満たしている。たとえば、送信元からの Cache-Control: public, max-age=3600 レスポンス ヘッダーを返している。

サーバーレス NEG に関する問題のトラブルシューティング

問題を調べる前に、次のページをよくお読みください。

リクエストが 404 エラーで失敗する

基盤となるサーバーレス リソース（App Engine、Cloud Run 関数、Cloud Run サービスなど）がまだ実行されていることを確認します。サーバーレス リソースが削除されてもサーバーレス NEG がまだ存在する場合、外部アプリケーション ロードバランサは引き続き存在しないサービスへのリクエストの転送を試みます。これにより、404 レスポンスが返されます。

一般に、外部アプリケーション ロードバランサは、基盤となるサーバーレス リソースが期待どおりに動作しているかどうかを検出できません。つまり、あるリージョンのサービスがエラーを返しても、そのリージョンの Cloud Run、Cloud Run 関数、または App Engine インフラストラクチャ全体が正常に動作している場合は、外部アプリケーション ロードバランサが他のリージョンにトラフィックを自動的に転送することはありません。ユーザー トラフィックを転送する前に、サービスの新しいバージョンを入念にテストしてください。

URL マスクの不一致への対処

ユーザー リクエスト URL に構成済み URL マスクを適用してもサービス名が生成されない場合や、存在しないサービス名が生成される場合、ロードバランサは使用中のサーバーレス コンピューティング プラットフォームに応じて、これらの不一致を異なる方法で処理する可能性があります。

Cloud Run: URL マスクが一致しない場合、ロードバランサは HTTP エラー 404（Not Found）を返します。

Cloud Run 関数: URL マスクが一致しない場合、ロードバランサは HTTP エラー 404（Not Found）を返します。

App Engine: URL マスクが一致しない場合、App Engine は dispatch.yaml と App Engine のデフォルトのルーティング ロジックを使用して、リクエストの送信先のサービスを決定します。