【入門編】 APIゲートウェイでのレートリミット(Rate Limiting)とスロットリング – Web APIアーキテクチャ・データ連携実践ガイド

サーバーを守る「門番」の知恵：APIのレートリミットを郵便局で理解しよう

こんにちは！ネットワークの世界に飛び込んだばかりの皆さん、ようこそ。

インフラの世界では、サーバーを「街」、クライアント（ユーザー）からのリクエストを「郵便物」に例えることがよくあります。普段はスムーズに届く郵便物も、ある日突然、何万通もの手紙が一度に押し寄せたらどうなるでしょう？そう、郵便局（サーバー）はパンクしてしまい、本当に届けるべき重要な手紙すら処理できなくなってしまいます。

これを防ぐための仕組みが、今回解説するレートリミット（Rate Limiting）とスロットリングです。なぜこれが必要なのか、そしてどうやって実装するのか、現場の視点を交えて紐解いていきましょう！

—

なぜ「制限」が必要なのか？

皆さんが開発したAPIが人気になり、世界中からアクセスが殺到するのは嬉しいことですよね。しかし、サーバーには「一度に処理できる限界」があります。

例えば、1秒間に100通しか処理できない郵便局に、1秒間に10,000通の手紙が届いたら？郵便局員はパニックになり、システムはクラッシュします。これを防ぐために、ゲートウェイという「門番」を入り口に配置し、「君は1秒間に10通までね！」とルールを設けるわけです。これがレートリミットの正体です。

—

賢い門番のアルゴリズム：バケットの魔法

レートリミットを実装する際、よく使われる2つの考え方を紹介します。

1. トークンバケット（Token Bucket）

「バケツ」の中に、一定のペースで「コイン（トークン）」が補充されます。

クライアントがリクエストを送るには、このコインを1枚消費します。
バケツが空だと、コインが補充されるまでリクエストは「お預け」です。

ポイント： 短時間の「急なラッシュ」をある程度許容しつつ、長期的には平均的なリクエスト数を守れるのが強みです。

2. リーキーバケット（Leaky Bucket）

「穴の空いたバケツ」を想像してください。

リクエストはバケツに注がれますが、バケツの穴からは一定の速度でしかリクエストが漏れ出しません。
どんなに激しく注いでも、処理速度は一定に保たれます。

ポイント： 処理速度を完全に一定に保ちたい、安定したインフラ運用に向いています。

—

門番からの返信：429 Too Many Requests

制限を超えてリクエストを送ってきた相手には、門番は冷たく、しかし礼儀正しくこう返します。
「429 Too Many Requests。今は混んでいるので、少し待ってから出直してくださいね」

この時、親切なAPIは Retry-After というヘッダーを添えて、「あと何秒待てばいいか」を教えてくれます。これを受け取ったクライアント側は、闇雲に再送するのではなく、指定された時間だけ静かに待つのが「大人のマナー」です。

—

実践：Nginxでレートリミットを実装してみよう

では、実際に現場でよく使われる Nginx というWebサーバーを例に、設定を見てみましょう。

# 1分間に10リクエストまでを許可するゾーン（10MBのメモリを使用）
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/m;

server {
    location /api/ {
        # 設定したゾーンを適用
        # burst=5 は、一時的に5リクエストまでなら待機させる設定
        limit_req zone=api_limit burst=5 nodelay;
        
        proxy_pass http://backend_server;
    }
}

rate=10r/m: 1分間に10回という制限です。
burst=5: 制限を超えても、5回分までは即座にエラーにせず、少しだけ「行列」を作って処理します。
nodelay: 行列に並ばせることなく、処理できるものは即座に返す設定です。

—

初学者の皆さんへ：トラブルシューティングの極意

現場で「APIが突然動かなくなった！」という相談を受けたとき、真っ先に確認すべきは以下の3点です。

1. エラーコードは何か？: 429 が返ってきているなら、サーバーの問題ではなく「制限に引っかかっている」というサインです。
2. クライアントの挙動は適切か？: 制限に引っかかった後、すぐにリトライしていませんか？指数バックオフ（待機時間を2倍、4倍と延ばしていく手法）を実装しましょう。
3. 適切なレート設定か？: そもそもビジネス上の要件と、APIの処理能力が乖離していないかを見直すことも重要です。

—

まとめ

レートリミットは、サーバーをいじめるための厳しいルールではなく、「サーバーとユーザー双方を守るための安全装置」です。

郵便局の窓口が適切に整理されているからこそ、私たちは安心して手紙を送ることができますよね。皆さんがこれから作るAPIも、こうした「門番」の考え方を取り入れることで、より堅牢で信頼されるシステムへと成長していくはずです。

一歩ずつ、焦らずに理解していきましょう！次回は、この「門番」をもっと賢くする認証のお話でお会いしましょう。それでは、良き開発ライフを！