Amazon DynamoDBは、2012年にAWSが公開したフルマネージド型のキーバリュー/ドキュメントNoSQLです。源流は2004年のホリデーシーズンにAmazonが社内向けに開発したDynamoで、そのときの教訓を綴った2007年のSOSP論文は分散DB研究の必読書になっています。Lambdaと組み合わせたサーバーレス構成の定番ストレージとして広く使われ、運用負荷を限界まで下げたい現場で選ばれます。
この記事の目次
- DynamoDBが約束する性能特性
- Dynamo論文から商用サービスまで
- 向いている使い方・向かない使い方
- 他の選択肢との違い
- まとめ
DynamoDBが約束する性能特性
DynamoDBは、テーブルがどれだけ大きくなっても一桁ミリ秒の応答を返すよう設計されています。Amazon.com本体のショッピングカートが2017年のプライムデーに毎秒数百万件のリクエストを捌いた事例は、AWSが繰り返し引用するベンチマークです。内部ではパーティションキーで自動的にシャーディングされ、サイズや負荷に応じてストレージとスループットが見えないところで増減します。
課金は2つのモデルから選びます。プロビジョンドキャパシティはRCU/WCU（読み書きユニット）を事前に確保する方式、オンデマンドはリクエスト数で従量課金する方式です。トラフィックが読みづらいスタートアップは後者、定常負荷が見えている業務系は前者、という使い分けが一般的になっています。
Dynamo論文から商用サービスまで
原型のDynamoはWerner Vogels CTOら率いるAmazon社内チームが、ショッピングカートの可用性問題を解くために生み出しました。コンシステントハッシング、Quorum、ベクタークロックといった分散システムの定番技法が一斉に投入され、2007年の論文公開後、Cassandra、Riak、Voldemortなど多数の派生実装を誘発しています。
AWSサービスとしてのDynamoDBは2012年1月にローンチ。2017年にGlobal Tablesで複数リージョン間のアクティブ-アクティブ複製を、2018年にACIDトランザクションをサポートするなど、NoSQLの不便さを年々埋めてきました。2022年にはマネージド変更データキャプチャ（Streams + Kinesis）が標準機能化し、イベント駆動のハブとしても定着しています。
向いている使い方・向かない使い方
DynamoDBはキーで一意に引ける読み書きが最も得意です。セカンダリインデックス（GSI/LSI）で別軸の検索もできますが、RDBのような自由なJOINやアドホックな分析クエリは前提から外されています。そのため設計段階で「どのキーで引くか」を網羅し、テーブルを用途ごとに分けるシングルテーブル設計が定番です。
向かないのは、レポーティングや横断集計が中心の業務系です。そうしたケースではAmazon Athena（S3への定期エクスポート）やRedshift、Snowflakeと組み合わせて、OLTPはDynamoDB、OLAPは別系統、と分業させるのが落としどころになります。1項目400KBの上限、トランザクションは最大100項目、といった細かな制約も事前に把握しておきたい点です。
他の選択肢との違い
DynamoDBの相対的な強みは、AWS内のサービスとの結合度の高さです。IAMでアクセス制御し、Lambdaトリガでイベント処理し、CloudWatchで監視する一連の流れがほぼ設定だけで完結します。Azure側ではCosmos DB、GCP側ではFirestoreが似た立ち位置を占めています。
弱点は、AWSロックインと、コスト最適化の難しさです。アクセスパターンが想定からズレると一気に費用が膨らむため、リードレプリカ的に使うDAX（DynamoDB Accelerator）の併用や、頻繁に読むデータをElastiCacheに逃がすといった工夫を組み込むと安定します。「運用しないこと」の価値を最大化したい現場ほど、DynamoDBの良さが効いてくるサービスです。
まとめ
DynamoDBは、サーバー管理を完全に手放しつつ規模に応じて勝手に伸びるNoSQLです。アクセスパターンを先に決められる業務であれば、もっとも運用コストの低い選択肢のひとつになります。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント