Amazon DynamoDB徹底解説：Cloud Bigtable・Cloud Firestore・Azure Cosmos DBとの比較で学ぶ「スケーラブルNoSQL設計」ガイド

はじめに（要点サマリー）

本記事では Amazon DynamoDB を主役に、Google Cloud Bigtable / Cloud Firestore、Azure Cosmos DB を並べて比較しながら、スケーラブルなNoSQLデータベース設計の考え方を整理していきます。
Amazon DynamoDBは、フルマネージドでサーバーレスな key-value / ドキュメント型NoSQLデータベース で、単桁ミリ秒のレイテンシでインターネット規模へ水平スケール できるのが特徴です。
GCPの Cloud Bigtable は大規模データ向けの ワイドカラム型NoSQLデータベース、Cloud Firestore はモバイルやWebアプリ向けの ドキュメントDB。Azureの Cosmos DB はグローバル分散・マルチモデルなNoSQL/ベクターデータベースとして位置づけられています。
設計の肝は、
1. ユースケースとアクセスパターンから「1テーブル設計」を考えること
2. パーティションキーとソートキーで「どうスケールさせるか」を決めること
3. GSI/LSI・インデックス・キャッシュを使ってクエリを最適化すること
4. オンデマンド／プロビジョンドキャパシティ・オートスケーリングでコストをコントロールすること
5. グローバルテーブルやイベント連携で将来の拡張性を確保すること
想定読者は、
- Web/モバイルアプリのバックエンド開発者
- ゲーム・EC・SaaSなどユーザー数・トラフィックが増えやすいサービスのエンジニア
- RDBMSからの移行を検討しているアーキテクト
- GCP/Azureを含めてNoSQL選定をしたい技術リーダー・SRE
読み終わるころには、「この要件ならDynamoDB／Bigtable／Firestore／Cosmos DBのどれを、どう設計して使うか」を自分の言葉で説明できる状態 を目指しますね。

1. DynamoDBとは：AWSの“インターネット規模NoSQLエンジン”

1.1 サービス概要と特徴

Amazon DynamoDBは、AWSが提供する フルマネージド・サーバーレスなNoSQLデータベース です。
主な特徴を整理すると：

key-value ＋ドキュメントモデル をサポート（1アイテム最大約400KB）。
単桁ミリ秒レイテンシ を前提とした設計で、リクエスト数やデータ量が増えても一定の性能を維持しやすい。
フルマネージド・サーバーレス：インスタンス管理・パッチ・シャーディングなどは不要。キャパシティはオンデマンド課金か、プロビジョンド＋オートスケールで制御。
マルチリージョン・マルチアクティブ なグローバルテーブルに対応し、リージョンを跨いで自動レプリケーション。
自動バックアップ・時間指定復元・暗号化、DAXによるインメモリキャッシュなどが利用可能。

「RDBMSのスキーマやJOINのしがらみから解放されて、アクセスパターンに合わせてテーブルを設計する世界」がDynamoDBの基本思想です。

1.2 他クラウドNoSQLとのポジション比較

ざっくりとした立ち位置を並べてみますね。

DynamoDB（AWS）
- key-value＋ドキュメント、インターネット規模のオンライン処理に強い。
Cloud Bigtable（GCP）
- ワイドカラム型NoSQL。時系列データ・メトリクス・IoT・分析基盤など、大規模な連続データに向く。
Cloud Firestore（GCP / Firebase）
- モバイル/フロントエンドからのリアルタイム同期・オフライン対応が得意なドキュメントDB。
Azure Cosmos DB
- グローバル分散・マルチモデル（ドキュメント・Key-Value・グラフなど）＋複数の一貫性モデル が特徴のNoSQL/ベクターDB。

DynamoDBは「超高スループットなOLTP・ユーザー向けオンライン処理」に最適化されており、Bigtableはより分析寄り・タイムシリーズ大量データ、Firestoreはクライアントアプリとの連携、Cosmos DBは多拠点分散とマルチモデルが得意、とイメージすると整理しやすいです。

2. DynamoDBのデータモデルと基本概念

2.1 テーブル・パーティションキー・ソートキー

DynamoDBのテーブルは、パーティションキー（必須） と ソートキー（任意） を中心に構成されます。

パーティションキー
- データ分散とスケーラビリティの要。値が偏るとパーティションホットスポットになり性能劣化の原因に。
ソートキー
- 同じパーティションキー内での並び順を決めるキー。時系列・種別などでソートしておくと、範囲クエリがしやすくなります。

