Upload
kenta-yasukawa
View
9.569
Download
9
Embed Size (px)
DESCRIPTION
DynamoDBを用いたシステムの設計や開発を行おうとする方に向けて、基本的な機能を紹介しつつ、ソーシャルネットワークサービスやゲームなど、いくつかの典型的なユースケースを取り上げて、それをDynamoDBで実現するとしたらどういったテーブル設計とクエリの仕方が効果的なのかといったTipsや、DynamoDBの各種機能をどう活用していくべきかといったノウハウをご紹介します。
Citation preview
Amazon DynamoDB Deep Dive
アマゾンデータサービスジャパン株式会社シニアソリューションアーキテクト安川 健太
自己紹介
• 安川 健太 (@thenkentiest)
– AWS ソリューションアーキテクト– 担当するお客様の範囲
• スタートアップ• ゲーム・ソーシャルサービス• 時々エンタープライズ
• 略歴– エリクソンリサーチにて M2M や SNS + IoT な感じの技術の研究開発– ユーザとして触った AWS に感銘を受けて AWS ソリューションアーキテク
トに(↑イマココ)
IT インフラストラクチャ
Amazon の 3 つのコアビジネス
セラー向けビジネス
アマゾンのウェブサイト上で販売
自社小売ウェブサイトにAmazon の技術を利用
アマゾンフルフィルメントセンター(物流センター)
の活用
コンシューマ向けビジネス
1 億を超えるアクティブなアカウント
8カ国で展開 :米国 , 英国 , ドイツ , 日
本 , フランス , カナダ , 中国 , イタリア
スケーラビリティ
高可用性
IT インフラストラクチャ
ビジネス2006 年開始
ウェブスケールでのクラウド基盤の提供
190 以上の国において、数十万に及ぶ登録アカウント
クラウドコンピューティングとは?
スケールアップ・ダウンが容易
初期投資が不要 実際の使用分のみ支払い
セルフサービスなインフラ
ビジネススピードの改善
低額な利用価格
Deploy
AWS が提供するデータベースサービス
完全マネージド型で、セットアップ、運用、拡張が容易なリレーショナル・データベースサービスAmazon RDS
Amazon DynamoDB
完全マネージド型で、高速なパフォーマンス、シームレスな拡張性と信頼性を NoSQL サービス
Amazon Redshift
高速で管理も万全なペタバイト規模のデータウェアハウスサービス
Amazon ElastiCache
完全マネージド型で、セットアップ、運用、拡張が用意なキャッシュサービス
AWS が提供するデータベースサービス
完全マネージド型で、セットアップ、運用、拡張が容易なリレーショナル・データベースサービスAmazon RDS
Amazon DynamoDB
完全マネージド型で、高速なパフォーマンス、シームレスな拡張性と信頼性を NoSQL サービス
Amazon Redshift
高速で管理も万全なペタバイト規模のデータウェアハウスサービス
Amazon ElastiCache
完全マネージド型で、セットアップ、運用、拡張が用意なキャッシュサービス
Amazon DynamoDB とは• NoSQL as a Service• 超高速・予測可能な一貫したパフォーマンス• シームレスなスケーラビリティと低コスト
運用管理必要なし
低レイテンシ、 SSD
プロビジョンスループット
無限に使えるストレージ
ADMIN
Amazon DynamoDB の生い立ち
• RDBMS のスケールの限界を超えるため開発されたDynamo が祖先
• 結果整合性モデル採用による可用性向上
• HW を追加する毎に性能が向上するスケーラビリティ
• シンプルなクエリモデルによる予測可能な性能
Amazon DynamoDB の特徴
管理不要で信頼性が高いプロビジョンスループットストレージの容量制限がない
特長1:管理不要で信頼性が高い
• SPOF の存在しない構成• データは 3 箇所の AZ に保存されるので信頼性が高い• ストレージは自動的にパーティショニング・スケール
クライアント
特長2:プロビジョンスループット
• Read と Write 、それぞれに対して必要な分だけのスループットキャパシティをプロビジョンする(割り当てる)ことができる
• 例えば一般的な Read ヘビーな DB なら– Read : 1,000– Write : 100
• ライトヘビーな DB なら– Read : 500– Write : 500
• この値は DB 運用中にオンラインで変更可能– ただし、スケールダウンに関しては日に4回までしかできないので注意
特長3:ストレージの容量制限がない
• 使った分だけの従量課金制のストレージ• データ容量が増えてきたのでディスクを足した
り、ノードを足したりという作業が不要
Amazon DynamoDBの料金体系
• プロビジョンスループットで決まる時間料金– Read/Write それぞれプロビジョンしたスループットによって時間あた
りの料金がきまる– 大規模に利用するのであればリザーブ度による割引もあり
• ストレージ利用量– 保存したデータ容量によって決まる月額利用料金– 計算は GB あたりの単価が適用される 実際の料金については下記を参照
http://aws.amazon.com/jp/dynamodb/pricing/
Amazon DynamoDB を使い始めるには
1. テーブルの Key や Index を決める2. Read/Write それぞれのスループット
を決めるThat’s it, write your code!
ご利用のお客様の一部
AWS の利用 : 世界最大級のスポーツイベント「 Super Bowl 2012」の広告配信で利用
DynamoDB を使用し、秒間 50 万以上の書き込み要求を処理ビジネス効果 :試合当日の急激なトラフィック増加のピークに対応
Amazon DynamoDB を使用し、秒間 50 万以上の書き込み要求に対応
Case Study
web
Web
Web
Web
Web
Web
・・・
Shazam for TVShazamable な広告コン
テンツを配信
利用者はテレビにスマートホンをかざす キャンペーン情報などを配
信Case Study
Amazon DynamoDB に増え続けるチャットデータを確実に保存しつつ、サービスの成長に備える
AWS の利用 : 2012 年のサービスの開始時から EC2上にシステムを構築
ビジネス効果 :Amazon DynamoDB の導入で増え続けるデータの心配や、バックアップやメンテナンスを考慮する必要がなくなった
課題 :MySQL と Redis では増え続ける思い出のデータを保持しながらのサービス成長が難しい
Case Study
Redisから Amazon DynamoDBへ
EC2
Redis
タイムスタンプでの検索が主用途だったので Range キーを用いた検索で置き換えRedis は高機能だがデータ保
存容量の単価は高い
Case Study http://timers-tech.hatenablog.com/entry/2013/10/31/232027
Amazon DynamoDB の基礎知識
テーブル設計のための基礎知識 (1/2)
• Table– いわゆるテーブル– プライマリキーの持ち方が2つ
• Hash key をプライマリキー• Hash key と Range key の複合キーをプライマリキー
• Hash key– 順序を指定しないハッシュインデックスを構築するためのキー– 単体でプライマリキーとして利用されることがある
• Range key– Hash key に該当する複数のデータの順序を保証するためのキー– Hash + Range でプライマリキーとすることもできる
テーブル設計のための基礎知識 (2/2)
• Item– RDB で言ういわゆるレコード– 1 つ以上の Attribute を持つ
• Attributes– データの中身。RDB で言うカラム。– Hash key, Range key に該当する Attributes 以外は事前定義不要– レコード間で Attributes が不揃いであっても問題ない
• Attributes の型– String– Number– Binary
– Set of String– Set of Number– Set of Binary
データモデル (1/2)Hash Key のみの場合
Item
Primary Key
AttributeA1-1Hash Key
データモデル (2/2)• Hash Key + Range Key の場合
ItemPrimary Key
AttributeA1-1
Hash Key A
Range Key 1
Range Key 2
Range Key 3
AttributeA2-1
AttributeA3-1
A,D B,E C,F
1 2
3
4
5
6
7
8
9
Parition1 Partition2 ParitionN
Range keyPartition内でのデータの並びを保証する
Hash keyPartition間でのデータ分散に利用される
PartitionDynamoDB では、性能を確保するためにデータはパーティションに分散して格納される
Hash key と Range key の概念 (1/2)
A,D B,E C,F
1 2
3
4
5
6
7
8
9
Parition1 Partition2 ParitionN
Hash key と Range key の概念 (2/2)
Partition• DynamoDB はデータを複数の Partition に分
散格納
• プロビジョンしたスループットは各パーティションに均等に付与、全体で合計値の性能
• 負荷が特定のキーに偏るとプロビジョンした性能が出ない可能性があるため、Hash key の設計には注意
プロビジョンドスループット : x
x/N x/N x/N
テーブル操作についての基礎知識 (1/3)
• GetItem• Hash key を条件として指定し、
一件のアイテムを取得
• PutItem• 1件のアイテムを書き込む
• Update• 1件のアイテムを更新
• Delete• 1件のアイテムを削除
• Query• Hash key と Range key の複合条件に
マッチするアイテム群を取得
• BatchGet• 複数のプライマリキーを指定して
マッチするアイテム群を取得
• Scan• テーブル総ナメする
API操作
テーブル操作についての基礎知識 (2/3)
• 強一貫性を持った Read オペレーション• GetItem 、 Query には Consistent Read オプションを指定可
• Read リクエストを受け取るよりも前に成功しているすべての Write リクエストが反映された結果が返る
• Read Capacity Unit を通常の 2倍消費する
• Conditional Write• 「キーにマッチするレコードが存在したら / しなかったら」や「この値が○○
以上 / 以下だったら」という条件付き書き込み / 更新ができる
より高度なオペレーション
テーブル操作についての基礎知識 (3/3)
• UpdateItem における Attributeへの操作• Attribute に対して、 UpdateItem で Put 、 Add 、 Delete という 3種類の操作が
可能• Put : Attribute を指定した値で更新• Add : Attribute が Number 型なら足し算 /引き算、 Set 型ならそのセットに対して値を
追加• Delete :当該 Attribute を削除する
• Atomic Counter• 上記の Add を利用することによって、 Atomic なカウンターを実現することもでき
る
より高度なオペレーション
Query のための Index
• Local Secondary Index (LSI)– Range key 以外に絞り込み検索のためのキーを持つことができる– Hash key が同一のアイテム群の中からの検索のために利用– インデックスもテーブルにプロビジョンしたスループットを利用する
• Global Secondary Index (GSI)– Hash Key をまたいで検索を行うためのインデックス– インデックスにテーブルとは独立したスループットをプロビジョンし
て利用する
ユースケースとテーブル設計例
ユースケースごとのテーブル設計及びクエリの例
1. アプリのイベント履歴管理– Hash + Range key の利用例
2. ソーシャル画像共有アプリ– 複数テーブルによるデータモデル、 LSI 、 GSI の利用例
3. ◯☓ ゲーム– 楽観的ロックによるゲームのステート管理
4. 分散処理におけるロック機構– 楽観的ロックによる分散システムの競合制御
ゲームの行動履歴管理データベース
User(Hash)
Timestamp(Range)
Opponent Result
Alice 2014-02-21 12:21:20 Bob Lost
Alice 2014-02-21 12:42:01 Bob Won
Alice 2014-02-24 09:48:00 Dan Won
Alice 2014-02-25 16:21:11 Charlie Won
Battle History
自分のバトル履歴を確認するケースを想定– User に自分 (Alice) を指定し、更に Timestamp が 7 日以内の
データをクエリしたりできる
Charlie02-25 16:21
Won!
Your Battle History
Dan02-24 09:48
Won!
Alice02-21 12:42
Won!
Amazon DynamoDB のデータも解析に利用
• Amazon Elastic MapReduce (EMR)で読み出し
• Amazon Redshift で直接読み込み• EMR で Filter した後、 Redshift に読
み込み• etc
EC2
ソーシャル画像共有アプリ
Home My Posts My Profile
BobSteak!
10:18
CarolBBQ! w/Alice
10:12
DanRiajuee…
10:11
AliceBeer!
10:21
AliceBBQ! w/Carol
10:12
AliceStarting BBQ!
10:09
Name:Alice
Mail: fooProfile: some texts
テーブル設計
Users TableFriends Table
2 つのテーブルを定義• ユーザ情報テーブル• 友達リストテーブル
User(Hash)
Nicknames
Bob [ Rob, Bobby ]
Alice [ Allie ]
Carol [ Caroline ]
Dan [ Daniel, Danny ]
友達一覧を取得
Users Table
Item
Attribute(string, number, binary, set)
Primary Key(Hash)
User(Hash)
Nicknames
Bob [ Rob, Bobby ]
Alice [ Allie ]
Carol [ Caroline ]
Dan [ Daniel, Danny ]
友達一覧を取得
Friends Table
User(Hash)
Friend(Range)
Bob Alice
Alice Bob
Alice Carol
Alice Dan
Users Table
Hash + RangePrimary Key
Friends Table Users Table
User(Hash)
Nicknames
Bob [ Rob, Bobby ]
Alice [ Allie ]
Carol [ Caroline ]
Dan [ Daniel, Danny ]
User(Hash)
Friend(Range)
Bob Alice
Alice Bob
Alice Carol
Alice Dan
友達一覧を取得
Alice の友達一覧を取得1. Query (Table =
Friends, Hash = Alice, Range = *)
2. BatchGetItem(Bob, Carol, Dan)
投稿画像の保存と検索
Images Table
User( Hash)
Image( Range)
Date Link
Bob aed4c 2013-10-01 s3://…
Bob cf2e2 2013-09-05 s3://…
Bob f93bae 2013-10-08 s3://…
Alice ca61a 2013-09-12 s3://…
Bob
Bob の投稿画像一覧を取得Query (Table=Images, Hash= Bob, Range=*)
でもある時刻以降の画像を取得したかったら… ?
ある日時の画像取得
Images Table
User Image Date Link
Bob aed4c 2013-10-01 s3://…
Bob cf2e2 2013-09-05 s3://…
Bob f93bae 2013-10-08 s3://…
Alice ca61a 2013-09-12 s3://…
User Date Image
Bob 2013-09-05 cf2e2
Bob 2013-10-01 aed4c
Bob 2013-10-08 f93bae
Alice 2013-09-12 ca61a
Table ByDate Local Secondary Index
Local Secondary Index を Date に張る
画像にユーザのタグ付け
ImageTags Table
Image User
aed4c Alice
aed4c Bob
f93bae Alice
f93bae Bob
Image f93bae に Alice をタグ付け PutItem(Table = ImageTags,
Hash = f93bae, Range = Alice)Bob
でもあるユーザがタグ付けされてる画像の一覧を取得したかったら… ?
Image f93bae にタグ付けされたユーザ一覧 Query(Table = ImageTags,
Hash = f93bae, Range = *)
ユーザのタグ付き画像一覧
ImageTags Table
User に Image を Range キーとしたGlobal Secondary Index を張る
User(Hash)
Image(Range)
Bob aed4c
Bob f93bae
Alice aed4c
Alice f93bae
ByUser Global Secondary Index
Image(Hash)
User(Range)
aed4c Alice
aed4c Bob
f93bae Alice
f93bae Bob
Table
Bob
Alice がタグ付けされた画像一覧
◯☓ ゲームのステート管理
◯☓ ゲーム
{ Id : abecd, Players : [ Alice, Bob ], State : STARTED, Turn : Bob, Top-Right : O}
Game Item
◯☓ ゲーム
AmazonDynamoDB
Alice Bob
◯☓ ゲーム
AmazonDynamoDB
Alice Bob
Update: Top-Left : X Turn : Alice
◯☓ ゲーム – 今のままだとチートが可能
Alice Bob (1)
AmazonDynamoDB
Bob (2) Bob (3)
◯☓ ゲーム – 今のままだとチートが可能
Bob (1)
AmazonDynamoDB
Bob (2)Bob (3)
Update: Turn : Alice Top-Left : X
Update: Turn : Alice Mid : X
State : STARTED,Turn : Bob,Top-Right : O
Update: Turn : Alice Low-Right : X
◯☓ ゲーム – 今のままだとチートが可能
Bob (1)
AmazonDynamoDB
Bob (2)Bob (3)
Update: Turn : Alice Top-Left : X
Update: Turn : Alice Mid : X
State : STARTED,Turn : Alice,Top-Right : O,Top-Left : X,Mid: X,Low-Right: X
Update: Turn : Alice Low-Right : X
条件付きアップデート(楽観的ロック)
• 現在の特定の Attribute に特定の値が入っていた場合にのみ更新を実施
• 条件が合わなかったら更新せずに終了• (但し、 1 つのアイテムのみで適用可
能)
修正版 ゲーム◯☓
Bob (1)
Amazon DynamoDB
Bob (2)Bob (3)
Update: Turn : Alice Top-Left : XExpect: Turn : Bob Top-Left : null
State : STARTED, Turn : Bob, Top-Right : O
Update: Turn : Alice Mid : XExpect: Turn : Bob Mid : null
Update: Turn : Alice Low-Right : XExpect: Turn : Bob Low-Right : null
修正版 ゲーム◯☓
Bob (1)
AmazonDynamoDB
Bob (2)Bob (3)
State : STARTED, Turn : Bob, Top-Right : O
Update: Turn : Alice Top-Left : XExpect: Turn : Bob Top-Left : null
Update: Turn : Alice Low-Right : XExpect: Turn : Bob Low-Right : null
Update: Turn : Alice Mid : XExpect: Turn : Bob Mid : null
修正版 ゲーム◯☓
Bob (1)
AmazonDynamoDB
Bob (2)Bob (3)
State : STARTED, Turn : Alice, Top-Right : O, Top-Left : X
Update: Turn : Alice Top-Left : XExpect: Turn : Bob Top-Left : null
Update: Turn : Alice Mid : XExpect: Turn : Bob Mid : null
Update: Turn : Alice Low-Right : XExpect: Turn : Bob Low-Right : null
バッチ処理のロック管理
S3 S3
Worker1
Jobs Table
JobID(Hash)
Created Time(Range)
Process1 Process2
aed4c 2014-01-01 00:00:00
Done InProcess
aed4c 2014-01-01 00:01:00
No t Yet NotYet
Worker2 も処理のジョブ一覧を取得
Scan (Table = jobs, Process1 = ‘NotYet’)
Worker1 が未処理のジョブ一覧を取得
Scan (Table = jobs, Process1 = ‘NotYet’)
ワーカーが複数クラスタいるので、複数箇所で同じデータが取得される
Worker2
バッチ処理のロック管理
S3 S3
処理1
Jobs Table
JobID(Hash)
Created Time(Range)
Process1 Process2
aed4c 2014-01-01 00:00:00
Done InProcess
aed4c 2014-01-01 00:01:00
No t Yet NotYet
Worker2 も Process1 を Lock しようとするUpdateItem (Table = jobs,
Key={JobID:aed4c}, AttributeUpdates={Process1:{Action:’Put’,Value:InProcess’}}, Expected:{Process1:‘NotYet’})
片方だけ Update に成功する(Lock できる )
Worker1 が Process1 を Lock しようとするUpdateItem (Table = jobs,
Key={JobID:aed4c}, AttributeUpdates={Process1:{Action:’Put’,Value:InProcess’}}, Expected:{Process1:‘NotYet’})
まとめ
• Amazon DynamoDB の特徴– 高い可用性– 一貫した性能– 低い運用負荷
• Amazon DynamoDB の高度な機能– Local Secondary Indexes– Global Secondary Indexes
• ユースケースを取り上げてテーブル設計やクエリの例– ユーザの行動履歴– ソーシャル画像共有アプリ– マルバツゲーム– 分散処理におけるロックの管理