LASSIC Media らしくメディア

「APIを外部に公開する開発で、ベンダーから『レートリミットをかけます』という説明を受けたが、それが何を制限し、どんな効果があるのかがつかめない」——IT事業部でシステムの提案や設計方針を確認する立場にいると、こうした場面に出会うことがあるのではないでしょうか。レートリミットは、Webサービスやシステム連携の裏側でよく使われる仕組みで、サーバを過負荷や濫用から守るための基本的な備えです。とはいえ画面に現れるものではなく、ふだんは意識されないため、発注者やPMにとってはイメージしづらい領域になりがちでしょう。その考え方を大まかにでも理解しておくと、なぜその制限が必要なのか、しきい値をどう決めるのか、正規の利用者に影響しないかといった判断がしやすくなります。本記事では、特定の製品の設定手順ではなく、レートリミットとはそもそも何を指すのか、なぜ必要で、どのような方式があり、運用で何に気をつけるべきかを、発注・運用の視点から順に整理します。用語をすべて覚える必要はありませんが、「一定時間あたりの回数に上限を設ける」という勘所をつかんでおくと、ベンダーとの会話の解像度が変わってくるはずです。

レートリミットとは何か

レートリミット（Rate Limit）とは、一定時間あたりに受け付けるリクエストの回数に上限を設け、それを超えた分を制限する仕組みです。たとえば「1つの利用者につき1分間に60回まで」といった形でしきい値を決め、その範囲を超えたリクエストは、いったん断ったり待たせたりします。過剰なアクセスがサーバに集中して全体が遅くなったり停止したりするのを防ぎ、サービスを落ち着いた状態に保つための備えといえます。

身近なたとえで言えば、人気の飲食店で行われる「1人あたりの注文数の制限」や、イベントの「1回の入場人数の上限」に近いものと考えると分かりやすいでしょう。制限がなければ、一部の人が大量に注文して他の客に商品が行き渡らなかったり、一度に人が殺到して会場が混乱したりします。レートリミットも同じように、限られた処理能力を多くの利用者で公平に分け合い、混雑による共倒れを避けるための交通整理の役割を担っています。

レートリミットは、特別なシステムだけの話ではありません。普段使っているWebサービスやスマートフォンのアプリの多くが、裏側で何らかの上限を設けています。短時間に検索や送信を繰り返したときに「しばらく待ってから試してください」と表示された経験があれば、それがレートリミットの働きの一例だといえるでしょう。外部に公開されるAPIはもちろん、ログイン処理やパスワードの再設定、メールの送信、ファイルのアップロードなど、悪用されたり過負荷になったりしやすい入り口には、こうした上限がよく設けられています。

似た言葉に「スロットリング」や「クォータ」があります。スロットリングは、上限を超えた分をすぐに断るのではなく、処理の速さをあえて落として受け流す考え方を指すことが多く、レートリミットと重ねて使われる場面もあります。クォータは「1か月に10万回まで」のように、より長い期間の総量に上限を設けるものです。いずれも「使いすぎを抑える」点では共通しますが、見ている時間の幅や超過時の振る舞いが異なります。厳密な線引きは製品やサービスによって揺れがあるため、言葉の定義そのものより「どの期間で・何を単位に・超えたらどうなるのか」を確認するほうが、実務では役立つでしょう。

ここで押さえておきたいのは、レートリミットは特定の攻撃だけを狙って弾くものではなく、正規のアクセスも含めて「回数」という物差しで一律に上限を設ける仕組みだという点です。そのため、しきい値の決め方を誤ると、正規の利用者まで制限してしまうこともあります。この加減が運用上の要点になるため、後の章で改めて触れます。次の図は、リクエストがレートリミッタを通り、上限内はサーバへ、超過分は断られる流れを単純化して示したものです。

なぜレートリミットが必要なのか

上限を設けるのは一見不便にも思えますが、レートリミットには、サービスを守るうえで重要な役割がいくつもあります。代表的なものを挙げてみましょう。

一つ目は過負荷の防止です。短時間に大量のリクエストが集中すると、サーバが処理しきれずに応答が遅くなり、ほかの利用者にも影響が及びます。上限を設けておけば、想定を超える負荷が一気にかかる事態を抑えられます。二つ目は濫用や不正利用の抑止です。パスワードを機械的に試し続ける総当たりや、プログラムによる大量のデータ収集など、短時間に繰り返される不審なアクセスは、回数の上限によって効きにくくなります。

三つ目はコストの抑制です。クラウドでは、処理量やデータ転送量に応じて費用が発生することが多く、一部の過剰なアクセスが費用を押し上げる場合があります。たとえば、リクエストの回数や処理時間に応じて課金される構成では、一つのプログラムが暴走して大量に呼び出すだけで、月の費用が想定を大きく超えてしまうことも起こり得るでしょう。上限を設けておくと、こうした想定外の急増による費用の膨張を抑えるのに役立ちます。四つ目は利用者間の公平性です。一部の利用者が処理能力を占有してしまうと、ほかの利用者の体験が損なわれます。回数の上限は、限られた資源を多くの利用者で分け合うための土台といえるでしょう。これらはいずれも、外部にAPIを公開する場面や、多くの利用者が同時に使うサービスで、とりわけ意味を持ちます。

具体的な場面を思い浮かべると、必要性がつかみやすいはずです。たとえば、あるキャンペーンの申込APIを外部の提携先に公開したとしましょう。提携先のプログラムに不具合があり、本来は数分に一度でよい問い合わせを、誤って毎秒何百回も送り続けてしまう——こうしたことは決して珍しくありません。上限がなければ、この一社の不具合だけで申込APIが応答できなくなり、ほかの提携先や自社の利用者まで巻き込む事態になりかねないのです。レートリミットを設けておけば、超過分を早い段階で断り、影響を送信元の一社にとどめられます。攻撃だけでなく、こうした善意の事故から全体を守るのも、レートリミットの大切な役目だといえるでしょう。

主な制限方式

「一定時間あたりの回数を数える」といっても、その数え方にはいくつかの方式があります。方式によって、制限のかかり方やアクセスの波への強さが変わるため、提案された設計がどの方式を前提にしているかを把握しておくと、判断の助けになるはずです。代表的な方式を、以下の表に整理しました。

どの方式が適しているかは、扱うアクセスの性質によって変わります。アクセスの波が大きく、瞬間的な集中を許容したい場合はトークンバケットが向きますし、下流の処理量を一定に保ちたい場合はリーキーバケットが選ばれることもあるでしょう。発注の段階で細かなアルゴリズムまで指定する必要はありませんが、「どういう考え方で数えるのか」をベンダーに一度確認しておくと、後から挙動を把握するときに戸惑いにくくなります。

方式選びで一つの軸になるのが、瞬間的な集中（バースト）をどこまで許すかという点です。利用者の操作は、一定のペースで平らに届くわけではありません。画面を開いた瞬間に複数のリクエストがまとめて飛ぶなど、短い時間に固まりがちです。固定ウィンドウやスライディングウィンドウが主に「一定時間の総数」を見るのに対し、トークンバケットは「平均のペースは抑えつつ、貯めたトークンの範囲で一時的な集中は通す」という調整ができます。正規の利用でも自然に起きる小さな集中を許容したいのか、それとも流入量をなるべく一定に保ちたいのか。この違いが、方式を選ぶ際の判断材料になるでしょう。

上限に達したときの挙動

レートリミットで上限を超えたとき、システムはどう振る舞うのでしょうか。Webの世界では、上限超過を示す専用の応答が用意されています。それがHTTPステータスコードの「429 Too Many Requests（リクエストが多すぎます）」です。上限を超えたリクエストには、この429が返され、「今は受け付けられないので、時間をおいてやり直してほしい」と伝えられます。

あわせて、応答には「いつ再試行すればよいか」を示す情報が添えられることがあります。代表的なのが「Retry-After」という項目で、どれくらい待てば再びリクエストできるかの目安が示されるものです。加えて、「1分間にあと何回使えるか」といった残り回数を示す情報が返される仕組みもあり、利用者側のプログラムは、これらを読み取って再試行のタイミングを調整できます。適切に設計されていれば、上限に達しても利用者側が自動でリトライして処理を続けられるため、単なるエラーで終わらせずに済みます。

ここで大切なのは、レートリミットは「拒否して終わり」ではなく、再試行を前提とした対話的な仕組みだという点です。制限をかける側と受ける側が、429やRetry-Afterといった共通の合図でやり取りすることで、混雑時にも秩序を保ちながら処理を進められます。ベンダーの提案を確認する際は、上限を超えたときにどう応答し、利用者側にどう再試行を促すのかまで含めて、設計を見ておくとよいでしょう。

