スロットリングとレート制限

は、サービスが受け付けられる量を超えたリクエストを拒否したり遅らせたりすることです。データパイプラインは大量の読み書きを短時間に行うため、、、、外部などの上限にぶつかりやすく、そのままではデータの取りこぼしやジョブの失敗につながります。この章では、上限の種類と、上限を守りながら処理を進める設計を整理します。

Point

Throttling は「絞ること」です。車のアクセル (スロットル) を絞るイメージです。
Rate limit (レート制限) は、単位時間あたりの回数の上限です。
指数バックオフ (exponential backoff) は、失敗するたびに待ち時間を倍々に延ばして再試行する方法、ジッター (jitter) は待ち時間にランダムなゆらぎを加えることです。
和訳
- Throttle: 絞り弁、絞る
- Weblio英和辞書「throttle」

概要

サービス	主な上限	の表れ方
	テーブルの容量 (プロビジョンド)、パーティションごとの上限	ProvisionedThroughputExceededException、ThrottlingException
/	同時接続数 (max_connections)、・I/O	接続エラー (too many connections)、応答の遅れ
	あたりの書き込み・読み取り	ProvisionedThroughputExceededException
	数 (既定であたり 1,000)	429 TooManyRequestsException
	アカウントで毎秒 10,000 リクエスト (バースト 5,000) が既定	429 Too Many Requests
外部の	提供元が決める回数の上限	429、待つべき秒数を示すヘッダー

対処の基本は4つです。上限を上げる、負荷を均す、再試行を正しく行う、集中を分散する、です。

主要技術

①DynamoDB のスロットリング ⚠️ 頻出

原因	対処
テーブル全体の容量が足りない (プロビジョンド)	、容量の引き上げ、モードへの切り替え
特定のに集中 (ホットキー)	分散するキーの設計、書き込みシャーディング (キーに接尾辞を付けて分散)
の容量不足	GSI の書き込み容量が足りないと、ベーステーブルへの書き込みもされる。GSI の容量を引き上げる
一度に大量のロード	書き込み速度を制御する。BatchWriteItem の UnprocessedItems をバックオフして再送

1つのパーティションが処理できるのは、毎秒 3,000 読み込みキャパシティユニットと 1,000 書き込みキャパシティユニットまでです。テーブル全体の容量に余裕があっても、1つのキーに集中すると、このパーティションの上限でスロットリングされます。の適応型キャパシティは、よく使われるパーティションに容量を寄せますが、パーティションの上限そのものは超えられません。

容量モード	向くケース
オンデマンド	流量が読めない、急に増える、容量の管理をしたくない
プロビジョンド + Auto Scaling	流量がおおむね予測でき、コストを抑えたい

⚠️ 頻出: 「テーブル全体の容量は余っているのにスロットリングされる」は、ホットキー (パーティションの上限) か GSI の容量不足です。容量を上げる前にキーの設計と GSI を確かめます。

②RDS の接続数と RDS Proxy ⚠️ 頻出

のように多数の実行環境が同時に DB へ接続すると、の最大接続数に達し、新しい接続が拒否されます。

対処	内容
RDS Proxy	アプリケーションと DB の間で接続をプールし、多数のクライアントの接続を少数の DB 接続にまとめる。の時間も短くする
Lambda の数の制限	予約同時実行数で、DB へ向かう関数の同時実行の上限を決める
接続の再利用	関数のハンドラーの外で接続を作り、呼び出しをまたいで使い回す
読み取りの分散	分析やエクスポートの読み取りをへ向ける

⚠️ 頻出: 「Lambda から RDS へ接続すると、負荷が高いときに接続数の上限エラーが出る」は RDS Proxy です。

③Kinesis の書き込み上限

のは毎秒 1 MB または 1,000 レコードまで書き込めます。上限を超えると ProvisionedThroughputExceededException が返ります。シャードの追加、モード、の分散、KPL による集約、付きの再送で対処します (「Amazon Kinesis Data Streams」の章)。

④指数バックオフとジッター ⚠️ 頻出

されたリクエストを、すぐに同じ間隔で再送すると、全クライアントが一斉に再送して再びスロットリングされます。

方法	内容
	1回目は短く、失敗のたびに待ち時間を倍にする (例: 100 ms、200 ms、400 ms …)。上限の待ち時間と最大の再試行回数を決める
ジッター	待ち時間にランダムなゆらぎを加え、多数のクライアントの再送の時刻をずらす
の再試行	AWS SDK はスロットリングのエラーを自動で再試行する。再試行モード (standard、adaptive) と最大回数を設定できる
	再送しても結果が変わらないよう、一意のキーやクライアントトークンを使う

再試行してはいけないエラーもあります。権限の不足や不正なリクエスト (多くの 4xx) は、何度送っても失敗します。再試行するのは、スロットリングと一時的なサーバーエラー (5xx) です。

⑤バッファリングで負荷を均す

書き込み先の上限より速くデータが届く場合は、キューやストリームでいったん受け止めて、書き込み先が受け付けられる速さで流します。

手段	内容
+	SQS にためて、Lambda のイベントソースマッピングの最大数で書き込みの速さを抑える
	ストリームにためて、コンシューマーのペースで読む
	バッファしてまとめて配信する
の分散マップ	並列数 (MaxConcurrency) を指定して大量の項目を処理する

⑥API のレート制限を越える設計

外部や AWS の API から大量のデータを取り込むときの考え方です。

手段	内容
ページング	1回で全部を取らず、ページ単位で取得する。次のページのトークンを使う
バッチ API	1件ずつではなくまとめて取得・登録する API を使う
呼び出しの速度の制御	トークンなどで毎秒の呼び出し回数を上限以下に保つ
増分の取得	変更分だけを取る (更新日時のフィルター)
	同じデータを何度も取らない
上限の引き上げ	で申請できる上限は引き上げる

自分で API を公開する側では、のステージやメソッドの、使用量プランと API キーで、利用者ごとの上限を設定します。

試験対策

①判断マトリクス

問題文のキーワード	選ぶ対処
の流量が読めず	モード
容量は余っているのに一部だけスロットリング	の分散 (ホットキーの解消)
の追加後にベーステーブルの書き込みが失敗	GSI の書き込み容量を上げる
からの接続数が上限	RDS Proxy
の書き込みでスロットリング	追加・オンデマンド・バックオフ
再試行が一斉に起きて再びスロットリング	+ ジッター
書き込み先より速くデータが届く	などでバッファし、数で速さを制御
外部の回数上限を超えないように取り込む	ページング、速度の制御、増分の取得
自社の API の利用者ごとに上限	の使用量プラン

②よくある誤答

に対して、待たずにすぐ再送するループを書くこと。
ホットキーが原因なのに、テーブル全体の容量だけを上げること。
権限エラーまで再試行すること。再試行するのは一時的なエラーだけです。
の数を増やせば DB への書き込みも速くなると考えること。DB の接続数の上限に先にぶつかります。