スロットリング・レート制限・バックプレッシャーの違いとは？クラウドAPIの過負荷対策設計と実装パターン完全ガイド

オンプレ時代、Webシステムへのアクセスが集中すると、Apacheの最大接続数を超えてサーバーが落ちる——という経験をしたインフラエンジニアは多いだろう。クラウドでもこの問題は消えない。むしろ、スケールアウトによって処理能力は上がる一方、上流から来るリクエストを適切に制御しないと、バックエンドのDBやマイクロサービスが連鎖的に過負荷で倒れる「カスケード障害」が起きやすくなった。

この記事では、クラウドAPIの過負荷対策として登場するスロットリング・レート制限・バックプレッシャーの3つの概念を整理し、AWS・Azureの主要サービスでどう実装するかを実践的に解説します。

なぜ過負荷対策の概念を整理する必要があるのか

「スロットリング」「レート制限」「バックプレッシャー」は、いずれも「リクエストを絞る」という意味合いで使われることが多く、混用されがちだ。しかし、この3つは「誰が」「どこで」「どのように」制御するかという点でまったく異なる設計アプローチを指している。

概念を混同したまま設計すると、「なぜかAPIが突然503を返す」「クライアントがリトライを繰り返して状況が悪化する」「キューが溢れても気づかない」といった事故につながる。正確に使い分けることが、現場の障害を防ぐ第一歩だ。

3つの概念の定義と違い

1. レート制限（Rate Limiting）

「単位時間あたりのリクエスト数に上限を設ける」 制御。主にAPIの入り口（エッジ）側で実装される。

典型的な表現: 「1ユーザーあたり100リクエスト/分まで」「1IPアドレスあたり1,000リクエスト/時まで」

・目的: 特定のユーザーやクライアントによる占有・乱用防止、DDoS的なアクセスパターンへの防衛
・制御する側: API提供者（サーバーサイド）が設定する
・超過時の挙動: HTTPステータス 429 Too Many Requests を返す
・実装場所: APIゲートウェイ、WAF、CDN、ロードバランサー

2. スロットリング（Throttling）

「システム全体のリソース保護のために処理を意図的に絞る」 制御。レート制限がユーザー単位なのに対し、スロットリングはシステム側の能力ベースで制御する。

典型的な表現: 「Lambda関数の同時実行数を1,000に制限」「RDSへのコネクション数が上限に達したため新規リクエストを拒否」

・目的: バックエンドリソース（DB、Lambda、外部APIなど）の過負荷防止
・制御する側: クラウドプロバイダーまたはアプリ自身が設定する
・超過時の挙動: 503 Service Unavailable、またはサービス固有のエラーコード（AWSの場合はThrottlingException）
・実装場所: AWS Lambdaの同時実行制限、API Gatewayのバースト制限、DynamoDBのプロビジョンドスループット

3. バックプレッシャー（Backpressure）

「下流のコンポーネントが処理しきれない状況を上流に伝えて流量を調整する」 仕組み。レート制限・スロットリングが「拒否する」設計なのに対し、バックプレッシャーは「遅くする・待たせる」 設計思想。

典型的な表現: 「SQSのキューが深くなってきたのでプロデューサーのペースを落とす」「ストリーム処理で下流のウィンドウが埋まったら上流の取り込みを止める」

・目的: データを捨てずに、システム全体として処理できる量に調整する
・制御する側: 下流コンポーネントが上流に圧力をかける（設計で作り込む）
・超過時の挙動: リクエストを遅延させる、プロデューサーをブロックする、キューに積む
・実装場所: Amazon SQS（キュー長モニタリング + プロデューサー側の制御）、ストリーミング処理（Kinesis、MSK）

3つの違いを比較表で整理する

AWSでの実装パターン

1. Amazon API Gatewayのレート制限設定

API Gatewayには2種類の制限がある。

・バーストリミット: 瞬間的なリクエスト急増への許容量。デフォルトはリージョンあたり5,000リクエスト（2026年時点）
・スロットルリミット: 持続的なリクエストレートの上限。デフォルトはリージョンあたり10,000リクエスト/秒
・使用量プラン: APIキー単位でレート（リクエスト/秒）とクォータ（日/週/月あたりのリクエスト総数）を設定できる

# 使用量プランの作成（AWS CLI例）
aws apigateway create-usage-plan \
  --name "standard-plan" \
  --throttle "burstLimit=200,rateLimit=100" \
  --quota "limit=10000,period=DAY"

# 作成したプランにAPIキーを紐づける
aws apigateway create-usage-plan-key \
  --usage-plan-id <plan-id> \
  --key-id <api-key-id> \
  --key-type "API_KEY"

超過時、クライアントには `429 Too Many Requests` とレスポンスヘッダー `X-RateLimit-Limit` / `X-RateLimit-Remaining` が返る。クライアント側はこれを読んで指数バックオフ付きのリトライを実装するのがベストプラクティスだ。

2. AWS Lambdaのスロットリング制御

Lambdaには2種類の同時実行制限がある。

・アカウントレベルの同時実行数上限: デフォルト1,000（リージョンごと）。引き上げ申請可能
・予約済み同時実行（Reserved Concurrency）: 特定の関数に同時実行数の枠を確保する。他の関数がその枠を使えなくなる代わりに、バーストでもスロットリングされなくなる
・プロビジョニング済み同時実行（Provisioned Concurrency）: コールドスタートを排除したい関数に温状態のコンテナを常時確保する（費用が発生）

スロットリングが発生すると `TooManyRequestsException`（HTTP 429）が返る。SQSトリガーのLambdaがスロットリングされた場合、SQSはメッセージを削除せず可視性タイムアウト後に再試行するため、バックプレッシャー的に機能する。

