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

2015.06.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、城内です。 今回は、先日開催された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との併用で、システム構成として頻繁に登場することになってくると思います。皆さんも、次世代のアーキテクチャに向けて、どんどん理解を深めて行きましょう!