スロットリングとは？ 10分でわかりやすく解説

UnsplashのKevin Kandlbinderが撮影した写真      

急増するトラフィックや大量のリクエストによって、Webサービスやアプリケーションの応答が遅くなったり、状況によっては停止に至ったりすることがあります。こうした問題を未然に抑えるための手法のひとつが「スロットリング（throttling）」です。この記事では、スロットリングの基本概念から代表的な制御方式、実装の考え方、導入時に起こりやすい落とし穴までを整理します。負荷が高まる場面でもサービスを継続するために、どこで・何を・どのように制限するのかという観点を、実務で使える形で押さえていきます。

スロットリングとは何か

スロットリングの定義と概要

スロットリングとは、システムへの過度な負荷を防ぐために、一定期間内に処理できるリクエスト数やトラフィック量を制限する手法です。大量のリクエストが同時に発生すると、サーバーCPUやメモリ、DB接続、外部API呼び出し枠などが飽和し、応答遅延やエラー増加が起きやすくなります。さらに、タイムアウトの増加や再試行の連鎖によって負荷が増幅し、結果としてシステム全体が不安定になるケースもあります。スロットリングは、処理能力の上限を超えないように、意図的に受け付け方を調整するという考え方で、サービスを守るための代表的な制御手段です。

スロットリングが必要とされる背景

近年は利用者数の増加だけでなく、セールやキャンペーンなどのイベント起因のアクセス集中、バッチ処理の重なり、Botによる過剰アクセスなど、負荷が急増する要因が増えています。さらに、DoS/DDoSのような攻撃要因が重なる場合もあり、平常時の設計だけでは追いつかない場面が出てきます。こうした状況では、スケールアップ/スケールアウトだけで対応しようとしても、増設が間に合わない、外部APIの上限が先に詰まる、DB接続数がボトルネックになる、といった制約に直面します。そのため、受け付ける量をコントロールし、全体として破綻しない状態を維持するための仕組みが欠かせません。

スロットリングの目的と効果

スロットリングの目的は、単に「制限すること」ではありません。狙いは次の通りです。

1. システムの安定性とパフォーマンスの維持（応答遅延・タイムアウト・障害連鎖の抑制）
2. サービス可用性の向上（完全停止を避け、制限しながら提供を継続する）
3. リソースの効率的利用（重要処理にリソースを残す）
4. DoS/DDoSやBotアクセスなどの影響を最小化する

適切に実装できれば、一部のリクエストを抑えつつ、サービス全体としては稼働を続ける状態を作りやすくなります。結果として、障害対応の負荷を下げたり、復旧までの影響範囲を小さくしたりする効果も期待できます。

スロットリングとレートリミットの関係

現場では「スロットリング」と「レートリミット（rate limiting）」がほぼ同義で使われることもあります。厳密には、レートリミットは“単位時間あたりの上限”を定義する概念であり、スロットリングは“制限のかけ方（拒否・遅延・優先制御など）を含む運用・実装全体”として語られることが多いです。どちらの用語を使う場合でも重要なのは、上限値（どこまで許容するか）と、超過時の挙動（どう処理するか）をセットで設計することです。本記事では、実務で混同しやすい点を踏まえ、広い意味での負荷制御としてスロットリングを扱います。

スロットリングの基本的な仕組み

基本の流れは次の通りです。

ポイントは、制限値と制御方法を固定せず、運用データを見て継続的に調整することです。スロットリングは「設定して終わり」ではなく、実際の負荷と利用状況に合わせて上限値・対象単位・例外ルールを見直す運用が前提になります。

スロットリングの具体的な手法

スロットリングには複数の設計パターンがあります。ここでは代表的な考え方を整理します。

リクエスト数による制限

一定期間内に受け付けるリクエスト数に上限を設ける方式です（例：1分100件）。実装が比較的簡単で導入しやすい一方、同じ1件でも処理が重い/軽い差を反映しにくいため、負荷のばらつきが大きいサービスでは別の方式と組み合わせて使われることも多いです。たとえば、同じAPIでもパラメータによってDBアクセス量が変わる場合は、件数だけでは実態に合いにくくなります。

