Amazon DynamoDB は、完全マネージド型の NoSQL データベースサービスであり、ハイスケーラブルな分散データベースサービスです。本公演では、Amazon DynamoDBの基本的な機能や、ソーシャルゲーム等の高規模なアプリケーションを構築するための使用方法をご紹介いたします。

1. Deep Dive: Amazon DynamoDB
Yuko Mori
Solutions Architect
Amazon Data Services Japan K.K.

2. 自己紹介
• 森 祐孝(もり ゆうこう)
– アマゾン データサービスジャパン株式会社
– ソリューションアーキテクト
• 経歴
– Sierなどで、アプリケーション開発、PL、PMなどを担当
– ゲーム会社（テクニカルディレクタ）
• ブラウザソーシャルゲーム、スマートフォン向けソーシャルゲーム
• 担当
– ソーシャルゲーム、コンソールゲーム系のお客様のAWS構築支援

3. Agenda
• DyanamoDBとは
• Table, API, Data Type
• Indexes
• Scaring
• Data Modeling
• ユースケース& ベストプラクティス
• DynamoDB Stream

4. DyanamoDBとは

5. Amazon DynamoDBの生い立ち
• Amazon.comではかつて全てのアクセスパターンをRDBMSで
処理していた
• RDBMSのスケールの限界を超えるため開発されたDynamoが
祖先
• 結果整合性モデル採用に
よる可用性向上
• HWを追加する毎に性能
が向上するスケーラビリ
ティ
• シンプルなクエリモデル
による予測可能な性能

6. Amazon DynamoDBの特徴
• 完全マネージド型の NoSQL データベースサービス
• ハイスケーラブル、低レイテンシー
• 高可用性– 3x レプリケーション
• シンプル且つパワフルAPI
• ストレージの容量制限がない
• 運用管理必要なし
クライアント

7. Tables, API, Data Types

8. Table
table
items
attributes
Hash
Key
Range
Key
必須
キーバリュー型のアクセスパターン
データ分散に利用される オプション
1:Nモデルのリレーションシップ
豊富なQueryをサポート
ハッシュキー検索用
==, <, >, >=, <=
“begins with”
“between”
sorted results
counts
先頭/末尾 N件
ページ単位出力

9. • CreateTable
• UpdateTable
• DeleteTable
• DescribeTable
• ListTables
• GetItem
• PutItem
• UpdateItem
• DeleteItem
• Query
• Scan
• BatchGetItem
• BatchWriteItem
• Liststreams
• DescribeStream
• GetShardIterator
• GetRecords
Table API
Stream API
DynamoDB
In preview

10. AWS SDKs and CLI
• 各種言語むけのオフィシャルSDKやCLIを利用
Java Python PHP .NET Ruby nodeJS
iOS Android
Javascript
in the Browser AWS CLI

11. Data Types
• String (S)
• Number (N)
• Binary (B)
• String Set (SS)
• Number Set (NS)
• Binary Set (BS)
• Boolean (BOOL)
• Null (NULL)
• List (L)
• Map (M)
JSON用に定義

12. 00 55 A954 AA FF
Hash Table
• Hash key は単体でプライマリキーとして利用
• 順序を指定しないハッシュインデックスを構築するためのキー
• テーブルは、性能を確保するために分割(パーティショニング)される場合あり
00 FF
Id = 1
Name = Jim
Hash (1) = 7B
Id = 2
Name = Andy
Dept = Engg
Hash (2) = 48
Id = 3
Name = Kim
Dept = Ops
Hash (3) = CD
Key Space

13. データは3箇所にレプリケーション
Id = 2
Name = Andy
Dept = Engg
Id = 3
Name = Kim
Dept = Ops
Id = 1
Name = Jim
Id = 2
Name = Andy
Dept = Engg
Id = 3
Name = Kim
Dept = Ops
Id = 1
Name = Jim
Id = 2
Name = Andy
Dept = Engg
Id = 3
Name = Kim
Dept = Ops
Id = 1
Name = Jim
Replica 1
Replica 2
Replica 3
Partition 1 Partition 2 Partition N

