ここに表示されているのは Apigee Edge のドキュメントです。
Go to the
Apigee X のドキュメントに移動します。 info
動画
503 Service Unavailable エラーの解決方法については、次の動画をご覧ください。
| 動画 | 説明 |
|---|---|
| バックエンド サーバーからの 503 Service Unavailable エラー | 次の内容について説明します。
|
症状
クライアント アプリケーションが、API プロキシの呼び出しの後に、[Service Unavailable] メッセージ付きの HTTP レスポンス ステータス 503 を受け取ります。
エラー メッセージ
次のいずれかのエラー メッセージを確認できます。
HTTP/1.1 503 Service Unavailable
HTTP/1.1 503 Service Unavailable: Back-end server is at capacity
HTTP レスポンスで次のようなエラー メッセージが表示されることもあります。
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
注: 上記のレスポンス コードとエラー メッセージは一例です。 エラー メッセージなしでエラー レスポンス コードのみが返される場合もあります。 エラー レスポンス コードとエラー メッセージの形式と内容は、バックエンド サーバーの実装によって異なります。
原因
HTTP ステータス コード 503 は、サーバーが現在受信 リクエストを処理できないことを意味します。通常、このエラーは、サーバーがビジー状態であるか、 一時的にメンテナンスのためにダウンしているために発生します。
503 Service Unavailable レスポンスの原因としては、次のことが考えられます。
| 原因 | 説明 | トラブルシューティング手順を実施できるユーザー |
|---|---|---|
| サーバーの過負荷 | バックエンド サーバーが過負荷状態であるか、容量を超えており、新たな 受信クライアント リクエストを処理できません。 | Edge Public Cloud と Private Cloud のユーザー |
| サーバーがメンテナンス中 | バックエンド サーバーが一時的にメンテナンス中である可能性があります。 | Edge Public Cloud と Private Cloud のユーザー |
原因: サーバーの過負荷/サーバーがメンテナンス中
Apigee Edge では、次のような状況でバックエンド サーバーから 503 Service Unavailable エラーが返されることがあります。
- バックエンド サーバーが過負荷状態またはビジー状態で、新しいリクエストを処理できない。
- メンテナンスのため、バックエンド サーバーが一時的にダウンしている。
診断
エラーを診断するには、次の 3 つの方法のいずれかを使用します。
- Trace ツール
- NGINX アクセスログ
- バックエンド サーバーへの直接呼び出し
各方法の詳細については、以下のタブをクリックしてください。
Trace ツール
- トレース セッションを有効にして API 呼び出しを行い、503 Service Unavailable の問題を再現します。
- 失敗したリクエストのいずれかを選択して、トレースを調べます。
- トレースのさまざまなフェーズを調べて、エラーが発生した場所を特定します。
- 503 エラーがターゲット サーバーからのレスポンスとして返されている場合は、
503 エラーの原因はターゲット サーバーです。
次に、ターゲット サーバーから受信した 503 Service Unavailable レスポンスを示すトレースのスクリーンショットの例を示します。
- [Response received from target server] フェーズをクリックし、[Response Headers] セクションと [Response Content] セクションを確認して、有用な情報がないか確認します。
- レスポンス ヘッダーには、エラー レスポンスの送信元を示す Server ヘッダーが含まれている場合があります。
- レスポンス コンテンツには、ターゲット サーバーが 503 レスポンス コードを送信した理由に関する追加情報が含まれている場合があります。
- 以下の手順で
-
トレースの [AX]
（Analytics Data Recorded）フェーズの X-Apigee-fault-source と X-Apigee-fault-code の値を確認して
、503 エラーがターゲット サーバーから発生していることを確認します。
- 次のスクリーンショットに示すように、[AX]（Analytics Data Recorded）フェーズをクリックします。
- [Phase Details] を [Response Headers] セクションまでスクロールし、
X-Apigee-fault-code と X-Apigee-fault-source の値を特定します。
- X-Apigee-fault-source と X-Apigee-fault-code の値が次の表に示す値と一致する場合は、503 エラーがターゲット サーバーから発生していることを確認できます。
レスポンス ヘッダー 値 X-Apigee-fault-source ターゲット X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
- 次のスクリーンショットに示すように、[AX]（Analytics Data Recorded）フェーズをクリックします。
- プロキシ チェーンを使用しているかどうかを確認します。つまり、ターゲット サーバーまたはターゲット エンドポイントが
別のプロキシを Apigee で呼び出しているかどうかを確認します。これを確認するには:
- [Request sent to target server] フェーズに戻り、 [Show Curl] ボタンをクリックして、ターゲット サーバーのホスト エイリアスを特定します。
- ターゲット サーバーのホスト エイリアスが仮想ホスト エイリアスを指している場合は、 プロキシ チェーンです。この場合は、503 Service Unavailable エラーの実際の原因を特定するまで、チェーンされた プロキシに対して上記の手順をすべて繰り返す必要があります。 このような場合、503 Service Unavailable は、他のチェーンされたプロキシの他の ステージでも発生する可能性があります。 このハンドブックを使用して診断できます。
- ターゲット サーバーのホスト エイリアスがバックエンド サーバーを指している場合は、 解決策に進みます。
NGINX アクセスログ
NGINX アクセスログを参照して、ステータス コード 503 がバックエンド サーバーによって送信されたかどうかを特定することもできます。これは、過去に発生した問題の場合 または問題が断続的に発生し、UI でトレースをキャプチャできない場合に便利です。 以下の手順に従って、NGINX のアクセスログから発生元を特定します。
- NGINX アクセスログを確認します。
/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log
- 特定の期間（過去に問題が発生した場合）に特定の API プロキシに対して 503 エラーがあるかどうか、または 503 で失敗しているリクエストがあるかどうかを検索します。
- 503 エラーがある場合は、エラーがバックエンド サーバーから発生しているかどうかを確認します。
X-Apigee-fault-source と X-Apigee-fault-code の値が次の表に示す値と一致する場合は、503 エラーがバックエンド サーバーから発生しています。
レスポンス ヘッダー 値 X-Apigee-fault-source ターゲット X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode 次に、ターゲット サーバーが原因で発生した 503 エラーを示すエントリの例を示します。
- 特定の API プロキシを確認し、 プロキシ チェーンを使用していることを確認します。つまり、 ターゲット サーバーまたはターゲット エンドポイントが Apigee で別のプロキシを呼び出していないことを確認します。プロキシ チェーンを使用している場合は、503 Service Unavailable エラーの実際の原因を特定するまで、チェーンされたプロキシに対して上記の手順をすべて繰り返す必要があります。このような場合、 503 Service Unavailable は、他のチェーンされたプロキシの他のステージでも発生する可能性があります。 このハンドブックを使用して診断できます。
- プロキシ チェーンを使用しておらず、503 エラーがバックエンド サーバーから発生していることを確認した場合は、解決策に進みます。
バックエンド サーバーの呼び出し
バックエンド サーバーを直接呼び出して、Apigee Edge 経由でリクエストを行ったときに受信したのと同じ 503 Service Unavailable レスポンスを取得していることを確認できます。
- リクエストの一部としてバックエンド サーバーに渡す必要があるヘッダー、クエリ パラメータ、認証情報がすべて揃っていることを確認します。
- バックエンド サービスが一般公開されている場合は、curl コマンド、 Postman、その他の REST クライアントを使用して、バックエンド サーバー API を直接呼び出すことができます。
- バックエンド サーバーに Message Processor からのみアクセスできる場合は、 curl コマンド、Postman、その他の REST クライアントを使用して、バックエンド サーバー API を Message Processor から直接呼び出すことができます。
- バックエンド サービスが 503 Service Unavailable エラーを返していることを確認します。
解決策
503 エラーがバックエンド サーバーから発生していることが判明した場合は、次の手順で問題を解決できます。
- バックエンド サーバーがメンテナンスのためにダウンしていることが原因で問題が発生している場合は、 メンテナンス期間後にバックエンド サーバーをオンラインに戻すことができます。
- バックエンド サーバーが過負荷状態であることが原因で問題が発生している場合は、 問題を修正します（バックエンド サーバーにアクセスできる場合）。それ以外の場合は バックエンド サーバー チームと協力して問題を解決する必要があります。
API Monitoring を使用して問題を診断する
API Monitoring では、問題領域を簡単に切り分けて、エラー、パフォーマンス、 レイテンシの問題とその原因（デベロッパー アプリ、API プロキシ、バックエンド ターゲット、 API プラットフォームなど）を診断できます。
ここでは、サンプルの シナリオを使用して、API Monitoring を使用して API で発生した 5xx 問題のトラブルシューティング方法を説明します。たとえば、messaging.adaptors.http.flow.ErrorResponseCode エラーの数が特定のしきい値を超えた時点で、アラートを通知するよう設定することもできます。
診断情報の収集が必要な場合
上記の手順でも問題が解決しない場合は、 次の診断情報を収集して Apigee サポートにお問い合わせください。
パブリック クラウドをご利用の場合は、次の情報を提供してください。
- 組織名
- 環境名
- API プロキシ名
- 503 エラーを再現するための完全な curl コマンド
- 503 Service Unavailable エラーを含むリクエストを含むトレースファイル
- 503 エラーが現在発生していない場合は、過去に 503 エラーが発生した期間とタイムゾーン 情報を提供してください。
プライベート クラウドをご利用の場合は、次の情報を提供してください。
- 失敗したリクエストで確認されたエラー メッセージの全文。
- 503 エラーが発生している組織、環境名、API プロキシ名。
- API プロキシ バンドル。
- 503 Service Unavailable エラーを含むリクエストを含むトレースファイル。
- NGINX アクセスログ。
/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log
- Message Processor ログ。
/opt/apigee/var/log/edge-message-processor/logs/system.log
- 503 エラーが発生した期間とタイムゾーン情報。