【入門編】 APIゲートウェイにおけるレートリミット(Rate Limiting)とDoS攻撃対策 – Web APIアーキテクチャ・データ連携実践ガイド

【API設計入門】サーバーの悲鳴を止めろ！APIゲートウェイで構築するレートリミット（429）とDoS攻撃対策の極意

みなさん、こんにちは！今日もネットワークとパケットの世界へようこそ。

Webサービスやアプリを作っていると、必ず直面するのが「アクセス集中」の問題です。ニュースで話題になった瞬間にアプリが重くなったり、特定のユーザーが猛烈な勢いでデータを取りにきてサーバーが倒れてしまったり……そんな苦い経験はありませんか？

インフラやWeb APIの世界では、こうした「過剰なアクセス」からシステムを守るための「レートリミット（Rate Limiting）」という非常に重要で美しい仕組みが存在します。

今回は、インフラやネットワークの学習を始めたばかりの初心者のみなさんに向けて、APIゲートウェイがどのようにして押し寄せるトラフィックを制御し、安全にサービスを稼働させているのかを、身近な例えを交えながら「一歩ずつ理解していきましょう！」

—

1. レートリミットとは？〜テーマパークの入場制限で考えよう〜

まずは「レートリミット」の基本的な概念から紐解いていきましょう。

レートリミットとは、一言で言えば「一定の時間内に受け付けるリクエスト（アクセス）の回数を制限する仕組み」のことです。

例えば、大人気のテーマパークを想像してみてください。
もし入場ゲートを無制限に開放してしまったらどうなるでしょうか？アトラクションには数時間待ちの大行列ができ、通路は人でごった返し、最悪の場合は安全確保のためにパーク全体が機能停止（システムダウン）してしまいますよね。

そこでテーマパークでは、以下のような工夫をします。

  • 1分間にゲートを通過できる人数を10人までに制限する
  • 上限を超えたら、外の広場で少し待ってもらう

これとまったく同じことをWeb APIの世界で行うのが「APIゲートウェイ」におけるレートリミットです。

なぜDoS攻撃対策になるのか？

インターネットの向こう側には、悪意を持って大量のアクセスを送りつけ、サーバーをダウンさせようとする「DoS攻撃（Denial of Service attack）」を行う人がいます。また、悪意はなくても「プログラムのバグで無制限ループに陥り、1秒間に数万回もAPIを呼び出してしまった」という親切な開発者のうっかりミス（事故）も日常茶飯事です。

APIゲートウェイが手前で「はい、あなたは1秒間に10回までですよ！」と通せんぼ（レートリミット）をすることで、後ろで控えている本陣のデータベースやアプリケーションサーバーまで過剰なパケットが届かないように守ってくれるのです。

—

2. 誰を制限する？「IPベース」と「ユーザーベース」の鑑別手口

では、APIゲートウェイは「誰がどれくらいアクセスしてきたか」をどうやって見分けているのでしょうか？
代表的な手法である「IPベース」と「ユーザーベース」の2つの仕組みを比較してみましょう。

① IPベース（郵便番号と住所で判断する手法）

インターネット上の機器には、必ず 192.168.1.1 や 203.0.113.5 といった「IPアドレス」と呼ばれる識別番号が割り当てられています。これは手紙でいう「差出人の住所」のようなものです。

IPベースの制限では、APIゲートウェイが「この 203.0.113.5 という住所からのアクセスは、1分間に60回までにしよう」とカウントします。

  • メリット: ユーザーがログインしていなくても、すべてのアクセスに対して一律で適用できる。
  • デメリット（注意点）: 同じオフィスや学校のWi-Fiからアクセスしている全員が「同じ1つのIPアドレス」を共有している場合（NAT機能といいます）、1人の暴走のせいで、同じオフィスにいる真面目な他の同僚まで巻き添えでアクセス制限がかかってしまうことがあります。

② ユーザーベース（会員証の番号で判断する手法）

ログイン機能があるWebサービスやAPIサービスでは、リクエストの中に「APIキー」や「アクセストークン」と呼ばれる固有のデジタル会員証を入れて通信します。

ユーザーベースの制限では、APIゲートウェイが「会員ID: user_12345 さんのアクセスは、1分間に100回までにしよう」とカウントします。

  • メリット: どこからアクセスしていても「個人」を特定できるため、非常に公平な制限がかけられる。課金プランに応じて「無料会員は1分に10回、有料会員は1分に1000回」といった柔軟な設計も可能。
  • デメリット: ログイン前の画面（トップページやユーザー登録画面など）には使えない。

実務では、「ログイン前はIPベースでざっくり守り、ログイン後はユーザーベースで厳密に制御する」というハイブリッドな構成がよく使われます。

—

3. 限界を超えたらどうなる？「429 Too Many Requests」という優しさ

もしユーザーが制限回数（上限）を超えてリクエストを送ってきた場合、APIはどのように返答すべきでしょうか？

無言で無視したり、サーバー内部のエラーである 500 Internal Server Error を返したりするのは、スマートな設計ではありません。ネットワークの世界には、「あいにく今はリクエストが多すぎます。少し時間をおいてね」と伝えるための専用のステータスコードが用意されています。

それが、429 Too Many Requests です。

応答ヘッダーに込める「思いやり」のパラメーター