14. Hash-Range Table
• Hash + Rangeでプライマリキーとすることもできる
• Hash keyに該当する複数のデータの順序を保証するためにRange keyが使
われる
• Hash Keyの数に上限はありません
（Local Secondary Indexesを使用時は上限あり）
00:0 FF:∞
Hash (2) = 48
Customer# = 2
Order# = 10
Item = Pen
Customer# = 2
Order# = 11
Item = Shoes
Customer# = 1
Order# = 10
Item = Toy
Customer# = 1
Order# = 11
Item = Boots
Hash (1) = 7B
Customer# = 3
Order# = 10
Item = Book
Customer# = 3
Order# = 11
Item = Paper
Hash (3) = CD
55 A9:∞54:∞ AA
Partition 1 Partition 2 Partition 3

15. DynamoDBの整合性モデル
• Write
• 少なくとも２つのレプリカでの書き込み完了が確認とれた時点
でAck
• Read
• デフォルト
• 結果整合性のある読み込み
• 最新の書き込み結果が反映されない可能性がある
• Consistent Readオプションを付けたリクエスト
• 強力な整合性のある読み込み
• Readリクエストを受け取る前までのWriteがすべて反映されたレス
ポンスを保証

16. Indexes

17. Local Secondary Index (LSI)
• Range key以外に絞り込み検索を行うkeyを持つことができる
• Hash keyが同一で、他のアイテムからの検索のために利用
• すべての要素（テーブルとインデックス）の合計サイズを、各ハッ
シュキーごとに 10 GB に制限
A1
(hash)
A3
(range)
A2
(table key)
A1
(hash)
A2
(range)
A3 A4 A5
LSIs A1
(hash)
A4
(range)
A2
(table key)
A3
(projected)
Table
KEYS_ONLY
INCLUDE A3
A1
(hash)
A5
(range)
A2
(table key)
A3
(projected)
A4
(projected)
ALL

18. Global Secondary Index (GSI)
• Hash Key属性の代わりとなる
• Hash Keyをまたいで検索を行うためのインデックス
A1
(hash)
A2 A3 A4 A5
GSIs A5
(hash)
A4
(range)
A1
(table key)
A3
(projected)
Table
INCLUDE A3
A4
(hash)
A5
(range)
A1
(table key)
A2
(projected)
A3
(projected) ALL
A2
(hash)
A1
(table key) KEYS_ONLY

19. GSIの更新フロー
Table
Primary
table
Primary
table
Primary
table
Primary
table
Global
Secondary
Index
Client
2. 非同期Update
(in progress)
GSIにはテーブルとは独立したスループットをプロビジョンして利用するため
十分なスループットが必要

20. Scaling

21. Scaling
• スループット
– テーブル単位で、読み書きのスループットを指定（プロビジョニングさ
れたスループット）
• サイズ
– テーブルには任意の数のアイテムが追加可能
• 1 つのアイテムの合計サイズは 400 KB
• local secondary index について、異なるハッシュキーの値ごとに最大
10 GB のデータを格納
• スケーリングはパーティショニングによって実現

22. スループット
• テーブルレベルによってプロビジョニング
– Write Capacity Units (WCU)
• 1 秒あたりの項目書き込み回数 x 項目のサイズ (1 KB ブロック)
– Read Capacity Units (RCU)
• 1 秒あたりの読み込み回数 x 項目のサイズ (4 KB ブロック)
• 結果整合性のある読み込みをする場合はスループットが 2 倍
• 読み込みと書き込みのスループットはそれぞれ独立
WCURCU

