502 Bad Gateway（不正なゲートウェイ）

Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントに移動します。 情報

症状

API 呼び出しのレスポンスで、クライアント アプリケーションが HTTP ステータス コード 502、「Bad Gateway」というメッセージを受け取ります。

HTTP ステータス コード 502 は、クライアントが、リクエストを実際に処理する必要があるバックエンド サーバーから有効なレスポンスを受信していないことを意味します。

エラー メッセージ

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

HTTP/1.1 502 Bad Gateway

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

<html>
<head>
<title>Error</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

エラーがバックエンド サーバーから発生した場合は、次のようなメッセージが表示されることがあります。バックエンドからのエラー メッセージは、その実装に完全に依存します。

<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>

考えられる原因

Apigee Edge を通過する API で 502 Bad Gateway エラーが発生する原因として、次のようなものが考えられます。

原因 説明 トラブルシューティング手順の適用対象
プールで使用可能な MP がない このエラーは、プール内のすべての MP が使用できない場合（ダウンしているか、ビジー状態で応答していない場合）に発生します。 Edge Private Cloud ユーザー
ルーターと MP 間の SSL 構成が正しくない このエラーは、クライアントの CA 署名付きルート証明書が Edge Router のトラストストアにない場合に発生します。 Edge Private Cloud ユーザー
バックエンド サーバーからのエラー このエラーは、バックエンド サーバーが失敗してこのレスポンスを送信した場合に発生します。 Edge Public Cloud と Private Cloud のユーザー

原因: プールで使用可能な MP がない

このエラーは、特定のリージョン/データセンター内のすべての Message Processor が使用できない（すべてダウンしているなど）場合に発生します。

Apigee Edge は、特定のリージョン/データセンターの受信 API トラフィック（リクエスト）が常に Router から同じリージョン/データセンターの Message Processor（MP）に転送されるように構成されています。Apigee Edge コンポーネントは、1 つのリージョン/データセンターに設定されることもあれば、複数のリージョン/データセンターに設定されることもあります。各リージョン/データセンターには、2 つ以上の Router と Message Processor が構成されます。

診断

  1. 複数のリージョン/データセンターがある場合は、API リクエストが 502 Bad Gateway エラーで失敗しているリージョン/データセンターを特定します。これは、ユーザーが 502 エラーを観測しているリージョンを特定するか、異なるリージョンに属する各ルーターの /opt/apigee/var/log/edge-router/nginx/ ディレクトリにある NGINX アクセスログを確認することで確認できます。
  2. NGINX エラーログ（/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log）に次のエラーが表示されます。
    2019/06/24 15:26:00 [error] 4796#4796: *56357443 no live upstreams while connecting to upstream, client: <Router_IP_address>, server: <HostAlias>, request: "PUT <BasePath> HTTP/1.1", upstream: "http://<ListOfMP-IP_R-MP-Port>/<BasePath>", host: "<HostAlias>"

シナリオ 1: すべての Message Processor がダウンしている

  1. 特定のリージョン/データセンターの Message Processor が稼働しているかどうかを確認します。
  2. すべての Message Processor が停止している場合は、再起動します。

解決策

次のコマンドを使用して、すべての Message Processor を再起動します。

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

シナリオ 2: すべての Message Processor が進行中のリクエストの処理でビジー状態である

このエラーは、特定のリージョン/データセンター内のすべての Message Processor が、進行中のリクエストの処理でビジー状態になっているため使用できないことが Router によって検出された場合に発生します。

  1. 特定のリージョン/データセンターの Message Processor が稼働しているかどうかを確認します。
  2. すべての Message Processor が起動してアクティブになっている場合は、Message Processor の CPU 使用率が高いかどうかを確認し、次のコマンドを使用して 30 秒ごとに 3 つのスレッドダンプを生成します。
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. Message Processor のメモリ使用率が高い場合は、次のコマンドを使用してヒープダンプを生成します。
    sudo -u apigee /bin/jmap -dump:live,format=b,file=
  4. 次のコマンドを使用して Message Processor を再起動します。これにより、CPU とメモリの使用率が下がります。
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. API 呼び出しをモニタリングし、まだ問題が存在するかどうかを確認します。
  6. CPU/メモリ使用量の高い原因を調査できるように、Apigee サポートにスレッドダンプ、ヒープダンプ、Message Processor のログ（/opt/apigee/var/log/edge-message-processor/logs/system.log）を提供します。

