【仕組み解説】APIのレートリミットはどうやってリクエストを制限しているのか — 流量制御の仕組みを図解

それはレートリミットに引っかかったときのエラーだよ。APIには「1分間に100回まで」みたいなリクエスト回数の制限があって、それを超えるとサーバーが429エラーを返して『ちょっと待ってね』と教えてくれるんだ。

気持ちは分かるけど、制限がないと大変なことになるよ。たとえば1人のユーザーが毎秒1万回リクエストを送ったら、サーバーがパンクして他のユーザーも使えなくなっちゃう。レートリミットには主に3つの目的があるんだ。サーバーの保護、ユーザー間の公平性の確保、そしてDDoS攻撃のような悪意あるアクセスへの防御だね。

一番シンプルなのは「固定ウィンドウ方式」だよ。たとえば「1分間に100回まで」というルールなら、毎分00秒にカウンターをゼロにリセットして、リクエストが来るたびに1を足していく。カウンターが100になったら、次のリセットまで全部拒否するんだ。実装が簡単だから広く使われてるよ。

いいところに気づいたね。固定ウィンドウには「境界問題」があるんだ。たとえば0:59に100回、1:00にまた100回リクエストを送ると、実質2秒間に200回のアクセスが集中しちゃう。これを解決するのが「スライディングウィンドウ方式」で、現在時刻から過去1分間をリアルタイムに見て判定するから、境界をまたいだバーストを防げるんだよ。

有名なのが「トークンバケット方式」だよ。バケツの中にトークン（許可証）が入っていて、リクエストを送るたびにトークンを1つ消費する。トークンは一定のペース、たとえば1秒に10個ずつ自動で補充されるんだ。バケツが空になったらリクエストは拒否されるけど、バケツに余裕があればバーストも許容される。平均的な流量を制限しつつ、一時的な集中は柔軟に受け入れてくれるバランスのいい方式だね。

多くのAPIはHTTPレスポンスヘッダーで教えてくれるよ。代表的なのは3つ。X-RateLimit-Limitが上限回数、X-RateLimit-Remainingが残り回数、X-RateLimit-Resetがリセットされる時刻だね。これを見れば「あと何回使えるか」「いつ回復するか」が分かるから、アプリ側で制限に引っかかる前にペースを調整できるんだ。

そのときは「指数バックオフ」でリトライするのがベストプラクティスだよ。1回目のリトライは1秒後、2回目は2秒後、3回目は4秒後…と待ち時間を倍々に増やしていく方法だね。Retry-Afterヘッダーが返ってきたらその秒数だけ待つのも大事。絶対にやってはいけないのは、429が返ってきたのに即座にリトライし続けること。サーバーにさらに負荷をかけてしまって、状況が悪化するだけだよ。

自分で実装することもできるけど、最近はAPI GatewayやCDNの機能として提供されることが多いよ。たとえばAWSのAPI Gatewayなら、設定画面でレート上限を指定するだけで自動的に制御してくれる。CloudflareみたいなCDNもエッジレベルでレートリミットをかけられるから、悪意あるリクエストがサーバーに届く前にブロックできるんだ。大規模なサービスでは、ユーザーごと・APIキーごと・IPアドレスごとに別々の制限を設けたりもするよ。

そうだね。ちなみにプロの現場だと、レートリミットの設計はビジネス判断でもあるんだ。無料プランは1分100回、有料プランは1分1000回、みたいに料金プランと連動させることも多い。GitHubのAPIもログインしてないと1時間60回、認証済みなら5000回と大きく差がつくよ。レートリミットは単なる技術的制約じゃなくて、サービスの価値設計にも関わる重要な仕組みなんだね。