23. パーティショニングの算出方法
# 𝑜𝑓 𝑃𝑎𝑟𝑡𝑖𝑡𝑖𝑜𝑛𝑠 =
𝑇𝑎𝑏𝑙𝑒 𝑆𝑖𝑧𝑒 𝑖𝑛 𝐺𝐵
10 𝐺𝐵(𝑓𝑜𝑟 𝑠𝑖𝑧𝑒)
# 𝑜𝑓 𝑃𝑎𝑟𝑡𝑖𝑡𝑖𝑜𝑛𝑠
(𝑓𝑜𝑟 𝑡ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡)
=
𝑅𝐶𝑈𝑓𝑜𝑟 𝑟𝑒𝑎𝑑𝑠
3000 𝑅𝐶𝑈
+
𝑊𝐶𝑈𝑓𝑜𝑟 𝑤𝑟𝑖𝑡𝑒𝑠
1000 𝑊𝐶𝑈
(𝑓𝑜𝑟 𝑡ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡)(𝑓𝑜𝑟 𝑠𝑖𝑧𝑒)(𝑡𝑜𝑡𝑎𝑙)
• スループット
• ストレージサイズ
• 大きいほうを採用

24. パーティショニング算出例
# 𝑜𝑓 𝑃𝑎𝑟𝑡𝑖𝑡𝑖𝑜𝑛𝑠 =
8 𝐺𝐵
10 𝐺𝐵
= 0.8 = 1
(𝑓𝑜𝑟 𝑠𝑖𝑧𝑒)
# 𝑜𝑓 𝑃𝑎𝑟𝑡𝑖𝑡𝑖𝑜𝑛𝑠
(𝑓𝑜𝑟 𝑡ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡)
=
5000 𝑅𝐶𝑈
3000 𝑅𝐶𝑈
+
500 𝑊𝐶𝑈
1000 𝑊𝐶𝑈
= 2.17 = 3
Table size = 8 GB, RCUs = 5000, WCUs = 500
(𝑡𝑜𝑡𝑎𝑙)
RCUs per partition = 5000/3 = 1666.67
WCUs per partition = 500/3 = 166.67
Data/partition = 8/3 = 2.66 GB
RCUとWCU の値は均一に各パー
テションに割り当てられます
• スループット
• ストレージサイズ
• 大きいほうを採用

25. DynamoDBの料金体系
• プロビジョニングされたスループットで決まる時間料金
– Read/Writeそれぞれプロビジョンしたスループットによって時間あた
りの料金がきまる
– 大規模に利用するのであればリザーブドキャパシティによる割引もあ
り
• ストレージ利用量
– 保存したデータ容量によって決まる月額利用料金
– 計算はGBあたりの単価が適用される
http://aws.amazon.com/jp/dynamodb/pricing/
詳細はこちらを参照

26. DynamoDB のスループットを最大限に活用
“DynamoDB のスループットを最
大限に活用するには、テーブル
を作成するときに、ハッシュキー
要素に個別の値が多数含まれ、
できるだけランダムかつ均一に
値がリクエストされるようにします。
”
– DynamoDB Developer Guide
• Space: キーアクセスはなる
べく均等になるように
• Time: リクエストはなるべく均
等な間隔で

27. Example: Hot Keys
Partition
Time
Heat

28. Example: Periodic spike

29. DynamoDBのバースト処理は?
• DynamoDBはパーティションごとのキャパシティのうち、
利用されなかった分を過去300秒分までリザーブ
• プロビジョン分を超えたバーストラフィックを処理する
ために利用する
– リザーブされたキャパシティは、各パーティションで利用可能

30. Burst capacity is built-in
0
400
800
1200
1600
CapacityUnits
Time
Provisioned Consumed
使われなかったキャパシティ分を保持
保持していたキャパシティを使用
バーストキャパシティ: 300秒
(1200 × 300 = 3600 CU)

