[レポート]Amazon DynamoDB Deep Dive #dbts2015 #be_crazy_about_db_tech

こんにちは、城内です。 今回は、先日開催されたdb tech showcase Tokyo 2015のセッションレポートを書きたいと思います。 かなり時間があいてしまいましたが、勉強になる内容でしたのでぜひご覧頂ければと思います。

セッション情報

• セッション名：Amazon DynamoDB Deep Dive
• スピーカー：アマゾン データ サービス ジャパン株式会社 森祐孝氏

スライド

[slideshare id=49711960&doc=dbts-tokyo-2015a33amazon-dynamodbamazondataservicejapan-150623010315-lva1-app6892&w=640&h=480]

セッション内容

DynamoDBの生い立ち

RDBMSのスケールの限界を超えるためDynamoを開発し、それをサービス化したものがDynamoDBである。

DynamoDBの特徴

• フルマネージドなNoSQL
• ハイスケーラブル、低レイテンシー
• 高可用性（3か所のリージョンにデータを分散）
• シンプル、かつパワフルなAPI

ストレージの容量に制限はなく、また運用管理の必要もない。

DynamoDBのアーキテクチャ

table
 └items
  └attributes

• Hash key・・・必須、データの分散を決める時などに使用
• Range Key・・・ハッシュキー検索用、クエリをサポート

インターフェース

• Table API
• Stream API
• SDK（Java、Pythonなど）
• CLI

データタイプ

• Stringなどの基本的なデータ型
• JSON用のデータ型

Hash Table

• Hash keyは単体でプライマリーキーとして利用
• Hash Indexを構築するためのキー
• Hash Keyを使ってデータを分割する

Hash-Range Table

• Hash key+Range keyをプライマリーキーにすることも可能 →Hash Keyに該当するデータの順序を保障するためにRange keyが利用される
• Hash Keyの使用に上限はなし

データの整合性モデル

• Write →2か所に書いた状態で完了
• Read →デフォルトでは結果整合性 →オプションでコンシステントリードあり（強い整合性、3か所の書き込みを強制）

Local Secondary Index

• Range key以外に絞り込み検索を行うkeyを持つことができる
• Hash keyが同一で、他のアイテムからの検索のために利用
• すべての要素の合計値を10GBに制限される

Global Secondary Index

• Hash key属性の代わりとなる
• Hash keyをまたいで検索を行うためのインデックス

※GSIのアップデートは、リクエスト対して非同期で実行される。プロビジョンドスループットを消費するため、十分なスループットが必要になる。

Scaling

• スループット →テーブル単位で読み書きのスループットを事前に指定可能
• サイズ →テーブルに対して任意の数のアイテムを追加可能、ただし、1つのアイテムは400KB以内
• スケーリング →パーティションの数を増やしている

スループット

• ・テーブルレベルによってプロビジョニング →リードキャパシティユニット（RCU）・・・項目のサイズは1KB/秒 →ライトキャパシティユニット（WCU）・・・項目のサイズは4KB/秒、結果整合性であれば2倍
• ・読み込みと書き込みのスループットはそれぞれ独立

パーティショニング

• スループット →RCU/3000+WCU/1000=パーティション数
• ストレージサイズ →テーブルサイズ/10GB=パーティション数
• スループットとストレージサイズの大きい方を採用

※RCUとWCUの値は各パーティションに均一に割り当てられる

DynamoDBの料金体系

• • プロビジョニングされたスループットで決まる時間料金 →RCUとWCUの指定の値で決定
  • ストレージ利用料 →指定のサイズで決定

DynamoDBの設計

スループットを最大限に活用

• Space：キーアクセスはなるべく均等に
• Time：時間アクセスもなるべく均等に

バースト処理

• パーティションごとに過去300秒分までリザーブ
• プロビジョン分を超えた分に利用される →メンテナンスなどの内部処理でも利用される

※超過分はエラーになるので、バーストキャパシティに依存しない作りにすることが大切。

データモデリング

1:1リレーション/キーバリュー型

• Hash keyを使ったテーブル、GSI
• GetItem/BatchGetItem APIを使用

1:Nリレーション/親子関係

• Hash keyとRange keyを使ったテーブル、GSI
• Query APIを使ってアクセス

N:Mリレーション

• テーブルとGSIを使用してHash keyとRange keyをスイッチ
• Query APIを使用

Document(JSON)

• 新データタイプ
• Document SDKsを使用（Java、Javascriptなど）

ユースケース毎のベストプラクティス

イベントログ

ポイント：Hot dataとCold dataは混在させずテーブルを分ける。Cold dataはS3へ。

メッセージアプリ

ポイント：大きいデータを分けて配置する。メッセージテーブルからインボックス/アウトボックステーブルへはGSIを利用。

マルチプレイヤーオンラインゲーム（ソーシャルゲーム）

ポイント：Hash key+Range keyにQuery filterを利用（フィルタされたCUも消費される） →改善策として、複合キーを利用する（複数カラムの情報を文字列連結しておく）

※スパースなインデックスの利用も推奨

リアルタイム投票・集計・分析システム

ポイント：スケールによるボトルネックはシャーディングで対応。 →投票テーブルと投票集計テーブルで片側に障害が発生した場合はStreamで対応する

DynamoDB Stream

概要

• テーブルのすべての更新情報を保持
• シリアライズなデータ（順序を確保）
• 直近24時間分のデータが保存
• テーブルが削除されてもStreamへのアクセスは可能
• アイテムごとの厳密な管理
• 高耐久性
• 非同期に更新（1秒未満の遅延の書き込み）

※まだPreview中で、かつTokyoリージョンでは使用不可（6/12現在）

機能

• View Type：Old Imange、New Image、両方、Keys Only
• StreamからKinesis Client Libraryアプリケーションによる取り出しが可能（Java、Pythonなど）
• Cross-Region Replication Library（OSSのライブラリ）を使用することで海外のDynamoDBへバックアップが可能
• Lambdaと連携することが可能

DynamoDBのユースケース

• Webアプリのセッション管理やユーザ情報を格納するデータベース
• 広告やゲーム等のユーザ行動履歴のデータベース
• ソーシャルアプリのバックエンド（モバイルアプリからの2Tier）
• バッチ処理のロック管理
• フラッシュマーケティング
• ストレージのインデックス

Q&A

• スループットの変更時にもサービスは利用可能か？ →継続して利用可能。リザーブされたキャパシティが使用される。（※下げるのは1日4回まで）
• 好きなAWSサービスは？ →DynamoDBです(笑)。

感想

DynamoDBは、2TierのモバイルアプリやRDSとの併用で、システム構成として頻繁に登場することになってくると思います。皆さんも、次世代のアーキテクチャに向けて、どんどん理解を深めて行きましょう！