HTTP 503 サービス利用不可の説明

Scrapeless Universal Scraping API は、管理されたウェブアンロッカーを通じて公共のウェブページを取得し、HTTP 障害を正確に分類する必要があるデータワークフローのためにページコンテンツを返します。

503 は明示的な可用性の決定です。

503 レスポンスは、上流との壊れた会話とは異なります。それは、応答するサービスが現在リクエストを処理できないことを発表する有効な HTTP 応答です。その応答は、無料のワーカーがいないアプリケーション、健全なターゲットがいないロードバランサー、メンテナンスページ、または過負荷のオリジンを保護するエッジプラットフォームから来る可能性があります。

利用不可という言葉は、リソースの存在ではなくサービスの状態を説明します。要求されたページは依然として実在し、準備が復元されると正常に返される場合があります。したがって、訪問者は制約された応答が必要であり、運営者はサービスが作業を拒否させたリソースまたは依存性を特定する必要があります。

データコレクターはこの区別を保持する必要があります。503 ページには通常、洗練されたナビゲーションと友好的なメッセージが含まれていますが、要求されたコンテンツではありません。ステータスを認識したバリデーションは、そのページがデータセットに入るのを防ぎ、可用性イベント中に負荷を増加させることを避けます。

HTTP 503 サービス利用不可とは何か

HTTP 503 サービス利用不可とは、サーバーが一時的な過負荷または予定されたメンテナンスのために、現在リクエストを処理できないことを意味します。 HTTP セマンティクス仕様 は、ステータスをサーバー側の条件として定義し、永久的な不在やクライアントの認証失敗とは区別しています。

503 は意図的に広範です。それは、労働者のキャパシティが枯渇したこと、依存性が利用できないこと、すべての準備が整ったインスタンスを削除したデプロイメント、メンテナンススイッチ、またはプラットフォームレベルのトラフィック制御を示すことができます。レスポンス単独では制約されたコンポーネントを明らかにしないため、診断はどのレイヤーがそれを生成したかを特定することから始まります。

サービスが作業を受け入れられないと決定する方法

サービスは複数のゲートを通じて作業を受け入れます。エッジはポリシーをチェックし、ロードバランサーはターゲットの健全性をチェックし、リバースプロキシは接続キャパシティをチェックし、アプリケーションはワーカー、キュー、依存性およびメンテナンス状態をチェックします。これらのレイヤーのいずれかが、別のリクエストを受け入れることが失敗または状況を悪化させると判断できます。

優れた可用性設計は、インスタンスが正しく応答できなくなる前に、サービスからインスタンスを削除します。その後、ロードバランサーは適格なターゲットを持たなくなり、自身が 503 を生成する可能性があります。別のアーキテクチャでは、アプリケーションは到達可能ですが、重要なデータベースまたは内部 API が利用できないため、意図的に 503 を返します。

ボディとヘッダーは所有者を明らかにする可能性があります。エッジブランドは外部層を示し、アプリケーション特定のコレレーション ID はリクエストがコードに到達したことを示唆します。メンテナンスウィンドウは、別のシステムによってサービスされる静的レスポンスを使用することがあります。それらの手がかりは、キャパシティやルーティングを変更する前にキャッチされるべきです。

503 を生成する条件

同じステータスは、計画された作業中にサービスを保護したり、計画外のキャパシティ障害を明らかにしたりすることができるため、文脈とメトリックがどの条件が適用されるかを確立する必要があります。

リクエストを拒否したレイヤーを見つける

503の調査では、可用性の決定を行った最初のレイヤーを見つけ、そのリソースを特定する必要があります。

1. 正確な応答を記録する。 サービスの状態が変わる前に、時間、ホスト名、パス、リージョン、応答ヘッダー、ボディブランド、リクエスト識別子をキャプチャします。
2. スコープを決定する。 軽量なヘルスエンドポイント、別のルート、別のリージョンをテストします。狭いエンドポイントの失敗は一つの依存関係またはプールを指し、広い失敗は共有インフラストラクチャを指し示します。
3. 応答の生成者を特定する。 エッジ、ロードバランサー、プロキシ、アプリケーションのログを比較します。意図的に503を記録する最初のレイヤーが次の診断ステップを所有します。
4. 準備可能な容量を確認する。 適格なインスタンスを数え、なぜいくつかが削除されたのかを確認します。プロセス数だけでは、準備チェックが失敗するか、インスタンスが排出されている場合は誤解を招くことがあります。
5. 制約されたリソースを検査する。 平均CPUに依存するのではなく、ワーカーの使用、キューの占有、データベース接続、メモリ、ファイルディスクリプタ、および依存関係の健康を見ます。
6. メンテナンスとデプロイメントのイベントを比較する。 計画されたスイッチ、移行、オートスケーリングアクション、またはリリースが最初のエラー時間と重なっているかを確認します。
7. 安全でない需要源を減らす。 影響を受けるサービスをターゲットにするバッチジョブや非必須の自動化を一時停止し、調査が圧力を加えないようにします。

