AWS はじめの一歩
データベース

Amazon DynamoDB

読み方: ダイナモディービー

ミリ秒単位のレイテンシを保証するフルマネージドな NoSQL データベースサービスで、どんな規模のトラフィックにも自動スケールする

約 2 分で読めます執筆 / 編集: あわしろ

概要

Amazon DynamoDB は、キーバリュー型とドキュメント型の両方のデータモデルをサポートするフルマネージドな NoSQL データベースサービスです。AWS は一桁ミリ秒台のレスポンスタイムを掲げており、データ量やリクエスト数が増えても一貫した応答性能を維持できるとしています。テーブルの作成後はキャパシティの管理を AWS に任せるオンデマンドモードと、事前にスループットを指定するプロビジョンドモードの 2 つの課金方式から選択できます。2026 年 9 月時点の AWS 公式ドキュメントによると、グローバルテーブル機能を使えば複数のリージョンにデータを自動複製し、各リージョンで読み書きできるマルチリージョン構成を組めます。DynamoDB Streams を使えばテーブルの変更をリアルタイムにキャプチャし、Lambda 関数でイベント駆動型の処理を実行できます。

パーティションキー設計とホットパーティション回避

DynamoDB のパフォーマンスはパーティションキーの設計に直結します。データは内部的にパーティションキーのハッシュ値に基づいて分散配置されるため、カーディナリティの高い属性 (ユーザー ID、注文 ID など) を選ぶことでリクエストが均等に分散されます。逆に日付やステータスのようなカーディナリティの低い属性をパーティションキーにすると、特定のパーティションにアクセスが集中するホットパーティション問題が発生し、スロットリングの原因になります。対策としては、パーティションキーにランダムサフィックスを付与する書き込みシャーディングや、複合キー (例: ユーザー ID + タイムスタンプ) の採用が有効です。グローバルセカンダリインデックス (GSI) を使えば主キー以外の属性でも効率的なクエリが可能ですが、GSI ごとに追加のストレージとスループットが消費されるため、必要最小限に抑えることが重要です。Azure Cosmos DB もパーティションキーの概念を持ちますが、スループットの分散方式が異なるため、DynamoDB のキー設計をそのまま移植すると性能問題が起きる場合があります。移行を検討する際は、両サービスの公式ドキュメントで最新のスループット設計を確認してください。

オンデマンドモードとプロビジョンドモードの判断基準

DynamoDB の課金方式は 2 つあり、ワークロードの特性に応じて選択します。オンデマンドモードはリクエストごとの従量課金で、キャパシティの事前見積もりが不要です。読み取り・書き込みリクエストユニットの単価は Amazon DynamoDB の公式料金ページで確認してください。トラフィックが予測困難な新規サービスや、スパイクが激しいワークロードに向いています。プロビジョンドモードは事前にスループット (RCU/WCU) を指定する方式で、安定したトラフィックパターンが見えている場合はオンデマンドより費用を抑えやすくなります。リザーブドキャパシティを組み合わせればさらに割引を受けられますが、契約期間と割引率は公式料金ページの記載に従います。実務では、サービス立ち上げ期はオンデマンドで始め、トラフィックパターンが安定してきたらプロビジョンドに切り替えるのが定石です。

DAX、TTL、バックアップによる運用最適化

DynamoDB Accelerator (DAX) はインメモリキャッシュレイヤーで、AWS は読み取りレイテンシをミリ秒からマイクロ秒台へ短縮できるとしています (2026 年 9 月時点)。読み取りが支配的なワークロード (リーダーボード、セッション管理など) で特に効果を発揮しますが、書き込み直後の読み取り一貫性が不要なケースに限定されます。TTL (Time to Live) 機能を有効にすれば、有効期限切れのアイテムが自動削除され、ストレージコストの肥大化を防げます。セッションデータや一時トークンの管理に最適です。バックアップにはポイントインタイムリカバリ (PITR) とオンデマンドバックアップの 2 種類があります。PITR を有効にすれば過去 35 日間の任意の時点にテーブルを復元でき、オペレーションミスからの復旧に備えられます。DynamoDB Streams を使えばテーブルの変更をリアルタイムにキャプチャし、Lambda 関数でイベント駆動型の後続処理 (検索インデックスの更新、集計テーブルへの反映など) を実行できます。

参考資料 (AWS 公式)

本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。

本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。

共有するXB!

関連する用語

Amazon RDSAmazon AuroraAmazon ElastiCache

関連するサービス

AWS LambdaAmazon API Gateway

関連する記事

Amazon API Gateway の設計パターン - REST API と HTTP API の選定基準HTTP API と REST API の選定基準を明確にし、Cognito・Lambda オーソライザーの認証パターンとスロットリング設計の実践手法を紹介します。AWS Infrastructure Composer (旧 AWS Application Composer) でサーバーレスアプリケーションをビジュアル設計 - IaC テンプレートの自動生成Infrastructure Composer によるサーバーレスアーキテクチャのビジュアル設計、SAM テンプレートの自動生成、VS Code 統合を解説します。AWS の API スロットリングの仕組み - トークンバケットアルゴリズムと 429 エラーの正体AWS API のレート制限がトークンバケットアルゴリズムで実装されている仕組み、バーストキャパシティの概念、サービスごとの制限値の違い、スロットリング回避の実践的な対策を解説します。Amazon Cognito で実装するユーザー認証 - User Pool と Identity Pool の設計Cognito User Pool によるユーザー認証、Identity Pool による AWS リソースアクセス、ソーシャルログインの統合を解説します。Lambda コールドスタートの正体と 3 つの最適化戦略の使い分けLambda のコールドスタートが発生するメカニズムを Firecracker MicroVM のライフサイクルから解説し、SnapStart / Provisioned Concurrency / 関数設計の 3 軸で 3 つの最適化手法をコストと制約の面から比較します。

内容が近い用語 / 記事

Amazon DynamoDBミリ秒レベルのレイテンシを提供するフルマネージド NoSQL データベースAmazon DynamoDB のテーブル設計パターン - シングルテーブル設計と GSI の活用DynamoDB のパーティションキー設計、シングルテーブルデザイン、GSI によるアクセスパターンの実現を解説します。サーバーレスデータベース - DynamoDB で実現するスケーラブルなデータ管理DynamoDB のオンデマンドモードを軸に、トラフィックに応じて自動スケールするデータベースを構築する。Aurora Serverless との比較を含め、ワークロード特性に応じたサーバーレス DB の選定基準を解説します。DynamoDB はなぜ 1 桁ミリ秒を保証できるのか - パーティション分割とリクエストルーターの内部構造DynamoDB が規模に関係なく 1 桁ミリ秒のレイテンシを維持できる仕組みを、パーティション分割アルゴリズム、リクエストルーター、ストレージノードの 3 層アーキテクチャから解説します。Amazon Keyspaces で Cassandra ワークロードをマネージドに運用 - CQL 互換とサーバーレスApache Cassandra 互換の CQL API でワイドカラムデータを管理し、サーバーレスのオンデマンドキャパシティで運用負荷をゼロにする。プロビジョンドモードとの使い分けとマルチリージョンレプリケーションを解説します。