はじめに
本報告書の目的
本報告書は、Amazon DynamoDBというAWSのNoSQLデータベースについて、概要、主要な特徴、高度な機能、そしてテーブル設計のポイントを分かりやすく整理したものです。実務での利用を念頭に置き、設計や運用の判断に役立つ情報を提供します。
想定する読者
開発者、システム担当者、アーキテクト、サービス企画の方を主な対象とします。データベースの基礎知識がある方を想定しますが、専門用語は最小限にし、具体例で補足します。
本報告書で扱う内容と読み方
第2章でDynamoDBの基本を説明します。第3章では利点や制約を具体例を交えて示します。第4章はDAXやグローバルテーブルなどの高度な機能を紹介します。第5章では実践的なテーブル設計とモデリング手法を取り上げます。短時間で全体像を掴みたい場合は、第2章と第5章を先にお読みください。
DynamoDBを一言で言うと
DynamoDBは、利用量に応じて自動で拡張するデータベースです。例えば、ECサイトでアクセスが急増しても、運用側がサーバー台数を増やす手間をかけずにデータを扱えます。
Amazon DynamoDBの概要
DynamoDBとは
Amazon DynamoDBは、AWSが提供する完全託管型のNoSQLデータベースサービスです。サーバーを自分で準備せずに使え、可用性やバックアップなどの運用負荷をAWSが引き受けます。小さなウェブアプリから大規模サービスまで幅広く利用できます。
データモデル（キー値・ドキュメント）
DynamoDBは主にキー値とドキュメントの形式を扱います。例えばユーザー情報を扱う場合、ユーザーIDを主キーにしてプロフィールを1つの項目（ドキュメント）として保存できます。JSONのような構造をそのまま格納できるため、柔軟な設計が可能です。
スケーラビリティとパフォーマンス
自動でスケールアウトし、低レイテンシーで読み書きができます。アクセスが急増しても設定に応じて処理能力を確保します。読み書きの単位（容量）を設定する方式と、従量課金のオンデマンド方式があり、用途に応じて選べます。
運用と管理
バックアップや復元、マルチリージョンレプリケーションなど運用機能が揃っています。インフラ運用の負担を減らし、アプリケーション開発に集中できます。
代表的な利用例
セッション管理、IoTデータの時系列保存、ショッピングカートなど、低レイテンシーでスケールが必要な場面に向きます。
DynamoDBの主要な特徴
1. スケーラビリティと性能
DynamoDBはデータ量やアクセス数に合わせて自動で分散します。パーティションという単位でデータを分け、読み書きを並列化するため、数百万件のリクエストでもミリ秒単位の応答を維持できます。たとえば、オンラインショップのカート情報やSNSのフィードなど、高頻度アクセスでも安定します。
2. 無サーバーアーキテクチャ
完全に管理されたサービスなので、サーバーの用意やパッチ適用は不要です。運用担当はハードウェアやOSの管理から解放され、アプリケーションに集中できます。スケール時のインフラ調整も自動で行います。
3. 柔軟なデータモデル
DynamoDBはキー値とドキュメント（JSONに相当）形式を扱えます。スキーマ固定を求めないため、項目を増やしたり型を変えたりしてもテーブルの定義を変えずに運用できます。たとえば注文にメモ欄を追加しても既存データに影響しません。
4. 容量管理モード
オンデマンドは利用に応じて自動課金され、突発的な負荷に強いです。プロビジョニングは事前に読み書き容量を設定し、予測可能な負荷でコスト効率が良くなります。自動スケーリングと組み合わせて柔軟に運用できます。
5. エンタープライズグレードの機能
トランザクションで複数アイテムの一括操作を原子性ありで実行できます。グローバルテーブルで複数地域にデータを複製し、低遅延と可用性を高められます。バックアップ、復元、暗号化、細かなアクセス制御も備え、企業利用に耐える機能が整っています。
DynamoDBの高度な機能
DynamoDB Accelerator (DAX)
DAXはメモリ内キャッシュを提供し、読み取りを数ミリ秒からさらに短くします。例えば、ゲームのリーダーボードや頻繁にアクセスする商品情報に適用すると、レイテンシが大幅に下がります。キャッシュはアプリ側から透過的に使え、実装は比較的簡単です。
グローバルテーブルと多リージョン強一貫性（プレビュー）
グローバルテーブルは複数リージョンへデータを自動でレプリケートします。2024年12月に多リージョン強一貫性のプレビューが公開され、複数リージョン間で強い整合性が必要なアプリでも高可用性を維持しやすくなりました。グローバル障害や地域偏在ユーザーに向いています。
Kinesis Data Streams for DynamoDB
項目単位の変更をリアルタイムにキャプチャしてストリーミング処理に送ります。これを使えば、変更イベントを分析やETL、通知へすぐに結び付けられます。例えば、在庫変動を検知して即座にアラートを出すことが可能です。
OpenSearchとの統合（ゼロETL）
DynamoDBのデータをOpenSearch Serviceへ自動同期できます。専用のETLを作らなくても検索やログ分析に使えるため、商品検索やログ探索の導入が速くなります。設定と権限管理を正しく行えば運用が楽になります。
テーブル設計とモデリング
主キーの考え方
DynamoDBのテーブルはパーティションキー（必須）とソートキー（任意）で主キーを作ります。パーティションキーはデータの保存先を決め、ソートキーは同じパーティション内での並びを決めます。たとえば「ユーザーID」をパーティションキーにすると、あるユーザーに関するデータを一箇所にまとめられます。
パーティションキーとソートキーの選び方
- 高頻度アクセスの属性をキーにします。アクセスパターンを先に洗い出してください。
- 同じキーに大量の書き込みが集中するとホットパーティションになります。ユーザーID以外に日付やタイプを組み合わせて分散させると良いです。
単一テーブル設計 vs 複数テーブル
単一テーブル設計は読み取りを高速にし、結合の必要を減らします。複数テーブルは設計が単純で運用しやすい場面があります。用途に応じて使い分けてください。
二次インデックス（GSI/LSI）の使いどころ
- GSIは異なるパーティション/ソートキーでの検索に便利です。グローバルにスケールします。
- LSIは同じパーティション内で別のソート順を使いたいときに有効です。書き込み制限に注意してください。
実践例（注文データ）
例: 注文テーブルでパーティションキーを”customerId”、ソートキーを”orderDate#orderId”にすると、顧客の全注文を日付順に取り出せます。検索で商品別集計が必要ならGSIを追加します。
運用上の注意とベストプラクティス
- まずアクセスパターンを定義する
- キー設計はアクセス重視で行う
- ホットパーティションを避けるためにキーを分散する
- 必要な属性のみ保存して項目サイズを抑える
これらを意識すれば、可用性と性能を両立したテーブル設計ができます。
