フレームワーク活用ガイドひとことで言うと#
クライアントからのリクエスト数やリソース消費量に上限を設け、システム全体の安定性とテナント間の公平性を維持するパターン。
押さえておきたい用語#
- Rate Limiting（レートリミティング）
- 一定時間内のリクエスト数に上限を設ける制御手法のこと。スロットリングの最も一般的な実装形態。
- Token Bucket（トークンバケット）
- バケットにトークンを一定速度で補充し、リクエストごとにトークンを消費するレート制限アルゴリズム。バースト許容が特徴。
- Sliding Window（スライディングウィンドウ）
- 固定時間枠ではなく直近N秒間のリクエスト数で判定するアルゴリズムを指す。窓の境界での急増を防げる。
- Backpressure（バックプレッシャー）
- 下流のシステムが過負荷の場合に上流へ処理速度の低下を伝播させる仕組みである。スロットリングと組み合わせて使う。
- 429 Too Many Requests
- HTTPステータスコードでレート制限超過をクライアントに通知するレスポンス。Retry-Afterヘッダーと組み合わせるのが標準的な実装。
スロットリングパターンの全体像#
こんな悩みに効く#
- 特定テナントの大量リクエストが他テナントのパフォーマンスを低下させる
- バースト的なアクセスでバックエンドやDBが過負荷になる
- APIの利用量に応じた課金モデルを実装したいが制御手段がない
基本の使い方#
具体例#
エンジニア30名のBtoB SaaS。テナント 500社 が共有インフラを利用する中、上位 3社 がAPI呼び出しの 60% を占め、他テナントのレスポンスタイムが 2.5秒 に悪化していた。
テナントIDベースのToken Bucketスロットリングを導入。Free/Standard/Enterpriseの3ティアで上限を設定（100/500/2,000 RPM）。制限超過時は429レスポンスとRetry-Afterヘッダーを返す実装とした。
導入後、全テナントのP95レスポンスタイムが 2.5秒 → 180ms に改善。上位3社にはEnterprise契約への移行を提案し、月額ARRが 15% 増加した。
エンジニア50名の決済APIプロバイダー。月間 2億件 のトランザクションを処理する中、月に 3〜4回 のDDoS攻撃を受け、毎回 15〜30分 のサービス停止が発生していた。
3層スロットリングを構築。CDN層でIPベースのFixed Window（1,000 RPM/IP）、API Gateway層でAPIキーベースのSliding Window、アプリケーション層でテナント別Token Bucketを適用。異常検知で動的にレートを絞る仕組みも追加した。
DDoS攻撃時のサービス停止が ゼロ に。正常トラフィックへの影響もP99レイテンシ 50ms以内 に収まっている。
エンジニア8名の自治体向けオープンデータAPI。通常は日 5万リクエスト だが、災害時に 100万リクエスト/時 のアクセスが集中し、サーバーがダウンして情報提供が停止する問題が繰り返されていた。
通常時は 100 RPM/クライアント のFixed Windowで制御しつつ、災害モード時にはCDNキャッシュのTTLを 60秒 に短縮しバックエンドへの到達を減らす二段構えの設計を採用。
災害時のアクセス集中でもサービス稼働率 99.95% を維持。レスポンスタイムは通常時 120ms、災害時でも 350ms に抑えられた。
やりがちな失敗パターン#
- レート上限が厳しすぎる — 正常な利用まで制限してしまうとユーザー体験が悪化する。トラフィック分析に基づき、正常利用の2〜3倍のマージンを設ける
- 429レスポンスにRetry-Afterがない — クライアントが即座にリトライして雪崩を起こす。Retry-Afterヘッダーで次にリクエスト可能な時刻を通知する
- 分散環境でのカウンター不整合 — 複数インスタンスがローカルカウンターで判定すると、実質的にインスタンス数倍のレートを許容してしまう。Redisなどの共有ストアを使う
- レート制限の存在を文書化しない — APIドキュメントにレート上限・429時の挙動・Retry-Afterの意味を明記しないと、クライアント側で適切な対処ができない
まとめ#
スロットリングパターンは、リクエストレートに上限を設けてシステムの安定性とテナント間の公平性を維持するクラウドデザインパターン。Token Bucket・Sliding Window・Fixed Windowの3つのアルゴリズムから要件に応じて選択し、429レスポンスとRetry-Afterヘッダーでクライアントに適切な再試行を促す。マルチテナント環境での公平性確保とDDoS防御の両面で必須の実装パターン。