1アイテムは柔軟な属性（カラム）を持つことができ、スキーマレス な構造になっています。テーブル作成時に決めるのは基本的にキーだけで、その他の属性はアイテムごとに違っていても構いません。

2.2 アクセスパターン設計の考え方

RDBMSでは「正規化→あとからクエリで取り出す」発想ですが、DynamoDBでは 「アクセスパターンを先に列挙し、そこからテーブル設計とキー設計を逆算」 するのが基本です。

例：ECサイトの商品・注文管理なら、

「ユーザーIDから注文履歴を新しい順で取得」
「注文IDから詳細を取得」
「商品IDから在庫レコードを取得」

…などのアクセスパターンを最初に列挙し、それぞれに対して パーティションキー＋ソートキー、必要ならインデックス を決めていきます。

2.3 GSI / LSI（セカンダリインデックス）

DynamoDBはRDBのような任意クエリは得意ではない代わりに、セカンダリインデックス を活用してビューを増やしていきます。

ローカルセカンダリインデックス（LSI）
- 同じパーティションキーを共有しつつ、ソートキーだけ変えてビューを増やす。
グローバルセカンダリインデックス（GSI）
- テーブル本体とは別に、キー定義を変えたテーブルのようなもの を作るイメージ。パーティションキーもソートキーも自由に設定可能。

FirestoreやCosmos DBでもインデックス設計は重要ですが、DynamoDBは「最初にアクセスパターンごとにインデックス含めた全体の絵を描く」必要がより強い印象です。

3. 代表ユースケース：どんなときにDynamoDBを選ぶ？

3.1 ユーザープロファイル・セッション・認証情報

SNS、ゲーム、SaaSなど、ユーザー数が増えやすく、ランダムな読み書きが発生するデータ にとても向いています。
ユーザーIDをパーティションキーにし、
- プロファイル
- 設定
- セッション
  などをまとめて扱う“シングルテーブル設計”がよく使われます。

3.2 ショッピングカート・注文履歴

カートやオーダーはユーザーごと・時間順での参照が多い典型例です。
PK = USER#<userid>, SK = ORDER#<timestamp> のように設計すると、1ユーザーの注文一覧を時間順に取得しやすくなります。
小売・EC分野でDynamoDBが選ばれる理由として、ピーク時（セール・キャンペーン）でも水平スケールしやすい点が挙げられます。

3.3 IoT・ログ・イベントストア

大量のセンサーデータやイベントストリームを高速に書き込みつつ、直近を参照したいケース。
ただし“全期間の集計・分析”には、BigtableやBigQuery、S3＋Athenaなど別の分析用ストアと組み合わせるのが現実的です。

3.4 比較：Bigtable / Firestore / Cosmos DBが得意なユースケース

Bigtable：メトリクス・時系列・ログ・レコメンド向け特徴量など、大量・連続データを低レイテンシで処理したいとき。
Firestore：クライアントアプリからのリアルタイム同期・オフライン対応が必須なモバイル/フロントエンド向け。
Cosmos DB：グローバル分散・マルチモデル・柔軟な一貫性レベルが欲しい大規模SaaSやエンタープライズアプリ。

4. パフォーマンスとスケーラビリティ：パーティション設計が命

4.1 リクエストレベルのスループット

DynamoDBは内部的にテーブルをパーティション（物理シャード）に分割しており、パーティションごとに処理能力が決まっています。

パーティションキーが偏ると、そのキーに関連するリクエストが1パーティションに集中し、スロットリング（ProvisionedThroughputExceededException）が発生しやすくなります。
そのため、「キーをどう分散させるか」＝スケール設計の核心 になります。

4.2 ベストプラクティス例

自増IDではなく、ハッシュ＋時間を組み合わせたID にする。
「ユーザーID × 日付」でシャーディングし、1ユーザーでも1日のデータが分散されるように工夫。
パーティションキーに“バケット番号”を混ぜて、複数パーティションへ分散。

Bigtableも、行キーのプレフィックスを工夫して負荷分散する設計が重要ですし、Cosmos DBもパーティションキーの設計を間違えるとスループットに大きく影響します。

5. キャパシティモデルとコスト設計

5.1 オンデマンド vs プロビジョンド

DynamoDBは主に2つのキャパシティモデルがあります。

オンデマンドキャパシティモード
- 事前のスループット設定不要。リクエスト数に応じて自動的にスケールし、使った分だけ課金。
- トラフィックが予測しにくい初期段階・PoCに向いています。
プロビジョンドキャパシティモード
- 読み込み/書き込みキャパシティユニット（RCU/WCU）を事前に設定。
- オートスケーリングも組み合わせ可能で、安定した負荷ならコスト最適化しやすい。

GCPのBigtableもノード数・スループット、FireStoreやCosmos DBもリクエスト数やRUsで課金されるなど、「スループットをどう見積もるか」がコストの鍵 という点は共通です。

5.2 コストを抑えるための設計ポイント

不要なGSI/LSIを増やしすぎない（インデックスも読み書き課金対象）。
1アイテムに詰め込みすぎると400KB制限に当たりやすくなり、逆に細かくしすぎるとリクエスト回数が増えるのでバランスが大切。
アクセス頻度の高い読み取りは、DAX（DynamoDB Accelerator）やアプリケーションキャッシュ を組み合わせてRCUを節約。

6. 信頼性・セキュリティ・グローバル分散

6.1 耐障害性とバックアップ

DynamoDBはAWSリージョン内でマルチAZレプリケーションされており、単一AZ障害に強い設計です。
オンデマンドバックアップやポイントインタイムリカバリ（PITR）に対応しており、誤削除・誤更新からの復元も容易です。

BigtableやCosmos DBもリージョン内/複数リージョンでの冗長構成が前提、Firestoreもリージョン／マルチリージョン構成が選べるなど、クラウドNoSQLでは耐障害性は標準機能になってきています。

6.2 グローバルテーブルとマルチリージョン

DynamoDBのグローバルテーブルは、選択した複数リージョン間でデータを自動レプリケーションし、どのリージョンでもローカル書き込みができる“マルチアクティブ”構成を実現します。
Cosmos DBもグローバル分散・複数の整合性レベルを提供しており、世界中のユーザー向けSaaSなどでよく使われます。

6.3 セキュリティとアクセス制御

IAMポリシーとリソースベースポリシーで、テーブル・アイテムレベルのアクセス制御が可能。
KMS連携による暗号化、VPCエンドポイントを使ったプライベートアクセスも利用できます。

FirestoreやCosmos DBにも、IAM / IAMロール・ロールベースアクセス制御・キー認証などが用意されており、「アプリケーションID単位で最小権限を付与する」 という設計思想は共通です。

7. 設計サンプル：シングルテーブルで扱うECサイト

ここでは、少し具体的なテーブル設計のサンプルを見てみましょう。

7.1 テーブル構造イメージ

テーブル名：ecommerce

PK（パーティションキー）：PK
SK（ソートキー）：SK

アイテム例：

PK	SK	type	attributes
`USER#123`	`PROFILE`	`USER`	name, email, created_at
`USER#123`	`ORDER#2025-11-20T10:00Z`	`ORDER`	total, status, items…
`USER#123`	`ORDER#2025-11-21T09:00Z`	`ORDER`	…
`PRODUCT#ABC`	`META`	`PRODUCT`	title, price, stock
`PRODUCT#ABC`	`INVENTORY#TOKYO`	`INV`	quantity
`PRODUCT#ABC`	`INVENTORY#OSAKA`	`INV`	quantity

こうすると、

「ユーザー123の注文履歴」
- PK = USER#123 のアイテムを SK 降順で取得
「商品ABCの情報と在庫」
- PK = PRODUCT#ABC のアイテムをまとめて取得

といった アクセスパターンを1テーブルで自然に表現できます。

7.2 GSI例：商品別の最近の注文を見る

商品IDから最近の注文を見たい場合、GSIを使って別視点の“ビュー”を作ります。

GSI1
- GSI1PK = PRODUCT#<productId>
- GSI1SK = ORDER#<timestamp>

注文アイテムにGSI1PK/GSI1SK属性を追加し、必要なときだけGSIをクエリすればOKです。
Firestoreならコレクション・サブコレクション＋複合インデックス、Cosmos DBならパーティションキー＋インデックス指定で似たようなビューを実現できます。

8. よくある落とし穴と回避策

8.1 RDBの頭でスキーマを決めてしまう

「まず正規化テーブルを作って、後からクエリを考える」やり方をそのまま持ち込むと、
- JOINができない
- アクセスパターンごとにGSIが爆増
- スループットとコストが膨らむ
  という事態になりがちです。
