← AWSサービスの内部原理 コース
42. スロットリングはトークンバケット — レートとバーストの正体
API Gatewayのスロットリングは「トークンバケット」アルゴリズムそのものです — バケツと水位の図を追うだけで、レート・バースト・429・多段制限のすべてが読み解けます。
① 仕組みはバケツとトークン — 「レート」と「バースト」の正体
トークン補充レート(rate)= 毎秒の補充速度(rps)
リクエスト1件 = トークン1個を消費
バケツ容量 = バースト(burst)
満杯以上は貯まらないトークンありリクエスト通過
バケツが空リクエストは弾かれる
- 公式: 1トークンが1リクエストに対応する
- 公式: バースト=「429を返し始めるまでにAPI Gatewayが受け付ける、同時リクエスト送信の目標最大数」
API Gatewayのスロットリングは授業で習ったトークンバケットそのもの。公式定義では、レート=トークンの補充速度、バースト=バケツの容量です。
② 水位を追えば挙動が読める — 平均は制限し、瞬間は許す
トラフィックが少ない水位が上がり、満杯(=バースト容量)で止まる
水位がゼロに到達
水位が一気に低下貯金の分だけレート超えの山を吸収(バッファ)
超過分は429で拒否定常状態ではレート以上は通せない
- レート = 長期的にどれだけ流し続けられるか
- バースト = 瞬間のスパイクをどこまで飲み込むか
- 2つのパラメータは独立に効く
暇な時間の「貯金」がスパイクのバッファになります。水位がゼロに達した瞬間から、超過分だけが429で弾かれ始めます。
③ 「保証値」ではなく「目標」 — ベストエフォートの理由
誤解バースト100なら101本目で必ず弾く
公式の立場上限は保証ではなく目標(target)
分散システムの流量カウント複数ノードで数える系では、多少の誤差を許して高速に判定するほうが理にかなう
- トークンバケットの性質上、バーストは事前に定義された超過を許す
- 他の要因で目標を上回ることもあり得る
公式は「スロットルもクォータもベストエフォートで適用され、保証された上限ではなく目標(target)と考えるべき」と明記しています。
④ バケツは1つじゃない — 入れ子の4階層フィルタ
リクエスト
通過
(1) 使用量プラン個別クライアント/メソッド単位
通過
(2) ステージ/メソッド単位
通過
(3) アカウント × リージョン単位
(4) AWSのリージョン全体上限最も外側(大きいバケツ)
- クライアント単位の制限はアカウント単位を超えられない
- アカウント単位はAWSのリージョン上限を超えられない
- だからステージに大きな数値を設定しても、外側のアカウント上限で頭打ちになる
1本のリクエストは、小さいバケツから大きいバケツへと順に通過する多段フィルタを通ります。鉄則は「内側の設定は外側を超えられない」。
⑤ 最後の一手はクライアント側 — 429とリトライで系が完成する
クライアントリクエスト送信
「今は無理」と押し返す
API GatewayHTTP 429 Too Many Requests を返す
REST APIでは TooManyRequestsException間隔を空けて出し直す
クライアント例外を捕捉し、レート制限をかけた形で再送信(指数バックオフ)
バックエンド(Lambda編で見たイベント駆動の下流など)過負荷から守られる
- 公式: 「クライアントはこの例外を捕捉したとき、失敗したリクエストをレート制限をかけた形で再送信できる」
- サーバー側の制御とクライアント側のリトライは切り離された2つの話ではない
サーバーのトークンバケットとクライアントの指数バックオフ付きリトライは、合わせて1つの流量制御系。この往復がバックエンドを過負荷から守ります。