Amazon DynamoDB

解決する課題

• アクセスが急増しても落ちない/遅くならないDBが欲しい
• DBの容量計画・シャーディングを自分でやりたくない
• ミリ秒の応答を安定して出したい

主要概念と用語

• テーブル / 項目（Item）/ 属性（Attribute）
• パーティションキー（PK）: データの分散先を決める最重要キー
• ソートキー（SK）: 同一PG内の並び/範囲検索
• GSI / LSI: 別の属性で検索するためのインデックス
• 容量モード: オンデマンド / プロビジョンド
• DynamoDB Streams: 変更をイベントとして流す（Lambda連携）
• TTL / DAX: 自動失効 / マイクロ秒キャッシュ

仕様・制限・クォータ

• 1項目最大400KB
• 結果整合性（デフォルト）と強い整合性を選べる
• マルチAZへ自動複製、グローバルテーブルで多リージョン化

内部の仕組み

DynamoDBはPKをハッシュして内部パーティションへ分散します。アクセスが増えると自動でパーティションを分割しスケール。ゆえにPK設計＝性能設計で、特定キーに偏るとホットパーティションで詰まります。

設計パターン / ベストプラクティス

• アクセスパターンを列挙 → PK/SK と GSI を設計
• スパイクが読めないなら オンデマンド 容量
• 変更駆動の処理は Streams → Lambda
• 読み取りが激しいなら DAX でキャッシュ

運用・監視・トラブルシュート

• メトリクス: ConsumedRead/WriteCapacity ThrottledRequests
• スロットルはホットパーティション or 容量不足を疑う
• 大量読み取りの Scan は避け、Query で絞る

コスト

• 読み書きキャパシティ（オンデマンド/プロビジョンド）＋ストレージ
• 定常負荷はプロビジョンド＋Auto Scalingが安いことも

セキュリティ

• 保存時暗号化はデフォルト（KMS）
• IAMで項目/属性レベルまで条件付与可能
• VPCからはゲートウェイ型VPCエンドポイントで到達

Well-Architected の観点

• パフォーマンス効率: 一桁ミリ秒・自動スケール
• 信頼性: マルチAZ複製・グローバルテーブル
• コスト最適化: 容量モードの使い分け

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# オンデマンド課金でテーブル作成（PK=userId, SK=createdAt）
aws dynamodb create-table \
  --table-name Orders \
  --attribute-definitions AttributeName=userId,AttributeType=S AttributeName=createdAt,AttributeType=S \
  --key-schema AttributeName=userId,KeyType=HASH AttributeName=createdAt,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST

# 1ユーザーの注文を範囲検索（Scanではなく Query）
aws dynamodb query --table-name Orders \
  --key-condition-expression "userId = :u" \
  --expression-attribute-values '{":u":{"S":"user-123"}}'