原因: Router と MP 間の SSL 構成が正しくない

診断

  1. NGINX アクセスログ（/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log）を確認します。次のように 502 レスポンスが表示されます。
        2019-07-23T12:13:42+03:00	sc-10-254-226-23	10.X.X.X:53634	10.X.X.X:8998	0.000	-	-	502	502	189	344	GET <path> curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2	<host alias>	mp-10-254-226-23-23706-8552529-1	10.129.107.101	-	-	-1	-	-	dc-2	gateway-2	green	-	gateway-2	dc-2	op	pilot	http	-
  2. NGINX エラーログ（/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log）を確認します。次のようなエラーが表示されます。
    	2019/07/30 17:02:24 [error] 7691#7691: *11753633 peer closed connection in SSL handshake while SSL handshaking to upstream, client: X.X.X.X, server: <HostAlias>, request: "GET /no-target HTTP/1.1", upstream: "https://X.X.X.X:8998/no-target", host: "<HostAlias>"
  3. これは、Router と Message Processor 間の SSL handshake が失敗したことを示しています。
  4. 手順 1 と 2 のエラー メッセージをよく見ると、Message Processor との通信に使用されるポート番号は 8998 で、これは安全でないポートですが、プロトコルは SSL（https）です。通常、使用されるセキュア ポート番号は 8443 です。安全な通信に安全でないポートが使用されているため、SSL ハンドシェイクが失敗します。
  5. 通常、これは、Router と Message Processor 間の SSL の構成中に、手順を省略したり、誤った値を設定したりした場合に発生します。こちらに記載されている手順を参照してください。
    たとえば、
    1. /opt/apigee/customer/application/message-processor.properties as shown below
      でポート番号が 8443 ではなく 8998 として指定されています。
              conf/message-processor-communication.properties+local.http.port=8998
    2. ディレクトリ /opt/nginx/conf.d/* の Router 構成ファイルが削除されておらず、SSL 構成の実行中に Router が再起動されていない。このシナリオでは、構成ファイル内の Message Processor のポート番号は 8998 のままになります。

解決策

  1. Router と Message Processor 間の TLS の構成に記載されているすべての手順が正しく実行されていることを確認します。
  2. 問題が解決しない場合は、診断情報の収集に進みます。

原因: バックエンド サーバーからのエラー

診断

  1. エラーが毎回発生する場合は、失敗したリクエストの UI トレースをキャプチャできます。失敗したリクエストを選択し、トレースのさまざまなフェーズをナビゲートします。バックエンド サーバー自体から「502 Bad Gateway」が返される場合は、バックエンド サーバーで障害が発生したことが原因である可能性があります。
    バックエンド サーバーから 502 Bad Gateway が返されたことを示すトレース
  2. 問題が断続的に発生し、トレースをキャプチャできない場合は、
    1. Public Cloud ユーザーの場合は、API Monitoring を使用して 502 エラーの詳細を確認できます。
      1. 障害コードが messaging.adaptors.http.flow.ErrorResponseCode で、障害発生元が target の場合は、エラーの原因はバックエンド サーバーです。
    2. Private Cloud ユーザーの場合は、NGINX アクセスログを分析できます。
      /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
      失敗したリクエストのエントリは次のようになります。
      2017-02-24T14:42:12+00:00	rt-01	192.8.155.2:18118	192.168.84.166:8998	10.225	-	-	502	502	440	0	GET /adv-eadlg-test/documents?type=doctype HTTP/1.1	rt-02efawae234-1234	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36	myorg-dev.apigee.net	 rt-02efawae234-1234	6	-	false	target	messaging.adaptors.http.flow.ErrorResponseCode	null/null	-	/organizations/myorg/environments/dev/apiproxies/api123
      1. 障害コードが messaging.adaptors.http.flow.ErrorResponseCode で、障害発生元が target の場合は、エラーの原因はバックエンド サーバーです。

解決策

  1. バックエンド サーバー チームと協力して、バックエンドでこの問題を修正します。

診断情報を収集する

  1. NGINX アクセスログ
    （/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log）
    とエラーログ
    （/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log）。
  2. Message Processor のログ
    （/opt/apigee/var/log/edge-message-processor/logs/system.log）。