【入門編】 APIゲートウェイにおけるレートリミット(Token Bucket/Leaky Bucket) – Web APIアーキテクチャ・データ連携実践ガイド

こんにちは！ネットワークエンジニアの視点から、Webの裏側を覗き見る楽しさをお届けしている筆者です。

今日は、Web APIの「門番」であるAPIゲートウェイが、どうやって押し寄せるアクセスを捌いているのか、その「心臓部」とも言えるトラフィック制御アルゴリズムについて紐解いていこうと思います。

「APIを公開したら、誰かに大量のリクエストを送りつけられてサーバーがダウンした……」なんて悪夢、インフラの世界ではよくある話です。そんな事態を防ぐための賢い仕組み、一緒に見ていきましょう！

—

郵便局の窓口で考える「混雑回避」の知恵

APIゲートウェイでのレートリミット（通信制限）は、例えるなら「郵便局の窓口対応」と同じです。

想像してみてください。突然、数百人が一気に郵便局に押し寄せたらどうなるでしょう？窓口が一つしかなければ、全員がパニックになり、結局誰も手続きができなくなりますよね。そこで郵便局は、整理券を配ったり、窓口を増やしたりして流れを整えます。

APIの世界でも、これと同じことを「アルゴリズム」を使って行っています。代表的なのが、Token Bucket（トークンバケツ）とLeaky Bucket（リーキーバケツ）です。

—

1. Token Bucket：短時間の「爆発」を許容する柔軟な心

Token Bucketは、バケツの中に一定の間隔で「トークン（チケット）」が補充される仕組みです。

ルール： リクエストを送るには、バケツからトークンを1枚取り出す必要がある。
特徴： バケツが満杯なら、多少の「急なリクエストの集中（バースト）」も即座に処理できる。

これは「普段は静かだけど、たまに大量の年賀状を出しに来る人がいても、窓口のスタッフが頑張って対応してくれる」という柔軟性のある窓口に似ています。

—

2. Leaky Bucket：一定の速度で「淡々」とこなす職人

一方でLeaky Bucketは、底に小さな穴が開いたバケツです。

ルール： リクエストという水がバケツに入り、底の穴から一定の速度で水が滴り落ちていく。
特徴： バケツがいっぱいになったら、それ以上のリクエストは溢れて捨てられる。

こちらは「どんなに人が並んでも、スタッフは決して慌てず、一定のペースで淡々と処理を行う」という、非常に安定した職人タイプです。

—

現場でどう使い分ける？設定の勘所

APIゲートウェイ（例えばAWS API GatewayやKongなど）では、これらを IPアドレス や APIキー をキーにして適用します。

例えば、特定の APIキー を持つクライアントに対して「1分間に100リクエストまで」と制限をかける設定は、以下のようなイメージで行います（擬似的な設定例です）。

# APIゲートウェイの設定例
rate_limit_policy:
  client_id: "user_12345"
  # 1分間に処理できるリクエスト数
  requests_per_minute: 100
  # バースト（瞬間的な許容量）
  burst_capacity: 20
  # 制限を超えた時のレスポンスコード
  error_status_code: 429 # "Too Many Requests"

この 429 Too Many Requests というステータスコードを返してあげるのが、マナーの良いAPI設計の第一歩です。「今は混んでいるから、少し休んでからまた来てね」とクライアントに伝えることが、健全なネットワークを守る鍵となります。

—

初学者のための「現場の知恵」

インフラを構築する際、初めて触れる方が陥りやすいのが「全部のAPIに同じ制限をかける」というミスです。

1. 重要度で分ける： ログインや課金処理など、絶対に落としてはいけないAPIは制限を緩くし、検索などの負荷が高いAPIは厳しく制限する。
2. IP制限は諸刃の剣： 社内LANや公衆Wi-Fiなど、一つの IPアドレス の背後に大勢のユーザーがいる場合、IP単位 で制限をかけると、無実のユーザーまで巻き添えを食らいます。可能であれば APIキー や ユーザーID 単位での制御を推奨します。

—

最後に：パケットの先には「人」がいる

ネットワークの世界では、Token Bucketのアルゴリズムだとか HTTPヘッダー だとか、無機質な言葉ばかりが並びます。でも、その一つひとつのパケットの先には、アプリを操作している誰かがいて、その人の体験を守るために私たちがいるんです。

「なぜこの制限が必要なのか？」を考えながら設定ファイルを書いてみると、ただの作業だったインフラ構築が、誰かの幸せを守るための「設計」に変わるはずです。

もし設定やアルゴリズムで迷ったら、いつでも郵便局の窓口を思い出してくださいね。これからも一緒に、ネットワークの深い森を楽しく冒険していきましょう！

それでは、また次回のブログでお会いしましょう。Happy Hacking!