当ブログの内容は筆者の経験と知識に基づいていますが、AWSのサービスおよび認定試験は日々アップデートされています。もしも記事に誤りや古い情報がある場合、お手数ですが「コメント」や「お問い合わせ」からお知らせいただければ幸いです。
Amazon DynamoDBとは
概要
Amazon DynamoDB は、AWS が提供する完全マネージド型の NoSQL データベースサービスです。キーと値のペア、もしくはドキュメント形式でデータを保存し、ミリ秒単位のレイテンシで高速な読み書きが可能です。スケーラビリティ、可用性、セキュリティに優れ、大規模なアプリケーションのデータストアとして広く利用されています。
特徴
Amazon DynamoDBには以下のような特徴があります。
- フルマネージドサービス
DynamoDB は AWS が完全に管理しており、インフラの運用やスケーリングを手動で行う必要がありません。AWS が自動的にバックアップ、スケーリング、パッチ適用を行います。 - スケーラブルで高可用性
リクエスト数やデータサイズが増加しても、DynamoDB は自動でスケールアウトし、常に高い可用性を維持します。テーブルは複数のアベイラビリティゾーンにレプリケートされ、耐障害性も高いです。 - パフォーマンス
DynamoDB はミリ秒単位の低レイテンシを実現しており、数千のリクエストに迅速に応答します。アクセスパターンに応じてプロビジョンドスループットを設定するか、自動スケーリングを利用することができます。 - セキュリティとアクセス制御
DynamoDB はデータを自動的に暗号化し、IAMを利用してアクセスを厳密に制御します。監査ログやトラフィック制御も可能です。 - トランザクションサポート
複数の項目に対する一貫した読み書き操作をサポートしており、ACID (Atomicity, Consistency, Isolation, Durability) トランザクションを提供します。
サーバーレスアプリケーションモデル
Amazon DynamoDBは、サーバーレスアプリケーションのバックエンドデータベースとして広く利用されています。
- メリット
- 自動スケーリング
DynamoDBは、トラフィックに応じて自動的にスケールし、常に最適なパフォーマンスを提供します。 - ゼロインフラ管理
サーバーレスアプリケーションでは、サーバーの管理が不要で、インフラストラクチャの設定やメンテナンスに時間を割く必要がありません。 - コスト効率
使用したリソースに対してのみ支払うため、リソースの無駄がありません。
- 自動スケーリング
- 仕組み
セカンダリインデックス(DVA向け)
Amazon DynamoDBのセカンダリインデックスは、一言で言うと「テーブルのデータを別の切り口(キー)で検索できるようにする背表紙(インデックス)」のことです。
DynamoDBは通常、最初に決めた「プライマリキー(主キー)」を使ってデータを高速に検索しますが、実務では「それ以外の項目でも検索したい!」という場面が必ず出てきます。それを解決するのがセカンダリインデックスです。
なぜセカンダリインデックスが必要なのか?(具体例)
例えば、以下のような「ユーザー管理テーブル」があるとします。
- プライマリキー:ユーザーID(一意のID)
- その他のデータ:名前、メールアドレス、登録日
インデックスがない場合
- 「ユーザーID:U101 のデータを取ってきて」
→ プライマリキーを指定しているので、ミリ秒単位で超高速に見つかります。 - 「メールアドレス:example@email.com のユーザーを探して」
→ プライマリキーではないため、DynamoDBはテーブルのデータを上から下まで全件チェック(スキャン)しなければなりません。データ量が何百万件もあると、時間もお金(データ読み込みコスト)も膨大にかかってしまいます。
インデックス(セカンダリインデックス)を作ると?
メールアドレスをセカンダリインデックスに設定すると、AWSの裏側で「メールアドレスを基準に並び替えた、検索用のミニテーブル」が自動で作られます。
これにより、メールアドレスからでもユーザーIDと同じように超高速でデータを検索できるようになります。
2つのセカンダリインデックス:LSI と GSI
DynamoDBには、役割の異なる2種類のセカンダリインデックスがあります。ここが試験や設計で一番重要なポイントです。
| 項目 | LSI(ローカルセカンダリインデックス) | GSI(グローバルセカンダリインデックス) |
|---|---|---|
| 範囲(ローカル/グローバル) | 特定のパーティション内だけで探す | テーブル全体から探す |
| キーの制約 | 親テーブルと同じパーティションキーを使う必要がある(ソートキーだけを変更する) | 親テーブルとは全く違う項目をキーに指定できる |
| 作成できるタイミング | テーブルを作るときだけ(後から追加・削除できない) | テーブルを作った後からでも、いつでも追加・削除できる |
| コスト(キャパシティ) | 親テーブルの割り当て(容量)を共有する | インデックス用に別途コスト(容量)を設定する必要がある |
| 一貫性 | 強力な一貫性のある読み込み(最新データ)が選べる | 結果整合性(わずかに遅れて反映)のみ |
基本は「GSI」を使います。 LSIは制限が多く、後から変更できないため、現在のAWS設計ではほとんどのケースで「GSI」が推奨されます。「どうしても最新のデータを即座にLSI経由で読み込みたい(強い整合性が必要)」という特殊な理由がない限りは、GSIを選べば間違いありません。
セカンダリインデックスを使うときの注意点(落とし穴)
非常に便利な機能ですが、使いすぎると痛い目を見る注意点があります。
- 書き込みコストが倍になる
親テーブルにデータを1件追加すると、セカンダリインデックス(裏側のミニテーブル)にも自動でデータが書き込まれます。インデックスを増やしすぎると、その分書き込みの料金(WCU)が余計にかかるようになります。 - 「射影(Projection)」を意識する
インデックスを作る際、元のテーブルから「どの項目をインデックス側にコピーして持っていくか」を選べます(これを射影と言います)。 すべての項目をコピー(ALL)すると検索は楽ですが、保存容量と転送量がかさみます。必要な項目だけを絞る(KEYS_ONLY や INCLUDE)ことで、コストを抑えることができます。
ユースケース
Amazon DynamoDBの代表的なユースケースをいくつか紹介します。
- リアルタイムアプリケーション
ゲーム、IoT デバイス、ソーシャルメディアアプリなど、リアルタイムでデータを処理し、迅速なレスポンスが求められるアプリケーションに最適です。 - モバイルバックエンド
ユーザープロファイル、セッション管理、プッシュ通知の保存に適しており、スケーラブルなモバイルアプリケーションのバックエンドとして利用されています。 - eコマースプラットフォーム
商品カタログ、注文処理、カート情報など、低レイテンシが求められる eコマースシステムで広く利用されています。 - ログとイベントデータの保存
DynamoDB は大量のログデータやイベントデータを効率的に保存・処理するのに適しており、分析のためのデータストアとして利用できます。
まとめ

Amazon DynamoDB は、スケーラビリティ、可用性、パフォーマンスに優れたフルマネージド型の NoSQL データベースサービスです。高速なデータ処理が求められる大規模なアプリケーションに最適であり、リアルタイム処理、モバイルバックエンド、eコマースなど、さまざまなユースケースに対応します。DynamoDB は、AWS 認定試験においても重要なサービスの一つとして取り上げられることが多いため、基本的な仕組みや特徴をしっかりと理解しておくことが重要です。
次回の記事では、「Amazon Neptune」について詳しく解説します。
参考
・Amazon DynamoDB How it works(PDF/AWS Black Belt Online Seminar)
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-DynamoDB-How-it-works_1231_v1.pdf
【AWS認定試験対策 サービス一覧】

【AWS各サービス概要一覧】
【おすすめのUdemy講座】
- 【ベストセラー完全日本語化】AWS 認定ソリューションアーキテクト アソシエイト SAA-C03 対応 2023 最新版

- 【SAA-C03版】AWS認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問)

【おすすめの参考書】

リンク先からご購入いただき、サイト運営をご支援いただけますと幸いです…



コメント