API レート制限: すべての開発者が知っておくべき 4 つのアルゴリズム
固定ウィンドウ、スライディング ウィンドウ、トークン バケット、およびリーキー バケットを図で説明し、X-RateLimit ヘッダーとコピー＆ペーストできる Node.js 再試行ロジックを説明します。
バッチ ジョブが 3 秒間で 200 リクエストを発行し、すべてのレスポンスが返されます。 429 Too Many Requests。
Webhook プロセッサがサードパーティ API を攻撃し、15 分間ブロックされます。 顧客の統合
再試行ループが最初の 1 時間で 1 日の割り当てを使い切ってしまうため、沈黙します。 これらの失敗の共通点
根本原因の 1 つは、コードがレート制限を無視していることです。
このガイドでは、4 つのコア レート制限アルゴリズムについて説明し、そのアルゴリズムを読み取る方法を示します。 X-RateLimit
任意の API のヘッダーを取得し、指数バックオフを使用した再試行ロジック用の Node.js コードをコピーアンドペーストできます。
4 つのレート制限アルゴリズム
すべてのレート リミッターは、「このリクエストは通過すべきか、それとも拒否すべきか?」という同じ質問に答えます。 4 つのアルゴリズムは、時間の追跡方法とバーストの処理方法が異なります。
1.固定窓
最もシンプルなアプローチ。 時間を一定の間隔（例: 1 分）に分割します。 間隔ごとのリクエストをカウントします。 カウントが制限に達すると、次の間隔が開始されるまですべてが拒否されます。
固定ウィンドウは構築が簡単です。クライアントごとに 1 つのカウンターと 1 つのタイムスタンプです。 欠点は、 境界の問題。 クライアントは、1 つのウィンドウの終了時に制限全体を送信でき、制限全体を送信できます。 次の開始時に、短期間で意図したレートの 2 倍を取得します。 GitHub の古い API レート リミッターは固定ウィンドウを使用しました。 その後、彼らはより洗練されたアプローチに移行しました。
2. 引き違い窓
固定境界でリセットするのではなく、ウィンドウはリクエストごとにスライドします。 いつでも、 リミッターは過去 N 秒間を振り返り、その範囲内のリクエストをカウントします。
スライディング ウィンドウにより、境界バーストの問題が解消されます。 コストはメモリの増加です。タイムスタンプを保存します。
単一のカウンターではなく、すべてのリクエストに対して。 レディス ZRANGEBYSCORE これを大規模に実用化します。
Cloudflareと多くのAPIゲートウェイは、ユーザーごとのレート制限にスライディングウィンドウを使用します。
3. トークンバケット
トークンが入っているバケツを想像してください。 各リクエストには 1 つのトークンがかかります。 トークンは固定レートで補充されます。 バケットが空の場合、リクエストは拒否されます。 バケットがいっぱいの場合、余分なトークンは蓄積されません。
トークン バケットは、運用環境で最も人気のあるアルゴリズムです。 Stripe、AWS API Gateway、およびほとんどのクラウド プロバイダーはそのバリアントを使用します。 バケットの容量はバースト サイズを制御し、補充速度は制御します 持続的なスループット。 2 つのパラメータを使用して、トラフィック形状をきめ細かく制御できます。
4. 漏れやすいバケツ
トークンバケットの逆。 リクエストはバケツにいっぱいになります。 バケツは一定の速度で排水されます。 もし バケットがオーバーフローすると、過剰なリクエストは拒否されます。 出力レートは入力に関係なく一定に保たれます 破裂する。
リーキー バケットは、安定した出力レートが必要なトラフィック シェーピングに適しています。キュー ワーカー、 Webhook 配信とビデオ エンコード パイプライン。 トレードオフは、バーストがキューに入れられることです。 提供されるよりも。 負荷がかかるとレイテンシが増加します。
4 つのアルゴリズムの比較
| アルゴリズム | バーストは許可されますか? | メモリ | 一般的な使用例 |
|---|---|---|---|
| 固定窓 | エッジバースト (境界で 2 回) | ロー（1カウンター） | シンプルなカウンター、分析 |
| 引き違い窓 | 滑らかで境界スパイクなし | 中 (リクエストごとのタイムスタンプ) | ユーザーごとの API 制限 |
| トークンバケット | 容量まで制御されたバースト | 低 (2 つの値) | ほとんどの実稼働 API (Stripe、AWS) |
| 漏れのあるバケツ | キューに入れられた、一定の出力レート | 中 (キュー) | トラフィックシェーピング、キューワーカー |
X-RateLimit ヘッダーの読み取り
ほとんどの API には、応答ヘッダーにレート制限情報が含まれています。 3 つのヘッダーですべてがわかる 制限以下に抑える必要があります。
X-RateLimit-Limit: ウィンドウごとに許可される最大リクエストX-RateLimit-Remaining: 現在のウィンドウに残したリクエストX-RateLimit-Reset: ウィンドウがリセットされたときの Unix タイムスタンプ (秒)
制限を超えると、応答ステータスは 429 Too Many Requests そして
Retry-After ヘッダーは待機する秒数を示します。
botoi の API に対して試してみます。 このカール コマンドは文字列をハッシュし、レート制限ヘッダーを出力します。
応答ヘッダー:
これは、制限が 1 ウィンドウあたり 5 リクエストであること、このリクエストの後は 4 リクエストが残っていること、そして ウィンドウは指定された Unix タイムスタンプでリセットされます。 HTTP クライアントでこれらの値を追跡して、ヒットを回避します そもそも429。
ヒント： 変換する X-RateLimit-Reset 待ち時間まで：
waitMs = (resetTimestamp - Math.floor(Date.now() / 1000)) * 1000
Node.js の指数バックオフを使用した再試行ロジック
429 がヒットした場合は、すぐに再試行しないでください。 タイトな再試行ループは問題を悪化させます。 レート制限が長くなると、サーバーはあなたを不正行為としてマークします。 代わりに、ジッターのある指数バックオフを使用してください。
任意のエンドポイントで使用します。
関数は次のことをチェックします。 Retry-After まずヘッダー。 サーバーがその時間を通知する場合
待つこと、それを尊重すること。 ヘッダーが存在しない場合は、指数バックオフに戻ります: 1 秒、2 秒、
4秒、8秒。 ランダム ジッター (0 ～ 500 ミリ秒) により、数百の
クライアントはまったく同じ瞬間に再試行します。
プロアクティブなスロットリング: 429 が発生する前に回避します
リアクティブな再試行は、障害が発生した後に処理します。 プロアクティブなスロットリングによりそれらを防止します。 知っていれば (ドキュメントまたはヘッダーからの) レート制限、クライアント側でのリクエストのペースを調整します。
このクライアント側のレート リミッタは、スライディング ウィンドウでリクエストのタイムスタンプを追跡します。 それぞれのリクエストの前に、 ウィンドウがいっぱいかどうかを確認し、必要に応じて待機します。 最大限安全な状態でリクエストを送信します 429 が 1 つも含まれていないレート。
Botoi のレート制限モデル
Botoi は 2 層のレート制限システムを使用します。
| プラン | バースト(1分あたり) | クォータ | 認証 |
|---|---|---|---|
| 無料 ($0) | 5 リクエスト/分 | 100/日 | なし (IP ベース) |
| スターター ($9/月) | 30 要求/分 | 300,000/月 | APIキー |
| プロ ($49/月) | 300 リクエスト/分 | 3,000,000/月 | APIキー |
| ビジネス ($199/月) | 1,000リクエスト/分 | 30,000,000/月 | APIキー |
匿名アクセスは IP アドレスによってリクエストを追跡します。 毎日のカウントは、UTC の午前 0 時にリセットされます。 クラウドフレアのKVカウンター。 認証されたリクエストでは、識別と制限のために API キーが使用されます。 を通じて強制されます アンキーズ エッジのトークンバケットレートリミッタ。
からのすべての応答 api.botoi.com 3つが含まれます X-RateLimit ヘッダー
上で説明したように、再試行ロジックは計画に関係なく同じように機能します。
API コンシューマ向けの実証済みのアプローチ
- すべての応答のヘッダーを読みます。 レート制限をドキュメントからハードコーディングしないでください。 API は予告なく制限を変更します。 ヘッダーは真実の情報源です。
- ジッターのある指数バックオフを使用します。 固定再試行間隔により同期が発生する クライアント間で再試行します。 ジッターにより負荷が分散されます。
- API がサポートするバッチ。 10 アイテムを含む 1 つのリクエストには 1 つのレート制限がかかります トークン。 10 個の個別リクエストには 10 の費用がかかります。
- 応答をキャッシュします。 リクエスト間でデータが変更されない場合は、結果を保存します API 呼び出しをスキップします。 DNS レコード、SSL 証明書、WHOIS データが数分以内に変更されることはほとんどありません。
- バックグラウンド作業にはキューを使用します。 ホット ループから API 呼び出しを起動しないでください。 プッシュ キュー (BullMQ、SQS、Cloudflare キュー) 上で作業し、制御された速度でアイテムを処理します。
-
残りの割り当てを監視します。 ログ
X-RateLimit-Remainingあなたへ メトリクスダッシュボード。 制限の 20% を下回ったときにアラートを設定します。
重要なポイント
- 4 つのアルゴリズムが主流です。 固定ウィンドウが最も単純です。 トークンバケットが最も人気があります。 スライディング ウィンドウにより境界バーストが排除されます。 漏れのあるバケットにより出力が平滑化されます。
-
X-RateLimit ヘッダーは API です。 読む
Limit、Remaining、 そしてResetすべての応答で上限を下回るようにします。 -
ジッターを伴う指数バックオフは 429 を処理します。 をコピーします
fetchWithRetry上記の関数をコードベースに組み込み、すべての外部 API 呼び出しをラップします。 - プロアクティブなスロットルにより 429 が防止されます。 クライアント側でリクエストのペースを調整する サーバーがプッシュバックするのを待つ代わりに。
- テストにアカウントは必要ありません。 任意の botoi エンドポイントにヒットします。 api.botoi.com 1 分あたり 5 つの無料リクエストでレート制限ヘッダーの動作を確認します。
FAQ
- API レート制限とは何ですか? API がそれを使用する理由は何ですか?
- レート制限により、クライアントが時間枠内に実行できるリクエストの数が制限されます。 API はこれを使用して、サーバーを過負荷から保護し、悪用を防止し、クライアント間で公平なリソース共有を確保し、インフラストラクチャのコストを予測可能に保ちます。 これがなければ、1 人のクライアントが他のすべてのクライアントを飢えさせる可能性があります。
- X-RateLimit ヘッダーは何を意味しますか?
- X-RateLimit-Limit は、ウィンドウごとに許可される最大リクエストです。 X-RateLimit-Remaining は、残りの数です。 X-RateLimit-Reset は、ウィンドウがリセットされたときの Unix タイムスタンプです。 Retry-After (429 応答の場合) は、再試行するまでに何秒待つかを示します。
- 429 Too Many Requests 応答はどのように処理すればよいですか?
- Retry-After ヘッダーを読み取り、その秒数だけ待ちます。 Retry-After ヘッダーが存在しない場合は、指数バックオフを使用します。最初の 429 の後に 1 秒、2 番目の後に 2 秒、3 番目の後に 4 秒というように待機します。 多くのクライアントが同時に再試行するときに発生する雷のような群れの問題を防ぐために、ランダム ジッター (0 ～ 500 ミリ秒) を追加します。
- 最も一般的なレート制限アルゴリズムはどれですか?
- トークン バケットは、実稼働 API で最も一般的です。 Stripe、AWS、およびほとんどのクラウドプロバイダーは、その亜種を使用しています。 トークン バケットを使用すると、持続的なレートを適用しながら制御されたバーストが可能になり、固定ウィンドウよりも実際のトラフィック パターンによく一致します。
- Botoi は匿名リクエストのレートを制限しますか?
- はい。 匿名リクエスト (API キーなし) では、1 分あたり 5 件のリクエストがバーストされ、1 日あたり 100 件のリクエストが IP アドレスによって追跡されます。 有料プランの認証されたリクエストには、より高い制限が適用されます。Starter では 30/分、Pro では 300/分、Business では 1,000/分が許可されます。
botoiで開発を始めよう
150以上のAPIエンドポイント。検索、テキスト処理、画像生成、開発者ユーティリティに対応。無料プラン、クレジットカード不要。