単に 429 というエラーを返すだけでなく、親切なAPIゲートウェイはHTTPレスポンスの「ヘッダー（手紙の便箋のヘッダー部分）」に以下のような追加情報を添えて返します。

  • X-RateLimit-Limit: 許可されている最大リクエスト数（例: 100）
  • X-RateLimit-Remaining: 今回のウィンドウ（時間枠）で残っているリクエスト数（例: 0）
  • X-RateLimit-Reset: リミットがリセットされる時刻（Unixタイムスタンプ）
  • Retry-After: 「あと何秒待てば再試行していいか」（例: 30）

この Retry-After: 30 というヘッダーがあるおかげで、呼び出し側のアプリ（スマホアプリやフロントエンド）は「あ、今混んでいるんだな。じゃあ30秒カウントダウンしてからもう一度ボタンを押せるようにしよう」と、賢く制御することができるのです。

—

4. 実践！設定コードとプログラム例を見てみよう

概念が理解できたところで、実際の設定ファイルやプログラムのイメージを覗いてみましょう。「案外シンプルなんだな」と感じていただけるはずです！

① Nginx（APIゲートウェイ）でのレートリミット設定例

WebサーバーやAPIゲートウェイとして世界中で広く使われている「Nginx」の設定例です。ここではIPアドレス（$binary_remote_addr）を元に制限をかける設定を書いています。

# httpブロック内に記述するレートリミットの定義
# $binary_remote_addr : 訪問者のIPアドレスを識別子として使用
# zone=mylimit:10m    : 状態を記憶するメモリ領域の名前を「mylimit」、サイズを10MBに設定
# rate=10r/s          : 1秒間に10リクエスト（10 requests per second）を上限とする
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

server {
    listen 80;
    server_name api.example.com;

    location /api/ {
        # 定義した「mylimit」を適用
        # burst=20 : 一時的なスパイク（瞬間的なアクセス）を20回分まで許容してキューに溜める
        # nodelay  : 許容範囲内のアクセスなら遅延させずに即座に処理する
        limit_req zone=mylimit burst=20 nodelay;

        # レートリミット超過時に返すステータスコードを「429」に指定（デフォルトは503）
        limit_req_status 429;

        # 実際のバックエンドサーバーへ転送
        proxy_pass http://backend_service;
    }
}

② Pythonによる「429エラー」と「Retry-After」のレスポンス処理例

もしアプリ側（またはAPI側）でレートリミットの判定を行い、クライアントに 429 を返す場合の擬似コード（Python）を見てみましょう。

import time
from fastapi import FastAPI, Request, Response, status

app = FastAPI()

# 簡易的なアクセス記録（実務ではRedisなどの高速なインメモリDBを使います）
# キー: IPアドレス, 値: 最終アクセス時刻のリスト
access_history = {}

# 制限ルール: 60秒間に最大5回まで
LIMIT_WINDOW = 60  # 秒
MAX_REQUESTS = 5   # 回

@app.get("/api/data")
async def get_data(request: Request, response: Response):
    # クライアントのIPアドレスを取得
    client_ip = request.client.host
    current_time = time.time()
    
    # 該当IPのアクセス履歴を取得・整理
    history = access_history.get(client_ip, [])
    # 60秒以上前の古い履歴を削除
    history = [t for t in history if current_time - t < LIMIT_WINDOW]
    
    # リクエスト数が上限（5回）に達しているかチェック
    if len(history) >= MAX_REQUESTS:
        # 一番古いアクセスから60秒経過するまでの「待ち時間」を計算
        oldest_access = history[0]
        retry_after_seconds = int(LIMIT_WINDOW - (current_time - oldest_access))
        
        # 429 Too Many Requests エラーを返す設定
        response.status_code = status.HTTP_429_TOO_MANY_REQUESTS
        # クライアントに親切なヘッダーを付与！
        response.headers["Retry-After"] = str(max(1, retry_after_seconds))
        response.headers["X-RateLimit-Limit"] = str(MAX_REQUESTS)
        response.headers["X-RateLimit-Remaining"] = "0"
        
        return {
            "error": "Too Many Requests",
            "message": f"アクセス頻度が高すぎます。{retry_after_seconds}秒後に再試行してください。"
        }
    
    # 今回のアクセス時刻を記録
    history.append(current_time)
    access_history[client_ip] = history
    
    # 正常なレスポンス
    remaining = MAX_REQUESTS - len(history)
    response.headers["X-RateLimit-Limit"] = str(MAX_REQUESTS)
    response.headers["X-RateLimit-Remaining"] = str(remaining)
    
    return {"message": "成功！データを取得しました。", "data": [1, 2, 3]}

—

5. まとめ：レートリミットは「拒絶」ではなく「システムと利用者を守る愛」

今回は、APIゲートウェイにおけるレートリミットの仕組みと、DoS攻撃対策、そして 429 Too Many Requests の重要性について解説しました。

最後に重要なポイントを振り返っておきましょう！

1. レートリミットは、サーバーのキャパシティを超えるアクセスを防ぎ、システムダウン（DoS状態）を防ぐ防波堤。
2. 識別手法には、誰でも制限できる「IPベース」と、個人ごとに公平に制限できる「ユーザーベース（APIキー等）」がある。
3. 超過時には無機質なエラーではなく、429 Too Many Requests と Retry-After ヘッダーを返して、親切に待ち時間を伝えるのが美しいAPI設計。

レートリミットは、決してユーザーのアクセスを意地悪く拒絶するためのものではありません。「すべてのユーザーに安定して快適なサービスを届けるための、交通整理のルール」なのです。

これからWeb APIを設計したり、インフラを構築したりするときは、ぜひこの「429の優しさ」を思い出して設計してみてくださいね。

一歩ずつ、確実にネットワークとインフラの深遠な世界を楽しんでいきましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました