どんな場面で検討するか
注文 ID・ユーザー ID 等からの取得や更新が中心で、アクセス増減の大きい API の状態を低運用負荷で保持したい場合。検索条件が明確なキー・ドキュメント型のデータで候補になる。
組織で使う条件
スロットリング、キーの偏り、消費容量、索引ごとの利用を観測する。条件付き更新の失敗とインフラエラーを分けて再試行する。 TTL を厳密な時刻の即時削除とみなさず、アプリの期限判定を設ける。復元は別テーブルへ行い、IAM・TTL・監視・再バックアップ等を改めて設定する。索引・暗号化・接続切替も含めて復旧を試験する。
採用前に試すこと
- 注文 ID・テナント・期間で必要な取得パターンを定義し、キーと索引を作って固定結果を照合する。
- 同じ在庫への同時更新と同一注文の再送を行い、条件付き更新・べき等性・偏った負荷を測定する。
- 検証バックアップを別テーブルへ復元し、読取り照合と切替を確認し、項目サイズ別の消費単位を費用見積りに反映する。
合格と判断する条件
- 日常経路が不要な全件 Scan に依存せず、取得件数と期待注文が一致する。
- 在庫の負値と注文二重確定が 0 件。競合・スロットリングを区別し、再試行後に期待結果へ一致する。
- 復旧点の注文集合と集計が一致し、索引や保存量を含めた容量・料金の根拠を示せる。
見落としたくない点
- 毎回異なる条件の SQL 分析、多数テーブルの JOIN、既存 RDB の構造を無変更で移したい場合は RDS・分析基盤と比較する。 全件 Scan や特定キーへの集中書込みを通常経路にしたまま採用しない。オンデマンドでもキー偏りとクォータに対する設計・観測が必要。
- 毎回異なる条件の SQL 分析、多数テーブルの JOIN、既存 RDB の構造を無変更で移したい場合は RDS・分析基盤と比較する。
- 全件 Scan や特定キーへの集中書込みを通常経路にしたまま採用しない。オンデマンドでもキー偏りとクォータに対する設計・観測が必要。
根拠となる資料
Fast NoSQL Key-Value Database – Amazon DynamoDB
First steps for modeling relational data in DynamoDB
Best practices for designing and using partition keys effectively in DynamoDB
DynamoDB on-demand capacity mode
Using time to live (TTL) in DynamoDB