レートリミットとは何か - 質問箱を大量投稿から守る仕組み

なぜ投稿頻度を制限する必要があるのか

質問箱に限らず、ユーザーが自由にデータを送信できる Web サービスは、大量投稿攻撃のリスクを常に抱えています。悪意のあるユーザーやBot が短時間に数百、数千件の投稿を送りつけると、2 つの問題が発生します。

第一に、質問箱のオーナーの管理画面がスパムで埋め尽くされます。正当な質問が大量のスパムに埋もれ、見つけられなくなります。オーナーは 1 件ずつスパムを削除する作業を強いられ、質問箱の運用自体が嫌になります。

第二に、サーバーに過剰な負荷がかかります。1 秒間に数百件のリクエストが集中すると、サーバーの処理能力を超え、正当なユーザーのアクセスまで遅延したり、最悪の場合サービスが停止したりします。これは DDoS (Distributed Denial of Service) 攻撃の一形態です。

レートリミットは、これらの問題を「投稿頻度の上限を設ける」というシンプルなアプローチで解決します。

レートリミットの仕組み - トークンバケットの考え方

レートリミットの実装方法はいくつかありますが、直感的に理解しやすいのは「トークンバケット (Token Bucket)」というモデルです。

バケツ (容器) の中にトークン (コイン) が入っていると想像してください。質問を 1 件送信するたびに、トークンが 1 枚消費されます。トークンは一定の速度で自動的に補充されます。バケツが空になると、トークンが補充されるまで投稿できません。

本サービスでは、同一 IP アドレスからの投稿を 1 分あたり 3 件に制限しています。つまり、バケツには最大 3 枚のトークンが入り、1 分ごとに 3 枚まで補充されます。人間が質問を送るペース (1 件あたり数十秒から数分) では、トークンが枯渇することはまずありません。しかし、Bot が 1 秒間に 100 件送ろうとすると、最初の 3 件で トークンが枯渇し、残りの 97 件は拒否されます。

この仕組みの優れた点は、正当なユーザーにはほぼ影響を与えず、悪意のある大量投稿だけを効果的にブロックできることです。

IP アドレスベースの制限とその限界

レートリミットは「誰からの投稿か」を識別する必要があります。本サービスでは、投稿者の IP アドレスを識別子として使用しています。同じ IP アドレスからの投稿が 1 分間に 3 件を超えると、超過分は拒否されます。

IP アドレスベースの制限には限界もあります。第一に、同じネットワーク (会社の Wi-Fi、学校の Wi-Fi) を共有する複数のユーザーは、同じ IP アドレスから投稿することになります。この場合、1 人が 3 件投稿すると、同じネットワーク上の別のユーザーも一時的に投稿できなくなる可能性があります。ただし、1 分間に 3 件という上限は十分に余裕があるため、通常の利用で問題になることは稀です。

第二に、攻撃者が VPN やプロキシを使って IP アドレスを頻繁に変更すれば、レートリミットを回避できます。IP アドレスを変えるたびに新しいバケツが割り当てられるため、制限がリセットされます。

この限界に対処するため、レートリミットは単独ではなく、Proof of Work やハニーポットフィールドと組み合わせて使用しています。IP アドレスを変えてレートリミットを回避しても、投稿ごとに Proof of Work の計算コストがかかり、ハニーポットによる Bot 検出も機能します。多層防御の一層として、レートリミットは重要な役割を果たしています。

レートリミットに引っかかった場合

正当なユーザーがレートリミットに引っかかることは極めて稀ですが、ゼロではありません。短時間に複数の質問箱に連続して質問を送った場合や、送信ボタンを連打してしまった場合に発生する可能性があります。

レートリミットに引っかかると、サーバーは HTTP 429 (Too Many Requests) というステータスコードを返します。画面上には「投稿の頻度が高すぎます。しばらく待ってから再度お試しください」のようなメッセージが表示されます。

対処法はシンプルです。1 分ほど待ってから再度送信してください。トークンは自動的に補充されるため、待つだけで投稿可能な状態に戻ります。入力した質問の内容は消えないため、再入力の必要はありません。

「1 分に 3 件」という制限は、人間の通常の利用パターンでは到達しない水準に設定されています。質問を 1 件送るのに最低でも 20 秒はかかる (質問を考え、入力し、送信する) ため、1 分間に 3 件を超えるペースで質問を送ること自体が、通常の利用では起こりません。

レートリミットの設計思想 - 利便性とセキュリティのバランス

レートリミットの設計で最も難しいのは、閾値 (上限値) の設定です。閾値を厳しくしすぎると正当なユーザーの利便性を損ない、緩すぎると攻撃を防げません。

「1 分あたり 3 件」という閾値は、以下の考慮に基づいて設定されています。人間が質問を 1 件送るのにかかる最短時間は約 15-20 秒 (定型的な短い質問の場合)。1 分間に 3 件は、人間の最速ペースでもギリギリ到達しない水準です。一方、Bot は 1 秒間に数十件から数百件の投稿を試みるため、3 件/分の制限で投稿速度が 100 分の 1 以下に低下します。

レートリミットは、Proof of Work と補完的な関係にあります。Proof of Work は「1 件あたりの計算コスト」を課すことで大量投稿を抑制し、レートリミットは「単位時間あたりの投稿数」を直接制限します。Proof of Work を高性能な GPU で高速に解いたとしても、レートリミットにより 1 分あたり 3 件しか投稿できません。逆に、IP アドレスを変えてレートリミットを回避しても、投稿ごとに Proof of Work の計算が必要です。

この二重の制約により、攻撃者は「計算コスト」と「時間コスト」の両方を負担しなければならず、スパムの費用対効果が著しく悪化します。セキュリティの世界では、攻撃を完全に防ぐことよりも、攻撃のコストを引き上げて割に合わなくすることが現実的な防御戦略です。レートリミットは、その戦略の重要な構成要素です。

Web アプリケーションのセキュリティ対策を体系的に学びたい方は、Web セキュリティの関連書籍も参考になります。