Amazon DynamoDBは、キーを指定するオンライン処理を低遅延でさばき、サーバー管理を減らしたい場面に適したNoSQLデータベースです。
ただし、RDBのテーブルをそのまま移せば性能が出るわけではありません。
画面やAPIがどのキーで何を読むかを先に決め、そのアクセスパターンからデータモデルを逆算します。
この記事では、DynamoDBの設計手順をECサイトの例で解説し、Cloud Bigtable、Cloud Firestore、Azure Cosmos DBとの違いを選定基準に落とし込みます。
料金、クォータ、提供機能は更新されるため、導入時には本文末の公式資料で最新情報を確認してください。
DynamoDBが合う要件と合わない要件
NoSQLは、リレーショナルデータベースとは異なるデータモデルを使うデータベースの総称です。
DynamoDBは、その中でもキーと値、およびドキュメントを扱うフルマネージド型のサービスです。
テーブルの各項目は同じ属性を持つ必要がありませんが、主キーの設計は必要です。
DynamoDBを選びやすいのは、次の条件がそろうワークロードです。
- ユーザーID、注文ID、デバイスIDなど、検索の起点となるキーが明確である
- セッション、カート、注文状況など、短い応答時間を求める読み書きが多い
- トラフィックの増減に合わせて処理能力を調整したい
- AWSの認証、監視、イベント処理と組み合わせたい
一方、自由な結合や複雑な集計を日常的に行う業務、検索条件が頻繁に変わる業務では、RDBや分析基盤のほうが扱いやすい場合があります。
データベース正規化と保守性の考え方も確認すると、RDBとDynamoDBの役割を分けやすくなります。
4つのクラウドNoSQLを同じ物差しで比べる
製品名だけを並べても、適切な選択にはつながりません。
データモデル、主なアクセス方法、分散の単位、アプリケーションとの接続方法を同じ順序で比べます。
| サービス | 主なデータモデル | 選びやすい場面 | 設計の中心 |
|---|---|---|---|
| Amazon DynamoDB | キーと値、ドキュメント | AWS上のオンライン処理、セッション、カート、注文状態 | アクセスパターン、パーティションキー、ソートキー、インデックス |
| Cloud Bigtable | 行キーで並ぶ疎なワイドカラム | 時系列、IoT、メトリクスなど、大量の単一キー型データ | 行キーの並びと書き込みの分散 |
| Cloud Firestore | コレクションとドキュメント | モバイルやWebアプリのリアルタイム同期、オフライン利用 | ドキュメント構造、クエリ、セキュリティルール |
| Azure Cosmos DB | 柔軟なJSON文書を中心とする分散NoSQL | 複数地域にまたがる低遅延アプリ、整合性を選びたい業務 | パーティションキー、RU、整合性レベル、リージョン配置 |
Bigtableを単に「分析用」、Firestoreを単に「小規模アプリ用」と決めつけるのは正確ではありません。
Bigtableは単一キー型データの高スループット処理、Firestoreはクライアント同期を含むドキュメント処理というように、アプリケーションが必要とする読み書きから判断します。
クラウド全体の選定から始める場合は、AWS、Azure、Google Cloud、OCIの比較も判断材料になります。
DynamoDBの基本用語
パーティションキーとソートキー
パーティションキーは、項目の保存先を決める計算に使われる属性です。
値の種類が少なく、一部の値にアクセスが集中すると、特定の領域だけに負荷が偏る可能性があります。
ソートキーは、同じパーティションキーを持つ項目を並べ、範囲で取得するための属性です。
たとえばパーティションキーをユーザーID、ソートキーを注文日時にすれば、一人の注文を時系列で取得できます。
パーティションキーだけの主キーも、二つを組み合わせた複合主キーも選べます。
アクセスパターン
アクセスパターンとは、アプリケーションが「どの条件で、どの項目を、何件ほど読むか、または書くか」を表したものです。
画面名だけではなく、API操作と必要な整合性まで書き出すと、キーとインデックスを決めやすくなります。
| 業務上の問い | 操作 | キー候補 | 確認事項 |
|---|---|---|---|
| 注文IDから詳細を表示する | 1件取得 | 注文ID | 強い整合性が必要か |
| 会員の注文履歴を新しい順に表示する | 範囲取得 | 会員IDと注文日時 | 1回の表示件数とページング |
| 商品の店舗別在庫を表示する | 範囲取得 | 商品IDと拠点ID | 更新競合と在庫確保の方法 |
| 商品ごとの最近の注文を調べる | 別のキーで検索 | 商品IDと注文日時 | オンライン画面か分析処理か |
最後の問いが運用レポートだけに必要なら、GSIを追加せず、別の分析基盤へ渡す設計も選べます。
すべての検索条件を一つのテーブルで満たそうとせず、応答時間と利用頻度で切り分けます。
ECサイトを例にしたシングルテーブル設計
シングルテーブル設計は、異なる種類の項目を一つのテーブルへ格納し、主キーの付け方で関連を表す手法です。
DynamoDBの必須条件ではなく、複数のアクセスパターンを少ないリクエストで処理したいときの選択肢です。
| PK | SK | 種別 | 主な属性 |
|---|---|---|---|
USER#123 |
PROFILE |
会員 | 氏名、連絡先 |
USER#123 |
ORDER#2026-09-20T10:00:00Z |
注文要約 | 注文ID、合計、状態 |
ORDER#001 |
ITEM#ABC |
注文明細 | 商品ID、数量、単価 |
PRODUCT#ABC |
META |
商品 | 名称、表示情報 |
PRODUCT#ABC |
INVENTORY#TOKYO |
在庫 | 数量、更新時刻 |
PK = USER#123をQueryすれば、会員情報と注文要約を同じパーティションから取得できます。
PK = PRODUCT#ABCをQueryすれば、商品情報と拠点別在庫をまとめて取得できます。
ここで使うQueryはキー条件を指定する操作であり、テーブル全体を調べるScanとは役割が異なります。
注文要約と注文明細で一部の値を重複させるのは、取得時の結合を避けるためです。
その代わり、更新処理は複雑になります。
どの項目を正とするか、更新失敗時にどう再実行するかを設計書に残す必要があります。
GSIとLSIで別の検索経路を作る
主キー以外の条件で検索する場合は、セカンダリインデックスを検討します。
インデックスは便利ですが、書き込みと保存の負担も増えるため、アクセスパターンごとに必要性を判断します。
| 項目 | GSI | LSI |
|---|---|---|
| パーティションキー | 基表と異なるキーを設定できる | 基表と同じキーを使う |
| ソートキー | 任意に設定できる | 基表とは別のソートキーを設定する |
| 用途 | 別の検索軸を追加する | 同じ項目群を別の順序で取得する |
| 設計上の注意 | 基表の更新に伴ってインデックスも更新される | 用途と制約をテーブル作成前に確認する |
商品ごとの最近の注文を表示するなら、注文明細にGSI1PK = PRODUCT#ABC、GSI1SK = ORDER#2026-09-20T10:00:00Zを持たせる方法があります。
一つの注文に複数商品が含まれるため、注文全体ではなく商品ごとの注文明細をインデックス対象にする点が設計の要所です。
パーティションの偏りを防ぐ
高い負荷を処理できるかどうかは、総データ量だけでは決まりません。
少数のパーティションキーに読み書きが集中すると、そのキーが処理の限界になり得ます。
STATUS#OPENのように全件が集まりやすい値を高頻度更新のキーにしない- 会員ID、注文ID、デバイスIDなど、値が十分に分散する候補を選ぶ
- 単一キーへの書き込みが避けられないときは、バケット番号を加える書き込みシャーディングを検討する
- キーを分割した場合は、読み取り時に複数結果をまとめる処理と順序保証も設計する
- 本番に近いキー分布と急増パターンで負荷試験を行う
ランダムな文字列を付ければ常に解決するわけではありません。
均等な書き込みと、必要な範囲を効率よく読むことの両方を満たすキーを選びます。
キャパシティとコストの決め方
DynamoDBにはオンデマンドモードとプロビジョンドモードがあります。
オンデマンドは読み書きの事前指定が不要で、リクエスト量に応じて課金されます。
プロビジョンドは必要な読み書き能力を設定し、予測しやすい負荷ではオートスケーリングも組み合わせられます。
| 確認する状況 | 検討しやすいモード | 運用上の確認 |
|---|---|---|
| 開始時の負荷が読めない、増減が大きい | オンデマンド | 急激な新記録のトラフィック、クォータ、利用上限 |
| 負荷が安定し、必要量を見積もれる | プロビジョンド | RCUとWCU、目標使用率、オートスケーリング |
| 読み取りが特定データへ集中する | どちらでも可 | キー分布、キャッシュの整合性と失効 |
オンデマンドは「設計不要」や「無制限」を意味しません。
AWSの現在の仕様では、過去のピークを大幅に上回る急増時の挙動やクォータも確認する必要があります。
インデックスの更新、バックアップ、レプリケーション、データ転送も含め、代表的なリクエストを料金計算へ入れます。
1項目の最大サイズは400KBです。
大きな画像や文書本体はオブジェクトストレージへ置き、DynamoDBには参照先と検索に使う属性を保存する構成が一般的です。
項目を細かく分けすぎるとリクエスト回数が増えるため、画面が一緒に読む単位も考慮します。
可用性、復旧、セキュリティを分けて設計する
可用性とバックアップは別の要件です。
DynamoDBはリージョン内の冗長化をサービス側で行いますが、誤削除や誤更新への備えにはポイントインタイムリカバリやバックアップを設定します。
復元手順を用意し、復旧時間と復旧時点の目標に合うかを試験します。
複数リージョンで読み書きする必要がある場合は、グローバルテーブルを検討します。
リージョンを増やすだけでなく、同じ項目を同時更新した場合の扱い、フェイルオーバー時の経路、複製と通信の費用まで確認します。
アクセス制御では、IAMでテーブル、インデックス、ストリームなどへの操作を最小限に絞ります。
アプリケーション利用者の権限は、API側の認証と認可を含めて設計します。
暗号化、監査ログ、VPCエンドポイントも、扱うデータと組織の基準に合わせて選びます。
変更イベントを別処理へ渡す場合はDynamoDB Streamsを利用できます。
通知、検索用データの更新、監査処理などを非同期化するときは、失敗時の再試行と重複実行を前提にします。
実行基盤との組み合わせは、AWS Lambdaと各クラウドのサーバーレス実行基盤の比較で確認できます。
導入前の設計チェックリスト
- 読み書きを列挙する。 画面とAPIごとに、条件、件数、順序、頻度、整合性を記録します。
- 主キーで満たす操作を決める。 パーティションキーとソートキーで取得できない操作だけをGSI候補にします。
- キー分布を確かめる。 平均値ではなく、特定会員や特定商品へ集中する日の負荷も試します。
- 更新の正しさを決める。 重複データ、同時更新、再試行、条件付き更新の扱いを決めます。
- 容量と費用を試算する。 項目サイズ、読み書き回数、インデックス、バックアップ、リージョン間通信を含めます。
- 障害と誤操作からの復旧を試す。 フェイルオーバーとバックアップ復元を別々に検証します。
- RDBや分析基盤との境界を決める。 結合、自由検索、長期集計をDynamoDBに背負わせない構成も比較します。
まとめ
DynamoDBの成否は、サービスの機能数ではなく、アクセスパターンとキー設計の一致で決まります。
検索条件が明確なオンライン処理では有力ですが、自由な結合や分析まで一つのテーブルに集める必要はありません。
まず代表的な画面やAPIを三つ選び、読み書きの条件を表にします。
その表から主キー、GSI、整合性、キャパシティ、復旧方法を決め、実データに近い偏りで検証します。
Bigtable、Firestore、Cosmos DBも同じ物差しで比較すれば、クラウド名ではなく要件から選べます。
公式資料
- AWS：DynamoDBのコアコンポーネント
- AWS：DynamoDBのキャパシティモード
- AWS：DynamoDBの制約とクォータ
- Google Cloud：Bigtableの概要
- Firebase：Cloud Firestoreの概要
- Microsoft Learn：Azure Cosmos DBの概要
この記事に関連する株式会社greedenの取り組み
DynamoDBの採用では、製品名より先に読み書きの流れ、データ量、障害時の復旧方法を整理する必要があります。株式会社greedenは、要件定義からDBとAPIの設計、実装、テスト、保守運用まで一貫してWebシステム開発を支援しています。