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 レスポンスで次のエラーメッセージも確認できます。

    {
       "fault": {
          "faultstring": "The Service is temporarily unavailable",
          "detail": {
               "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
           }
        }
    }

考えられる原因

HTTP ステータスコード 503 はサーバーが現在利用不可であることを意味します。Apigee Edge では、この問題は受信（上り）または送信（下り）のどちらの接続でも発生する可能性があります。このエラーは通常、サーバーがビジー状態であるか、なんらかの理由（一時的なメンテナンスなど）で停止しているために発生します。また、クライアントとサーバーの間で TLS/SSL handshake が失敗した場合にも発生します。

503 Service Unavailable レスポンスで考えられる原因は次のとおりです。

原因	説明	トラブルシューティング手順を実施できるユーザー
サーバーの過負荷	サーバーが過負荷状態であり、新たな受信クライアントリクエストを処理できません。	Private ユーザーと Public Cloud ユーザー
接続エラー	ネットワークまたは接続性の問題により、クライアントがサーバーに接続できなくなっています。	Private Cloud ユーザーのみ
SSL handshake の失敗	クライアントとサーバーの間で TLS/SSL handshake が失敗しています（このような場合のトラブルシューティングは別のトピックで説明しています）。	Private ユーザーと Public Cloud ユーザー

サーバーの過負荷

サーバーが過負荷状態であるか、新たなリクエストを処理できない場合に、次のエラーが発生することがあります。

    HTTP/1.1 503 Service Unavailable: Back-end server is at capacity

診断

この問題を診断するには、エラーが受信（上り）と送信（下り）のどちらの接続で発生しているかを特定します。それを特定する方法については問題の発生元の特定をご覧ください。

エラーが受信（上り）で発生している場合:

Private Cloud ユーザー: Edge Router で Average Load/CPU/Memory 使用量が高くなっているかどうかを確認します。
Public Cloud ユーザー: Edge Router へのアクセス権がありません。Apigee サポートにお問い合わせください。

エラーが送信（下り）で発生している場合:

すべてのユーザー: バックエンドサーバーで Average Load/CPU/Memory 使用量が高くなっているかどうかを確認します。

解決策

Edge Router が過負荷状態になっている場合:

Private Cloud ユーザー: Edge Router を再起動してから使用状況をモニタリングして、問題が解消されているかどうかを確認します。問題が解消されない場合は、Apigee サポートにお問い合わせください。
Public Cloud ユーザー: Edge Router へのアクセス権がありません。Apigee サポートにお問い合わせください。

バックエンドサービスが過負荷状態になっている場合:

すべてのユーザー: 該当するバックエンドサーバーを再起動してからモニタリングして、問題が解消されているかどうかを確認します。
すべてのユーザー: 問題が解消されない場合は、該当するバックエンドサーバーの容量を増やしたり、そのバックエンドサーバーでの問題を修正したりする必要があるかどうかを確認します。

このトラブルシューティング手順はお役に立ちましたか。フィードバックをお送りください。

接続エラー

Apigee Edge Message Processor がバックエンドサーバーに接続しようとして、次のいずれかの問題が発生したときに接続エラーになります。

Message Processor が、プリセットされている接続タイムアウト時間内（デフォルトでは 3 秒）に接続できなかった。
バックエンドサーバーが接続を拒否した。

診断

Message Processor のログ（/opt/apigee/var/log/edge-message-processor/logs/system.log）で以下のエラーが記録されているかどうかを確認します。

onConnectTimeout エラーは、プリセットされている接続タイムアウト時間内に Message Processor がバックエンドサーバーに接続できなかったことを表しています。

    2016-06-23 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@10 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11:80 resolvedAddress=www.abc.com/11.11.11.11
    2016-06-23 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)

java.net.ConnectException: Connection refused エラーは、バックエンドサーバーによって接続が拒否されたことを表しています。

    14:40:16.531 +0530
    2016-06-17 09:10:16,531 org:myorg env:prod api:www.abc.com rev:1 rrt07eadn-22739-40983870-15 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() : connect to www.abc.com:11.11.11.11:443 failed with exception {}
    java.net.ConnectException: Connection refused
    at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:1.7.0_75]
    at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) ~[na:1.7.0_75]
    at com.apigee.nio.ClientChannel.finishConnect(ClientChannel.java:121) ~[nio-1.0.0.jar:na]
    at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:108) ~[nio-1.0.0.jar:na]

