HTTP 503 Service Unavailable の解説

Scrapeless Web Unlocker は、service-unavailable 応答を有効なデータとは別に分類する必要がある収集システム向けに、公開ページのコンテンツを取得します。

HTTP 503 Service Unavailable は、サーバーが現在リクエストを処理できないことを意味し、一般的には過負荷か計画メンテナンスが原因です。この応答が示すのは現在の可用性であり、失敗した依存関係の正体やインシデントの継続時間ではありません。修復方法を選ぶ前に、それを生成したコンポーネントを特定してください。

503 ステータスが伝えること

HTTP 503 は、応答しているサービスが現在リクエストを処理できないことを伝えます。 HTTP セマンティクスの定義 では、このステータスの想定コンテキストとして、一時的な過負荷または計画メンテナンスが記述されています。単一の実装方式は規定されていないため、同じステータスがサービスアーキテクチャ内の異なる部分から発生し得ます。

リバースプロキシには、利用可能なアプリケーションバックエンドがないかもしれません。アプリケーションは、依存サービスが利用できないために意図的に新しい処理を拒否するかもしれません。メンテナンスレイヤーが、トラフィックがアプリケーションに到達する前に応答することもあります。いずれのケースも可用性シグナルの正当な利用になり得ますが、必要となる運用上の証拠はそれぞれ異なります。

このステータスは復旧時間の見積もりではありません。人間が読めるページが追加情報を提供する場合もありますが、その文言はサービスの実際のインシデントコミュニケーションと照らして確認すべきです。503 だけから保証された復旧時間を導き出したり、追加の証拠なしに恒久的なソース削除へと変換したりしないでください。

レスポンスを生成したコンポーネントを見つける

レスポンスを生成したコンポーネントは、503 調査の最良の出発点です。ステータス、ヘッダー、ボディの形状、リクエスト識別子、最終 URL、およびタイミングを取得してください。その上で、そのリクエストがゲートウェイとアプリケーションの両方のログに現れているかどうかを判断します。アプリケーション側の記録がない場合、経路のより手前で拒否されたことと整合する可能性がありますが、ログカバレッジは確認されなければなりません。

影響を受けるルートを比較します。静的ページが動作する一方でアプリケーションエンドポイントが失敗する場合、静的コンテンツは別コンポーネントまたはキャッシュから配信されているかもしれません。1 つのアップストリームグループの背後にあるあらゆるルートが 503 を返すなら、そのグループの健全性と利用可能性を調査してください。見えている影響範囲は優先的に確認すべき箇所を絞り込むのに役立ちますが、それ自体で原因を証明するものではありません。

トレーシングが利用可能な場合は、コンポーネント間でリクエストを相関させます。 W3C Trace Context はトレース伝播を標準化しており、ゲートウェイでの観測を下流の処理と結びつけるのに役立ちます。トレース識別子は、インストルメンテーションと伝播が存在する範囲でのみ有用です。あらゆる依存関係への完全な可視性が保証されるとは考えないでください。

過負荷には複数のリソース次元がある

過負荷は、到着する処理量がサービス内の制約された部分の容量を上回ったときに発生します。制約となるのは CPU の場合もあれば、メモリ、ワーカースロット、オープンコネクション、データベースプール、ロック、あるいはキュー領域の場合もあります。CPU に余裕があっても、すべてのワーカーが同じ依存サービスの待ち状態にあるせいで、有用な処理を受け付けられないことがあります。

到着率、アクティブな処理量、完了率の関係を調べます。完了率が平坦なままキューが増加する状況は、サービスが吸収できる短時間のバーストとは異なります。キュー長だけでなく、キューに滞留している処理の経過時間も追跡してください。少数でも高コストなオペレーションのキューは、すでにユーザーの許容時間を超えている可能性があります。

新しく受け付けた処理が制約を悪化させていないか確認します。すべてのアプリケーションレプリカが、データベースが処理できる数を超える接続を開くのであれば、レプリカを追加すると競合が激化するかもしれません。容量変更は、測定されたボトルネックを狙い、下流サービスのリソース制限を保ったまま行うべきです。

メンテナンスとデプロイは健全な容量を取り除くことがある

メンテナンスやデプロイは、システムが意図的に容量を取り除いたり、一時的にリクエストを処理できるバックエンドが存在しなかったりすることで 503 を生む場合があります。デプロイのタイムライン、ヘルスチェック、readiness 条件、ドレイン動作を確認してください。新しいプロセスがトラフィックを受ける前に、要求される処理に本当に対応可能かを必ず確認します。

プロセスが生存していることと、アプリケーションが ready であることは同義ではありません。起動には、設定、マイグレーション、コネクションプール、外部サービスなどが必要になることがあります。プロセスの存在だけを確認するヘルスチェックは、ユーザーをリクエストを完了できないアプリケーションへ送ってしまう可能性があります。一方で、チェックが厳しすぎると、本来は有用な容量をも排除してしまうこともあります。

メンテナンスに関する案内の範囲を確認してください。サイトが意図的にメンテナンスページを提示しているのであれば、レスポンスとユーザーメッセージは計画されたサービス状態と一致している必要があります。管理用ヘルスチェックは一般顧客向けの業務オペレーションとは区別し、ヘルスエンドポイントの成功が、すべての業務ルートが動作している証拠と誤解されないようにしてください。

503 と 429、502、504 を分けて扱う

503 と近接するステータスを区別することは、誰が、なぜリクエストを止めたのかを説明するのに役立ちます。429 はリクエストレートの制限を示します。502 はゲートウェイが受信した無効なレスポンスに関係します。504 は上流レスポンスの期限切れに関係します。503 は現在リクエストを処理できないことを表します。

