AWSサービス解説
Amazon DynamoDBとは？NoSQLを初心者向けに解説
DynamoDBの基本、テーブル、パーティションキー、オンデマンド課金、Lambda連携を初心者向けに整理します。
Amazon DynamoDBは、AWSのマネージドNoSQLデータベースです。サーバーレス構成と相性が良く、Lambdaから使いやすいサービスです。
結論
DynamoDBは、キーを使って高速にデータを読み書きするNoSQLデータベースです。複雑なSQL結合より、決まったアクセスパターンに沿った設計が重要です。
NoSQLとは
NoSQLは、リレーショナルデータベースとは異なるデータモデルを使うデータベースの総称です。DynamoDBでは、テーブルにアイテムを保存し、キーを使って取得します。
SQLのように自由にJOINする設計ではなく、「どのキーで保存し、どのキーで取得するか」を先に考えます。
パーティションキー
DynamoDBの基本はパーティションキーです。テーブル内のアイテムを分散・取得するためのキーになります。
問い合わせテーブルなら、contactIdをパーティションキーにする設計が考えられます。ユーザー別学習履歴なら、userIdをパーティションキーにする設計が候補になります。
オンデマンド課金
DynamoDBにはオンデマンドキャパシティがあります。アクセス数が少ない個人MVPでは始めやすい選択肢です。
ただし、大量アクセスやScan多用ではコストが増えます。AWS BudgetsとCloudWatch Metricsで監視します。
このプロジェクトでの使い方
このサイトでは、問い合わせフォームから送信された名前、メール、件名、本文をDynamoDBに保存します。MVPでは問い合わせだけを動的データとして扱い、記事や問題は静的ファイルで管理します。
試験で問われるポイント
- DynamoDBはマネージドNoSQLデータベース
- サーバーレス構成と相性が良い
- パーティションキー設計が重要
- 大量アクセスに強い設計ができる
- RDSとはデータモデルが違う
DynamoDBを選ぶ前に考えること
DynamoDBは、キーと値を中心に扱うマネージドなNoSQLデータベースで、属性を持つドキュメント形式のアイテムも保存できます。Amazon DynamoDB とはを読むと、サーバー運用を意識せずに利用できる一方で、アクセス方法を先に設計する重要性が分かります。
「データをどの画面で、どの条件で、どの順番に読むか」を列挙してからテーブルを設計します。SQLのJOINで後から柔軟に組み立てる発想ではなく、よく使う検索をキーで効率よく行える形に寄せるのがDynamoDBの基本です。
パーティションキーとソートキー
パーティションキーはアイテムを配置・取得する中心となる値です。同じパーティションキーを持つ複数のアイテムを、順序を付けて扱いたい場合にはソートキーを組み合わせます。たとえば学習履歴ならuserIdをパーティションキー、学習日時をソートキーにして、特定ユーザーの履歴を時系列で読む形が考えられます。
問い合わせ保存なら一意のcontactIdを主キーにするだけでも書き込みはできます。しかし「未対応の問い合わせを新しい順に一覧する」といった運用画面が必要なら、その読み方もあらかじめ設計対象です。DynamoDB のコアコンポーネントを参照し、テーブル、項目、主キーの関係を確かめてください。
アクセスパターンから逆算する
まず「IDで1件取得する」「ユーザーごとの履歴を期間で読む」「状態別に管理画面へ表示する」のようにクエリを文章で書きます。次に、その条件がパーティションキーとソートキーで取得できるかを確認します。この手順を飛ばしてデータを保存してから一覧機能を考えると、Scanに頼る構成になりやすく、性能と費用の見通しを失います。
二次インデックスは、主キーとは別のアクセスパターンを支える選択肢です。ただしインデックスを増やすこと自体が目的ではありません。書き込み時にどの属性が必要か、いつ更新されるか、一覧の並び順は何かを整理してから採用します。
Lambdaから問い合わせを保存する流れ
フォームがAPI GatewayへPOSTし、Lambdaが入力を検証してDynamoDBへPutItem相当の書き込みを行う構成は、小さなサーバーレスAPIの典型です。Lambdaの実行ロールには、対象テーブルに必要な最小限の権限だけを付与します。フォーム本文やメールアドレスをログへそのまま出さず、失敗時にも個人情報を返さないことが大切です。
保存に成功したかどうかをHTTPレスポンスで返すまでがAPIの責務です。重複送信、タイムアウト後の再送、入力不正をどう扱うかも先に決めます。データ設計とAPI設計を分けずに考えることで、必要なキーと検証が見えます。
RDSとの境界
複数テーブルをJOINし、複雑な検索やトランザクションをSQLで表現したいならRDSが適することがあります。DynamoDBは固定的なアクセスパターンで高いスケールを求める用途と相性があります。「NoSQLはRDSより優れている」「RDSは古い」といった比較ではなく、データの関係、クエリ、運用の得意分野で選びます。
DynamoDBとRDSの違いとRDSとDynamoDBの選び方を読むと、サービス名から選ばず要件から選ぶ感覚を身に付けられます。
整合性、キャパシティ、費用の注意
読み取りの整合性には選択肢があり、直後の更新を必ず読める前提にするのか、通常の読み取りでよいのかを用途ごとに考えます。またオンデマンドとプロビジョニングは、アクセスの予測可能性や運用方針に応じて選びます。どちらかが常に安いとは断定できないため、現在の料金と利用状況を確認してください。
大量のScan、偏ったキーへのアクセス、想定外のインデックス追加は、性能とコストの注意点です。CloudWatchのメトリクス、アプリケーションのアクセスログ、請求の傾向を合わせて観察し、アクセスパターンを改善します。
試験で混同しやすい点
DynamoDBはSQLを実行するRDSではなく、キーによる取得を前提にしたNoSQLです。パーティションキーを適当に決めるのではなく、アクセスパターンと分散を考えます。またDynamoDBを使えば全ての検索が高速になるわけではなく、キーに合わない全件走査は別の問題を生みます。
設問に「サーバーレス」「予測しにくいアクセス」「キーによる低レイテンシな取得」があれば候補になります。「複雑なJOIN」「既存SQL資産」「多表の関係」が中心ならRDSを含めて考えます。
よくある失敗と次の一歩
最初にテーブルを作ってから使い道を探す、一覧画面をScanで作る、本文から渡された利用者IDを認可に使う、全権限のIAMロールをLambdaへ付ける、といった失敗を避けます。まずは一つの問い合わせを安全に保存し、IDで再取得する小さな流れを作るのがおすすめです。
その後、必要な一覧のクエリを増やし、主キーか二次インデックスで読めるかを都度確認します。実際のアクセスパターンを文章とテストデータで残すと、設計の理由を将来の自分にも説明できます。
設計メモに残すべき情報
テーブル名や属性名だけでは、DynamoDBの設計意図は伝わりません。各アクセスパターンについて、呼び出し元、入力条件、返す件数、並び順、主キーまたはインデックス、想定される例外を残します。たとえば「管理者が未対応の問い合わせを新しい順に見る」という要件なら、誰が管理者か、状態がいつ変わるか、ページングが必要かまで確認します。
同じアイテムへ複数の用途を詰め込む場合は、属性名の衝突や更新の責務も整理します。単一テーブル設計は目的ではなく、アクセスパターンを満たす選択肢です。初学者のうちは、まず分かりやすいテーブルで一つの読み書きを完成させ、実測と要件に基づいて複雑さを増やすほうが判断しやすいです。
障害時の扱いを決める
書き込みに失敗したとき、利用者へ再送を促すのか、内部で再試行するのか、運用者へ通知するのかを決めます。タイムアウトしたリクエストは、実際には保存が成功している可能性もあります。再送に備えた一意なIDや冪等性を考えると、同じ問い合わせが複数件できる事故を減らせます。
バックアップや復旧についても、単に有効化したかではなく、どの時点へ戻す必要があるかを考えます。データモデルを変更するときは、古いアイテムが混在する前提で読み取り側の互換性を確認します。NoSQLはスキーマが自由に見えても、アプリケーションとの契約がなくなるわけではありません。
小さな検証から始める
コンソールで一件だけ登録して終わりにせず、アプリが実際に使うキーで複数件を書き込み、必要な順番で取得できるかを試します。空の結果、同じID、状態変更、削除後の表示も確認します。アクセスパターンに沿ったテストを行うことで、キー設計の誤りを早く見つけられます。
利用量が増えた後にしか分からない点もありますが、最初から計測する場所を決めておけば改善できます。アクセス数、遅延、エラー、Scanの利用を観察し、想定と違うクエリが増えたらデータモデルを見直します。
試験対策では、DynamoDBを選んだ理由を「NoSQLだから」だけで終わらせません。キーで取得するアクセスパターン、サーバーレスサービスとの連携、運用するサーバーを持たない点を問題文の要件と結び付けます。反対に、複雑な集計や結合が必要な場面では、無理に一つのNoSQLテーブルへ押し込まず、RDSなど別の選択肢へ戻る判断も必要です。
データを保存する前に、主キーに空文字列や利用者が自由に決めた値を許すかを検討します。一意性のないキーは上書きや偏ったアクセスの原因になります。日時をソートキーに使うときも、同じ時刻の扱い、タイムゾーン、表示順を決めます。識別子の生成方法と更新ルールをAPIの契約に含めることで、後からデータを追跡しやすくなります。
管理画面用の検索を追加するときは、テーブル全体を読む処理が増えていないかを確認します。少量データで速く見える画面でも、データが増えれば運用上の問題になります。ページング、取得件数、検索条件を明示し、必要なら別のインデックスや集計用データを設計します。最初の設計を絶対視せず、計測結果で見直す姿勢が重要です。
アクセスパターンを変更する前に、既存データと新しいコードが共存できるかを確認します。新属性がない古いアイテム、途中で失敗した更新、権限のない利用者からの読み取りをテストケースに含めると、データ整合性の見落としを減らせます。
データの保管期間も設計に含めます。問い合わせのような個人情報を必要以上に残さず、削除対象と削除方法を決めることで、運用とセキュリティの両方を改善できます。
設計の変更は、読み取りと書き込みの両方に影響します。利用者が見る画面、管理者が使う画面、バッチ処理の順に影響を確認し、ロールバックが必要な場合の手順も残します。
変更理由を記録すると、将来の改善判断にも使えます。
関連用語
次に読む記事
次に学ぶ内容
ブログ記事だけでなく、AWS用語集・サービス比較・模擬問題・構成図を組み合わせると、資格知識と実装イメージをつなげて理解できます。