502 Bad Gateway タイムアウトエラー

症状

クライアントアプリケーションが [502 Bad Gateway] エラーを受け取ります。Message Processor はバックエンドサーバーからのレスポンスを受信しないと、このエラーをクライアントアプリケーションに返します。

エラーメッセージ

クライアントアプリケーションは、次のレスポンスコードを受け取ります。

HTTP/1.1 502 Bad Gateway

さらに、次のエラーメッセージも確認できます。

{
     "fault": {
        "faultstring":"Bad Gateway",
        "detail":{
            "errorcode":"messaging.adaptors.http.flow.BadGateway"
        }
     }
    }

考えられる原因

次の表に、この問題に考えられる原因を記載します。

原因	説明	トラブルシューティング手順の適用対象
TLS/SSL handshake タイムアウト	Message Processor とバックエンドサーバー間の TLS/SSL handshake 中にタイムアウトが発生しました。	Edge Private Cloud と Public Cloud のユーザー

原因: TLS/SSL handshake タイムアウト

Apigee Edge では、Edge Message Processor とバックエンドサーバー間での TLS 通信を有効にするために、バックエンドサーバーへの TLS/SSL 接続を設定できます。

TLS/SSL handshake には複数のステップがあります。通常、Message Processor とバックエンドサーバー間の TLS/SSL handshake がタイムアウトになると、このエラーが発生します。

診断

このセクションでは、TLS/SSL handshake タイムアウトを正しく診断する方法を説明します。Edge Private Cloud と Edge Public Cloud に適用される手順を記載します。

Trace セッションの出力を調べる

次の手順では、Apigee Edge Trace ツールを使用して問題の予備診断を行う方法を説明します。

Edge UI で、影響を受けた API プロキシの Trace セッションを有効にします。
失敗した API リクエストのトレースで次のことが明らかになった場合、TLS/SSL handshake タイムアウトエラーが発生した可能性が高いことを意味します。エラーの原因として、バックエンドサーバーのファイアウォールが Apigee からのトラフィックをブロックしていることが考えられます。
1. [502 Bad Gateway] エラーが 55 秒後に発生しているかどうか確認します。これは、Message Processor に設定されるデフォルトのタイムアウト期間です。エラーが 55 秒後に発生している場合、タイムアウトが問題の原因となっている可能性が高いことを意味します。
2. エラーに messaging.adaptors.http.BadGateway と示されているかどうか確認します。このエラーも、通常はタイムアウトが発生したことを意味します。
3. Edge Private Cloud を使用している場合、次に示すトレース出力内の X-Apigee.Message-ID フィールドの値をメモします。追って説明するように、Private Cloud ユーザーはこの ID 値を使用して、さらにトラブルシューティングを進めることができます。
  1. トレースパスで [Analytics Data Recorded] アイコンをクリックします。
  2. [X-Apigee.Message-ID] という名前のフィールドまでスクロールダウンして、このフィールドの値をメモします。

TLS/SSL handshake タイムアウトがエラーの原因であることを確かめるには、Public Cloud または Private Cloud のどちらを使用しているかに応じて、以降の該当するセクションで説明する手順に従ってください。

Edge Private Cloud ユーザーにのみ適用される追加診断手順

Apigee Edge Private Cloud を使用している場合は、次の手順に従うことで、handshake エラーの原因を確認できる可能性があります。この手順では、Message Processor ログファイルを調べて、関連する情報を探します。Edge Public Cloud を使用している場合は、このセクションをスキップして Private Cloud および Public Cloud ユーザーに適用される詳細な診断手順に進んでください。

telnet コマンドを使用して、各 Message Processor から特定のバックエンドサーバーに直接接続できるかどうか確認します。
1. バックエンドサーバーが単一の IP アドレスに解決される場合は、次のコマンドを使用します。
```
    telnet BackendServer-IPaddress 443
```
2. バックエンドサーバーが複数の IP アドレスに解決される場合は、次に示すように、telnet コマンドでバックエンドサーバーのホスト名を使用します。
```
    telnet BackendServer-HostName 443
```
エラーなしでバックエンドサーバーに接続できる場合は、次のステップに進みます。

telnet コマンドが失敗する場合は、ネットワークチームと協力して Message Processor とバックエンドサーバー間の接続を確認する必要があります。
Message Processor のログファイルを調べて、handshake 失敗の証拠を探します。次のファイルを開きます。

/opt/apigee/var/log/edge-message-processor/system.log

一意のメッセージ ID（トレースファイルで見つけた X-Apigee.Message-ID の値）を検索します。メッセージ ID と関連付けられている、次に示す handshake エラーメッセージが記録されているかどうか判断します。
```
org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
    HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
    Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
    isOpen=true handshake timeout
    
```

Message Processor のログファイルにこのエラーが記録されている場合は、さらに調査を進めます。Private Cloud および Public Cloud ユーザーに適用される詳細な診断手順に進んでください。

ログファイル内に handshake メッセージが見つからない場合は、診断情報の収集が必要な場合に進んでください。

