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

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

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

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

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

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

バックエンドのバランシングモードに互換性がない

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

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 レスポンスのトラブルシューティングを行います。

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

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

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

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

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`	バックエンドの応答に過度に長い時間を要した。バックエンドサービスのタイムアウトが過剰に低い値に設定されているため、指定したサービスが応答していない可能性があります。バックエンドサービスのタイムアウト値を引き上げることを検討するか、サービスが応答するのに非常に長い時間を要している理由を調査してください。

バックエンドインスタンスで実行されている 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 バックエンドを構成するには:

gzip_proxied ディレクティブを（any などに）適切に設定します。
gzip_vary ディレクティブを on に設定します。

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

DEFLATE フィルタを使用します。
mod_headers モジュールを使用して、レスポンスヘッダーに Vary Accept-Encoding を追加します。

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

バックエンドに接続する 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 Functions、Cloud Run サービスなど）がまだ実行されていることを確認します。サーバーレスリソースが削除されても、サーバーレス NEG がまだ存在する場合、外部アプリケーションロードバランサは引き続き存在しないサービスへのリクエストの転送を試みます。これにより、404 レスポンスが返されます。

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

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

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

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

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

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

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

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

バックエンドのバランシング モードに互換性がない