現在、Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントをご確認ください。 情報
動画
503 Service Unavailable エラーの解決方法について詳しくは、次の動画をご覧ください。
動画 | 説明 |
---|---|
バックエンド サーバーからの 503 Service Unavailable エラー | 以下を確認してください。
|
内容
API プロキシの呼び出しの後、クライアント アプリケーションが HTTP レスポンス ステータス 503 と「Service Unavailable」メッセージを受け取ります。
エラー メッセージ
次のいずれかのエラー メッセージが表示されます。
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」レスポンスには、次の原因が考えられます。
原因 | Description | トラブルシューティングの手順を実施できるユーザー |
---|---|---|
サーバーの過負荷 | バックエンド サーバーが過負荷になっているか、処理能力を超えているため、新しい受信クライアント リクエストを処理できません。 | Edge Public Cloud ユーザーと Private Cloud ユーザー |
メンテナンス中のサーバー | バックエンド サーバーが一時的にメンテナンス中の可能性があります。 | Edge Public Cloud ユーザーと Private Cloud ユーザー |
原因: メンテナンス中のサーバー/サーバーの過負荷
Apigee Edge では、次のいずれかの状況でバックエンド サーバーから 503 Service Unavailable エラーが返されることがあります。
- バックエンド サーバーが過負荷またはビジー状態となり、新しいリクエストを処理できません。
- メンテナンスのため、バックエンド サーバーが一時的に停止しています。
診断
エラーを診断するには、次の 3 つの方法のいずれかを使用します。
- Trace ツール
- NGINX アクセスログ
- バックエンド サーバーへの直接呼び出し
以下の各タブをクリックして、それぞれの方法をご確認ください。
Trace ツール
- トレース セッションを有効にし、API 呼び出しを行って問題を再現します(503 Service Unavailable)。
- 失敗したリクエストの 1 つを選択し、トレースを調べます。
- トレースのさまざまなフェーズを確認し、エラーが発生した場所を特定します。
- ターゲット サーバーからのレスポンスとして 503 エラーが返された場合、503 エラーの原因はターゲット サーバーです。
次のトレースのスクリーンショットは、ターゲット サーバーから受信した 503 Service Unavailable レスポンスを示しています。
- [Response received from target server] フェーズをクリックし、[Response Headers] と [Response Content] のセクションに、次のような有用な情報があるかどうかを確認します。
- レスポンス ヘッダーには、エラー レスポンスの送信元を示す Server ヘッダーが含まれる場合があります。
- [Response Content](レスポンス コンテンツ)には、ターゲット サーバーが 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
- プロキシ チェーンを使用しているかどうか(ターゲット サーバー/ターゲット エンドポイントが Apigee で別のプロキシを呼び出しているかどうか)を確認します。これを確認するには:
- [Request sent to target server] フェーズに戻り、[Show Curl] ボタンをクリックして、ターゲット サーバーのホスト エイリアスを確認します。
- ターゲット サーバーのホスト エイリアスが仮想ホスト エイリアスを参照している場合、これはプロキシ チェーンです。この場合、503 Service Unavailable エラーの実際の原因を特定するまで、チェーンされたプロキシに対して上記の手順をすべて繰り返す必要があります。このような場合、他のチェーンされたプロキシで他のステージで 503 Service Unavailable が発生する可能性があり、こちらのハンドブックを使用して診断できます。
- ターゲット サーバーのホスト エイリアスがバックエンド サーバーを参照している場合は、解決策に進みます。
NGINX アクセスログ
NGINX の lccess ログでも、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 クライアントを使用して、Message Processor から直接バックエンド サーバーの API を呼び出すことができます。
- バックエンド サービスが実際に 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 エラーが発生した期間。