AWS ソリューションアーキテクト – アソシエイト学習サイト CP 学習サイトへ戻る

Amazon DynamoDB

Amazon DynamoDB は、サーバーの管理がいらない NoSQL（SQL の表形式にしばられないデータベース）のサービスです。SAA では「RDS と DynamoDB のどちらを選ぶか」「キャパシティ（読み書きの処理量）をどう決めるか」「DAX・グローバルテーブル・TTL などの機能をどの要件で使うか」がよく問われます。

ひとことで言うと: キーを指定して 1 件ずつ読み書きするのがとても速く、アクセスが増えても自動で広がるサーバーレスのデータベースです。

たとえるなら、ロッカー番号（キー）さえ分かれば一瞬で荷物を出し入れできる巨大なコインロッカーです。「中身が赤い荷物を全部探す」ような探し方は苦手です。

このページで押さえる論点

DynamoDB の基本

DynamoDB のデータはテーブルに入り、1 件分のデータを項目（アイテム）、項目の中の 1 つ 1 つの値を属性と呼びます。RDS の「行」と「列」に近いものです。ただし、主キー以外の属性は事前に決めておく必要がなく（スキーマレス）、項目ごとに違う属性を持てます。

項目を区別するのが主キーで、次の 2 通りがあります。

主キーの種類しくみ例
パーティションキーのみ1 つの属性で項目を決める。値から保存先のパーティション（データの置き場所）が計算されるユーザー ID
パーティションキー＋ソートキー（複合主キー）同じパーティションキーの項目を、ソートキーの順に並べて近くに保存する。2 つの組み合わせで一意になる顧客 ID＋注文日時

1 つの項目の最大サイズは 400 KB（属性名と値の合計）です。画像や動画のような大きなデータは S3 に保存し、DynamoDB には S3 のキー（保存場所）だけを入れる設計が定番です。

アクセスが 1 つのパーティションキーの値に集中すると、その置き場所だけが混み合います（ホットパーティション）。ユーザー ID のように値の種類が多く、アクセスが散らばるキーを選ぶのが基本です。

RDS との使い分け

DynamoDB は、決まったキーでの読み書きを大量にさばくのが得意です。一方で、複数のテーブルを JOIN（結合）する集計や、条件を自由に組み合わせる検索は苦手です。試験では「どんな問い合わせをするか（アクセスパターン）」から選びます。

観点Amazon RDS / AuroraAmazon DynamoDB
データの形表（行と列）。スキーマを先に決めるキーバリュー・ドキュメント。主キー以外は自由
得意な問い合わせSQL・JOIN・複雑な条件の検索や集計キーを指定した読み書き（1 桁ミリ秒）
スケールの仕方インスタンスのサイズを上げる・リードレプリカを足す自動でパーティションを増やし、横に広がる
管理するものインスタンスのサイズ・台数、メンテナンスの時間帯サーバーはなし。キャパシティモードを選ぶだけ
向く場面業務システム、既存のリレーショナル DB の移行セッション情報、ゲームのスコア、IoT のデータ、ショッピングカート、急にアクセスが増えるアプリ

キャパシティモードと RCU・WCU

DynamoDB は、読み書きの処理量（スループット）の決め方を 2 つのモードから選びます。

モードしくみ向く場面
オンデマンド処理量を決めずに使い、リクエストの分だけ支払う。アクセスに合わせて自動でスケール。AWS はほとんどのワークロードの既定の選択肢として推奨アクセス量が予測できない、急に増える、新しいアプリ
プロビジョンド1 秒あたりの読み取り・書き込みの量を先に決め、使った量ではなく確保した量に支払う。Auto Scaling で自動調整もできるアクセス量が安定していて予測できる。コストを見通したい

プロビジョンドモードの Auto Scaling は、消費量が目標使用率（推奨 70%）を超える状態が 2 分続くと容量を増やします。急なスパイクには間に合わないことがあるので、「予測できない急増」にはオンデマンドが向きます。モードの切り替えは、プロビジョンド → オンデマンドが 24 時間で 4 回まで、オンデマンド → プロビジョンドはいつでもできます。

プロビジョンドモードでは、処理量をRCU（読み込みキャパシティユニット）と WCU（書き込みキャパシティユニット）で指定します。計算問題が出るので、単位のサイズを覚えます。

操作1 単位で処理できる量
強い整合性の読み取り1 RCU で、4 KB までの項目を 1 秒に 1 回
結果整合性の読み取り1 RCU で、4 KB までの項目を 1 秒に 2 回（強い整合性の半分の RCU）
トランザクションの読み取り4 KB までの項目を 1 秒に 1 回読むのに 2 RCU
書き込み1 WCU で、1 KB までの項目を 1 秒に 1 回
トランザクションの書き込み1 KB までの項目を 1 秒に 1 回書くのに 2 WCU

項目のサイズは、読み取りは 4 KB 単位、書き込みは 1 KB 単位で切り上げます。たとえば 6 KB の項目を強い整合性で毎秒 10 回読むと、6 KB → 4 KB 単位で 2 つ分なので 2 × 10 = 20 RCU です。同じ項目を毎秒 10 回書くと、1 KB 単位で 6 つ分なので 6 × 10 = 60 WCU です。

操作できるシミュレーター

RCU・WCU を計算してみる

項目のサイズと 1 秒あたりの回数を変えて、必要な RCU・WCU がどう変わるかを確かめましょう。四角 1 つが「1 回の操作に必要な単位」です。

読み取り 1 回（4 KB 単位） 書き込み 1 回（1 KB 単位）
読み取りの種類