における定義 HTTPセマンティクス、実装ノート MDNの503参照、および Cloudflareの503ガイダンス におけるオリジン対エッジのチェックは、503を準備と容量の信号として扱うことをサポートしています。

訪問者がサービスを損なうことなくできること

訪問者はサーバー側の可用性状態を制御する能力が限られており、迅速なリクエストの繰り返しは過負荷を悪化させる可能性があります。

• サービスステータスページを確認してください。 宣言されたメンテナンスまたはインシデントの通知は、失敗したページを繰り返しリフレッシュするよりも情報量が多いです。
• 未保存の作業を保持する。 フォームやトランザクションが失敗した場合、ローカルの入力を保持し、再度送信する前にサーバーの状態を確認します。
• 軽量なページを比較する。 ホームページやステータスエンドポイントは、その障害が一つの機能に影響を与えているのか、全体のサービスに影響を与えているのかを示すことができます。
• サポートに相関キーを送信する。 リクエストID、時間、ルート、リージョンを含め、認証情報やプライベートペイロードを共有しないでください。

容量と準備を回復する

オペレーターは健康なサービスエンベロープを回復し、その後にそれを枯渇させた制御または依存関係を修正する必要があります。

ターゲットが健康でない場合は、トラフィックを追加する前に準備失敗を検査します。厳格な健康チェックは良好なインスタンスを削除することがあり、浅いチェックは壊れたインスタンスを適格のままにします。チェックは、すべてのオプションの依存関係をグローバルな障害トリガーに変えずにルートに必要な依存関係を表すべきです。

サービスが飽和している場合は、希少リソースを特定します。キューの深さ、ワーカーの占有、データベース接続の使用、ロック時間、下流レイテンシは需要が蓄積されている場所を示します。間違ったティアをスケーリングすると、競合が増え、503のレートが変わらなくなる可能性があります。

回復後、メトリクスの過負荷応答からメンテナンス応答を分離してください。プロデューサー、ルート、地域、依存関係ごとにステータスを追跡します。容量アラームは、リクエストスロットが消費される前に発生する必要があり、デプロイメントポリシーは展開全体を通じて準備プールを保持する必要があります。

503を429、502、および504と区別する

近くのステータスは、可用性、負荷、および上流の通信に関する異なる質問に答えます。

コレクションシステムにおける503応答の処理

公共ウェブコレクションは、影響を受けたターゲットとワークロードのための停止信号として503を扱う必要があります。 スクレイピングのないユニバーサルスクレイピングAPIドキュメント は、管理された取得対象を説明しており、コレクターは応答が意図されたページを含むことを検証する責任があります。

ステータス、応答プロデューサー、最終URL、リクエスト時間、およびコンテンツフィンガープリントを記録します。エラードキュメントをデータセットの外に保ち、URLを利用不可としてマークし、ワークロードコントロールが圧力を軽減できるようにします。友好的なメンテナンスページを、単に有効なHTMLを含むという理由で成功した抽出に変換しないでください。

所有されたサービスについては合成チェックは制限された頻度と安価なエンドポイントを使用する必要があります。サードパーティのサービスについては、公開されているアクセスルールとインシデントガイダンスを尊重する必要があります。可用性の監視は、需要の重要なシェアになることなくシステムを観察する必要があります。

503を可用性シグナルとして扱う

HTTP 503 サービス利用不可は、サービスが現在リクエストを処理する準備ができていないことを示す有効な声明です。これは問題を容量、メンテナンス、準備、依存関係の健康、または保護されたトラフィック制御に絞ります。

応答を生成したレイヤーを見つけ、制約となったリソースを測定し、準備の整った容量を回復し、自動需要を抑制してください。そのアプローチは、ステータスページを問題として扱うのではなく、サービス状態を修理します。