レート制限はどのように機能するのか？

Scrapeless Web Unlocker は、アプリケーションがソースのアクセス・ポリシーを順守しつつ自分のワークロードを管理する必要がある収集ワークフロー向けに、Web コンテンツを取得します。

レート制限はどのように機能するのか？

レート制限は、ある期間に対する許容量と活動を比較し、そのリクエストを進行させてよいかどうかを判断します。ポリシーは、カウント対象となるアクティビティ、そのアクティビティが属するアイデンティティまたはスコープ、許可されるレートまたはバースト、そして許容量が尽きたときに取られるアクションを定義します。このメカニズムはサービスを保護したり、キャパシティを公平に分配したり、利用契約を強制したりするために使われます。

リクエストの許容量は認可そのものとは異なります。呼び出し元は有効な認証情報を持っていても許容量を超過することがありますし、レート閾値の下に収まっていても、リソースへアクセスする権限を欠いている場合があります。この 2 つの状態を切り分けるには、トラフィック量だけに基づいた想定ではなく、実際のレスポンスとサービス・ポリシーが必要です。

レート制限ポリシーは実際には何を数えているのか？

レート制限ポリシーは、定義されたスコープ内で定義された作業単位をカウントします。その単位は、リクエスト、バイト数、オペレーション、または重み付きコストかもしれません。スコープは、アカウント、認証情報、エンドポイント、テナント、もしくはネットワーク・アイデンティティなどが考えられます。テナントの許容量と、別個の高コスト・オペレーション向け許容量のように、複数のスコープが同時に適用されることもあります。

どのアイデンティティで数えるかは公平性に影響します。ネットワークアドレスは、共有インフラの背後にいる多くの無関係なユーザーを表し得ます。1 つのアカウントが複数の認証情報を使用することもあります。ポリシーの意図がアカウント全体での制限である場合、サービスが明示的にそうすると言わない限り、新しい認証情報を作成しても新たな正当な許容量が生まれるわけではありません。

重み付きの制限は高コストなオペレーションをより適切に表現できますが、そのコスト規則は理解可能である必要があります。大きなコレクション全体を検索する処理は、キャッシュされたレコードを読むよりも多くのキャパシティを消費し得ます。クライアントはレスポンスのサイズやレイテンシだけから、それらの重みを推測することはできません。

持続レート、バースト許容量、長期クォータを分けて考えます。サービスは、より低い平均レートを維持しつつ短時間のバーストを許可するかもしれません。月次の利用権は別の境界です。短期レートを満たしていても、長期的なキャパシティがまだ残っていることの証明にはなりません。

固定ウィンドウとスライディングウィンドウはどのように機能するか？

固定ウィンドウ・リミッターは離散的な区間内のアクティビティをカウントし、スライディングウィンドウ・リミッターは移動する区間を評価します。固定ウィンドウは説明が簡単ですが、区間境界付近のトラフィックが隣り合うウィンドウにまたがって集中することがあります。そのようなバーストが許容できるかどうかは、保護対象システムに依存します。

スライディングログは、関連するリクエストのタイムスタンプを保持し、移動する区間内にとどまっているものをカウントできます。スライディングカウンタは、隣接するカウンタから移動区間を近似できます。この 2 つのアプローチは、状態のコストと精度が異なるため、「スライディングウィンドウ」という言葉だけでは完全なアルゴリズム仕様にはなりません。

The rate-limiter algorithm comparison では、固定ウィンドウ、スライディング方式、トークンバケット、リーキーバケットを説明しています。どれを選ぶかは、ある手法が常に最適だという主張ではなく、求められるバースト挙動と実装上の制約に従うべきです。

時間ソースと更新セマンティクスを定義します。分散サービスでは、古いカウンタを評価している個々のワーカーが、意図より多くの作業を許可してしまうことがあります。チェックと状態更新は、そのポリシーが求めるだけの原子性を持つ必要があります。単一プロセスでは正しいアルゴリズムであっても、グローバルな許容量を正しく提供できるとは限りません。

トークンバケットとリーキーバケットはどう違うか？

トークンバケットは、最大容量まで許容量を補充し、作業を受け入れる際にその許容量を消費します。未使用の許容量は、バケット容量を上限とした後続のバーストを支えることができます。補充レートが、時間経過に対する持続的な受付量を制御します。

The トークンバケットとリーキーバケットのトラフィックモデル レート、バーストサイズ、および時間の関係を説明します。これらの概念を API リクエストに適用するには、1 つのトークンが何を表すかを定義する必要があります。トークンは 1 つのリクエスト、または別のコスト単位を表すことができます。

リーキーバケットの用語はポリシングまたはシェーピングを表すために使われます。シェーピング設計では、キューに入った作業は制御されたレートで解放されます。キューには最大サイズ、有効期限ポリシー、および許可できない作業に対する判断が必要です。無制限のキューは、過負荷を単に増大するメモリ使用量と遅延へと変えるだけです。

