Skip to main content

Rate Limiting - Controlling API and Web Traffic

About 2 min read

レートリミット (Rate Limiting) とは、一定時間内に受け付ける リクエスト数に上限を設け、サービスを過負荷や悪用から保護する仕組みです。DDoS 攻撃の緩和、ブルートフォース攻撃の抑制、 API の公平な利用を実現するために広く導入されています。 2025 年現在、 API エコノミーの拡大に伴い、 レートリミットは API セキュリティの基本要件として定着しています。

現場での使用例

「 API のレートリミットを設定していなかったため、 1 つのクライアントが 毎秒 500 リクエストを送信し、他のユーザーのレスポンスが遅延しました。 トークンバケット方式で 1 秒あたり 50 リクエストの制限を導入し、 バースト許容量を 100 に設定したところ、全ユーザーの応答時間が安定しています。」

レート制限フロー

クライアントからリクエスト受信
レートリミッター (カウンター確認)
制限内
200 OK (処理実行)
制限超過
429 Too Many Requests

主要なアルゴリズム

固定ウィンドウ方式は「 1 分間に 100 リクエストまで」のように 時間枠を固定して計測します。実装が簡単ですが、 ウィンドウの境界でバースト的なリクエストが集中する問題があります。 スライディングウィンドウ方式は直近の時間枠で計測し、 バースト問題を緩和します。トークンバケット方式は 一定速度でトークンが補充され、リクエストごとにトークンを消費する モデルで、短時間のバーストを許容しつつ平均レートを制限できます。API 設計の書籍 (Amazon)で体系的に学べます。

実装シナリオ

ログインエンドポイントでは、同一 IP アドレスからのログイン試行を 「 5 分間に 10 回まで」に制限し、クレデンシャルスタッフィングを 抑制します。 API では、認証済みユーザーに「 1 時間あたり 1,000 リクエスト」、 未認証ユーザーに「 1 時間あたり 100 リクエスト」のように ティア別の制限を設けます。制限超過時は HTTP 429 (Too Many Requests) レスポンスと Retry-After ヘッダーを返し、 クライアントに適切な待機時間を伝えます。API キー管理と レートリミットを組み合わせることで、 API の不正利用を効果的に防止できます。

設計のポイント

レートリミットの閾値は、正規ユーザーの利用パターンを分析して 設定する必要があります。閾値が低すぎると正規ユーザーの体験を損ない、 高すぎると攻撃を防げません。分散環境では Redis などの 共有ストアでカウンターを管理し、複数サーバー間で 一貫した制限を適用します。強力なランダムパスワードと レートリミットを組み合わせることで、 ログインページの安全性を大幅に向上できます。DDoS 対策の書籍 (Amazon)も参考になります。

Related Terms

Was this article helpful?

XHatena