処理量（コスト）による制限

処理時間やCPUコスト、DBクエリ数など“重さ”を考慮して制限する方式です（例：1分あたり処理コスト合計が一定を超えないようにする）。リクエストの種類によって負荷が大きく異なるサービスでは有効ですが、コストの見積もりや計測設計が必要になります。設計時は「何をコストとして扱うか（CPU、DB、外部API、キュー消費など）」を決め、測定できる形に落とし込むことが肝になります。

ユーザー/テナント単位での制限

特定のユーザー（またはAPIキー、テナント）ごとに上限を設ける方式です。少数のヘビーユーザーやBotが全体を圧迫するのを防げます。B2B/SaaSでは「プラン別に上限を変える」「特定テナントに優先枠を与える」といった運用と相性が良いです。一方で、上限値の設計が利用規約やSLAと関係する場合もあるため、技術だけでなく運用・契約面の整理が必要になるケースがあります。

優先度に基づく制限

重要度の高い処理を優先し、重要度の低い処理を制限・遅延する方式です。例えば、決済・ログインなどの重要APIは優先し、検索や集計などは制限を強める、といった設計ができます。可用性を“重要機能から守る”という意味で効果が高い反面、優先度設計が曖昧だと不公平感が出やすい点に注意が必要です。また、優先度に応じたキュー分離や別レーンの用意など、設計要素が増えるため、運用の複雑化とのバランスも考える必要があります。

代表的なアルゴリズム（実装の型）

方式を支える実装アルゴリズムとして、次がよく使われます。

• トークンバケット（Token Bucket）：一定速度でトークンを補充し、リクエストごとにトークンを消費する。バースト（短時間の集中）を許容しつつ平均レートを抑えられる。
• リーキーバケット（Leaky Bucket）：バケツから一定速度で流すイメージで、突発的な集中をなだらかにする。一定の出力レートを保ちやすい。
• 固定ウィンドウ/スライディングウィンドウ：一定時間枠でカウントする。実装しやすいが、境界タイミングの偏りに注意。

「どれが正解」というより、許容したい挙動（バースト可否、平滑化、計測精度）に合わせて選ぶのが現実的です。たとえば「瞬間的な集中は許容するが、平均的には抑えたい」のか、「一定の処理速度を守りたい」のかで、選び方が変わります。

スロットリングの実装方法

スロットリングは実装する“層”によって、得意/不得意が変わります。ここでは、アプリケーション層、ミドルウェア層、インフラ層での考え方を整理します。

アプリケーション層でのスロットリング

アプリケーションコード内で制御ロジックを実装する方法です。リクエストを受け付ける段階でカウント・判定し、制限時はエラー応答（例：HTTP 429）を返す、またはキューへ逃がすなどの制御を行います。

メリットは、ユーザー属性やAPI種別などを踏まえたきめ細かな制御ができる点です。たとえば、ログインや決済は優先しつつ、重い集計APIは早めに制限する、といった方針をコード側で表現しやすくなります。一方で、分散環境ではカウンタを共有する仕組み（例：分散キャッシュ）や、カウンタ自体の可用性を考慮した実装が必要になり、複雑になりやすい点がデメリットです。

ミドルウェア層でのスロットリング

APIゲートウェイ、リバースプロキシ、ロードバランサーなどで制御する方法です。アプリを改修せずに一元管理しやすく、複数サービスにまたがる統制をかけたい場合に向きます。認証（APIキー等）と組み合わせたレート制御も設計しやすいのが特徴です。

ただし、アプリ内部の状態（DB負荷やジョブキュー長など）に連動した高度な制御は難しい場合があります。入口側で制限しても、内部の特定処理だけが詰まる構造だと十分に効かないこともあるため、必要に応じてアプリ側の“補助的な制御”と併用するのが現実的です。

インフラ層でのスロットリング

