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 秒)に接続できなかった。
  • または
  • バックエンド サーバーが接続を拒否した。

診断

  1. Message Processor のログ(/opt/apigee/var/log/edge-message-processor/logs/system.log)で以下のエラーが記録されているかどうかを確認します。
    1. 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)
          
    2. 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]
          
  2. telnet コマンドを使用して、各 Message Processor から該当バックエンド サーバーに直接接続できるかどうかを確認します。
    1. バックエンド サーバーが 1 つの IP アドレスに解決される場合は、次のコマンドを使用します。
      telnet BackendServer-IPaddress 443
          
    2. バックエンド サーバーが複数の IP アドレスに解決される場合は、次のように、そのバックエンド サーバーのホスト名を telnet コマンドで使用します。
      telnet BackendServer-HostName 443
          
  3. バックエンド サーバーに接続できると、[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 ユーザーが行うことができます。

  1. 問題が引き続き発生する場合は、影響を受けている API に対して UI トレースを有効にします。
  2. 失敗した API リクエストに対する UI トレースで、503 Service Unavailable エラーがターゲット リクエスト フローで発生しているか、そのエラーがバックエンド サーバーによって送信されていることが示されている場合、その問題は下り(つまり、Message Processor とバックエンド サーバーの間)で発生しています。
  3. 該当 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 ユーザーはこの手順をスキップしてください。

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

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