DynamoDB オンデマンドスループットの実測

新規作成した DynamoDB オンデマンドテーブルはどれくらいのスループットを得られますか？

新規作成直後のオンデマンドテーブルは、約 秒間 4,130 回の書き込み を処理します — AWS のドキュメントでは 4,000 とされています — そして少なくとも 秒間 12,700 回の結果整合性のある読み取りを処理します。両方とも 2026-08-27 に、 数分前に作成したばかりのテーブルに対して実測しました。書き込みはベースラインを 超えるどの負荷でも 4,130 ±2/秒に張り付き、読み取りは、当方の負荷生成側の余力が 尽きるまで一度もスロットリングされませんでした。

これら 2 つの数値、そしてこのページのそれ以外すべては、ドキュメントの内容を 言い換えたものではなく、実サービスに対する実際のリクエストを数えた結果です。 手法、生データ、そして 3 回の失敗した試みは ベンチマークの記事にまとめてあります。 このページはその数値が根を下ろすリファレンスです。

新規テーブルの書き込み上限

トラフィックを一度も受けたことのないテーブルに対し、30 秒単位のウィンドウで 負荷を段階的に増やしました。すべてのリクエストは一様ランダムなキーを持つ約 1 KB のアイテムで、ホットパーティションは関与していません:

ドキュメントに書かれた「秒間 4,000 回の書き込み」というベースラインは成立しており、 その上に約 3% の余裕があります。上限は驚くほど平坦です — 5,000、6,000、8,000 の オファー負荷に対して、実測値はそれぞれ 4,132、4,131、4,134 でした。上限を超えても レイテンシは悪化しません — p50 の書き込みレイテンシは、どのウィンドウでも リージョン内で 4～5 ms のままでした。サービスは遅くなるのではなく、拒否します。

スロットリング時に実際に返ってくるもの

最初の拒否は、ベースラインを超えた各ウィンドウの開始から 0.9～3.8 秒後に発生しました （オファー負荷が高いほど早く来ました）。以下がそのままの内容です:

ThrottlingException: Throughput exceeds the current capacity of your table or index. DynamoDB is automatically scaling your table or index so please try again shortly. If exceptions persist, check if you have a hot key: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html

計画しておくべき点が 2 つあります。これは HTTP 400 であって 5xx ではありません — 5xx だけを監視するリトライポリシーやアラームは、オンデマンドのスロットリングを まったく見逃します（SDK はデフォルトでこれをリトライします — 指数バックオフを参照）。 そして「ホットキー」というヒントはデフォルトの提案であって診断結果ではありません — 今回のキーは一様ランダムだったので、この規模ではこのメッセージの最初の容疑者は キー設計ではなく、テーブルレベルの上限です。4 つの異なるスロットリング原因については 専用のガイドがあります。

読み取りの上限

読み取りは、1,000 件のアイテムをあらかじめ入れておいた別の新規テーブルに対して、 結果整合性のある GetItem（約 1 KB、それぞれ 0.5 読み取りユニット） として実行しました:

どのレートでもスロットリングはゼロでした。ドキュメントに書かれた「秒間 12,000 回の 読み取り」というベースラインは成立しており、実際の限界は見つけられませんでした — 16,000/秒をオファーした時点で、当方の 8 台のランナーのうち 5 台がクライアント側で 飽和したため、12,762/秒というのは当方のフリートが頭打ちになった地点であり、DynamoDB 側の限界ではありません。読み取りは p50 でリージョン内 2～4 ms で応答しました。

持続負荷の下で上限はどう伸びるか

AWS のドキュメントには、オンデマンドキャパシティは直前のピークの最大 2 倍まで 対応できるよう伸び、30 分以内に直前のピークの 2 倍を超えるとスロットリングされる 可能性があると書かれています。1 つのテーブルに対して秒間 8,000 回の書き込み負荷を 34 分間連続でかけ続け（8 分間の波を 4 回、波と波の間の休止は 1 分未満）、上限が 1 分ごとにどう動くかを観察しました:

タイムラインを読み解くと:

• 最初の上限はしぶといです。 最初の 8 分間を通して、テーブルは約 4,000/秒の ベースラインに張り付いたままでした — このウィンドウ内では、持続的な過剰需要でも 上限は動きませんでした。
• 成長はランプではなく、約 1,000/秒単位のステップでやって来ます。 上限は 9 分目 あたりで約 5,000/秒に、26 分目あたりで約 6,000/秒に、その 1 分後には約 7,000/秒に ステップし、その後最後まで 7,000/秒で横ばいになりました。それぞれのステップは、 ある 1 分から次の 1 分の間に唐突に現れます。3 回のステップのうち 2 回は波の境界 付近で発生しており、1 分未満の休止が成長の仕組みに影響している可能性があります — ここでは観測されたタイミングをそのまま報告します。
• 30 分間の持続的な需要でも上限は 2 倍になりませんでした。 秒間 8,000/秒の オファー負荷を 34 分間かけた後、テーブルが処理したのは 7,000/秒 — 開始時の上限の 1.75 倍で、オファー負荷にも、きれいな 2 倍にも届きませんでした。スロットリングされた リクエストは波を追うごとに減少しました（190 万件 → 50 万件）。

ローンチ当日のトラフィックが新規テーブルで秒間約 4,000 回の書き込みを超えそうなら、 事前にウォームアップしてください — イベントの前に合成負荷をかけるか、テーブルの 最大オンデマンドスループットを明示的に設定して AWS にプロビジョンさせるか、どちらか です。オンデマンド vs プロビジョンドのガイド ではどちらのモードがどんなときに有利かを扱っており、オートスケーリング は、ここで自動的に起きるのを観察した現象の、プロビジョンドモード版の対応物です。

驚いた 2 つの数値

• ACTIVE になるまでの時間は 3 倍ばらつきます。 新規作成したオンデマンドテーブルは、 ある実行では 7.4 秒で ACTIVE になり、別の 2 回の実行では 22 秒かかりました — リージョンもスキーマも同じです。テーブルをテナントごと、あるいはテストごとに作る 設計では、遅いケースを見込んでおいてください。
• ベンチマーク全体のコストは 0.97 ドルでした。 課金対象は 672,116 回の書き込みと 108 万回の読み取りです。34 分間の持続成長の実行には追加で 12.67 ドルかかりました。 自分でサービスを実測する方が、キャパシティの判断を 1 回間違えるよりも安上がりです — このようなワークロードのコストは、事前に DynamoDB 料金計算ツールで見積もることもできます。

対象範囲と手法について、正直に

以上はすべて、フェーズごとに 1 つのテーブル、1 日、1 リージョン（us-east-1）、約 1 KB のアイテム、一様ランダムなキーによるものです。パーティションごとの上限（秒間 3,000 読み取りユニット／1,000 書き込みユニット）は、ここで実測したテーブルレベルの挙動より 下に位置し、独自の失敗パターンを持ちます。アカウント レベルのクォータとハードなサービス上限は、同じ手法で実測した DynamoDB 上限リファレンスにあります。そして DynamoDB を 日常的に扱っているなら、DynoTable は当方が作っているそのためのデスクトップ クライアントです — 同じチームによって、主張を繰り返す前に実サービスに照らして確認する という同じ習慣とともに作られています。