ピクセル菌
ログをまとめています。
525 文字
3 分
レートリミットの考え方と代表的なアルゴリズム
レートリミットは、「同じ利用者からのリクエストを、一定時間あたり一定数までに制限する」仕組みです。攻撃対策にも、過負荷対策にも、コスト対策にも効きます。
何のためにかけるのか
- 総当たり攻撃やスパムの抑止（ログイン、登録、問い合わせフォームなど）
- クローラーや誤実装の暴走対策
- 公平性の確保：一部の利用者がリソースを食い尽くさないようにする
- 下流コストの制御：外部APIや課金リソースを保護する
代表的なアルゴリズム
Fixed Window（固定窓）
「直近1分間で◯回まで」のように、決まった時間枠でカウントする方式。実装が簡単で軽い反面、窓の境界で2倍流れる（59秒目に N 回、0秒目にもう N 回）というアラ がある。
Sliding Window（スライディング窓）
直近の任意の時間幅（例：直近60秒）に対してカウントする方式。境界の問題は解消するが、計算量とメモリが増える。Sliding Window Counter のような近似アルゴリズムで、実用的なバランスを取ることが多い。
Token Bucket
「バケツにトークンが一定速度で貯まり、リクエストが来ると1個消費する」モデル。バケツに上限があるので、短期的なバーストは許容しつつ、平均レートを守れる。多くのAPIゲートウェイで採用されている。
Leaky Bucket
「リクエストがバケツに溜まり、一定速度で漏れる」モデル。流量を平準化したいときに向く。Token Bucket がバーストに寛容なのに対し、こちらは出力レートを揃えたい用途に合う。
実装の置き場所
- API Gateway / CDN / WAF の機能として（Cloudflare、AWS WAF、Kong など）
- アプリケーション内 で Redis のカウンタを使って自前実装
- DBレイヤー で一意制約を使った乱暴な方式（高負荷では非推奨）
クライアントには 429 Too Many Requests と Retry-After ヘッダーで返すのが定番。さらに X-RateLimit-Limit / X-RateLimit-Remaining / X-RateLimit-Reset を返してあげると、行儀のいいクライアントは自発的に減速してくれます。