Amazon DynamoDB

Amazon DynamoDB Database tech black belt aws

# Amazon DynamoDB

https://d1.awsstatic.com/webinars/jp/pdf/services/20170809_AWS-BlackBelt-DynamoDB.pdf

## history

  • Amazon.com ではかつてRDBMSで処理していた。スケールの限界を迎えDynamo  を開発した。
    • 結果整合性
    • HWを追加するごとに性能が向上するスケーラビリティ
    • シンプルなクエリモデル

 

## Amazon DynamoDB の特徴

  • NoSQL
  • ハイスケーラブル、低レイテンシー
  • シンプル
  • 容量制限がない
  • マネージド
  • 高信頼性・高可用性
    • SPOF の存在しない構成
    • データは3箇所のAZni保存
    • シトレージは必要に応じてパーティショニング
  • プロビジョンドスループット
    • テーブルごとにRead / Write のスルプットキャパシティを割り当て

 

  • 結果整合性モデル
    • Write
      • 少なくとも2つのAZでの書き込み完了が確認取れた時点でAck
    • Read
      • デフォルト
        • 結果整合性
        • 最新の書き込み結果が即時に反映されない可能性あり
      • Consistent Read オプション
        • Read リクエストを受け取る前までのWriteがすべて反映されたレスポンスを保証
        • CUを2倍消費する
  • 料金
    • プロビジョンドスループット
      • キャパシティユニット
    • ストレージ利用料
  • ユースケース
    • KVS
    • 広告、ゲームのユーザ行動履歴DB
    • モバイルアプリ
    • バッチ処理のロック管理

 

## 使い方

  • テーブル設計（Key や Index）
    • プライマリーキー
      • Only Partition key
      • Partation key & Sort key
    • Patition table
      • Partition key は単体でプライマリキーとして利用
      • ハッシュインデックスを構築するためのキー
      • テーブルはパーティショニングされる場合あり
    • Partition-Sort Table
      • Partition + Sort でプライマリーキーとすることもできる
    • Attributes
  • Read / Write のキャパシティユニットの決定
  • DynamoDB Streams の設定を決める

 

  • Scaling
    • スループット
      • テーブル単位でスループットをプロビジョニング
      • テーブルのアイテムは1つあたり400kbが上限
      • LSI は異なるハッシュキーごとに最大10GB
    • パーティショニング
    • Burst Capacity
      • 直近300秒までのキャパシティを貯めておける
  • LSI / GSI
    • Local Secondary Index(LSI)
      • Sort key 以外で絞り込み検索を行うことができる
      • Partition key が同一で中身が違う場合に利用できる
      • 各ハッシュキーごとに最大10GB
      • 特定パーティション内の検索
    • Global Secondary Index(GSI)
      • Partition Key 属性の代わりになる
      • Partition key をまたいで検索が行える
      • 全体検索
      • 更新方法はClient <-> Table の後に非同期でGSIの更新がおこなわれる
    • 注意点
      • スループットやストレージ容量が追加で必要
      • インデックスの数が増えれば増えるほど書き込みコストが上がる
      • セカンダリインデックスに強く依存する設計になっている時は何かがおかしくなっている。（RDBを考える機運）
  • 高度なテーブル操作
    • Consistent Read
      • Capacity Unit を倍消費する
      • 強い一貫性を持ったRead
    • Conditional Write
      • 条件付き書き込み / 更新ができる
    • UpdateItem におけるAttributeへの操作
    • Atomic Counter
  • TTL
    • テーブルの有効期限を作成できる
    • プロビジョニングされたスループットを消費することなく利用可能
    • Background Job としてテーブルのExpiration Time をチェック
    • TTLになったら即削除というわけではない（最大48時間の遅延）
  • Auto Scaling
    • WCU、RCU、GSIに対する設定を管理
    • 自動で容量を拡大、縮小してくれる
    • 設定した上限と下限と目標使用率を満たすように維持してくれる
  • DynamoDB Accelerator(DAX)
    • 高可用性インメモリキャッシュ
      • Item cache
      • Query cache
    • Client -> DAX -> DynamoDB
    • DynamoDB 互換
    • インスタンスサイズとクラスタのノード数で料金が決まる
    • 最大10ノードまで
    • Read, Put, Update, Delete のオペレーションに対応
    • Cache Eviction
      • TTL
      • Least Recently Used
      • Write-through eviction
    • Security
      • VPC subnet
      • IAM
      • AWS CloudTrail
    • ユースケース
      • スパイクに対応
      • Speed up
  • DynamoDB Streams
    • 追加・更新・削除の変更履歴を保持し取り出し可能
    • 過去24時間以内にそのテーブルのデータに対して行われた変更のストリーム全てにアクセス可能。（24時間経過したデータは削除される）
    • 容量は自動で管理
    • 同じハッシュキー内での順番は保証される
    • DynamoDBテーブルのWrite プロビジョニングスループットの最大2倍の速度で DynamoDB Streams から更新を読み取ることが可能
    • 変更は1秒以内で反映される
    • クロスリージョンレプリケーション
    • ユーザの集計・分析・解析のための非同期集計
    • 非同期の通知
  • DynamoDB Streams & Kinesis Client Library
    • Kinesis クライアントライブラリを使用してDynamoDB Streams にアクセス可能
  • DynamoDB Triggers
    • DynamoDB + Lambda
    • 書き込みに応じて値をチェックして、別テーブルに更新やプッシュ通知を行う
    • DynamoDBの更新状況の監査ログをS3にほぞん
    • ゲームデータなどのランキング集計を非同期に実施
  • DynamoDB Cross-region Replication
    • DRとして利用
    • 近いリージョンからの読み取り
    • 読み取り作業負荷の分散（マスタ表のリードキャパシティの節約）
    • CloudFormation でライブラリを利用することも可能

 

