HTTP 429 リクエストが多すぎます: ウェブスクレイピングの原因と防止策

TL;DR:

• HTTP 429 Too Many Requestsは、クライアントが期間内にサーバーが選択したリクエスト制限を超えたことを意味します。 制限は、アカウント、認証、IPアドレス、エンドポイント、地域、または重み付けされた操作によってスコープされる場合があります。
• 最初の対応は、新しい作業を追加しないことです。 応答を保持し、制限のスコープを特定し、新しいジョブを共有リクエスト予算の背後に保つことが重要です。
• 予防は調整から来ます。 中央集権的な同時実行制御、キャッシング、重複排除、適応スケジューリング、明確な停止条件が無駄なリクエストを減少させます。
• Scrapeless Scraping Browserは、ブラウザの同時実行とセッションガバナンスを中央集権化できます。 これは、対象のルール、アカウントの許可、および明示的な収集予算内で運用されるべきです。

HTTP 429 Too Many Requestsはフロー制御シグナルです：サーバーはリクエストを呼び出し元またはリソーススコープに関連付け、ポリシーを超える十分な作業をカウントし、新しいリクエストを拒否しました。したがって、ウェブスクレイピングにおける429エラーは、トラフィック制御層で診断されるべきです。

すべてのスケジューラーとワーカーが共有するウェブスクレイピングリクエスト予算は、持続可能な修正を提供します。このガイドは、制限のスコープを見つけ、 accidental pressureによって引き起こされる429エラーを防ぎ、パイプラインを責任を持って運用する方法を説明します。

HTTP 429は何を意味しますか？

定義される標準はRFC 6585, セクション4です。これは、429ステータスがユーザーが一定の時間内にあまりにも多くのリクエストを送信したことを示していると述べています—レート制限。この標準は、サーバーがユーザーを特定する方法やリクエストをカウントする方法を選択する余地を残しています。

その柔軟性が、ステータスだけでは完全なルールを明らかにできない理由を説明しています。あるサービスはAPIキーごとにリクエストをカウントし、別のサービスはアカウントとエンドポイントごとにカウントし、別のサービスは重み付けされたコストによってカウントするかもしれません。トラフィックを変更する前に、応答ボディ、ドキュメント化されたヘッダー、サービスダッシュボード、およびプロバイダーのガイダンスを読みましょう。

HTTP 429と403と503

RFC 9110は、403を拒否として定義し、503 Service Unavailableを過負荷またはメンテナンスのためにリクエストを処理できないことを示します。プラットフォームはカスタムの動作を実装できるため、単なる番号から分類するのではなく、ボディとリクエストIDを保持することをお勧めします。

レート制限が適用される方法

ゲートウェイまたはアプリケーションはまずスコープを特定し、その後、時間ウィンドウまたはキャパシティモデル内の作業を考慮します。

カウンターを共有するすべてのプロデューサーを特定します。ローカルワーカーは保守的に見える場合があっても、フリートは同じアカウントの許容範囲を超えている場合があります。

スクレイピングパイプラインにおける一般的な原因

最も一般的な原因はアーキテクチャ上のものです：

• すべてのワーカーが独立したレートカウンターを維持している；
• スケジューラーがファンアウト後に重複するURLを発行する；
• ページが変更されていない場合でもポーリングが続く；
• ページネーションにアイテム、ページ、または時間の境界がない；
• 開発と本番が認証情報を共有；
• 同時実行が自動的に目標レベルの上限なしに成長する；
• コンシューマーの失敗が上流の作業を蓄積させる；
• キャッシュキーがロケール、アイデンティティ、またはスキーマの詳細を省略し、不必要なミスを作成する。

トラフィックは、コードが設計どおりに機能している場合でも、製品プランまたはターゲットの文書化されたポリシーを超えることがあります。キャパシティプランニングは、ブラウザプラットフォームの制限とアクセスしているサービスのルールの両方を含める必要があります。

Scrapelessでスクレイピングを開始する

Scrapelessでウェブスクレイピングと自動化のワークフローを強化しましょう！
今すぐサインアップして**$5の無料クレジット**を獲得 — クレジットカード不要。

Scrapeless Dashboardで今すぐ無料クレジットを取得してください。

制限のスコープを診断する

429が表示された場合、影響を受けるターゲットの入場を一時停止し、証拠を保存します。記録するもの：