31. Burst capacity may not be sufficient
0
400
800
1200
1600
CapacityUnits
Time
Provisioned Consumed Attempted
バーストキャパシティ: 300秒
(1200 × 300 = 3600 CU)
超過したリクエスト
バーストキャパシティの機能に依存しないように。

32. Data Modeling

33. 1:1 リレーション or キー・バリュー型
• Hash keyを使ったテーブルまたはGSI
• GetItem かBatchGetItem APIを使用
例: UserIDやEmailから要素を抽出する場合
Users Table
Hash key Attributes
UserId = bob Email = bob@gmail.com, JoinDate = 2011-11-15
UserId = fred Email = fred@yahoo.com, JoinDate = 2011-12-01
Users-email-GSI
Hash key Attributes
Email = bob@gmail.com UserId = bob, JoinDate = 2011-11-15
Email = fred@yahoo.com UserId = fred, JoinDate = 2011-12-01

34. 1:N リレーション or 親子関係
• Hash key とRange key を使ったテーブル、GSI
• Query APIを使ってアクセス
例:1ユーザでN個のゲームをプレイしている場合
User-Games
Hash Key Range key Attributes
UserId = bob GameId = Game1 HighScore = 10500, ScoreDate = 2011-10-20
UserId = fred GameId = Game2 HIghScore = 12000, ScoreDate = 2012-01-10
UserId = bob GameId = Game3 HighScore = 20000, ScoreDate = 2012-02-12

35. N:M リレーション
• table と GSI を使用してhash key とrange key の
要素をスイッチして設計
• Query API を用いてアクセス
例: 1ユーザが複数のゲームをプレイし,
1ゲームで複数のプレイヤーがゲームをしている場合
User-Games-Table
Hash Key Range key
UserId = bob GameId = Game1
UserId = fred GameId = Game2
UserId = bob GameId = Game3
Game-Users-GSI
Hash Key Range key
GameId = Game1 UserId = bob
GameId = Game2 UserId = fred
GameId = Game3 UserId = bob

36. Document (JSON)
• 新データタイプ (M, L, BOOL,
NULL) としてJSONをサポート
• Document SDKs
– 単純なプログラミングモデル
– JSONから、JSONへの変換
– Java, JavaScript, Ruby, .NET
Javascript DynamoDB
string S
number N
boolean BOOL
null NULL
array L
object M

37. ユースケース及び、ベストプラクティス

38. イベントログ
Storing time series data

39. Time Series Tables
Events_table_2015_June
Event_id
(Hash key)
Timestamp
(range key)
Attribute1 …. Attribute N
Events_table_2015_May
Event_id
(Hash key)
Timestamp
(range key)
Attribute1 …. Attribute N
Events_table_2015_April
Event_id
(Hash key)
Timestamp
(range key)
Attribute1 …. Attribute N
Events_table_2015_March
Event_id
(Hash key)
Timestamp
(range key)
Attribute1 …. Attribute N
RCU = 1000
WCU = 100
RCU = 10000
WCU = 10000
RCU = 100
WCU = 10
RCU = 10
WCU = 1
Current table
Older tables
HotdataColddata
ホットデータとコールドデータは混在させない
アーカイブしたコールドデータはS3へ

40. メッセージアプリ
Large Items
Filters vs Indexes
M:N modeling – Inbox & Sent Items

41. Messages
Table
Messages App
David
SELECT *
FROM Messages
WHERE Recipient='David'
LIMIT 50
ORDER BY Date DESC
Inbox
SELECT *
FROM Messages
WHERE Sender ='David'
LIMIT 50
ORDER BY Date DESC
Outbox

42. Recipient Date Sender Message
David 2014-10-02 Bob …
… 48 more messages for David …
David 2014-10-03 Alice …
Alice 2014-09-28 Bob …
Alice 2014-10-01 Carol …
大小のデータが混在
(Many more messages)
David
Messages Table
50 items × 平均 256 KB
大きなメッセージボディーを
格納
SELECT *
FROM Messages
WHERE Recipient='David'
LIMIT 50
ORDER BY Date DESC
Inbox

