500 Internal Server Error（内部サーバーエラー）

症状

クライアントアプリケーションが、API 呼び出しに対するレスポンスとして [Internal Server Error] というメッセージ付きの HTTP ステータスコード 500 を受け取ります。500 Internal Server Error は、Edge 内でのポリシーの実行中のエラー、またはターゲット / バックエンドサーバーでのエラーが原因である可能性があります。

HTTP ステータスコード 500 は汎用のエラーレスポンスです。これは、予期しない状況が発生し、サーバーがリクエストを処理できないことを意味します。このエラーは、通常、他に適切なエラーコードがない場合にサーバーによって返されます。

エラーメッセージ

次のエラーメッセージを受け取ることがあります。

    HTTP/1.1 500 Internal Server Error

場合によっては、詳細が含まれている別のエラーメッセージを受け取ることがあります。サンプルのエラーメッセージを次に示します。

    {
       "fault":{
          "detail":{
             "errorcode":"steps.servicecallout.ExecutionFailed"
          },
          "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
       }
    }

考えられる原因

500 Internal Server Error は、さまざまな原因でスローされることがあります。Edge では、その原因はエラーが発生した場所に基づいて大きく 2 つのカテゴリに分類できます。

原因	詳細	詳細なトラブルシューティング手順の対象
Edge ポリシーでの実行エラー	API プロキシ内のポリシーがなんらかの理由で失敗した可能性があります。	Edge Private Cloud と Public Cloud のユーザー
バックエンドサーバーでのエラー	バックエンドサーバーがなんらかの理由で失敗した可能性があります。	Edge Private Cloud と Public Cloud のユーザー

Edge ポリシーでの実行エラー

API プロキシ内のポリシーがなんらかの理由で失敗した可能性があります。このセクションでは、ポリシーの実行中に 500 Internal Server Error が発生した場合に、この問題をトラブルシューティングする方法について説明します。

診断

Private Cloud と Public Cloud のユーザーに適用される診断手順

エラーに対する UI トレースのセッションがある場合:

エラーの原因がポリシーの実行であるかどうかを確認します。詳しくは問題の発生元の特定をご覧ください。
エラーがポリシーの実行中に発生していた場合は続行します。エラーの原因がバックエンドサーバーであった場合はバックエンドサーバーでのエラーに移動します。
トレースで、500 Internal Server Error で失敗した API リクエストを選択します。
トレースでそのリクエストを調べて、失敗した特定のポリシー、または失敗したポリシーの直後にある「Error」という名前のフローを選択します。
[Properties] セクションまたは [Error] の内容にある [error] 項目を確認して、そのエラーに関する詳細を取得します。
エラーに関して収集した詳細を使用して、その原因の特定を試みます。

Private Cloud ユーザーのみに適用される診断手順

エラーに対する UI トレースのセッションがない場合:

エラーがポリシーの実行中に発生したかどうかを確認します。詳しくは問題の発生元の特定をご覧ください。
エラーの原因がポリシーの実行であった場合は続行します。エラーがポリシーの実行中に発生していた場合は続行します。エラーの原因がバックエンドサーバーであった場合はバックエンドサーバーでのエラーに移動します。
問題の発生元の特定での説明に従って、Nginx のアクセスログを使用して、API プロキシで失敗したポリシーと、一意のリクエストメッセージ ID を特定します。
Message Processor のログ（/opt/apigee/var/log/edge-message-processor/logs/system.log）で、その一意のリクエストメッセージ ID を検索します。
その一意のリクエストメッセージ ID が見つかったら、失敗の原因に関する詳細情報を取得できるかどうかを確認します。

解決策

ポリシーでの問題の原因を特定できたら、ポリシーを修正して再デプロイすることで、その問題の修正を試みます。

以下の例では、さまざまな種類の問題に対する原因と解決策を特定する方法について説明しています。

500 Internal Server Error のトラブルシューティングに関して不明な点がある場合や、Edge 内での問題である可能性がある場合は、Apigee サポートにお問い合わせください。

例 1: バックエンドサーバーでのエラーによる Service Callout ポリシーでの失敗

Service Callout ポリシー内でバックエンドサーバーの呼び出しが 4XX や 5XX などのエラーで失敗している場合は、500 Internal Server Error として処理されます。

次の例では、Service Callout ポリシー内でバックエンドサーバーが 404 エラーで失敗しています。次のエラーメッセージがエンドユーザーに送信されます。

    {
    "fault":
         { "detail":
               { "errorcode":"steps.servicecallout.ExecutionFailed"
               },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
     failed. Reason: ResponseCode 404 is treated as error"
              }
         }
    }

次の UI トレースセッションは、Service Callout ポリシーでのエラーが原因である 500 ステータスコードを示しています。
この例では、Service Callout ポリシーの失敗の理由が [ResponseCode 404 is treated as error] であると [error] プロパティに表示されています。このエラーは、Service Callout ポリシーでバックエンドサーバーの URL を介してアクセスされたリソースが利用不可である場合に発生する可能性があります。
バックエンドサーバーでそのリソースが使用可能であるかどうかを確認します。そのリソースが一時的または完全に利用不可になっているか、別の場所に移動されていることが考えられます。

例 1 の解決策

バックエンドサーバーでそのリソースが使用可能であるかどうかを確認します。そのリソースが一時的または完全に利用不可になっているか、別の場所に移動されていることが考えられます。
Service Callout ポリシーで、有効で存在するリソースを指すように、バックエンドサーバーの URL を修正します。
そのリソースが単に一時的に利用不可になっている場合は、リソースが使用可能になってから API リクエストを試します。

例 2: Extract Variables ポリシーでの失敗

次に、Extract Variables ポリシーでのエラーが原因で 500 Internal Server Error が発生している別の例について、問題をトラブルシューティングして解決する方法を見ていきます。

次の UI トレースセッションは、Extract Variables ポリシーでのエラーが原因である 500 ステータスコードを示しています。
失敗した Extract Variables ポリシーを選択し、[Error Content] セクションまで下にスクロールして詳細を表示します。
[Error Content] には、Extract Variables ポリシーで serviceCallout.oamCookieValidationResponse 変数が利用不可であることが示されています。変数名が示すように、この変数には前回の Service Callout ポリシーのレスポンスが保持されます。
トレースで Service Callout ポリシーを選択すると、serviceCallout.oamCookieValidationResponse 変数が設定されていないことがわかります。このことは、バックエンドサービスの呼び出しが失敗したために、レスポンス変数が空になっていることを表しています。

Service Callout ポリシーは失敗していますが、次に示すように、Service Callout ポリシーで continueOnError フラグが true に設定されているため、Service Callout ポリシーの後のポリシーの実行は続行されています。

    <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
      <DisplayName>Callout.OamCookieValidation</DisplayName>
      <Properties />
      <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
      </Request>
      <Response>serviceCallout.oamCookieValidationResponse</Response>
      <HTTPTargetConnection>
        <Properties />
        <URL>http://{Url}</URL>
      </HTTPTargetConnection>
    </ServiceCallout>

トレースから、この特定の API リクエストに対する一意のメッセージ ID である X-Apigee.Message-ID を次のようにメモします。
1. そのリクエストの [Analytics Data Recorded] フェーズを選択します。
2. 下にスクロールして X-Apigee.Message-ID の値をメモします。
注: 以下の手順を実施できるのは Edge Private Cloud ユーザーだけです。
Message Processor のログ（/opt/apigee/var/log/edge-message-processor/system.log）を表示して、手順 6 でメモしておいた一意のメッセージ ID を検索します。該当 API リクエストで次のエラーメッセージが見つかります。
```
    2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX
    
```
このエラーメッセージは、バックエンドサーバーへの接続中の接続タイムアウトが原因で Service Callout ポリシーが失敗したことを表しています。
接続タイムアウトエラーの原因を特定するには、Message Processor からバックエンドサーバーへの telnet コマンドを実行します。telnet コマンドで次のように [Connection timed out] エラーが表示されます。
```
    telnet mybackend.domain.com 443
    Trying XX.XX.XX.XX...
    telnet: connect to address XX.XX.XX.XX: Connection timed out
    
```
通常、このエラーは以下の状況で発生します。
- バックエンドサーバーが、Edge Message Processor からのトラフィックを許可するように構成されていない。
- バックエンドサーバーが特定のポートをリッスンしていない。
上記の例では、Extract Variables ポリシーが失敗しているものの、実際の原因は、Service Callout ポリシーで Edge がバックエンドサーバーに接続できなかったことです。また、その失敗の原因は、バックエンドサーバーが Edge Message Processor からのトラフィックを許可するように構成されていなかったことです。

お客様独自の Extract Variables ポリシーでは動作が異なり、別の理由で失敗することも考えられます。[error] プロパティ内のメッセージを確認することによって、Extract Variables ポリシーの失敗の原因に応じて問題を適切にトラブルシューティングできます。

例 2 の解決策

Extract Variables ポリシーでのエラーや失敗の原因を適切に修正します。
上記の例での解決策は、Edge Message Processor からバックエンドサーバーへのトラフィックを許可するようにネットワーク構成を修正することでした。このために、バックエンドサーバーで Message Processor の IP アドレスをホワイトリストに登録しました。たとえば、Linux の場合は、iptables を使用してホワイトリストに登録したり、バックエンドサーバーで Message Processor の IP アドレスからのトラフィックを許可したりすることができます。

例 3: JavaCallout ポリシーでの失敗

次に、Java Callout ポリシーでのエラーが原因で 500 Internal Server Error が発生している別の例について、問題をトラブルシューティングして解決する方法を見ていきます。

次の UI トレースセッションは、Java Callout ポリシーでのエラーが原因である 500 ステータスコードを示しています。
失敗した Java Callout ポリシーの前にある「Error」というフローを選択すると、次の図のようなエラーの詳細が表示されます。
この例では、[Properties] セクションにある [error] プロパティを見ると、JavaCallout ポリシー内から Oracle データベースに接続するときに期限切れのパスワードが使用されていることが原因で失敗していることがわかります。お客様独自の Java Callout ポリシーでは動作が異なり、[error] プロパティには別のメッセージが入ります。
JavaCallout ポリシーのコードで、使用する必要がある適切な構成を確認します。

例 3 の解決策

ランタイム例外が発生しないように、Java Callout ポリシーのコードまたは構成を適切に修正します。上記の Java Callout ポリシーでの失敗の例では、問題を解決するために、Oracle データベースへの接続で正しいパスワードを使用する必要があります。

バックエンドサーバーでのエラー

500 Internal Server Error はバックエンドサーバーが発生元である可能性もあります。このセクションでは、バックエンドサーバーからのエラーである場合に、この問題をトラブルシューティングする方法について説明します。

診断

すべてのユーザーに適用される診断手順

その他のバックエンドのエラーには多様な原因が考えられます。それぞれの状況で個別に診断することが必要になります。

エラーの原因がバックエンドサーバーであるかどうかを確認します。詳しくは問題の発生元の特定をご覧ください。
エラーがバックエンドサーバーによって発生した場合は、続行します。エラーがポリシーの実行中に発生していた場合は Edge ポリシーでの実行エラーに移動します。
失敗した API に対する Trace セッションにアクセスできるかどうか、およびバックエンドが Node.js サーバーであるかどうかに応じて、以下の手順に従います。

失敗した API 呼び出しの Trace セッションがない場合:

失敗したリクエストの UI トレースを使用できない場合は、バックエンドサーバーのログを確認して、エラーに関する詳細を取得します。
可能であれば、バックエンドサーバーでデバッグモードを有効にして、エラーと原因に関するさらに詳細な情報を取得します。

失敗した API 呼び出しの Trace セッションがある場合:

Trace セッションがある場合は、以下の手順が問題の診断に役立ちます。

Trace ツールで、500 Internal Server Error で失敗していた API リクエストを選択します。
次の図のように、失敗している API リクエストで [Response received from target server] フェーズを選択します。
[Response Content] セクションでエラーに関する詳細を取得します。
この例では、SOAP Envelope である [Response Content] に障害文字列として [Not Authorized] メッセージが示されています。この問題の原因として最も可能性が高いのは、ユーザーがバックエンドサーバーに適切な認証情報（ユーザー名とパスワード、アクセストークンなど）を渡していないことです。この問題は、バックエンドサーバーに適正な認証情報を渡すことによって修正できます。

バックエンドが Node.js である場合:

バックエンドが Node.js バックエンドサーバーである場合は、Edge UI で該当 API プロキシの Node.js のログを確認します（Public Cloud ユーザーと Private Cloud ユーザーのどちらも Node.js のログを確認できます）。Edge Private Cloud ユーザーは、Message Processor のログ（/opt/apigee/var/log/edge-message-processor/logs/system.log）でエラーに関するより詳細な情報を確認することもできます。

Edge UI の [NodeJS Logs] オプション - API プロキシの [Overview] タブ

解決策

エラーの原因を特定できたら、バックエンドサーバーでその問題を修正します。
バックエンドが Node.js バックエンドサーバーである場合、
1. エラーがカスタムコードからスローされているかどうかを確認し、可能であれば問題を修正します。
2. エラーがカスタムコードからスローされていない場合や、不明な点がある場合は Apigee サポートにお問い合わせください。

問題の発生元の特定

以下のいずれかの手順に従って、500 Internal Server Error が API プロキシ内でポリシーの実行中にスローされたか、バックエンドサーバーによってスローされたかを特定します。

UI での Trace の使用

注: このセクションの手順は Public Cloud ユーザーと Private Cloud ユーザーのどちらも実施できます。

問題が引き続き発生する場合は、影響を受けている API に対して UI でトレースを有効にします。
トレースをキャプチャしたら、レスポンスコードが 500 であることが示されている API リクエストを選択します。
失敗した API リクエストのすべてのフェーズを調べて、どのフェーズで 500 Internal Server Error が返されているかを確認します。
1. エラーがポリシーの実行中にスローされている場合は Edge ポリシーでの実行エラーに進みます。
2. バックエンドサーバーが 500 Internal Server Error で応答している場合はバックエンドサーバーでのエラーに進みます。

API Monitoring の使用

注: このセクションの手順を実施できるのは Public Cloud ユーザーだけです。

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

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

Nginx アクセスログの使用

注: このセクションの手順を実施できるのは Edge Private Cloud ユーザーだけです。

Nginx のアクセスログを参照して、ステータスコード 500 が API プロキシ内でポリシーの実行中にスローされたか、バックエンドサーバーによってスローされたかを特定することもできます。これは、問題が過去または断続的に発生し、UI でトレースをキャプチャできない場合に役立ちます。以下の手順に従って、Nginx のアクセスログから発生元を特定します。

Nginx のアクセスログ（/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log）を確認します。
該当期間に該当 API プロキシに対して 500 Error があるかどうかを検索します。
500 Error が見つかったら、そのエラーがポリシーまたはターゲットサーバーのエラーであるかどうかを確認します（次の図を参照）。
ポリシーエラーを示すサンプルエントリ

ターゲットサーバーエラーを示すサンプルエントリ
ポリシーのエラーかターゲットサーバーのエラーかを特定した後、次のようにします。
1. ポリシーのエラーの場合は、Edge ポリシーでの実行エラーに進みます。
2. ターゲットサーバーのエラーの場合は、バックエンドサーバーでのエラーに進みます。