バースト許容量がすべてのエンドポイントに対する余剰キャパシティだと仮定しないでください。複数のクライアントが同時に自分の許容量を消費する可能性があります。キャパシティプランニングでは、ポリシーが許可する結合された挙動を考慮しなければなりません。

HTTP 429 はクライアントに何を伝えるか？

HTTP 429 は、サーバーが関連する期間内にクライアントがリクエストを送りすぎたと見なしていることを示します。 429 status-code definition は、カウントの仕組みとクライアント識別ポリシーをサーバー側に委ねています。このステータスだけでは、その許容量が認証情報、ユーザー、エンドポイント、または別のスコープに属するかどうかは分かりません。

実際のポリシーを特定するために、公開されているレスポンスフィールドとプロバイダーのダッシュボードを確認してください。すべてのサービスが同じヘッダー名や単位を使っていると仮定してはいけません。残り許容量の値は 1 つのポリシーを指している一方で、別のより厳しいポリシーも適用されている場合があります。

HTTP 403 は、レートの枯渇を特定するというより、操作が拒否されたことを説明します。HTTP 503 はサービス可用性に関するもので、原因はいくつか考えられます。 HTTP response semantics は、より広い区別を提供します。成功ステータスで返される HTML アクセスページも、コレクターがデータとして受け入れる前に内容の検査が必要です。

ワークロードが公開された許容量を超えた場合、そのアプリケーションの運用ポリシーが許すまで、影響を受けた作業の受け入れを中止します。不完了タスクの状態を保持し、制限されたスコープを報告してください。キャパシティまたは権利の変更は、プロバイダーがサポートするプロセスを通じて行う必要があります。

レートは同時実行性とどう違うか？

レートは時間当たりの活動量を測定し、同時実行性は同時にアクティブな操作数を測定します。ワーカープールが小さいクライアントでも、各操作がすぐに終わるなら高いリクエストレートを生み出せます。リクエストレートが低くても、操作が長時間アクティブなままなら、かなりの同時実行キャパシティを消費し得ます。

両方が重要な場合は別々の制御を使ってください。スケジューラは受付レートを制御でき、ワーカープールはアクティブな作業を制限します。ソース単位の制御は、大きなグローバルキューが 1 つの宛先を圧倒することを防ぎます。アカウント全体の制御は、互いに独立したジョブ間でも、結合された許容量を保持します。

ページネーションはその違いをよく示します。順次カーソルウォークは、アクティブなリクエストが 1 件だけでも、大規模なエクスポート中に多くのリクエストを消費する場合があります。ブラウザセッションは、収集リクエストをほとんど送信していなくても、ページ操作を待っている間はアクティブなままでいられます。プロバイダーが実際に制限しているリソースをモデル化してください。

キューで待機している作業に対して、キャンセルと期限を定義します。古い収集リクエストは、その鮮度の期限を過ぎれば、もはや有用でないかもしれません。記録された理由とともに期限切れの作業を破棄する方が、見かけ上は最新の完了タイムスタンプで後から届けるよりも誠実です。

Scrapeless はワークロード制御のどこに位置づけられるか？

Scrapeless は収集機能を提供し、許可されるワークロードと受け入れポリシーはあなたのアプリケーションが決定します。 Web Unlocker は、ソースのアクセスルールを超える権限を生み出すものではありません。収集用の認証情報、ソースの許可、スケジューリングポリシーを区別して保ってください。

この Scrapeless API key requirements は認証について説明しています。有効なキーがあっても、無制限の同時実行性やすべてのプロダクトへのアクセスが保証されるわけではありません。選択したサービスに適用される制御とアカウントの権利を使用してください。

不要な作業を減らすことで、キャパシティの利用効率とデータの鮮度の両方を改善できます。 インクリメンタル収集とレコード変更検出 は、変わっていないコンテンツと変更されたビジネスレコードを切り分けます。これらの仕組みは、ソースの挙動がそれをサポートしている箇所にのみ適用してください。

受け入れた作業、拒否された作業、キューの年齢、受け入れたレコード、および関与するポリシースコープを監視してください。収集リクエスト数だけでは、制限された実行が有用なデータセットを生み出したかどうかは説明できません。コスト計画には Scrapeless pricing を、ソース側の独立したアクセス・キャパシティルールと合わせて利用してください。

結論

明確なレート制限設計は、カウントされる作業、アイデンティティ、時間モデル、および過負荷時の判断を名指しします。受付制御と同時実行制御をそれらの境界に合わせ、そのうえで不完了の作業を明示的に記録し、トラフィック制御が密かに欠損データへと変質しないようにします。