43. クエリーコストの計算
1回の問い合わせによって
取得されるアイテム数
平均アイテムサイズ
4KB毎に1RCU
消費
結果整合性のある読み込み

44. Recipient Date Sender Subject MsgId
David 2014-10-02 Bob Hi!… afed
David 2014-10-03 Alice RE: The… 3kf8
Alice 2014-09-28 Bob FW: Ok… 9d2b
Alice 2014-10-01 Carol Hi!... ct7r
大きいデータを分けて配置
Inbox-GSI Messages Table
MsgId Body
9d2b …
3kf8 …
ct7r …
afed …
David
1. Query Inbox-GSI: 1 RCU
2. BatchGetItem Messages: 1600 RCU
(50 separate items at 256 KB)
(50 sequential items at 128 bytes)
均等に大きいアイテムを読むように配置
(Recipientをindex,
Message メタデータを格納)

45. Inbox GSI

46. 書き込み処理を単純化
David
PutItem
{
MsgId: 123,
Body: ...,
Recipient: Steve,
Sender: David,
Date: 2014-10-23,
...
}
Inbox
Global secondary
index
Messages
Table

47. Outbox Sender
Outbox GSI
SELECT *
FROM Messages
WHERE Sender ='David'
LIMIT 50
ORDER BY Date DESC

48. Messaging app
Messages
Table
David
Inbox
Global secondary
index
Inbox
Outbox
Global secondary
index
Outbox
update

49. マルチプレイヤー
オンラインゲーム
Query filters vs
Composite key indexes

50. GameId Date Host Opponent Status
d9bl3 2014-10-02 David Alice DONE
72f49 2014-09-30 Alice Bob PENDING
o2pnb 2014-10-08 Bob Carol IN_PROGRESS
b932s 2014-10-03 Carol Bob PENDING
ef9ca 2014-10-03 David Bob IN_PROGRESS
Games Table
マルチプレイヤーオンラインゲームデータ

51. ゲーム内でのクエリー要件
• DynamoDBのインデックスはhash keyと range
keyのみ対応
• 2つの一致条件と範囲検索を行いたい場合は?
SELECT * FROM Game
WHERE Opponent='Bob‘
AND Status=‘PENDING'
ORDER BY Date DESC
(hash)
(range)
(?)

52. Secondary Index
Opponent Date GameId Status Host
Alice 2014-10-02 d9bl3 DONE David
Carol 2014-10-08 o2pnb IN_PROGRESS Bob
Bob 2014-09-30 72f49 PENDING Alice
Bob 2014-10-03 b932s PENDING Carol
Bob 2014-10-03 ef9ca IN_PROGRESS David
Approach 1: Query filter
Bob

53. Secondary Index
Approach 1: Query filter
Bob
Opponent Date GameId Status Host
Alice 2014-10-02 d9bl3 DONE David
Carol 2014-10-08 o2pnb IN_PROGRESS Bob
Bob 2014-09-30 72f49 PENDING Alice
Bob 2014-10-03 b932s PENDING Carol
Bob 2014-10-03 ef9ca IN_PROGRESS David
SELECT * FROM Game
WHERE Opponent='Bob'
ORDER BY Date DESC
FILTER ON Status='PENDING'
(filtered out)

54. Needle in a haystack
Bob
消費されるキャパシティー
ユニット数は、フィルタさ
れた分は取り除かれない

55. Approach 2: 複合キー
StatusDate
DONE_2014-10-02
IN_PROGRESS_2014-10-08
IN_PROGRESS_2014-10-03
PENDING_2014-09-30
PENDING_2014-10-03
Status
DONE
IN_PROGRESS
IN_PROGRESS
PENDING
PENDING
Date
2014-10-02
2014-10-08
2014-10-03
2014-10-03
2014-09-30

