DynamoDB のアダプティブキャパシティ

DynamoDB はテーブルをパーティションにまたいで広げますが、トラフィックが均等に広がることはめったにありません。バーストキャパシティとアダプティブキャパシティ は、偏ったワークロードがスロットルするのを止める2つの自動メカニズムです — 硬い上限に当たるまでは。

DynamoDB のアダプティブキャパシティとは？

DynamoDB のアダプティブキャパシティは、未使用のスループットをへ自動的に振り向けるメカニズムで、偏ったキーがテーブルの残りをアイドルのままにしてスロットルすることを防ぎます。バーストキャパシティと組み合わせることで、スパイクと持続的な偏りを追加コストなしで吸収します — ただし、単一のキーをパーティション上限を超えて押し上げることはできません。

バーストキャパシティ は、短いスパイクを乗り切るために最大5分（300秒）分の未使用スループットを貸す。チューニングする機能ではなくバッファだ。
アダプティブキャパシティ は、テーブルの残りの未使用キャパシティから引き出して「ホットな」パーティションのスループットを自動で引き上げ、偏ったキーがスロットルしないようにする。
ホットなアイテムを専用パーティションに隔離さえする — 単一キーにパーティション上限の 3,000 RCU / 1,000 WCU まで与える。
キー設計を無視してよい免罪符ではない。 パーティションあたりの上限を超えると、もう借りる先はない — 本当にホットなキーは依然としてスロットルする。

まずパーティションの上限を知る

すべてのパーティションは独立して上限が課されます — 毎秒 3,000 読み取りユニットと 1,000 書き込みユニット。その上限はプロビジョンドではなく物理的なもので、プロビジョンドテーブルでもオンデマンドテーブルでも成り立ちます。（AWS、バーストとアダプティブキャパシティ。）

SQL から来ると、総サーバー負荷で考えます。DynamoDB ではスロットルする単位は 単一パーティション であり、1つの偏ったキーは、テーブルが 90% アイドルのまま溶け落ちることがあります。それが両メカニズムが埋めるために存在するギャップです。

バーストキャパシティが短いスパイクを吸収する

パーティションのスループットを使い切らないとき、DynamoDB は余りを貯めておきます。その未使用キャパシティの最大 300秒 分が予備として保持され、突然のバーストは、通常の毎秒レートが許すより速くそれを使い切れます。

それは見えず、自動です。サイズを決められず、DynamoDB が自身のバックグラウンド作業のために黙ってそれを使うこともあります。バースト性のトラフィックへのクッションとして扱い — 計画に当て込める余裕として決して扱わないこと。

アダプティブキャパシティがホットパーティションをブーストする

バーストキャパシティは短いスパイクを扱います。アダプティブキャパシティ は 持続的な 偏りを扱います。1つのパーティションがホットなまま、隣がアイドルのとき、DynamoDB はスループットをホットなものへ移します — テーブルの合計とパーティション上限まで。

VEHICLE#<id>（パーティション）と TS#<epoch>（ソート）をキーとする車両テレメトリのテーブルを運用しているとします。フラッシュセールのゾーンにいる1台の配送バンが、他のどれよりも 10 倍の ping を発します。そのパーティションはホットで、他の 200 台のバンのパーティションはほぼアイドルです。

アダプティブキャパシティはそれに気づき、その1つのパーティションのスループットを、コールドなパーティションの未使用キャパシティから引き出して引き上げます。設定なし、コストなし、ウォームアップなし — 2019 年 5 月以降、ブーストは実質的に即時です。（AWS Database Blog、"How DynamoDB adaptive capacity accommodates uneven access patterns"。）

ホットなバンのパーティションは 150 WCU を必要としますが、100 WCU の均等な取り分ではスロットルします。アダプティブキャパシティはそれを賄うために、コールドなパーティションからアイドルの WCU を借ります。

隔離: 1つのアイテムが問題のとき

偏りはいつもキー単位とは限りません — ときに 単一のアイテム が真っ赤に熱くなります。容赦ないトラフィックが1つの VEHICLE#HOT アイテムを駆動すると、DynamoDB の split-for-heat がパーティションを再バランスし、頻繁にアクセスされるアイテムが単独で着地するようにします。

いったん隔離されると、その単一アイテムのキーは パーティション上限: 3,000 RCU と 1,000 WCU をフルに引き出せます。それが1つのキーの絶対的な天井で — その上にメカニズムはありません。（AWS、キー範囲のスループット超過。）

留めておく価値のある注意点が1つ: アダプティブキャパシティは テーブルに Local Secondary Index があるとき、アイテムコレクションをパーティションにまたいで分割しません。LSI はコレクションを1つのパーティションに縛りつけます — その理由はGSI と LSIを参照。

アダプティブキャパシティが救えないとき

これが罠です。どちらのメカニズムもスループットを移すだけで、どちらもパーティションが物理的に許す以上を生み出しません。

シナリオ	バースト	アダプティブ	結果
短いスパイク、テーブルに余裕あり	賄う	—	スロットルなし
持続的な偏り、コールドな隣	—	ホットをブースト	スロットルなし
1アイテム、< 3K RCU / 1K WCU	—	隔離する	スロットルなし
1アイテム、**> パーティション上限	速く枯渇	天井に到達	スロットル — 再設計が必要**
多数のキーが同時にホット、テーブル満杯	速く枯渇	アイドルなし	スロットル — 再設計が必要

単一のキーが正当に毎秒 1,000 を超える書き込みを必要とするなら、どんな自動メカニズムもあなたを救いません — 負荷を複数のキーにまたいで分散させなければなりません。

書き込みシャーディング が通常の解決策です。サフィックス（VEHICLE#HOT#0 … #9）を付けて書き込みがパーティションにまたいでファンアウトするようにし、読み取りをファンインで戻します。

そのファンインは、シングルテーブル設計でクエリ経路を計画するのと同じように、意図的にモデリングすべきアクセスパターンそのものです — アダプティブキャパシティは時間を稼ぐのであって、キー設計のフリーパスではありません。

自分のテーブルで見る

アダプティブキャパシティは設計上見えないので、1つの症状を通して考えます — どのキーがホットか。シャーディングした書き込み経路を構築するとき、式ビルダーはサフィックス付きキーの PutItem と Query の構文を生成します。

キーが実際にデータ全体にどう分散するかを見るには、DynoTable をダウンロードし、アダプティブキャパシティが何とかしてくれると仮定する前に、自分の実テーブルでパーティションの分散を調べましょう。偏りの読み取り側については、Query と Scanを参照してください。