502 Bad Gateway - ソケットのハングアップ

現在、Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントをご確認ください。 情報

内容

クライアント アプリケーションは、Edge Microgateway で API 呼び出しのレスポンスとして、502 Bad Gateway という HTTP ステータス コードとコード ECONNRESET を受信します。

エラー メッセージ

クライアントには次のレスポンス コードが表示されます。 

HTTP/1.1 502 Bad Gateway

レスポンスには、次のエラー メッセージが含まれます。

{"message":"socket hang up","code":"ECONNRESET"}

考えられる原因

原因 説明 トラブルシューティングの実施対象
キープアライブ タイムアウトが正しく構成されていない Edge Microgateway とターゲット サーバー間のキープアライブ タイムアウトが正しく構成されていません。 Edge Public Cloud ユーザーと Private Cloud ユーザー
ターゲット サーバーが接続を途中で終了する Edge Microgateway がリクエスト ペイロードを送信している間、ターゲット サーバーが接続を途中で終了する。 Edge Public Cloud ユーザーと Private Cloud ユーザー

共通の診断手順

  1. Edge Microgateway ログを確認します。 
    /var/tmp/edgemicro-`hostname`-*.log
  2. 特定の期間にコード ECONNRESET の 502 エラーがあったかどうか（問題が過去に発生した場合）や、502 で失敗するリクエストがあるかどうかを検索します。
    2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test]
[emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684]
[microgateway-core][][GET][502][socket hang up][ECONNRESET][]
  3. ロギングレベルを warn または info に設定している場合は、2 つ目の要素にターゲット サーバーのホスト名とポートを含む [warn] メッセージも表示されます。この例では X.X.X.X:8080 ですが、後で tcpdump をキャプチャするために使用できます。
    2021-06-23T03:52:24.109Z
[warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup]
[][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware]
[targetRequest error][GET][][socket hang up][ECONNRESET][395]
  4. エラーコード [socket hang up][ECONNRESET] は、ターゲット サーバーが Edge Microgateway との接続を閉じたことを示します。ログ内でこれを検索して、問題の発生頻度を確認できます。

原因: キープアライブ タイムアウトが正しく構成されていない

診断

  1. 一般的な診断手順の手順に沿って、[socket hang up][ECONNRESET] エラーが発生したかどうかを確認します。

  2. 「はい」の場合は、以下のように tcpdump を使用してさらに調査します。

tcpdump の使用

  1. 次のコマンドを使用して、Edge Microgateway と Edge Microgateway ホスト オペレーティング システムのバックエンド サーバーの間の tcpdump をキャプチャします。 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  2. キャプチャされた tcpdump を分析します。

    tcpdump の出力例:（ 拡大画像を表示）

    上記のサンプル tcpdump で、次のことがわかります。

    1. パケット 250288 で、クライアントが POST リクエストを送信します。
    2. パケット 250371 で、サーバーは 200 OK で応答します。
    3. パケット 250559 で、クライアントが ACK. を送信します。
    4. パケット 250560 で、サーバーが Continuation メッセージを送信します。
    5. パケット 250561 で、クライアントが ACK. を送信します。
    6. パケット 262436 で、サーバーは FIN, ACK をクライアントに送信し、接続の終了を開始します。これは、前のパケット（250561）から約 5 秒後であることに注意してください。
    7. パケット 262441 で、クライアントは別の POST リクエストを送信します。ただし、サーバーがすでに接続の終了を開始しているため、これは失敗します。パケット 262441 で RST が返されます。

    この例では、同じ接続が少なくとも 1 回正常に再利用されましたが、最終的なリクエストでは、サーバーが 5 秒間のアイドル時間の後に接続の終了を開始します。これは、クライアントが新しいリクエストを送信したのと同時に発生します。これは、バックエンド サーバーのキープアライブ タイムアウトが、クライアントに設定された値と同じか、それより短い可能性が高いことを示しています。これを検証するには、Edge Microgateway とバックエンド サーバーのキープアライブ タイムアウトの比較をご覧ください。

キープアライブ タイムアウトの比較

  1. Edge Microgateway には、特定のキープアライブ タイムアウト プロパティはありません。これは、それが実行されているオペレーティング システムによって決定されます。一般的な例としては、Windows、Linux、Docker コンテナがあります。
  2. オペレーティング システムでカスタマイズされている可能性があります。システム管理者に確認してください。Linux オペレーティング システムのデフォルトのキープアライブ タイムアウトは 2 時間です。
  3. 次に、バックエンド サーバーで設定されているキープアライブ タイムアウト プロパティを確認します。バックエンド サーバーが 10 秒の値で構成されているとします。
  4. 上記の例のように、オペレーティング システムのキープアライブ タイムアウトの値がバックエンド サーバーのキープアライブ タイムアウト プロパティの値よりも大きいと判断した場合、これが 502 エラーの原因です。

解像度