56. Secondary Index
Approach 2: 複合キー
Opponent StatusDate GameId Host
Alice DONE_2014-10-02 d9bl3 David
Carol IN_PROGRESS_2014-10-08 o2pnb Bob
Bob IN_PROGRESS_2014-10-03 ef9ca David
Bob PENDING_2014-09-30 72f49 Alice
Bob PENDING_2014-10-03 b932s Carol

57. Opponent StatusDate GameId Host
Alice DONE_2014-10-02 d9bl3 David
Carol IN_PROGRESS_2014-10-08 o2pnb Bob
Bob IN_PROGRESS_2014-10-03 ef9ca David
Bob PENDING_2014-09-30 72f49 Alice
Bob PENDING_2014-10-03 b932s Carol
Secondary Index
Approach 2: 複合キー
Bob
SELECT * FROM Game
WHERE Opponent='Bob'
AND StatusDate STARTS_WITH 'PENDING'

58. Needle in a sorted haystack
Bob
消費されるキャパシ
ティーユニット数を節約

59. スパースなインデックスの利用
Id
(hash)
User Game Score Date Award
1 Bob G1 1300 2012-12-23
2 Bob G1 1450 2012-12-23
3 Jay G1 1600 2012-12-24
4 Mary G1 2000 2012-10-24 Champ
5 Ryan G2 123 2012-03-10
6 Jones G2 345 2012-03-20
Game-scores-table
Award
(hash)
Id User Score
Champ 4 Mary 2000
Award-GSI
項目内にインデックスキー値があ
る場合のみ書き込み
書き込み、読み込みキャパシティ
ユニットも少なくなる

60. リアルタイム投票
システム
Write-heavy items

61. 投票システムの要件
• 投票は一回のみ
• 一度投票したものは変えられない
• リアルタイムに集計
• 投票者の統計、分析を行いたい

62. リアルタイム投票システムのアーキテクチャ
票集計
Table
Voters
投票
Table
Voting App

63. Partition 1
1000 WCUs
Partition K
1000 WCUs
Partition M
1000 WCUs
Partition N
1000 WCUs
投票Table
Candidate A Candidate B
スケールすることによるボトルネック
Voters
Provision 200,000 WCUs

64. シャーディングでの書き込み
Candidate A_2
Candidate B_1
Candidate B_2
Candidate B_3
Candidate B_5
Candidate B_4
Candidate B_7
Candidate B_6
Candidate A_1
Candidate A_3
Candidate A_4
Candidate A_7 Candidate B_8
Candidate A_6 Candidate A_8
Candidate A_5
Voter
投票 Table

65. シャーディングでの書き込み
Candidate A_2
Candidate B_1
Candidate B_2
Candidate B_3
Candidate B_5
Candidate B_4
Candidate B_7
Candidate B_6
Candidate A_1
Candidate A_3
Candidate A_4
Candidate A_7 Candidate B_8
UpdateItem: “CandidateA_” + rand(0, 200)
ADD 1 to Votes
Candidate A_6 Candidate A_8
Candidate A_5
Voter
投票Table

66. 正確な投票
UserId Candidate Date
１ A 2013-10-02
２ B 2013-10-02
３ B 2013-10-02
４ A 2013-10-02
投票Table
Segment Votes
A_1 23
B_2 12
B_1 14
A_2 25
投票集計Table
Voter
1. 投票データの登録、重複排除 2. 投票データの集計

67. 正確な集計は?
UserId Candidate Date
１ A 2013-10-02
２ B 2013-10-02
３ B 2013-10-02
４ A 2013-10-02
投票Table
Segment Votes
A_1 23
B_2 12
B_1 14
A_2 25
投票集計Table
Voter

68. DynamoDB Stream
In preview

69. What is DynamoDB Stream?
It is a stream of updates
Scales with your table
DynamoDB StreamDynamoDB
In preview