telnet コマンドを使用して、各 Message Processor から該当バックエンドサーバーに直接接続できるかどうかを確認します。
1. バックエンドサーバーが 1 つの IP アドレスに解決される場合は、次のコマンドを使用します。
```
telnet BackendServer-IPaddress 443
    
```
2. バックエンドサーバーが複数の IP アドレスに解決される場合は、次のように、そのバックエンドサーバーのホスト名を telnet コマンドで使用します。
```
telnet BackendServer-HostName 443
    
```
バックエンドサーバーに接続できると、[Connected to backend-server] のようなメッセージが表示されます。バックエンドサーバーに接続できない場合、該当バックエンドサーバーのホワイトリストに Message Processor の IP アドレスが登録されていないことが原因である可能性があります。

解決策

Edge Message Processor からバックエンドサーバーへのトラフィックが許可されように、該当バックエンドサーバーで Message Processor の IP アドレスをホワイトリストに登録します。たとえば、Linux の場合は、iptables を使用してホワイトリストに登録したり、バックエンドサーバーで Message Processor の IP アドレスからのトラフィックを許可したりすることができます。

問題が解消されない場合は、ネットワーク管理者と協力して、問題を特定して修正します。ご不明な点がございましたら Apigee サポートにお問い合わせください。

このトラブルシューティング手順はお役に立ちましたか。フィードバックをお送りください。

SSL handshake の失敗

1 つのトラブルシューティングハンドブック全体が、TLS/SSL handshake のエラー専用になっています。SSL handshake の失敗をご覧ください。

問題の発生元の特定

特定の種類のエラーは、受信（上り）または送信（下り）のどちらの接続でも発生する可能性があります。受信（上り）エラーはクライアントアプリケーションと Edge の間で発生します。送信（下り）エラーは Edge とバックエンドサーバーの間で発生します。このような問題を診断するには、まず、エラーが上りと下りのどちらで発生しているかを特定します。

上り接続と下り接続について

Edge では、503 Service Unavailable エラーは受信と送信のどちらの接続でも発生する可能性があります。

受信（上り）接続 - クライアントアプリケーションと Edge Router の間の接続。Router は Apigee Edge のコンポーネントとして、システムに対して行われた受信リクエストを処理します。
送信（下り）接続 - Edge Message Processor とバックエンドサーバーの間の接続です。Message Processor は Apigee Edge のコンポーネントであり、バックエンドサーバーへの API リクエストのプロキシとして機能します。

Edge Public Cloud ユーザーは、Router や Message Processor などの内部コンポーネントを認識していないことがあります。Public Cloud ユーザーはこれらの内部コンポーネントが見えず、アクセスすることもできません。可能な場合は、問題を調査するために、これらのコンポーネントに直接アクセスする必要がない代替手段をご提供します。

次の図は、Apigee Edge に対する上り接続と下り接続を示しています。

503 Service Unavailable エラーが発生している場所の特定

以下のいずれかの手順に従って、503 Service Unavailable エラーが上りと下りのどちらの接続で発生しているかを特定します。

手順 1: UI トレースの使用（すべてのユーザー）

この手順は Public Cloud ユーザーまたは Private Cloud ユーザーが行うことができます。

問題が引き続き発生する場合は、影響を受けている API に対して UI トレースを有効にします。
失敗した API リクエストに対する UI トレースで、503 Service Unavailable エラーがターゲットリクエストフローで発生しているか、そのエラーがバックエンドサーバーによって送信されていることが示されている場合、その問題は下り（つまり、Message Processor とバックエンドサーバーの間）で発生しています。
該当 API 呼び出しのトレースを取得できない場合、その問題は上り（クライアントアプリケーションと Router の間）で発生しています。

手順 2: API Monitoring の使用（Apigee Cloud ユーザーのみ）

Private Cloud ユーザーはこの手順をスキップしてください。

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

API Monitoring を使用して API での 5xx の問題をトラブルシューティングする方法の実例を示しているサンプルシナリオに従ってください。たとえば、messaging.adaptors.http.flow.ServiceUnavailable の失敗回数が所定のしきい値を超えたときにアラートが通知されるようにセットアップすることもできます。

手順 3: Nginx のアクセスログの使用（Apigee Private Cloud ユーザーのみ）

Public Cloud ユーザーはこの手順をスキップしてください。

問題が過去または断続的に発生し、トレースをキャプチャできない場合は、以下の手順に従います。

Nginx のアクセスログ（/opt/apigee/var/log/edge-router/nginx/ org-env.port_access_log）を確認します。
該当 API プロキシに対して 503 エラーがあるかどうかを検索します。
該当時刻に該当 API プロキシに対する 503 エラーを確認できた場合、その問題は下り接続（Message Processor とバックエンドサーバーの間）で発生しています。
確認できなかった場合、その問題は上り接続（クライアントアプリケーションと Router の間）で発生しています。