Edge Microgateway が実行されているオペレーティング システムのキープアライブ タイムアウト プロパティが、バックエンド サーバーのプロパティよりも常に低いことを確認します。

  1. バックエンド サーバーのキープアライブ タイムアウトに設定された値を決定します。
  2. ご使用のオペレーティング システムに応じて、キープアライブ タイムアウト プロパティがバックエンド サーバーの設定値よりも小さくなるように、オペレーティング システムのキープアライブ タイムアウト プロパティに適切な値を構成します。

ベスト プラクティス

このような競合状態や 502 エラーを回避するため、ダウンストリーム コンポーネントのキープアライブ タイムアウトのしきい値を常にアップストリーム サーバーで構成した値よりも小さくすることを強くおすすめします。各ダウンストリーム ホップは、各アップストリーム ホップより小さくする必要があります。Edge Microgateway では、次のガイドラインを使用することをおすすめします。

  1. クライアント アプリケーションまたはロードバランサのキープアライブ タイムアウトは、Edge Microgateway のキープアライブ タイムアウトよりも短くする必要があります。

    Edge Microgateway でキープアライブ タイムアウトを構成するには、~/.edgemicro/org-env-config.yaml ファイルに keep_alive_timeout 値を追加します。

    edgemicro:
  keep_alive_timeout: 65000
  2. Edge Microgateway オペレーティング システムのキープアライブ タイムアウトは、ターゲット サーバーのキープアライブ タイムアウトよりも短くする必要があります。
  3. Edge Microgateway の前または背後に他のホップがある場合は、同じルールを適用する必要があります。アップストリームとの接続を閉じることは、常にダウンストリーム クライアントが担います。

原因: ターゲット サーバーが接続を途中で終了する

診断

  1. 一般的な診断手順の手順に沿って、[socket hang up][ECONNRESET] エラーが発生したかどうかを確認します。
  2. 「はい」の場合は、以下で説明するように tcpdump を使用してさらに調査します。

    上記の例のエラー メッセージ [targetRequest error][GET][][socket hang up][ECONNRESET] は、Edge Microgateway がバックエンド（ターゲット）サーバーにリクエストを送信している間にこのエラーが発生したことを示します。つまり、Edge Microgateway がバックエンド サーバーに API リクエストを送信し、レスポンスを待機していました。ただし、Edge Microgateway がレスポンスを受信する前に、バックエンド サーバーが接続を突然終了しました。

  3. バックエンド サーバーのログを確認し、バックエンド サーバーが接続を突然終了させる原因となった可能性のあるエラーや情報がないか確認します。エラーや情報が見つかった場合は、解決策に進み、バックエンド サーバーで問題を適切に修正します。
  4. バックエンド サーバーでエラーや情報が見つからない場合は、Edge Microgateway サーバーで tcpdump の出力を収集します。 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  5. キャプチャされた tcpdump を分析します。

    tcpdump の出力例:（ 拡大画像を表示）

    上記のサンプル tcpdump で、次のことがわかります。

    1. パケット 4 で、Edge Microgateway は GET リクエストをターゲット サーバーに送信しました。
    2. パケット 5 で、ターゲット サーバーは ACK で応答してリクエストを確認します。
    3. ただし、パケット 6 では、ターゲット サーバーがレスポンス ペイロードで応答する代わりに、FIN, ACK を送信して接続の終了を開始します。
    4. 7 以降のパケットでは、接続が相互に閉じられます。レスポンスが送信される前に接続が閉じられたため、Edge Microgateway は HTTP 502 エラーをクライアントに返します。
    5. パケット 8（2021-06-23T03:52:24.110Z ）のタイムスタンプは、Edge Microgateway ログに記録されたエラーのタイムスタンプに対応しています。ログファイルと tcpdump のタイムスタンプは、多くの場合、エラーと実際のパケットの関連付けに使用されます。

    解像度

    バックエンド サーバーの問題を修正します。

    問題が解決せず、502 Bad Gateway Error のトラブルシューティングのサポートが必要な場合、または Edge Microgateway 内の問題であると思われる場合は、診断情報の収集が必要をご覧ください。

    診断情報の収集が必要な場合

    上記の手順でも問題が解決しない場合は、次の診断情報を収集して Apigee Edge サポートに連絡してください。

    • ログファイル: デフォルトのフォルダは /var/tmp ですが、メインの config.yaml ファイル（logging > dir parameter）でオーバーライドされる可能性があります。ログファイルを Apigee サポートに提供する前に、log > level を info に変更することをおすすめします。
    • 構成ファイル: Edge Microgateway の主な構成は、デフォルトの Edge Microgateway フォルダ $HOME/.edgemicro にある YAML ファイルにあります。default.yaml というデフォルト構成ファイルがあり、環境 ORG-ENV-config.yaml ごとに 1 つの構成ファイルがあります。影響を受ける組織と環境について、このファイルをすべてアップロードしてください。