3. SQSとAuto Scalingを組み合わせたバックプレッシャー設計

バックプレッシャーの実装として現場で最も使われる構成がSQS + Auto Scalingの組み合わせだ。

（想定例）EC2インスタンスが画像変換ジョブを処理するケースで考えると:

# SQSキューの深度をCloudWatchで監視
# ApproximateNumberOfMessagesVisible（取り出し待ちメッセージ数）が
# しきい値を超えたらEC2インスタンスを追加スケールアウト

# CloudWatch メトリクスアラームの例（CLI）
aws cloudwatch put-metric-alarm \
  --alarm-name "sqs-backlog-scale-out" \
  --metric-name "ApproximateNumberOfMessagesVisible" \
  --namespace "AWS/SQS" \
  --dimensions Name=QueueName,Value=image-processing-queue \
  --statistic Average \
  --period 60 \
  --threshold 100 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions <scaling-policy-arn>

この設計では:
・キューが深くなる（下流の処理が追いつかない）→ CloudWatchアラームが発火 → Auto ScalingでEC2を追加
・キューが解消される → スケールインで余剰インスタンスを削除
・プロデューサー側はキューへの投入を続けられる（データを捨てない）

Azureでの対応サービスと考え方

Azure API Managementのレート制限

Azure API Management（APIM）ではポリシーとしてレート制限を設定する。

・rate-limit ポリシー: 呼び出しごとのレートとバンド幅（KB）を制限。サブスクリプション単位
・rate-limit-by-key ポリシー: 任意のキー（IPアドレス、JWTのsub、カスタムヘッダーなど）単位でレート制限を柔軟に設定できる
・quota ポリシー: 週・月などの長期クォータ管理に使用

超過時は `429 Too Many Requests` が返り、`Retry-After` ヘッダーで次のリトライ可能時間が通知される。

Azure Service BusとEvent Hubsのバックプレッシャー

Azure Service Busはキューの深度をAzure Monitorで監視し、AKSのKEDA（Kubernetes-based Event Driven Autoscaler）と組み合わせてコンシューマーをオートスケールする設計が一般的だ。Event Hubsはパーティションとコンシューマーグループの設計で処理能力を調整する。

設計判断のポイント：どれをいつ使うか

レート制限を優先すべき場面

・外部公開APIを提供する: 特定ユーザーのアクセスが他ユーザーに影響しないよう、APIキー単位でレート制限を設ける
・無料枠と有料枠を分ける: API Gatewayの使用量プランで、プラン別に異なる上限を設定する
・DoS/DDoS的なアクセスへの防衛ライン: WAFと組み合わせてIP単位のレート制限を設ける（ただしDDoS対策はAWS ShieldやAzure DDoS Protectionが主役）

スロットリングを意識すべき場面

・サービスクォータの上限に近づいている: AWS各サービスにはソフトリミットとハードリミットがある。Lambdaの同時実行数、DynamoDBのRCU/WCU、API Gatewayのスループットなどが特に要注意
・サードパーティAPIとの連携: 外部APIには必ずレート制限がある。呼び出し元でバーストしないよう、SQSを挟んで流量を制御する設計が定番
・コスト抑制のためのリミット設計: Lambda予約済み同時実行数でコスト上限を設けることができる（ただし上限を超えるとスロットリングが発生することを許容する設計になる）

バックプレッシャーを設計に組み込むべき場面

・データを捨ててはいけない処理: 注文処理、決済、ログ収集など、メッセージを失ってはいけないケースはキューを挟んだバックプレッシャー設計が必要
・処理速度に波がある: 夜間バッチや定期的なスパイクがあるシステムでは、キューがバッファとして機能し、コンシューマーは自分のペースで処理できる
・下流サービスのスケールアウトに時間がかかる: EC2のスケールアウトには数分かかる。その間のリクエストをキューで受け止めることで、データを失わずに済む

よくあるつまずきと対処

「スロットリングエラーが突然増える」
AWS各サービスのデフォルトクォータを把握していないまま本番に臨むと、予期しないThrottlingExceptionが発生する。あらかじめ上限値を確認し、必要であれば事前に引き上げ申請をしておく。

一般的な注意点として、Lambda関数は同時実行数がアカウントレベルで共有されるため、1つの関数がバーストすると他の関数もスロットリングされる。クリティカルな関数には予約済み同時実行数を設定して枠を確保する設計が推奨される。

「429エラーへのクライアントの対応漏れ」
レート制限を設けても、クライアント側が429を受けた後に即座に大量リトライするとかえって状況が悪化する。指数バックオフ（Exponential Backoff）＋ジッター（ランダムな遅延）を組み合わせたリトライ設計をクライアント側でも実装することが不可欠だ。

「SQSキューの深度が増加し続ける」
バックプレッシャー設計でSQSを使う場合、コンシューマーのスループットがプロデューサーを下回り続けるとキューが増加し続ける。メッセージの保持期間（デフォルト4日、最大14日）を超えると自動削除されるため、アラームの設定と根本原因の調査が重要だ。

本記事のまとめ

スロットリング・レート制限・バックプレッシャーの違いをまとめると次のとおりだ。

クラウドの実システムでは、APIゲートウェイでレート制限を受け、その後段のLambdaやバックエンドサービスでスロットリングが発生し、さらにSQSでバックプレッシャーが働く——という3層の制御が組み合わさっている。それぞれの制御がなぜ発動しているかを正確に理解することが、過負荷障害の根本対処につながる。

「どれが発動したか」を判断するには、CloudWatchのメトリクスで 4xxエラー率（レート制限/スロットリング） と SQSキュー深度（バックプレッシャーのシグナル） を合わせて確認するのが実務的な切り分けの出発点だ。