※簡略化しています: プロビジョンドモードの単位の計算だけを示しています。オンデマンドモードの料金（リクエスト単位の課金）、GSI が別に消費するキャパシティ、Query・Scan で複数の項目をまとめて読む場合の計算は含めていません。

読み取りの整合性とトランザクション

DynamoDB のデータは 1 つのリージョンの中の複数の AZ に自動でコピーされます。コピーには少し時間がかかるため、読み取り方を 2 つから選べます。

トランザクションを使うと、複数の項目（別のテーブルでもよい）への書き込みを「全部成功するか、全部取り消すか」のどちらかにできます。在庫を減らして注文を登録する、のように途中で止まると困る処理に使います。1 回のトランザクションで扱えるのは最大 100 のアクションで、同じリージョンの中だけで有効です。キャパシティは通常の 2 倍かかります。

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

DynamoDB は主キーで検索するのが基本です。主キー以外の属性で効率よく探したいときは、セカンダリインデックス（別のキーで並べ直した索引）を作ります。インデックスがないと、テーブル全体を読む Scan になり、遅くキャパシティも多く消費します。

項目グローバルセカンダリインデックス（GSI）ローカルセカンダリインデックス（LSI）
キーパーティションキーもソートキーも、テーブルと別の属性にできるパーティションキーはテーブルと同じ。ソートキーだけ別の属性
作れるタイミングテーブル作成後にも追加・削除できるテーブル作成時だけ。後から追加・削除できない
読み取りの整合性結果整合性のみ結果整合性か強い整合性を選べる
キャパシティテーブルとは別に持つテーブルのキャパシティを共有する
作れる数既定のクォータで 1 テーブルあたり 20 個1 テーブルあたり最大 5 個

キャッシュ: DynamoDB Accelerator（DAX）

DAX は DynamoDB 専用のインメモリキャッシュです。DynamoDB の応答は 1 桁ミリ秒ですが、DAX を通すと結果整合性の読み取りをマイクロ秒単位で返せます。DynamoDB と API の互換性があるので、アプリの変更は DAX のクライアントに差し替える程度で済みます。

リージョンをまたぐ構成: グローバルテーブル

グローバルテーブルは、DynamoDB のテーブルを複数のリージョンに自動でコピーする機能です。どのリージョンのレプリカでも読み書きの両方ができる（マルチアクティブ）ので、世界中の利用者が近いリージョンで速く書き込めます。1 つのリージョンが使えなくなっても、ほかのリージョンで処理を続けられます。

TTL と DynamoDB Streams

TTL（Time to Live）は、項目ごとに有効期限を持たせ、期限が過ぎた項目を自動で削除する機能です。期限は UNIX 時間（1970 年からの秒数）の数値で属性に入れます。削除は期限切れから通常数日以内に行われ、WCU を消費しません。セッション情報や一時的なデータを追加の費用なしに片付けたいときに使います。期限切れで削除前の項目が読み取り結果に含まれることがあるので、必要ならフィルターで除きます。

DynamoDB Streams は、項目の追加・更新・削除を順番どおりに記録する機能です。記録は 24 時間保持され、同じ項目への変更は起きた順に並びます。Lambda のトリガーにして「注文が入ったら確認メールを送る」「変更を別のシステムに反映する」といったイベント駆動の処理を作れます。グローバルテーブルのコピーにも使われています。

バックアップと復元

方法しくみ使いどころ
ポイントインタイムリカバリ（PITR）有効にすると継続的にバックアップし、復元期間（1〜35 日で設定、既定 35 日）の任意の時点に秒単位で戻せる誤った書き込み・削除からの復旧
オンデマンドバックアップ好きなタイミングでテーブル全体を丸ごとバックアップ長期保管、リリース前の保存（AWS Backup で管理もできる）

RDS と同じく、復元すると新しいテーブルが作られます。PITR の復元先は別のリージョンにもできます。

セキュリティとコスト

問題文のキーワード → 選ぶべき答え

問題文の言い回し答えと理由
「キーバリュー」「スキーマが柔軟」「1 桁ミリ秒」「サーバーレスな DB」DynamoDB。サーバー管理なしで自動的にスケールする
「アクセス量が予測できない」「急にスパイクする」オンデマンドモード。事前の容量設定なしで使った分だけ支払う
「アクセス量が安定」「コストを予測したい」プロビジョンドモード（＋Auto Scaling）
「マイクロ秒の応答」「同じ項目への読み取りが集中」DAX。DynamoDB 専用のインメモリキャッシュ
「複数リージョンで読み書き」「世界中で低遅延の書き込み」グローバルテーブル。マルチアクティブのレプリカ
「期限切れのデータを自動で削除」「追加コストなし」TTL。削除に WCU を消費しない
「項目の変更をきっかけに処理を実行」DynamoDB Streams ＋ Lambda
「誤って書き換えたデータを数分前の状態に戻す」ポイントインタイムリカバリ。新しいテーブルとして復元
「主キー以外の属性で検索したい」「テーブル作成後に追加」GSI（LSI はテーブル作成時のみ）
「400 KB を超えるデータ（画像など）」S3 に保存し、DynamoDB には S3 のキーを保存
「プライベートサブネットから DynamoDB へ、NAT を使わず接続」ゲートウェイ型の VPC エンドポイント
「複数の項目をまとめて、全部成功か全部失敗かにしたい」DynamoDB トランザクション（キャパシティは 2 倍）

引っかけポイント

まとめ: SAA 試験で押さえるポイント

確認問題

参考リンク

AWS 公式ドキュメント（外部サイトが開きます）。