• タイムスタンプとタイムゾーン；
• URLテンプレートとHTTPメソッド；
• 認証情報またはアカウント識別子の秘匿形式;
• ソース環境と出口グループ;
• アクティブな同時実行数とキューの深さ;
• レスポンスヘッダー、制限されたボディ、リクエストID;
• 最近のリクエスト数の可能性がある範囲ごとの集計;
• 別のアプリケーションが同じアイデンティティを共有しているかどうか。

アカウント、キー、エンドポイント、ターゲットホスト、およびソースネットワークごとに429の観察をグループ化する。1つの次元の下にシャープなクラスターがあると、しばしばカウンターが露呈する。証拠をプロバイダーの公式なクオータ文書と比較するか、リクエストIDを特定するためにサービスオーナーに問い合わせてください。

トラフィックを増やして正確な閾値を探ろうとしないでください。それはプレッシャーを加え、ターゲットの運用ポリシーに違反する可能性があります。

リクエスト予算で429を防ぐ

リクエスト予算は、作業がネットワークに到達する前に適用される入場ルールです。ターゲットごと、既知のアイデンティティスコープごとにそれを定義し、各プロデューサーが同じ予算から予約できるようにします。

ワークシートを中央集権的なキューポリシーに変えます。キューはターゲット、アイデンティティスコープ、優先順位、期限、重複排除キー、推定単位コストを知っている必要があります。ブラウザのキャパシティを占有する前に、古くなったまたは重複したジョブを拒否する必要があります。

同時実行、キャッシング、および重複排除

同時実行は、アクティブな操作の数を制御しますが、長期間にわたり許可される数を制御するものではありません。アクティブなセッションのキャップとリクエスト予算の両方を使用します。これらの制御を個々のワーカーの上に置くことで、水平スケーリングがトラフィックを静かに増加させることを防ぎます。

キャッシングは、ビジネスの新鮮さウィンドウが再利用を許可する場合に同等の読み取りを排除します。 RFC 9111 は、HTTPキャッシュがレスポンスタイムとネットワーク帯域幅を削減し、保存されたレスポンスを再利用する条件を設定することを説明しています。アプリケーションレベルのキャッシュには、ターゲットURL、関連ヘッダー、位置、認可されたアイデンティティ、スキーマバージョンなど、同等性に影響を与える可能性のある慎重なキーが必要です。

重複排除は同時の需要を圧縮します。複数の消費者が同じ製品と観察ウィンドウを要求する場合、すべてのサブスクライバーに1つのコレクションイベントを公開します。変更されていない観察が高価な下流作業を引き起こさないように、コンテンツハッシュまたはソースバージョンを保持します。

以下のローカル例は、固定予算内でユニークな作業を許可し、容量が尽きると停止します:

jobs = ["/a", "/a", "/b", "/c", "/d", "/e"]
request_budget = 4
seen = set()
admitted = []

for path in jobs:
    if path in seen:
        continue
    if len(admitted) >= request_budget:
        break
    seen.add(path)
    admitted.append(path)

print({"admitted": admitted, "remaining": len(jobs) - len(admitted)})

出力は /a、/b、/c、/d を許可し、重複の /a はネットワークの配分を消費しません。運用時には、すべてのワーカーが使用するインフラストラクチャに共有カウンターを永続化します。

モニタリングと停止条件

拒否に至る前にシステムを監視します。役立つ測定値には、受け入れた作業、抑制された重複、キャッシュヒット、アクティブセッション、キューの年齢、リクエストユニット、スコープごとの429カウント、データの新鮮さが含まれます。

OpenTelemetryはメトリックをタイムスタンプとメタデータを持つランタイム測定として説明しています。その メトリックガイダンス は、リクエスト予算、キューの遅延、および同時実行に適したカウンターとヒストグラムをサポートしています。

停止条件は構成で定義し、オペレーターの記憶には記載しないでください:

• ターゲットに対する任意の429はそのスコープの新規入場を閉じる;
• 文書化されていない制限は自動収集をレビュー待ちで終了させる;
• ビジネスの期限を超えたキューの年齢は古い作業を破棄する;
• エラー比率が上昇することで入場が減少または閉じられる;
• 認可の欠如、条件の対立、またはロボットポリシーによって収集が停止される;
• コストの上限は必須のものの前にオプションの作業を停止させる。

