「レートリミッター」って聞いたことある？たぶん、アプリとかサービスを使ってて「ちょっと待ってね、アクセスが多すぎるよ」みたいなメッセージを見たことあるかも✨
実はこれ、サーバーがパンクしないように一定時間に処理できるリクエストの数を制限する仕組みなんだよね🧠
今回は、そのレートリミッターをどうやって作るか、システム設計の視点からざっくり説明してみるよ🌸
レートリミッターって何？🤔
ざっくり言うと、「○秒に○回までしか使わせないよ」って決めるルールのことだよね。
たとえば、
- 1分に100回までAPIを使える
- 1時間に1000回までログイン試行できる
みたいに制限かけて、サーバーの負荷を調節してるんだ💡
これがないと、悪意ある攻撃や単純にアクセス集中でサービスが落ちちゃうかも😳
どうやって設計するの？ポイントは3つ✨
-
制限の単位を決める
例えば「10秒に5回」なのか「1時間に100回」なのか。ここが基本のルールになるよ📌 -
どこでリクエストを数えるか
- アプリ側？
- サーバー側？
- それともAPIゲートウェイ？
多くの場合はサーバーの入口あたり（APIゲートウェイとか）で数えることが多いよ🧠
-
カウンターの更新方法
リクエストが来るたびにカウントアップして、決めた上限を超えたら拒否する仕組み。
でもこれ、単純に数えるだけじゃなくて、どのくらいの期間で数えるかが大事⚡
よく使われる3つのアルゴリズム🎀
1. Fixed Window（固定時間枠）
一定の時間枠ごとにリクエストを数える。たとえば、毎分リセットされて、0〜59秒の間のリクエストだけ数える感じ📅
シンプルだけど、時間の境目に大量アクセスくると制限が甘くなることもあるよ😵💫
2. Sliding Window（スライド時間枠）
今から過去○秒間のリクエスト数を常にチェックする方式。
時間の境目問題が減るけど、計算がちょっと複雑✨
3. Token Bucket（トークンバケット）
あらかじめトークン（許可証）を貯めておいて、リクエストが来たらトークンを消費するイメージ。
トークンがなければリクエスト拒否。時間とともにトークンが補充されるよ🎈
これだと、たまにバースト（一気にいっぱい来ること）にも対応できるんだ♪
具体的にどうやって実装する？🔧
- メモリやDBでカウントを管理
Redisみたいな高速でカウントできるストアがよく使われるよ📚 - 分散システムだとデータ同期が難しい
複数のサーバーがある場合、どこでカウントするか調整が必要💭 - レスポンスに制限情報を入れると親切
「あと何回使えるよ」みたいに教えてあげると、ユーザーも安心するよね🥺
面接で出たらどう答える？🧠
わたしも最初は「何それ？」って感じだったけど、
「レートリミッターは過剰なアクセスを防ぐための仕組みで、時間単位の制限をかける」って説明して、
- 実装としてはFixed WindowやToken Bucketなどのアルゴリズムがあるよと話せればOK👌
そして、分散環境でのカウント同期の難しさや、それに対する工夫も一言添えられたらいいかも✨
レートリミッターって地味だけど、サービスの安定には欠かせない大事な仕組みなんだな〜って思うよ💭
聞いてみると、思ったよりシンプルで「あ、なるほどね」ってなるから、もし面接とかで出てきたら落ち着いて話してみてね🫶
はてな
コメント
チャーリー
すごくありがたい！ マジで感謝してる！
