DynamoDBを利用した
KPI保存システム
2016/01/25 VisualizationNight#1
グリー株式会社 長谷川貴之

本日の内容
• 自己紹介
• グリー内製の可視化システム
• DynamoDBを利用したKPI保存システム
2

自己紹介
• データエンジニアリングチーム
• Hadoopなどの分析基盤の運用
• ツールの開発，利用者のサポート
• 最近ではオンプレだけでなくAWSも利用
• Kinesis，EMRの検証をするメンバーも
3

グリー内製の可視化システム
注) これから出てくる値はサンプルデータです
4

可視化システム (一部のシステムの紹介です)
• NativeGame KPIレポート
• 決められた数値指標のみ表示
• プロダクト間の比較が容易
• ユーザーテキストダッシュボード
• テキスト閲覧に特化したシステム
• ユーザーのアンケート，問い合わせなどが見れる
• BIツール(Macaron)
• プロダクト運営者が自由に数値指標を作成できる
• スケジューリングの機能を備える
5

NativeGame KPIレポート
6

NativeGame KPIレポート
Rails + RDS(MySQL) + TD or Hadoop
Treasure Data Inc.(https://www.treasuredata.com/)
Apache®, Apache Hadoop, Hadoop®(http://hadoop.apache.org/), and the yellow elephant logo are either registered trademarks or
trademarks of the Apache Software Foundation(http://www.apache.org/) in the United States and/or other countries.
7

ユーザーテキストダッシュボード
8

ユーザーテキストダッシュボード
Django + Presto + Hadoop
Django
9

BIツール(Macaron)
10

BIツール(旧Macaron)
Rails + HBase or Hive or Presto + Hadoop
11

BIツール(新Macaron)
Rails + HBase or Hive or Presto + Hadoop
DynamoDBへ！
12

ここからの内容
• Macaronの機能
• 既存ストレージ(HBase, OpenTSDB)
• リプレイスの背景 / 検討
• 設計 / 実装
13

Macaronの機能
• HiveやPrestoにクエリの発行する
• クエリの結果を時系列データベースに保存
• with スケジューリング
• セグメント毎のグラフ描画
• その他
14

Macaronの機能 / クエリの発行
15

Macaronの機能 / データの保存
定期実行した結果を保存する
16

Macaronの機能 / グラフの描画
17

BIツール(Macaron)
Rails + DynamoDB or Hive or Presto + Hadoop
• HBase(OpenTSDB)からDynamoDBへ
18

そもそもOpenTSDBって？
• HBaseをストレージとした時系列データベース
• オープンソース
• RRDToolのように値を丸めない
• システムのメトリクスなど大規模データが得意
• 米Yahoo!では15台のサーバーで毎秒28万件のWrite
をさばく
• http://www.slideshare.net/HBaseCon/ecosystem-session-6/6
19

OpenTSDBのメタデータ
• DataPoints
(time, value)
• Metrics
デバイス別DAU
• Tags
device=fp, device=sp
• Metrics + Tags = TimeSeries
ref. OpenTSDB HBaseCon http://opentsdb.net/misc/opentsdb-hbasecon.pdf 20

リプレイスした背景
• サーバーの移設の必要があった
• HBaseクラスタを再構築？
• 新しく作り直す？
• 期間は7月末 ~ 10月
• 決められた期限，求められる費用削減
21

リプレイスした背景
• 現状のシステムが高機能すぎる
• 描画機能，集計関数などは利用していない
• HBaseで持つほどのデータ規模ではない
• 少しカスタマイズする必要があった
• 日本語に対応させるためにパッチを当てた
• メトリックの操作が意外と面倒
22

AWSを前提としたリプレイス案
• HBase on EMR
• 常時稼働させておくとコストが高い
• InfluxDB on EC2
• 検証期間がとれず運用面で信頼しきれなかった
• MySQL(RDS)
• 実績があり，値段も予想できる
• DynamoDB
• 詳しくないが，データはソートできるらしい
23

DynamoDBに関する調査
• スループット課金である
• 一度に大きなデータを取得，保存は苦手
• テーブルごとに課金される
• 10Gごとにパーティションが分割される
• 保存は安いがスループットが分散する
24

あれ、向いてない…？
25

Unit消費について調査する
• GemItem, BatchGetItem
• どんなに小さいrecordでも，1 record = 1 unit
• 1日1recordだとすると，3年分取得で1095unit
• Query, Scan
• 累計サイズを使用してスループットを計算
• 1record = 1unitではない
• 1recordが1KBとすると，3年分取得で273unit
26

Unit消費について調査する
• GemItem, BatchGetItem
• どんなに小さいrecordでも，1 record = 1 unit
• 1日1recordだとすると，3年分取得で1095unit
• Query, Scan
データ取得はQueryなので安心
• 累計サイズを使用してスループットを計算
• 1record = 1unitではない
• 1recordが1KBとすると，3年分取得で273unit
27

ユースケースを確認する
• 1ページにいくつかのKPI指標を配置
• 期間は固定，dailyならば90日程度
• 指標の更新頻度は高くない
• しかし，過去分を1度に入れることはある
• 時間帯によって見る見ないがはっきりする
• 夜間や土日はほとんど見られない
28

工夫する余地がありそう…！
29

スループットを下げる取り組み
• 読み込みスループットの削減
• 固定された期間のデータはキャッシュへ
• 時間帯に合わせた動的スループット変更
• 書き込みスループットの削減
• 急な書き込み増に備えキューを利用
30

キャッシュを活用する
• ElastiCache(Redis)を活用する
• 直近のデータ(ex. 90日)をキャシュする
• 基本的に過去の施策を振り返る場合のみ
DynamoDBにアクセスがいく
• ElastiCacheは安いのでお得
• 直近のデータのみならt2.microでも可
31

キューを活用する
• SQSを利用する
• 書き込みが増えて失敗してもリトライできる
• 低いスループットを指定してもデータのロスト
を防ぐことができる
• 値段はほぼ無料
32

スループットを変動させる
SumoLogicで可視化したアクセス数 (一部)
明らかに夜間にアクセスがなくもったいない！
33

例) スループットを変動させる
一定に保った場合
終日(read: 1000)
• 0.00742 * 24 * 30 * 1000 / 50 = $107
読み込みスループットを変動させた場合
平日&日中(read: 1000)，夜間or土日(read: 500)
• 0.00742 * 24 * 22 * (1000+500) / 2 / 50 = $59
• 0.00742 * 24 * 8 * 500 / 50 = $14
• $59 + $14 = $73
この例では，スループットの変動で32%オフに！
34

DynamoDBでいけるのでは…
35

サーバー構成
36

実装
• Scala，フレームワークはSprayを利用
• AWSのClientはJavaが一番充実している
• AWSロックインされてもローカルで開発可能
• DynamoDB → DynamoDBLocal
• SQS → ElasticMQ
37

運用
• cronでスループットを変更
• 朝9時 ~ 夜9時でスループットをあげる
• ログはSumoLogicで管理してアクセス数の確認
• デプロイはCodeDeployで
• ときどきagentのプロセスがdownする…!!
38

まとめ
• グリーの可視化システムについて紹介した
• 役割によってそれぞれ存在する
• HBase(OpenTSDB)からDynamoDBへ
• スループットの変動で値段を抑える
• ElastiCacheやSQSもコストダウンに貢献
39

Happy Hacking :)