Private Cloud および Public Cloud ユーザーに適用される詳細な診断手順

問題をさらに特定するために、tcpdump ツールを使用できます。このツールで TCP/IP パケットを分析し、TLS/SSL handshake 中にタイムアウトが発生したかどうか確認します。

Private Cloud ユーザーは、バックエンドサーバーまたは Message Processor 上で TCP/IP パケットをキャプチャできます。バックエンドサーバー上ではパケットが復号化されるため、バックエンドサーバー上でパケットをキャプチャすることをおすすめします。
Public Cloud ユーザーは、Message Processor にアクセスできませんが、バックエンドサーバー上で TCP/IP パケットをキャプチャすると問題を特定するのに役立ちます。
TCP/IP パケットをキャプチャする場所を決定したら、次の tcpdump コマンドを使用して TCP/IP パケットをキャプチャします。
```
tcpdump -i any -s 0 host <IP address> -w <File name>
    
```
- バックエンドサーバー上で TCP/IP パケットをキャプチャする場合は、tcpdump コマンドで Message Processor のパブリック IP アドレスを使用します。バックエンドサーバーのトラフィックを調べるためのコマンドの使用方法について詳しくは、tcpdump をご覧ください。
- Message Processor 上で TCP/IP パケットをキャプチャする場合は、tcpdump コマンドでバックエンドサーバーのパブリック IP アドレスを使用します。Message Processor のトラフィックを調べるためのコマンドの使用方法について詳しくは、tcpdump をご覧ください。
- バックエンドサーバー / Message Processor に複数の IP アドレスがある場合は、別の tcpdump コマンドを使ってみる必要があります。このツールの詳細とこのコマンドの他のバリアントについては、tcpdump をご覧ください。
Wireshark ツールまたは同様のツールを使用して TCP/IP パケットを分析します。以下のスクリーンショットには、Wireshark での TCP/IP パケットが示されています。
Wireshark の出力から、最初の 3 パケットで 3 方向の TCP handshake が正常に完了したことがわかります。
Message Processor は続く 4 番目のパケットで「Client Hello」メッセージを送信しています。
バックエンドサーバーからの確認応答がないため、Message Processor は事前定義された待機時間が経過してから、5 番目、6 番目、7 番目のパケットで「Client Hello」メッセージを繰り返し再送信します。
Message Processor は 3 回の再試行で確認応答を受け取らないと、接続を閉じることを意味する「FIN, ACK」メッセージをバックエンドサーバーに送信します。
この Wireshark セッションの例に示されているように、バックエンドへの接続は成功しました（ステップ 1）が、バックエンドサーバーがまったく応答しないため、SSL handshake はタイムアウトになりました。

このプレイブックのトラブルシューティング手順を行って、タイムアウトが TLS/SSL handshake エラーの原因であると判断したら、解決策セクションに進みます。

API Monitoring を使用して問題を特定する

API Monitoring では、問題領域を簡単に切り分けて、エラー、パフォーマンス、レイテンシの問題とその原因（デベロッパーアプリ、API プロキシ、バックエンドターゲット、API プラットフォームなど）を診断できます。

API Monitoring を使用して API での 5xx 問題をトラブルシューティングする方法を説明するサンプルシナリオに従ってください。たとえば、messaging.adaptors.http.BadGateway エラーの数が特定のしきい値を超えた時点で、アラートを通知するよう設定することもできます。

解決策

通常、SSL ハンドウェイクタイムアウトが発生する理由は、バックエンドサーバー上のファイアウォール制限によって、Apigee Edge からのトラフィックがブロックされるためです。診断手順に従って handshake エラーの原因がタイムアウトであると判断した場合、ネットワークチームと協力して原因となっているファイアウォール制限を特定して修正する必要があります。

ファイアウォール制限はさまざまなネットワークレイヤで適用されている場合があります。Apigee Edge とバックエンドサーバー間でトラフィックがスムーズに流れるようにするには、すべてのネットワークレイヤで Message Processor IP に関連する制限を確実に削除することが重要です。

ファイウォール制限がない場合や問題が解決されない場合は、診断情報の収集が必要な場合に進んでください。

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

以上の手順に従っても問題が解決されない場合は、次の診断情報を収集してください。Apigee サポートに連絡して、収集した情報を共有してください。

Public Cloud をご利用の場合は、次の情報を提供してください。
1. 組織名
2. 環境名
3. API プロキシ名
4. エラーを再現するための完全な curl コマンド
5. エラーが記録されているトレースファイル
6. バックエンドサーバー上でキャプチャした TCP/IP パケット
Private Cloud をご利用の場合は、次の情報を提供してください。
1. 確認したエラーメッセージ全文
2. API プロキシバンドル
3. エラーが記録されているトレースファイル
4. Message Processor のログ /opt/apigee/var/log/edge-message-processor/logs/system.log
5. バックエンドサーバーまたは Message Processor 上でキャプチャした TCP/IP パケット
このプレイブックのどのセクションを試したかを含め、その他すべての分析情報を詳しく説明していただけると、迅速な問題解決に役立ちます。