429 Too Many Requestsとは
429 Too Many Requests（フォー・トゥー・ナイン・トゥー・メニー・リクエスツ）は、短時間の要求数が制限を超えたため、処理を一時的に拒否したことを示すステータスです。
頻度制限の結果をクライアントへ伝えます。応答本文で制限条件を説明し、Retry-After ヘッダーで再試行までの待ち時間を示せます。
「一つのIPアドレスから多すぎた」とは限りません。利用者、API鍵、トークン、アカウント、資源、組織、地域、全体処理余力など、サーバーが選んだ単位で数えます。
何を単位に数えるか
共有IPでも利用者を分けやすい一方、認証前の要求には使えません。
契約プランごとの割り当て量を表せますが、鍵漏えい対策が必要です。
簡単ですが、NAT利用者をまとめて制限し、IPv6アドレスの変更へ弱い場合があります。
重い検索やログインだけを厳しくし、軽いステータス確認と分けられます。
代表的な頻度アルゴリズム
| 方式 | 考え方 | 注意 |
|---|---|---|
| 固定時間窓 | 一定区間ごとにカウンターをリセット | 境界の前後で瞬間的に集中しやすい |
| Sliding 期間 | 直近時間範囲を連続評価 | 精度と保存・計算費用の長所と短所 |
| Token バケット | トークンを一定速度で補充し要求ごとに消費 | 平均頻度を守りつつ一定瞬間的な集中を許す |
| Leaky バケット | 待ち行列から一定速度で流す | 待ち時間と待ち行列上限を管理する |
クライアントの再試行
- Retry-Afterを読む秒数またはHTTP日時として示される待機目安を解釈します。
- 要求の再送安全性を確認する同じ操作が二重実行にならない冪等性鍵等を使います。
- 指数バックオフを行う連続失敗ほど間隔を広げ、最大待機と試行回数を定めます。
- 待ち時間のばらつきを加える多数クライアントが同時に復帰する同時再試行の集中を避けます。
503との使い分け
429は特定クライアント・利用単位が要求数の上限を超えたことを示します。サービス全体が過負荷・メンテナンスで処理不能なら503 Service Unavailableが適します。入口で両方が混ざる場合も、監視では方針超過と処理余力不足を別指標にします。
分散システムでは各処理点のローカルカウンターだけだと総上限を超え、中央カウンターだけだと遅延や単一障害点になります。近似カウンター、区画ごとの割り当て量、最終的な整合性、障害時に要求を許可するか拒否するかを決めます。
要求数の上限は防御と公平性の両方
DoS対策だけでなく、誤った再試行ループ、巡回プログラム、瞬間的なアクセス集中から他利用者の処理余力を守り、契約プランごとの利用枠を公平に分ける目的があります。制限値、残量、リセット時刻の目安をAPI仕様で明示できると、クライアント側で超過を予防できます。
429は要求数の上限の超過を示します。数える主体、時間期間、瞬間的な集中、Retry-Afterを明確にし、クライアントは安全なバックオフと待ち時間のばらつき、サーバーは公平な分散カウンターで再集中を防ぎます。
429とRetry-After：RFC 6585「429 Too Many Requests」