ネットワーク機器やクラウド機能でトラフィックを制限する方法です。IP単位の制限やWAF/CDNでのBot対策、DDoS緩和など、入口対策として有効です。システム全体を守る観点では強力ですが、ユーザー体験やアプリの要件に合わせた“細かな制御”は不得意になりがちです。たとえば「同じIPでもユーザーによって扱いを変える」といった設計は、インフラ層だけでは表現しにくい場合があります。

スロットリングの設定とチューニング

スロットリングは、設定が“適切”でないと逆効果になります。特に重要なのは次の4点です。

• しきい値は根拠を持って決める：CPU/メモリだけでなく、DBコネクション数、外部API上限、ワーカー数など“ボトルネック”を起点に考えます。
• 拒否だけでなく“案内”を用意する：制限時はHTTP 429などを返し、可能なら再試行の目安（例：Retry-After）を示します。
• ログとメトリクスを残す：発動頻度、対象ユーザー、対象API、時間帯、拒否率を可視化し、改善に使える状態にします。
• 段階的な制限（グレースフルデグレード）：突然すべて拒否ではなく、優先度やプラン別に制限を変えるなど、サービス設計として“劣化の仕方”を決めます。

運用開始後は、応答時間、エラー率、キュー長、スロットリング発動数などを見ながら、「守れているか」「守りすぎていないか」を継続的に調整することが重要です。制限が効いているかだけでなく、通常利用に影響が出ていないかという観点でも、定期的に見直します。

スロットリング導入の留意点

スロットリングによる影響の把握

スロットリングは負荷を抑える一方で、ユーザー体験に影響を与えます。しきい値が厳しすぎると通常利用でも制限がかかり、問い合わせや離脱につながりかねません。導入前に、どの機能を優先し、どの操作は制限しても許容されるのかを整理し、サービス設計として影響を受け止められる形にしておく必要があります。たとえば、重要な処理は制限しにくい一方で、検索やレポート生成などは時間帯によって制限を強めても業務影響が小さい、というケースがあります。

適切なしきい値の設定

しきい値が低すぎると利便性が落ち、高すぎると過負荷を防げません。目安としては「通常時は発動しないが、異常時には確実に効く」ラインを狙います。さらに、固定値だけでなく、時間帯・曜日・イベント時の増加を踏まえた調整や、段階的に閾値を切り替える仕組みを用意できると運用が楽になります。実際の運用では、ピーク時の実測値と、ボトルネックとなる指標（DB接続、外部APIの上限到達など）を照らし合わせながら調整していくことになります。

エラーハンドリングの設計

制限時は、ユーザーやクライアント（アプリ・他システム）が“正しく振る舞える”応答が重要です。たとえばAPIなら、制限を明確に示すステータス（例：429）を返し、必要なら再試行の目安を提示します。単にタイムアウトさせるより、制限中であることを明示したほうが、再試行制御や原因切り分けがしやすいためです。クライアント側で指数バックオフなどの再試行制御をしている場合は、制限応答と整合するかも確認しておくと事故が減ります。

スロットリング状況のモニタリングと改善

スロットリングは導入して終わりではありません。発動頻度、対象の偏り（特定ユーザーだけが弾かれていないか）、発動により守れた指標（CPU飽和やDBエラーが抑えられたか）を見て、継続的に改善する必要があります。ユーザーからのフィードバックも含め、安定性と利便性のバランスを取り直すプロセスが重要です。発動が多すぎる場合は「閾値が低すぎる」のか、「そもそもボトルネックが別にある」のかを切り分け、対策を選びます。

まとめ

スロットリングは、システムへの過度な負荷を防ぎ、安定したサービス提供を実現するための重要な制御手法です。リクエスト数、処理量、ユーザー単位、優先度などの観点から制限方式を選び、アプリ・ミドルウェア・インフラの適切な層で実装します。導入時は、しきい値の根拠、制限時の応答設計（例：429）、可視化と継続調整をセットで考えることが欠かせません。設計と運用が噛み合えば、負荷が高い状況でもサービス全体としての停止を避けやすくなり、運用の安定化につながります。