HTTP 504 Gateway Timeout の概要

Scrapeless Web Unlocker は、アップストリームのタイムアウトと、受け入れられたソースデータとを区別する必要があるワークフロー向けに、公開ページのコンテンツを取得します。

HTTP 504 Gateway Timeout は、ゲートウェイまたはプロキシとして動作するサーバーが、リクエストを完了するために必要なアップストリームサーバーから、期限内に応答を受け取れなかったことを意味します。ゲートウェイ側の時計は期限切れになっていますが、遅い処理はリクエストパスのさらに奥で発生している可能性があります。どこで時間が費やされたかを特定してから、いかなるデッドラインも引き上げてください。

Gateway Timeout が証明すること

ゲートウェイタイムアウトは、仲介者が適用される待機時間内に必要なアップストリーム応答を受信しなかったことを証明します。 HTTP セマンティクスにおける 504 の定義 は、この境界を説明しています。このステータスからは、アップストリームが到達不能だったのか、ビジーだったのか、別の依存関係を待っていたのか、または非常に高コストな処理を実行していたのかは分かりません。

ゲートウェイは、クライアントからの接続を通常どおり受け入れている可能性があります。その後、504 エラードキュメントを返す前に、アップストリームの予算全体を待機に費やすことができます。クライアントは、要求された処理がその経路を通じて期待どおりの結果を返さなかったとしても、完全な HTTP レスポンスを受け取ります。

ステータスを出力したゲートウェイを特定してください。リクエストは CDN、ロードバランサー、リバースプロキシ、アプリケーションゲートウェイ、内部サービスメッシュを横断する場合があります。外側のコンポーネントが内側の 504 を転送することも、自身で生成することもあります。ユーザーが目にしたリクエストを終わらせたのがどのタイマーかを判断するには、ログとトレーシングが必要です。

アップストリームのタイムラインを再構成する

アップストリームのタイムラインには、接続確立、キューイング、アプリケーション処理、依存関係の呼び出し、応答の配送を含める必要があります。総所要時間だけでなく、これらのステージを分けて測定してください。同じ経過時間の 2 つのリクエストでもボトルネックは異なり、1 つは接続待ちで、もう 1 つはデータベースクエリ内で時間を費やしているかもしれません。

サービス間で観測結果を相関させるために、リクエスト識別子を使用してください。 W3C Trace Context は、標準的なトレース伝播を定義しており、計測したコンポーネント間でスパンを結びつけるのに役立ちます。スパンが欠けていても、処理が行われなかった証拠にはなりません。ギャップを解釈する前に、サンプリング、伝播、およびロギングのカバレッジを確認してください。

失敗したリクエストと、コストが類似した成功したリクエストを比較してください。可能であれば、ルート、入力サイズ、テナントコンテキスト、デプロイバージョンを合わせます。高速なヘルスチェックエンドポイントは高コストなエクスポートと比較するには不適切であり、キャッシュされた読み取りは、タイムアウトの原因である依存関係そのものを回避しているかもしれません。

アップストリーム遅延の一般的な原因

アップストリームの遅延は、多くの場合、ゲートウェイ自体ではなく制約された依存関係に起因します。データベースロックは、高い CPU 使用率を伴わずにアプリケーションリクエストを保持できます。外部サービスが、レスポンス予算の大半を消費する場合もあります。接続プールにより、依存関係呼び出しが始まる前に処理が待たされることがあります。

アプリケーションの計算も、別の可能性です。大きなデータセットをスキャンしたり、大規模なエクスポートを組み立てたりするリクエストは、同期パスに意図された予算を超える場合があります。ゲートウェイのタイムアウトを延長すれば、一部のリクエストは完了できるかもしれませんが、接続やワーカーをより長く保持し、通常トラフィックのキューイングを悪化させる可能性もあります。

ネットワークの問題は、フェーズ固有の証拠を用いて調査する必要があります。名前解決の遅延、接続確立、応答転送の遅さは、アプリケーション実行とは異なります。宛先と関連する接続タイミングを記録し、証拠がアプリケーション外部を指し示す場合はネットワークの責任者を巻き込んでください。

入れ子になったデッドラインには一貫した予算が必要

ネストされたデッドラインは、それぞれのコンポーネントが呼び出し元に意味のある結果を返せるだけの時間を残すべきです。クライアント、ゲートウェイ、アプリケーション、依存先はそれぞれ異なる間隔を監督している場合があります。最も早い適用可能なデッドラインがユーザーが目にするものを制御しますが、別のレイヤーでの処理はまだ実行中かもしれません。

設定された予算とそのスコープをマッピングしてください。コネクションタイムアウトは、全体的なリクエストデッドラインとは異なる作業を対象にします。クライアントによっては、読み取りタイムアウトは操作全体ではなく、データ転送のギャップを制御する場合があります。タイムアウトと呼ばれるすべての設定が同じ時間間隔を測定していると仮定するのではなく、実際のコンポーネント契約を用いてください。

アプリケーションのデッドラインを設計する際には、クリーンアップとレスポンス配信のための時間を確保してください。依存先が外側の予算全体を消費できてしまうと、アプリケーションは説明的なレスポンスを返す機会を失うかもしれません。一貫した予算設計により、制限している操作が可視化され、呼び出し元がすでに待機をやめた後も高コストな処理が走り続けることを防げます。

なぜゲートウェイのタイムアウトを長くしても役に立たないことがあるのか

ゲートウェイのタイムアウトを長くすることが有効なのは、上流の処理が妥当で境界があり、見直された予算内で完了すると期待できる場合だけです。それはデッドロックや、存在しないバックエンド、決して応答を返さない依存先を修復してはくれません。待ち時間を増やすのが適切かどうかを決める前に、完了挙動を計測してください。