目標は、直ちにプレッシャーを軽減し、制御された決定のための証拠を保持することです。429は、別のリクエストを自動的に作成するループを決して開始すべきではありません。

Scrapeless Scraping Browser の適合性

Scrapeless Scraping Browser は、動的で認可されたターゲットのための管理されたブラウザ実行を提供します。中央のセッション作成により、ブラウザの同時実行が可視化され、管理可能になります。位置情報やセッション入力により、アプリケーションは観察コンテキストを定義できます。

Scrapelessはターゲットのレートポリシーを置き換えるものではありません。ブラウザ接続を共有入場キューの背後に配置し、同時セッションを制限し、ターゲットまたは独自の予算で停止するように指示してください。Scraping Browser API ドキュメントで現在の接続詳細を確認してください。

責任あるスクレイピングチェックリスト

• 対象、アカウント、データが自動化のために承認されていることを確認する。
• 対象の利用規約、公式APIガイダンス、文書化されたクォータを読む。
• 適用可能な場合は、解析可能な robots.txt ルールを取得し、従う。 RFC 9309 はクローラーのルールに対する標準化されたアクセスおよび解析動作を定義する。
• サービス間で共有される1つの対象レベルのリクエスト予算を使用する。
• URLを重複排除し、新鮮さのウィンドウ内で同等の観察結果をキャッシュする。
• ページネーション、アイテム数、経過時間、支出に制約を設ける。
• 開発、ステージング、プロダクションの資格情報と予算を分離する。
• 秘密情報を保存せずにリクエストIDとポリシースコープをログに記録する。
• 429エラーや認証の競合が発生した場合、新しい作業を停止する。
• 正当な需要が文書化された許容量を超えた場合、サービス所有者に連絡する。

結論

HTTP 429 Too Many Requestsは、キャパシティとガバナンスの問題として扱うのが最適です。カウンターを特定し、リクエスト予算の背後にすべてのプロデューサーを調整し、重複作業を排除し、適切なキャッシュ結果を再利用し、同時実行数を制限し、停止条件を自動化します。

Scrapeless Scraping Browserは、ブラウザ依存のコレクションのための制御された実行レイヤーになる可能性があり、キューとポリシーレイヤーが受け入れられるものを決定します。セッションキャパシティのサイズ設定時には、Scrapeless価格を確認してください。

ブラウザ作業を予算内に収める

Scrapeless Dashboardを使用して管理されたブラウザセッションを評価し、ウェブスクレイピングでのページネーションの処理方法を制約のないページトラバースなしで確認します。コミュニティに参加するには、DiscordまたはTelegramをご利用ください。

FAQ

Q: ウェブスクレイピングで429エラーの原因は何ですか？

サーバーは、クライアントをリクエストスコープに関連付け、そのスコープがレートポリシーを超えたと判断する際に429を発行します。重複したジョブ、共有資格情報、調整されていないワーカー、および過度の同時実行が一般的なパイプラインの原因です。

Q: HTTP 429は503と同じですか？

いいえ。429は、選択されたポリシーに基づいて呼び出し元のリクエストボリュームを拒否することに関係しています。503は、サービスが過負荷またはメンテナンスのために現在リクエストを処理できないことを示します。

Q: ローテーショナルプロキシは429エラーを防ぐことができますか？

プロキシローテーションは、対象のクォータやトラフィックポリシーを回避するために使用すべきではありません。文書化されたスコープを診断し、作業を減らし、正当な許容量を調整し、必要に応じてサービス所有者から追加のキャパシティを要求します。

Q: キャッシングはどのように429エラーを防ぎますか？

キャッシングは、同等の需要が新たなネットワークリクエストを作成するのではなく、適切な観察を再利用できるようにします。キャッシュキーと新鮮さのウィンドウは、URL、場所、アイデンティティ、スキーマ、およびソースポリシーを反映する必要があります。

Q: ブラウザの同時実行数はどのように制御すべきですか？

セッション作成を中央集権的なキューの背後に置きます。対象レベルのキャップを施行し、価値のある作業のためにキャパシティを予約し、キューの年齢を測定し、個々のワーカーが独立して艦隊を増やすのを防ぎます。

Q: 429が表示されたらすぐに何をすべきですか？

影響を受けたスコープに対して新しい作業の受け入れを停止し、レスポンスとリクエストIDを保持し、共有カウンターを特定し、収集を再開する前にサービス所有者や内部プラットフォームチームを巻き込みます。