上限を超えたリクエストへの対応にも、いくつかの選択肢があります。もっとも一般的なのは429ですぐに断る方法ですが、用途によっては、超過分をすぐに捨てずに短い時間だけ待たせてから処理する、あるいは順番待ちの列（キュー）に入れて後から順に捌く、といった設計も採られます。どれを選ぶかは、利用者を待たせてでも処理を通したいのか、それとも早めに断って負荷をしっかり抑えたいのかという方針しだいです。発注や仕様確認の場では「上限を超えたリクエストは断るのか、待たせるのか」を一言確認しておくと、後から挙動を理解するのがぐっと楽になります。

発注・運用で意識したい観点

レートリミットは仕組み自体はシンプルですが、実運用でうまく機能させるにはいくつか押さえておきたい観点があります。発注や設計方針の会話で出てくる代表的なものを挙げておきます。

第一に、何を単位に数えるかです。利用者ごとなのか、接続元のIPアドレスごとなのか、APIキーごとなのかによって、制限のかかり方は大きく変わります。たとえばIPアドレス単位にすると、同じ社内から多数の利用者がアクセスする環境では、一人の過剰利用が全員に影響することもあるでしょう。自社の利用形態に合った単位を選ぶことが出発点になります。第二に、しきい値の決め方です。厳しくしすぎると正規の利用者まで弾いてしまい、緩くしすぎると守りの効果が薄れます。想定される正常な利用のピークを見積もり、それに余裕を持たせた値から始めて、運用しながら調整していく進め方が現実的でしょう。

第三に、正規の利用者を締め出さない配慮です。制限に達したときに、いきなり長時間ブロックするのではなく、まず429で丁寧に断り、待てば再開できるようにしておくと、正規の利用者の体験を大きく損なわずに済みます。第四に、監視です。どのくらいの頻度で上限に達しているか、特定の利用者や経路に偏りがないかを把握できるようにしておくと、しきい値の見直しや、不審なアクセスの early な検知に役立ちます。制限が頻発しているなら、しきい値が実態に合っていないか、あるいは想定外の使われ方をしている手がかりになります。なお本記事は特定製品の設定手順ではなく、レートリミットという仕組みの考え方と運用で押さえたい観点に焦点を当てているものです。個別の実装を詰める段階では、利用するサービスやフレームワークの公式ドキュメントや、実績のあるベンダーへの確認が別途必要になります。

もう一つ、レートリミットは単独ですべてをまかなえるわけではない、という点も押さえておきたいところです。大量アクセスへの備えとしては、処理を複数のサーバに振り分ける負荷分散、配信を肩代わりするCDN、不正な通信を見分けて遮る役割のWAF（Webアプリケーションファイアウォール）、負荷に応じてサーバの台数を増減させるオートスケールなど、役割の異なる仕組みが組み合わさって全体の守りを形づくります。レートリミットは、そのなかで「受け付ける量の入り口を絞る」一枚を担う存在です。どこまでをレートリミットで受け持ち、どこからを他の仕組みに任せるのかを、全体像のなかで位置づけて考えると、過不足のない設計に近づけるでしょう。

まとめ

• レートリミットとは、一定時間あたりのリクエスト回数に上限を設け、超過分を制限してサービスを守る仕組みです。
• 過負荷の防止、濫用・不正利用の抑止、コストの抑制、利用者間の公平性の確保といった役割があります。
• 固定ウィンドウ・スライディングウィンドウ・トークンバケット・リーキーバケットなどの方式があり、アクセスの性質に応じて選ばれます。
• 上限を超えるとHTTP 429で断り、Retry-Afterなどで再試行を促す、対話的な仕組みになっています。
• 運用では、数える単位・しきい値の決め方・正規利用者への配慮・監視といった観点を押さえておくと安定します。
• 本記事は特定製品の設定手順ではなく、レートリミットという仕組みの考え方と運用の観点の整理を狙いとしています。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典

• MDN Web Docs「429 Too Many Requests」
• IETF「RFC 6585 Additional HTTP Status Codes」
• Microsoft「Rate Limiting パターン」

Tweet