大きなエクスポートを同期的に実行するレポートエンドポイントという説明用の例を考えてみましょう。ゲートウェイの上限を延長すると、小さなエクスポートは完了できても、大きなものは依然として失敗するかもしれません。運用上の論点は、エクスポート自体がそもそもリクエスト・レスポンスのやり取りに属すべきかどうかです。ステータスリソースを持つ非同期ジョブであれば、プロダクトがその設計をサポートしているときに、進捗と完了を明示できます。

呼び出し元のデッドラインも確認してください。呼び出し元がゲートウェイの新しい上限より先に待機を終了してしまうと、その変更はサーバーリソースを長く占有させるだけになるかもしれません。デッドラインの変更はリクエスト経路全体でレビューし、成功率だけでなくリソース占有の観点からも評価する必要があります。

504 とローカルタイムアウトおよび 522 を区別する

ローカルタイムアウトはクライアントが待機を終了したことを意味し、504 はクライアントがゲートウェイのタイムアウトレスポンスを受け取ったことを意味します。レスポンスがまったく受信されなかった場合は、HTTP ステータスの null または欠如を保持してください。すべてのクライアント例外に 504 を割り当てると、誤解を招くインシデント件数が生じ、何も返していないゲートウェイへと調査を向かわせてしまう可能性があります。

Cloudflare 522 は別の境界における Cloudflare とオリジン間の通信に関するものです。便宜上 504 に名称変更するのではなく、独自のカテゴリを維持すべきです。集約システムは、両者を利用不能という観測の下にまとめつつ、その下で異なる技術的証拠を保持することができます。

ブラウザのナビゲーションと要素待機はさらに別のレイヤーを追加します。ブラウザは 504 ページを受信した後、コンテンツ要素の読み込み待ちでタイムアウトすることがあります。その結果としての自動化例外を、別個のレンダリング不具合として扱う前に、ページレスポンスを確認してください。最初の意味のある失敗が、その後の症状を説明していることが多いのです。

タイムアウトは常に書き込みの結果を明らかにするわけではない

タイムアウトした状態変更リクエストは、その処理が完了したかどうかについて呼び出し元を不確実な状態に置くことがあります。ゲートウェイは待機をやめても、アプリケーションや依存先が処理を続けているかもしれません。したがって、ユーザーから見えるエラーだけでは、注文や更新、ジョブ作成が行われたかどうかを判断するには不十分です。

不確実性を解消するには、オペレーション識別子や信頼できるアプリケーション記録を使用してください。冪等性をサポートするシステムは、識別子のスコープと有効期間を含む、文書化された契約を適用すべきです。任意のヘッダーが冪等性を生み出すと仮定したり、すべての書き込みエンドポイントが同じ挙動を実装していると見なしたりしてはいけません。

インシデントレポートでは、「レスポンスが受信されなかった」と「操作が行われなかった」を区別してください。この表現の違いは、サポートや照合作業にとって重要です。確定した読み取り失敗と不確実な書き込みは、どちらもタイムアウトという症状を共有しながら、次に取るべき行動はまったく異なる可能性があります。

データ収集では鮮度と内容の両方を検証する

収集ワークフローは、対象とする成果と必要な内容を確認してからのみデータを受け入れるべきです。504 エラーページは、別のサービスのレスポンス内で通常のテキストや HTML として返されることがあります。そのボディをパーサーが正常に抽出できたとしても、意図した業務レコードを収集できたとは言えません。

キャッシュは別の区別を追加します。 HTTP キャッシュセマンティクス は、明示的なルールの下で保存済みレスポンスを再利用することについて説明しています。古い成功レスポンスは、ワークフローによっては有用な場合もありますが、その鮮度のコンテキストを保持しなければなりません。障害発生中に利用可能だからといって、以前に収集したデータを新しい観測結果として提示してはいけません。

収集時間、ソース観測時間、レスポンスステータス、検証結果のフィールドを、ワークフローで必要な場合は分けて保持してください。そうすれば、下流の利用者が古いデータを許容するかどうかを判断できます。収集レイヤーが、利用可能なテキストをすべて成功結果にまとめてしまうことで、その判断を見えなくしてはいけません。

Web Unlocker には独自の実行境界がある

Web Unlocker はマネージドな取得レイヤーを提供し、その タイムアウトポリシー はページロードと累積インストラクション実行を区別します。これらのサービス制限は、ターゲットゲートウェイのデッドラインやクライアント全体のジョブ予算とは別物です。クライアント側の設定を増やしても、ターゲット側で制御されるデッドラインを上書きすることはできません。

この HTTP クライアントとブラウザフィンガープリントに関する議論 は、なぜ異なる取得パスが異なる挙動を示すのかを説明していますが、トランスポートの選択は過負荷なターゲットデータベースを修復する手段ではありません。必要なコンテンツに対して文書化された取得インターフェースを選択し、そのうえで関連する各レイヤーで結果を確認してください。

最新の Scrapeless 料金表 を利用する 適格な収集作業を計画し、キャパシティ制限を明示的に保つためです。上流ソースに障害がある場合、そのスコープに対して不要なジョブの受付を停止し、所有者に必要な証拠を保持します。同一の停止したリクエストが大量にキューに溜まっても、元の遅延要因を説明しないままコストだけが増加します。

結論

HTTP 504 は、上流側の待機境界に関する手がかりです。発行しているゲートウェイを特定し、タイムラインを再構成し、入れ子になった期限と実際の作業を比較します。測定されたボトルネックを修正し、意図した動作を検証すると同時に、不確実な書き込みや欠落した収集データが可視である状態を維持します。