DynamoDB のアダプティブキャパシティ：できることとできないこと

DynamoDBはテーブルをパーティションに分散させますが、あなたのトラフィックが均等に分散することはめったにありません。バーストキャパシティーとアダプティブキャパシティーは、偏ったワークロードがスロットリングされるのを止める2つの自動メカニズムです — ハードリミットにぶつかるまでは。

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

DynamoDBのアダプティブキャパシティーは、未使用のスループットをへと移す自動メカニズムで、偏ったキーが、テーブルの残りが遊んでいる間にスロットリングされないようにします。バーストキャパシティーと組み合わさって、スパイクと持続的な偏りを無料で吸収します — ただし単一のキーをパーティションの上限を超えて押し進めることはできません。

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

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

すべてのパーティションは独立して上限が定められています。1秒あたり読み込み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つ：アダプティブキャパシティーは、テーブルにがあるとき、をパーティションをまたいで分割しません。LSIはコレクションを1つのパーティションに束縛します — なぜかはGSI vs LSIを参照してください。

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

これが罠です。両メカニズムはスループットを_あちこちに動かす_だけ。どちらもパーティションが物理的に許す以上を作り出しはしません。

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

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

書き込みシャーディングが通常の解決策です。サフィックスを付けて（VEHICLE#HOT#0 … #9）書き込みをパーティションにまたいで扇状に広げ、読み込みで扇状に集めます。

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

自分のテーブルで見てみる

アダプティブキャパシティーは設計上目に見えないので、1つの症状を通じてそれについて考えます。どのキーがホットか、です。シャード化された書き込みパスを構築するとき、 Expression Builderがサフィックス付きキーの PutItemとQueryの構文を生成します。

キーが実際にデータ全体にどう分散するかを見るには、DynoTableをダウンロードして、 SQL Workbenchでパーティションキーに対してGROUP BYを実行し、アダプティブキャパシティーが賄っていると決めつける前に、キーごとに項目がどう積み上がるかを見てください。偏りの読み込み側については、Query vs Scanを参照してください。