対策：
- ユースケース・画面・API単位でアクセスパターンを全て洗い出す
- そこから「テーブル構造・キー・インデックス」を逆算する。

8.2 パーティションキーの偏り

ユーザー数の少ないテスト環境で気づきにくいのですが、本番でユーザーが増えると、特定キーにアクセスが集中しスロットリングやレイテンシ増加につながります。
対策：
- キーの分布を CloudWatchメトリクスやログ分析 で可視化。
- ハッシュ化・シャーディングバケットの導入など、キー設計の再検討を早い段階で行う。

8.3 過剰なGSI作成

GSIは便利ですが、読み書きのたびにGSIも更新されるため、リクエストコストも増えます。
対策：
- 「本当にオンライン処理で必要なビューか」「分析は別ストアでよいか」を切り分ける。
- どうしてもGSIが増える場合は、アクセス頻度の低いものを削り、別テーブルやS3＋Athenaへ逃がす。

9. 誰がどう得をする？（読者別の具体的メリット）

9.1 バックエンドエンジニア・アプリ開発者

DynamoDB・Firestore・Cosmos DBなどのNoSQLを、**「なんとなくNoSQL」ではなく「アクセスパターン駆動で設計するもの」**として理解できるようになります。
結果として、
- スケールしても破綻しにくい
- 変更に強い
- コストも予測しやすい
  データモデルを自信を持って提案できるようになります。

9.2 SRE・インフラエンジニア・データ基盤担当

パーティション設計・キャパシティモデル・グローバルテーブル・キャッシュなど、運用に直結する論点が整理できます。
また、BigtableやCosmos DBなど、他クラウドのNoSQLとも比較しながら、**「このワークロードはどのサービスに置くべきか」**を判断しやすくなります。

9.3 アーキテクト・技術リーダー・CTO

RDBMS中心だったシステムを、
- 「トランザクション性が強く必要な部分はRDS/Aurora」
- 「高スループットで拡張性重視の部分はDynamoDB/Bigtable/Cosmos DB」
  といった形で分割し、ハイブリッドなデータレイヤーとして設計する視点が得られます。
マルチクラウド戦略を考える際も、各クラウドのNoSQLの共通点と違いを言語化しながら判断できるようになります。

10. 今日からできる3ステップ

自分のサービスの「読み書きパターン」を10個だけ書き出す
- 画面やAPIごとに、「どのキーで何件くらい読み書きする？」をざっくり列挙してみてください。
そのうち1〜2パターンを、DynamoDBテーブル設計に落としてみる
- PK / SK / GSI候補 / アイテム例をノートに書いてみるだけでもイメージが掴めます。
同じ設計をBigtable / Firestore / Cosmos DBならどう表現するか考えてみる
- 行キー・コレクション/ドキュメント・パーティションキー/コンテナなどへのマッピングを想像すると、クラウドが変わってもブレない設計感覚が育ちます。

11. まとめ：DynamoDBは「アクセスパターンから逆算する世界」への入り口

Amazon DynamoDBは、

サーバーレスでインターネット規模までスケールするNoSQLエンジンであり、
パーティションキー・ソートキー・インデックス設計によって性能とコストがほぼ決まる
アクセスパターンを起点にテーブルを設計する という、RDBとは少し違う思考を要求してきます。

一方で、GCPのBigtable/Firestoreや、Azure Cosmos DBもそれぞれに強みを持っており、ユースケースと組織の文脈に応じた最適解は一つではありません。

大切なのは、

「このデータはどんな頻度で、誰から、どんな形で読まれるのか・書かれるのか」
「どこまでスケールしそうか、どこまで一貫性が必要か」

を丁寧に考え、その答えから逆算してDynamoDBや他のNoSQLサービスを選ぶことです。

少しずつ、小さなテーブルやPoCから試していけば、きっと “スケールしても怖くないデータ設計” が手に馴染んでいきます。焦らず、楽しみながら、DynamoDBと他クラウドNoSQLを自分の味方にしていきましょうね。

参考リンク（公式ドキュメント・解説記事）

[Amazon DynamoDB 製品ページ]
[What is Amazon DynamoDB?（Developer Guide）]
[DynamoDB Features（key-value & document models）]
[Google Cloud Bigtable Overview]search15
[Cloud Firestore Overview]
[Azure Cosmos DB Overview]

※料金・制限値・最新機能は変わる可能性がありますので、実際の設計や導入時には必ず最新の公式ドキュメント・料金ページをご確認ください。