Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントに移動します。 情報
症状
クライアント アプリケーションが、API 呼び出しに対するレスポンスとして、HTTP ステータス コード 504 とメッセージ Gateway Timeout を受け取ります。
このエラー レスポンスは、クライアントが API 呼び出しの実行中に Apigee Edge またはバックエンド サーバーからタイムリーなレスポンスを受信しなかったことを示します。
エラー メッセージ
クライアント アプリケーションは、次のレスポンス コードを受け取ります。
HTTP/1.1 504 Gateway Time-out
cURL またはウェブブラウザを使用してこのようなプロキシを呼び出すと、次のエラーが発生することがあります。
<!DOCTYPE html> <html> <head> <title>Error</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>An error occurred.</h1> <p>Sorry, the page you are looking for is currently unavailable.<br/> Please try again later.</p> </body> </html>
タイムアウトの原因
Edge プラットフォームを経由する API リクエストの一般的なパスは、次の図に示すように、クライアント > Router > Message Processor > バックエンド サーバーです。
クライアント、Router、Message Processor、バックエンド サーバーなど、Apigee Edge ランタイム フローのすべてのコンポーネントは、API リクエストの完了に時間がかかりすぎないように、適切なデフォルトのタイムアウト値で設定されています。フロー内のコンポーネントが、タイムアウト構成で指定された期間内に上流コンポーネントからレスポンスを取得しない場合、そのコンポーネントはタイムアウトし、通常は 504 Gateway Timeout エラーを返します。
このプレイブックでは、Router のタイムアウト時に発生する 504 エラーのトラブルシューティングと解決方法について説明します。
Router のタイムアウト
Apigee Edge の Router で構成されているデフォルトのタイムアウトは 57 秒です。これは、Edge で API リクエストが受信されてからレスポンスが返送されるまでの API プロキシの最大実行時間です。これには、バックエンド レスポンスと実行されるすべてのポリシーが含まれます。デフォルトのタイムアウトは、 Router の I/O タイムアウトを構成するで説明されているように、Router/仮想ホストでオーバーライドできます。
考えられる原因
Edge で、ルーターのタイムアウトが原因で発生する 504 Gateway Timeout エラーの一般的な原因は次のとおりです。
| 原因 | 説明 | トラブルシューティングの実施対象 |
|---|---|---|
| Router のタイムアウト構成が正しくない | これは、ルーターが正しくない I/O タイムアウト期間で構成されている場合に発生します。 | Edge Public Cloud と Private Cloud のユーザー |
共通の診断手順
次のいずれかのツールまたは手法を使用して、このエラーを診断します。
- API モニタリング
- NGINX アクセスログ
API Monitoring
API Monitoring を使用してエラーを診断するには:
- [Analyze] > [API Monitoring] > [Investigate] ページに移動します。
5xxエラーでフィルタし、期間を選択します。- ステータス コードと時間をプロットします。
-
504エラーが表示されている特定のセルをクリックすると、次の図のように、エラーの詳細とエラーに関するログが表示されます。504 エラーを示す例
- 右側のペインで、[ログを表示] をクリックします。
[トラフィック ログ] ウィンドウで、一部の
504エラーについて次の詳細を確認します。- リクエスト: 呼び出しに使用されるリクエスト メソッドと URI を提供します。
- 応答時間: リクエストの合計経過時間を示します。
上記の例では
- リクエスト が
GET /test-timeoutを指している。 - 応答時間 は
57.001秒です。これは、値が Router に設定されたデフォルトの I/O タイムアウト（57 秒）に非常に近いため、Message Processor が応答する前に Router がタイムアウトしたことを示しています。
API Monitoring の GET logs API を使用して、すべてのログを取得することもできます。たとえば、
org、env、timeRange、statusのログをクエリすると、クライアントがタイムアウトしたトランザクションのすべてのログをダウンロードできます。API Monitoring では、これらの
504エラーのプロキシが-（not set）に設定されるため、API（Logs API）を使用して、仮想ホストとパスに関連付けられたプロキシを取得できます。For example :
curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https
- レスポンス時間で追加の
504エラーを確認し、すべての504エラーでレスポンス時間が一致しているか（Router に設定されている I/O タイムアウト値である 57 秒）を確認します。
NGINX アクセスログ
NGINX アクセスログを使用してエラーを診断するには:
- NGINX アクセスログを確認します。
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log - 特定の期間に
504エラーが発生したかどうか（問題が過去に発生した場合）、または504で失敗しているリクエストがまだあるかどうかを検索します。 - 一部の
504エラーについては、次の点に注意してください。- 応答時間
- リクエスト URI
この例では、次の情報が表示されます。
-
リクエスト時間:
57.001秒。これは、Router が 57.001 秒後にタイムアウトしたことを示します。 - リクエスト:
GET /test-timeout - ホスト エイリアス:
myorg-test.apigee.net
-
リクエスト時間が、Router/仮想ホストで構成されている I/O タイムアウトと同じかどうかを確認します。この場合、Message Processor がこの期間内に応答しなかったため、Router がタイムアウトしたことを意味します。
上記の NGINX アクセスログ エントリの例では、リクエスト時間の
57.001秒は、Router に設定されたデフォルトの I/O タイムアウトに非常に近い値です。これは、Message Processor が応答する前に Router がタイムアウトしたことを明確に示しています。 - リクエスト フィールドのベースパスを使用して、リクエストが行われた API プロキシを特定します。
原因: Router のタイムアウト構成が正しくない
診断
- Message Processor が応答する前に Router がタイムアウトしたことが原因で
504エラーが発生したかどうかを判断します。これを行うには、API モニタリングのレスポンス時間と Router のリクエスト時間（両方のフィールドは同じ情報を表しますが、名前が異なります）が、Router / 仮想ホストで構成された I/O タイムアウトと同じであり、障害の原因、障害プロキシ、障害コードの各フィールドが-に設定されていることを確認します。これには、 一般的な診断手順で説明されているように、API モニタリングまたは NGINX アクセスログを使用します。 -
Router または特定の仮想ホストで構成された I/O タイムアウト値が、Message Processor または特定の API プロキシで構成された値よりも小さいかどうかを確認します。
この操作は、このセクションの手順に沿って行うことができます。
仮想ホストの I/O タイムアウトを確認する
Edge UI
Edge UI を使用して仮想ホストのタイムアウトを確認する手順は次のとおりです。
- Edge UI にログインします。
- [Admin] > [Virtual Hosts] に移動します。
- タイムアウトの問題が発生している特定の環境を選択します。
- I/O タイムアウト値を確認する特定の仮想ホストを選択します。
- [プロパティ] で、[プロキシ読み取りタイムアウト] の値（秒単位）を確認します。
上記の例では、プロキシの読み取りタイムアウト が
120の値で構成されています。つまり、この仮想ホストで構成された I/O タイムアウトは 120 秒です。
Management API
次の管理 API を使用して、プロキシの読み取りタイムアウトを確認することもできます。
-
仮想ホストの取得 API を実行して、次のように
virtualhost構成を取得します。パブリック クラウド ユーザー
curl -v -X GET https://api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUALHOST_NAME -u USERNAME
Private Cloud ユーザー
curl -v -X GET http://MANAGEMENT_SERVER_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/v/virtualhosts/VIRTUALHOST_NAME -u USERNAME
ここで
ORGANIZATION_NAME は組織の名前です
ENVIRONMENT_NAME は、環境の名前です。
VIRTUALHOST_NAME は仮想ホストの名前です。
-
プロパティ
proxy_read_timeoutに構成されている値を確認します。仮想ホストの定義例
{ "hostAliases": [ "api.myCompany,com", ], "interfaces": [], "listenOptions": [], "name": "secure", "port": "443", "retryOptions": [], "properties": { "property": [ { "name": "proxy_read_timeout", "value": "120" } ] }, "sSLInfo": { "ciphers": [], "clientAuthEnabled": "false", "enabled": "true", "ignoreValidationErrors": false, "keyAlias": "myCompanyKeyAlias", "keyStore": "ref://myCompanyKeystoreref", "protocols": [] }, "useBuiltInFreeTrialCert": false }上記の例では、
proxy_read_timeoutは120の値で構成されています。つまり、この仮想ホストで構成された I/O タイムアウトは 120 秒です。
router.properties ファイルの I/O タイムアウトを確認する
- Router マシンにログインします。
/opt/nginx/conf.dディレクトリでプロパティproxy_read_timeoutを検索し、次のように新しい値が設定されているかどうかを確認します。grep -ri "proxy_read_timeout" /opt/nginx/conf.d
-
特定の仮想ホスト構成ファイルで、プロパティ
proxy_read_timeoutに設定された値を確認します。grep コマンドのサンプル結果
/opt/nginx/conf.d/0-default.conf:proxy_read_timeout 57; /opt/nginx/conf.d/0-edge-health.conf:proxy_read_timeout 1s;
上記の出力例では、デフォルトの仮想ホストの構成ファイルである
0-default.confで、プロパティproxy_read_timeoutが新しい値57で設定されていることがわかります。これは、Router のデフォルトの仮想ホストで I/O タイムアウトが 57 秒に構成されていることを示します。複数の仮想ホストがある場合は、それぞれの情報が表示されます。504エラーで失敗した API 呼び出しに使用した特定の仮想ホストのproxy_read_timeoutの値を取得します。
API プロキシでの I/O タイムアウトの確認
I/O タイムアウトは次の場所で確認できます。
- API プロキシのターゲット エンドポイント
- API プロキシの ServiceCallout ポリシー
API プロキシのターゲット エンドポイントで I/O タイムアウトを表示する
- Edge UI で、I/O タイムアウト値を表示する特定の API プロキシを選択します。
- 確認する特定のターゲット エンドポイントを選択します。
TargetEndpoint構成の<HTTPTargetConnection>要素に、適切な値のio.timeout.millisプロパティがあることを確認します。たとえば、次のコードの I/O タイムアウトは 120 秒に設定されています。
<Properties> <Property name="io.timeout.millis">120000</Property> </Properties>
API プロキシの ServiceCallout ポリシーで I/O タイムアウトを表示する
- Edge UI で、ServiceCallout ポリシーの新しい I/O タイムアウト値を表示する特定の API プロキシを選択します。
- 確認する特定の ServiceCallout ポリシーを選択します。
-
<ServiceCallout>構成の下に適切な値を持つ要素<Timeout>があることを確認します。たとえば、次のコードの I/O タイムアウトは 120 秒になります。
<Timeout>120000</Timeout>
Message Processor の I/O タイムアウトを確認する
- Message Processor マシンにログインします。
-
次のコマンドを使用して、
/opt/apigee/edge-message-processor/confディレクトリでプロパティHTTPTransport.io.timeout.millisを検索します。grep -ri "HTTPTransport.io.timeout.millis" /opt/apigee/edge-message-processor/conf
出力例
/opt/apigee/edge-message-processor/conf/http.properties:HTTPTransport.io.timeout.millis=55000
- 上記の出力例では、
http.propertiesのHTTPTransport.io.timeout.millisプロパティが55000の値で設定されていることに注意してください。これは、Message Processor で I/O タイムアウトが 55 秒に正常に構成されたことを示します。
Router と Message Processor で構成されたタイムアウトを特定したら、Router/仮想ホストが Message Processor/API プロキシよりも低いタイムアウト値で構成されているかどうかを確認します。
下の表に示すように、すべてのレイヤに設定された値をメモします。
| Router のタイムアウト（秒） | 仮想ホストのタイムアウト（秒） | Message Processor のタイムアウト（秒） | API プロキシのタイムアウト（秒） |
|---|---|---|---|
| 57 | - | 55 | 120 |
この例では
- デフォルト値の 57 秒は Router で構成されます。
- 特定の仮想ホストにタイムアウト値が設定されていません。つまり、ルーター自体に構成されているデフォルト値の 57 秒が使用されます。
- Message Processor では、デフォルト値の 55 秒が構成されています。
- ただし、特定の API プロキシでは 120 秒の値が構成されています。
タイムアウト値が大きいのは API プロキシのみで、Router は引き続き 57 秒で構成されます。そのため、Message Processor/バックエンドがリクエストを処理している間、Router は 57 秒でタイムアウトします。これにより、Router はクライアント アプリケーションに 504 Gateway Timeout エラーで応答します。
解決策
この問題を解決するには、次の手順で Router と Message Processor の適切な I/O タイムアウトを構成します。
- Apigee Edge を介した API リクエスト フローに関与するさまざまなコンポーネントに設定するタイムアウト値については、 I/O タイムアウトの構成に関するベスト プラクティスをご覧ください。
- 上記の例で、バックエンド サーバーでより長い時間が必要なため、タイムアウト値を大きくする必要があると判断し、Message Processor のタイムアウト値を 120 秒に増やした場合は、Router でより大きなタイムアウト値（
123 secondsなど）を設定します。新しいタイムアウト値がすべての API プロキシに影響しないようにするには、特定の API プロキシで使用される特定の仮想ホストでのみ123 secondsの値を設定します。 - Router の I/O タイムアウトを構成するの手順に沿って、仮想ホストのタイムアウトを設定します。