Amazon DynamoDB

は、任意の規模で一貫した低遅延性能を提供する、でフルマネージドな分散データベースです。

SAA では、キー値・ドキュメント型データ、水平スケール、、のアクティブ／アクティブ構成で選びます。

概要

テーブル、項目、属性でデータを管理し、で分散します。サーバー、、パッチ、レプリカを利用者が管理せず、高可用なデータ層を構築できます。

主要技術

①プライマリキーと分散 ⚠️ 頻出

キー	構成	判断ポイント
	1属性	値を十分に分散させます。
複合キー	パーティション + ソート	同じグループ内を範囲検索できます。

偏ったキーは一部パーティションへ負荷を集中させるため、高カーディナリティなキーを設計します。

②キャパシティモード

は変動が大きく予測困難な負荷、プロビジョンドは予測可能な負荷に向きます。プロビジョンドではを利用できます。

プロビジョンドの容量は、1 RCUが4KBまでの項目の強い整合性の読み取り1回/秒（結果整合性なら2回/秒、トランザクション読み取りは1回に2 RCU）、1 WCUが1KBまでの項目の書き込み1回/秒です。項目サイズは単位ごとに切り上げて計算します。

1つのパーティションが処理できるのは、毎秒3,000読み取りユニットと1,000書き込みユニットまでです。日付のような値をにすると書き込みが1つのキーへ集中し、テーブル全体の容量に余裕があってもが起きます。この上限はオンデマンドでも同じなので、高カーディナリティの属性をキーにするか、キーにサフィックスを付けて書き込みを複数のキーへ分ける書き込みシャーディングで直します。

費用の面では、オンデマンドは処理した読み書きのリクエスト数で課金され、アクセスのない時間は読み書きの料金がかかりません。プロビジョンドは設定した容量に対して時間単位で課金されるため、負荷が予測でき、設定した容量を高い使用率で使い続けられるときに安くなります。Auto Scalingは使用率を見て設定容量を調整しますが、変更が反映されるまで時間がかかるため、急な跳ね上がりには追いつかずスロットリングが起きることがあります。

プロビジョンドでStandardテーブルクラスのテーブルには、読み書きの容量を1年（一部のでは3年）の期間で予約するリザーブドキャパシティーを100単位から購入でき、割引を受けられます。オンデマンドのテーブルとStandard-のテーブルには使えません。

テーブルクラスとTTL

テーブルクラス	料金の特徴	向いているテーブル
Standard（既定）	読み書きの料金が安い	読み書きの費用が中心のテーブル
Standard-IA	保存の料金が安く、読み書きの料金が高い	保存の費用が大半を占めるテーブル（古い注文履歴、ログなど）

Standard-IAはStandardと同じ性能、、可用性で、もも変わらないため、アプリケーションを変えずに切り替えられます。テーブルクラスの変更は、直近30日間で2回までです。

（Time to Live）は、項目ごとに持たせた有効期限の属性を見て、期限を過ぎた項目を自動で削除する機能です。削除は期限後の数日以内に行われ、書き込み容量を消費しません。保持期間を過ぎたデータを消すためにScanと削除を繰り返す処理より、安く運用の手間もかかりません。

③整合性、バックアップ、ストリーム

結果整合性または強い整合性の読み取りを選びます。ポイントインタイムリカバリとバックアップで復旧し、 Streamsで項目変更をなどへ配信します。ポイントインタイムリカバリを有効にすると、1〜35日で設定した保持期間内の任意の時点の状態を秒単位で指定し、新しいテーブルとして復元できます。ポイントインタイムリカバリを有効にしたテーブルを削除すると、削除直前の状態のシステムバックアップが自動で作られ、35日間残ります。削除そのものを防ぎたい場合は、テーブルの削除保護を有効にすると、保護を外すまで削除の操作が拒否されます。誤った一括更新のようにデータそのものが壊れた場合、のレプリカにも同じ変更が伝わるため、複製ではなくポイントインタイムリカバリで戻します。

ポイントインタイムリカバリ () は、1〜35日の復旧期間の任意の時点へ、新しいテーブルとして復元します。PITRを有効にしたテーブルを削除すると、削除直前の状態のシステムバックアップが自動で作られ、35日間保持されます。削除そのものを防ぐには、テーブルの削除保護を有効にします。削除保護が有効なテーブルは、で削除を許可された利用者でも削除できません。

DynamoDB Streamsは項目の変更を時系列のレコードとして記録し、Lambdaのトリガーにできます。アプリケーションのコードを変えずに、書き込みを契機とした後続処理を足せるのが利点です。後続処理の宛先が複数ある場合は、Lambdaから1つのトピックへ発行して各受信者にサブスクライブさせると、宛先が増えてもコードを変えずに済みます。

条件付き書き込みは、指定した条件を満たすときだけ書き込む機能で、同時更新の制御に使います。変更を他システムへ知らせる仕組みではないため、通知の配信手段として選ばないようにします。書き込み処理の中で同期的に通知まで行う構成は、書き込みの遅延と失敗の影響範囲を広げます。

本番テーブルへの読み取り負荷を増やさず大規模なバッチ分析を行う場合は、ポイントインタイムでテーブルデータをへエクスポートし、、、などから分析します。分析処理がテーブルを直接 Scan しないため、オンライン処理のキャパシティーとを分離できます。エクスポートはポイントインタイムリカバリの有効化が前提で、読み取りキャパシティーを消費しません。前回からの差分だけを出す増分エクスポートもあります。

読み取りをさらに高速化する場合は、（DAX）をテーブルの前段に置きます。DAXはDynamoDB と互換ので、アプリケーションの呼び出し方を変えずにキャッシュを挟めるのが特徴です。ただし対象はDynamoDBのテーブルに限られ、やなどのの前段には置けません。リレーショナルデータベースの読み取り負荷を下げるなら、やを検討します。DAXがキャッシュから返すのは結果整合性の読み取りで、強い整合性の読み取りはキャッシュせずDynamoDBへそのまま渡します。書き込みはDynamoDBへ書いてからキャッシュも更新するライトスルーのため、書き込みの多い処理は速くなりません。

キャッシュしたい相手	選ぶ仕組み	判断ポイント
DynamoDBのテーブル	DAX	同じAPIのまま前段に置けます。
RDS / Auroraの読み取り	リードレプリカ、ElastiCache	DAXは使えません。
で配信する静的コンテンツ		エッジでキャッシュします。

④グローバルテーブル

複数へマルチアクティブに複製し、各リージョンで読み書きできます。競合、アプリケーション経路、サービスも含めてを設計します。

試験対策

要件	選ぶ機能

でローカル読み書き
変更イベントを処理	Streams +
DynamoDBの読み取りをマイクロ秒級へ
本番負荷と分離してバッチ分析	へエクスポートして／／で処理
リレーショナル結合が必要	／

DynamoDBはJOIN中心の設計ではなく、アクセスパターンからキーとインデックスを先に設計します。