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

このガイドでは、Google Cloud の内部アプリケーション ロードバランサの構成に関する問題のトラブルシューティングについて説明します。このガイドに進む前に、次の内容を理解しておいてください。

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

ネットワーク アナライザは、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 つの異なるロードバランサで同じバックエンドを使用しようとしたが、互換性のある負荷分散モードがバックエンドにない場合に発生します。

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

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

これは想定された挙動です。内部アプリケーション ロードバランサは HTTP(S) リバース プロキシ（ゲートウェイ）として動作します。クライアント プログラムが INTERNAL_MANAGED 転送ルールの IP アドレスへの接続を開くと、その接続はプロキシで終端し、接続を介して到着したリクエストはプロキシで処理されます。リクエストのたびに、プロキシは URL マップなどの要素に基づいてリクエストの受信先となるバックエンドを選択し、そのバックエンドにリクエストを送信します。その結果、バックエンドから見ると、受信パケットのソースはそのリージョンのプロキシ専用サブネットの IP アドレスになります。

リクエストがロードバランサによって拒否される

リクエストが到着するたびに、プロキシはロードバランサの URL マップのパスマッチャーに基づいて受信先となるバックエンドを選択します。リクエストのパスマッチングが定義されていない場合、URL マップはバックエンド サービスを選択できないため HTTP 404（Not Found）レスポンス コードを返します。

ロードバランサがバックエンドに接続されない

バックエンド サーバーを保護するファイアウォールは、内部 HTTP(S) ロードバランサのリージョンに割り当てたプロキシ オンリー サブネットの範囲内でプロキシからの受信トラフィックを許可するように構成する必要があります。

プロキシはバックエンド サービスの構成で指定された接続設定を使用してバックエンドに接続します。これらの値がバックエンドで実行されているサーバーの構成と一致しない場合、プロキシはバックエンドにリクエストを転送できません。

ヘルスチェック プローブがバックエンドに到達できない

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

クライアントがロードバランサに接続できない

プロキシがリッスンする接続は、転送ルールで構成されているロードバランサの IP アドレスとポート（10.1.2.3:80 など）を宛先とし、転送ルールで指定されたプロトコル（HTTP または HTTPS）を使用する接続です。クライアントが接続できない場合は、正しいアドレス、ポート、プロトコルが使用されていることを確認してください。

ファイアウォールが、クライアント インスタンスと負荷分散された IP アドレスの間のトラフィックをブロックしていないことを確認してください。

クライアントがロードバランサと同じリージョンにあることを確認してください。内部 HTTP(S) 負荷分散はリージョナル プロダクトであるため、すべてのクライアントとバックエンドはロードバランサ リソースと同じリージョンになければなりません。

共有 VPC の組織のポリシーの制限

共有 VPC を使用していて、特定のサブネットに新しい内部アプリケーション ロードバランサを作成できない場合は、組織のポリシーが原因である可能性があります。組織ポリシーで、許可されたサブネットのリストに、ロードバランサを作成したいサブネットを追加するか、組織管理者にお問い合わせください。詳細については、constraints/compute.restrictSharedVpcSubnetworks をご覧ください。

ロードバランサがゾーン間で均等にトラフィックを分散しない

内部アプリケーション ロードバランサのトラフィックがゾーン間で不均衡になっている場合があります。これは特に、バックエンド容量の使用率が低い（10% 未満）場合に発生することがあります。

このような状態が発生すると、1 つのゾーン内の少数のサーバーにのみトラフィックが送信されるため、全体的なレイテンシに影響する可能性があります。

ゾーン間で均等にトラフィックを分散するには、次のように構成を変更します。

  • RATE 分散モードを使用し、max-rate-per-instance のターゲット容量を少なく設定します。
  • LocalityLbPolicy バックエンド トラフィック ポリシーを使用し、LEAST_REQUEST の負荷分散アルゴリズムを使用します。

原因不明の 5xx エラー

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

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

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

  1. ヘルスチェックを許可するように構成されたファイアウォール ルールがあることを確認します。 存在しない場合、通常、ロードバランサ ログに destination_unavailable に一致する proxyStatus があります。これは、ロードバランサがバックエンドを使用できないとみなすことを示します。

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

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

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

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

制限事項

他の Google Cloud ネットワーク機能と内部アプリケーション ロードバランサを併用できない場合は、現在の互換性の制限事項をご確認ください。