これらのカテゴリは、入れ替え可能になることなく 1 件のインシデントの中で重なり合うことがあります。過負荷のアプリケーションは、一部のリクエストでゲートウェイに 503 を返させ、他のリクエストで 504 を返させる場合があります。観測されたステータスとそれを生成したコンポーネントを保持し、そのうえでトレースとメトリクスを使って共通の制約を特定してください。

「 HTTP 429 workload discussion 」は、アドミッションコントロールを比較するうえで有用です。呼び出し元ごとの許容量と、サービス全体のキャパシティ障害では、影響範囲が異なります。証拠が共有サービスのボトルネックを示しているのに、すべてのユーザーに資格情報やネットワーク経路の変更を求めるようなことはしないでください。

訪問者が報告できること

訪問者は、サーバー内部を診断することなく、失敗したアクションとその範囲を報告できます。URL、概ねの時刻、表示されたステータス、および問題がフォーム送信の前後どちらで発生したかを含めてください。可能であれば、そのサービス自身のインシデントまたはメンテナンス告知も確認します。

リクエストによって状態が変化した可能性がある場合は、別の書き込みを行う前に、アプリケーションの信頼できる記録を確認してください。ユーザーに表示されたエラーは、下流の処理が完了したかどうかを必ずしも示しません。その不確実性を解消するには、注文履歴、処理 ID、サポートからの確認などが必要になることがあります。

公開の報告では、個人情報を含むフォームデータや認証ヘッダーを共有しないでください。マスク済みのスクリーンショットとリクエスト ID が、通常はより安全な初期記録となります。サービスオーナーは、特定の処理を調査するうえで必要であれば、管理されたチャネルを通じて追加の情報を求めることができます。

コレクションデータから利用不能なレスポンスを除外する

データ収集側は、503 レスポンスを、明示的な契約で別の意味が与えられていない限り、「利用不能」の観測として分類するべきです。メンテナンスメッセージを含むページボディは、構文的には正しい HTML であっても、要求された業務データを一切含まない場合があります。パースに成功しても、それを受け入れ済みの結果に変えることにはなりません。

空の結果と利用不能なソースは、切り分けておきましょう。有効なスキーマを満たした空のカタログレスポンスは、一致する商品が存在しないことを意味する場合があります。503 は、そのリクエストでは収集側が最新のカタログを取得できなかったことを意味します。この 2 つを混同すると、下流システムが、まだ存在している商品を削除してしまう原因になります。

最後に有効だった観測値を、その本来のタイムスタンプとともに保持してください。鮮度の低下は明示的に示し、現在のデータが利用できないときには、どの下流の判断を一時停止すべきかを決めます。価格や在庫のダッシュボードでは、直近の収集ジョブがエラーで終了したからといって、古い値があたかも新たに観測されたように見える状態には決してしてはいけません。

キャッシュ動作と復旧の証拠

キャッシュの動作は、どのユーザーが可用性インシデントを観測するかに影響を与えます。 HTTP キャッシュルール は、適用されるディレクティブのもとで、レスポンスをどのように保存・再利用できるかを決定します。すべてのユーザーが同じライブアプリケーションのレスポンスに到達していると想定するのではなく、実際のキャッシュポリシーとレスポンスメタデータを確認してください。

キャッシュされた成功ページは、一方の観測者からオリジンの障害を隠してしまう一方で、新しいデータを必要とする別のリクエストには 503 が返されることがあります。逆に、意図的にキャッシュ可能にされたメンテナンスレスポンスは、その設定されたポリシーのもとで配信が続く場合があります。重要なのは、どのレスポンスが再利用され、それがサービスの現在の意図に合致しているかどうかです。

復旧の証拠には、単なるヘルスチェックや 1 件のホームページリクエストだけでなく、影響を受けた処理を含める必要があります。想定したバックエンドがトラフィックを処理していること、その依存先のレイテンシが許容範囲にあること、新しい処理がインシデントの原因となったキューやリソース圧力を再び生じさせていないことを確認してください。

Web Unlocker とサービス可用性の境界

Web Unlocker はパブリックページの取得をマネージドで提供しますが、対象 Web サイトは自サイトの提供能力に引き続き責任を負います。 Web Unlocker introduction では、その取得対象範囲について説明しています。このサービスは、対象サイトの不健全なバックエンド、メンテナンスデプロイ、過負荷のデータベースを修復することはできません。

「 HTML extraction and validation 」を取得後の独立したステージとして利用してください。コレクションサービスの結果と、対象サイトのステータスおよび受け入れ済みデータの結果は、それぞれのフィールドが利用できる限り分離しておきます。これにより、有効なソースデータは得られなかったとしても、API のやり取り自体は成功したと報告できるようになります。

現在の Scrapeless pricingを使ってキャパシティとコストを計画しつつ、リクエスト総数だけでなく、受け入れられたレコード数と鮮度も併せて計測してください。ソース側のインシデント発生中は、不必要に受け入れる処理を減らすことで、収集予算と影響を受けたサイト双方のキャパシティを保護できます。通常の収集を再開するための責任者と明確な運用条件を定めておきましょう。

結論

HTTP 503 の診断は、利用不能となっているサービス境界を特定することにかかっています。バックエンドの受付可否、リソースの飽和、メンテナンス状態、依存関係の動作をあわせて確認してください。訪問者や収集側は、実際の結果をそのまま保持し、欠落した最新データを誤った業務結果に変換しないようにしましょう。