70. • テーブルの更新の情報を
保持
• 非同期に更新
• シリアライズされたデータ
• アイテム毎の厳密な管理
• 高耐久性
• テーブルよるスケール
• 有効期限は24時間
• 1秒未満の遅延書き込み
DynamoDB stream

71. View Type Destination
Old Image – 更新前の情報 Name = John, Destination = Mars
New Image – 更新後の情報 Name = John, Destination = Pluto
Old and New Images Name = John, Destination = Mars
Name = John, Destination = Pluto
Keys Only Name = John
View types
更新情報（Name = John, Destination = Mars）
⇒(Name = John, Destination = Pluto)

72. Stream
Table
Partition 1
Partition 2
Partition 3
Partition 4
Partition 5
テーブル
Shard 1
Shard 2
Shard 3
Shard 4
KCL
Worker
KCL
Worker
KCL
Worker
KCL
Worker
Amazon Kinesis Client
Library Application
DynamoDB
クライアント
アプリケーション 更新
DynamoDB Stream and
Amazon Kinesis Client Library

73. DynamoDB Stream
Open Source Cross-
Region Replication Library
Asia Pacific (Sydney) EU (Ireland) Replica
US East (N. Virginia)
クロスリージョンレプリケーション

74. DynamoDB Stream and AWS Lambda

75. AWS Lambda
• 特徴 (http://aws.amazon.com/jp/lambda/)
– OS、キャパシティ等インフラの管理不要
– S3、Kinesis、SNS等でのイベント発生を元に
ユーザが用意したコード（Node.js）を実行
– ユーザアプリからの同期/非同期呼び出し
• 価格体系 (http://aws.amazon.com/jp/lambda/pricing/)
– コード実行時間（100ms単位）
– Lambdaファンクションへのリクエスト回数
– 1月あたり100万リクエスト、400,000GB/秒が無
料で利用可能
イベントをトリガーにコードを実行するコンピュートサービス
AWS LambdaAmazon S3 Bucket イベント
元画像 サムネイル画像
1
2
3
AWS LambdaAmazon DynamoDB
Table and Stream
プッシュ通知
別テーブルを更
新
■イメージのリサイズやサムネイルの作成
■値チェックや別テーブルへのコピー

76. Real-time voting architecture
投票集計
Table
Amazon
Redshift Amazon EMR
Your
Amazon Kinesis–
Enabled App
Voters 投票TableVoting app 投票
DynamoDB
Stream

77. Real-time voting architecture
投票集計
Table
Amazon
Redshift Amazon EMR
Your
Kinesis-enabled
app
Voters 投票TableVoting app 投票
DynamoDB
Stream

78. Real-time voting architecture
投票集計
Table
Amazon
Redshift Amazon EMR
Your
Kinesis-enabled
app
Voters 投票TableVoting app 投票
DynamoDB
Stream

79. Real-time voting architecture
投票集計
Table
Amazon
Redshift Amazon EMR
Your
Kinesis-enabled
app
Voters 投票TableVoting app 投票
DynamoDB
Stream
投票者の統計、分析

80. DynamoDBが使われているユースケース
• KVSとして
– Webアプリケーションのセッションデータベース
– ユーザー情報の格納するデータベース
• 広告やゲームなどのユーザー行動履歴DBとして
– ユーザーIDごとに複数の行動履歴を管理するためのデータベース
• ソーシャルアプリのバックエンドとして
– モバイルアプリから直接参照できるデータベースとして
• 他にも
– バッチ処理のロック管理
– フラッシュマーケティング
– ストレージのインデックス

81. ユースケースに合わせてDB製品を選択
Elastic
Load
Balancing
Clients
EC2
Amazon
DynamoDB
Managed NoSQL
Amazon RDS
Managed SQL
Amazon ElastiCache
Managed in-memory caching
Amazon Redshift
Managed data
warehouse
BI tools

82. ありがとうございました！