🚀

DynamoDB パーティション

2022/07/23に公開

DynamoDB は、パーティションというアーキテクチャーで、ノードや格納データを分割することでスケールする構成を取る。そのため、書き込みや読み込みいずれもスケールアウトできる構成を持つNoSQLデータベース。根幹とも言えるアーキテクチャーであるパーティションに関して諸々まとまる。

パーティション数変更時のダウンタイム有無

パーティション数は特定の条件で決まる(後述)だが、変更はサービスにより自動的、アプリケーションからは透過的に行われるのでアプリケーションから見た時のダウンタイムは無い。

パーティション管理は自動的にバックグラウンドで自動的に発生し、アプリケーションに対して透過的です。テーブルは利用可能な状態のままで、プロビジョニングされたスループット要件を完全にサポートします。

パーティションの冗長化

ストレージは自動的にパーティション化され、3AZにレプリケートされることで冗長化される。

なお、書き込みについては、少なくとも2AZでの書き込みが完了した時点でAckが返却される。
最終的には、結果整合性で全てのAZに反映され、また、更新されたデータを参照できるようになる。

アプリケーションが DynamoDB テーブルにデータを書き込み、HTTP 200 応答 (OK) を受け取ると、書き込みが開始され、継続します。データは、すべてのストレージの場所で結果的に整合性が保たれます (通常は 1 秒以内)。

パーティションごとの RCU/WCU

テーブルに対して指定するRCU/WCUはテーブル全体の性能値。
そのため、パーティションが複数あれば、スループットは各パーティションに均等分散される。

パーティション数の計算方法

DynamoDB でパーティションは必要に応じて増えるのでユーザーで意識する必要性はない。ただ、計算方法はある。ストレージサイズやスループットによって決定される。1つのパーティションに対しては、3000RCU/1000WCU/10GBのデータ量の制限があるため、それを基準に分割される。

Adaptive Capacity

各パーティションに対してRCU/WCUは均等分散されるのが基本動作だが、もし特定のパーティションに対してアクセスが集中してホットパーティションになってしまうような不均等なワークロードがあったとする。
その際に、他のパーティションに割り振られた性能値がMaxまで使用されていなければ余力の性能値をそのホットパーティションで追加で利用できるという機能。
ゆえに、仮に不均等なワークロードが発生してホットパーティションが生まれても、スロットリングを回避できる可能性が高まる。
DynamoDB にデフォルトで備わっている機能で明示的な有効化不要。逆にいうと無効化する術もない。

オンデマンドモード時のキャパシティの暖気

この記載や事例を確認する限り、事前に想定のWCU/RCUのプロビジョニングモードにしてからオンデマンドに切り替えることで暖気ができる想定。

オンデマンドキャパシティーモードに切り替えられた既存のテーブル: 前のピークは、テーブルにプロビジョニングされた、最大書き込みキャパシティーユニットおよび最大読み取りキャパシティーユニットの半分、またはオンデマンドキャパシティーモードで新しく作成されたテーブルの設定の、どちらか高い方です。つまり、このテーブルで提供されるスループットは、オンデマンドキャパシティーモードに切り替える前と同じかそれ以上になります。

このような場合、要件を満たすのに十分な WCU と RCU でプロビジョニングされたテーブルを「事前に温めて」おいてから、テーブルをオンデマンドモードに切り替えます。これは、以前にプロビジョンドモードを使用していたオンデマンドテーブルのキャパシティーを決定する DynamoDB のロジックのおかげで機能するものです。