## Data Modeling

  • 1:1
    • リレーション or KV 型
    • Partition Key を使ったテーブルまたはGSI
    • GetItem、 BatchGetItem API
  • 1:N
    • リレーション or 親子関係
    • Partition Key と Sort Key を使ったテーブル、GSI
    • Query API
  • N:M
    • リレーション
    • Table と　GSIを使用してPartition key と Sort key の要素をスイッチして設計
    • Query API

 

## ユースケース＆ベストプラクティス

  • イベントログ
    • 直近のデータ(hot data) とCold data でテーブルを分け、CUを変える
  • メッセージアプリ
    • メッセージ本文はアイテムサイズが大きくなりがち。
    • 本文は別のテーブルに格納することで処理を単純化＆RCUを削減
  • 2-Tier アーキテクチャ
    • クライアントから直接AWSサービスを利用する
    • Object Mapper
    • DynamoDB Streams と連携し、SNSからPush 通知をしたり、別のDynamoDB にデータを入れたりできる
  • 性能監視はCloudWatchで
  • データのバックアップ
    • DynamoDB Streams + Cross-region Reprication
      • レプリカをストップして、PITR(静止点)を設ける
    • AWS Data Pipeline を利用
      • テーブルに対してコピー
      • 選択したAttribute のみコピー
      • 選択したAttribute の差分のみコピー
    • Amazon Elastic MapReduce を使ったコピー
  • ローカル開発 & テスト
    • DynamoDB Local

 

## 雑感

先日、社内でDynamoDB のハンズオンがあったので参加した。テーブル設計の基礎知識がなかったので、勘所をつかむ上で非常に有用だった。

DynamoDB はLambda + DynamoDB で利用される印象が強かったが、ビジネス要件や運用要件と照らし合わせるとこういうアーキテクチャになるのは当然といった感じだという印象を受ける。

パフォーマンスチューニングに当たる部分はDynamoの機能やエコシステムを理解しているとパフォーマンスを出しやすくなるかと思う。