http://kokucheese.com/event/index/97770/ AWSセミナー『AWSのビッグデータサービスを使いこなせ！』 セッション２　講演内容

1.  2013-07-16
 株式会社マイネット
 伊藤 祐策
DynamoDB 活用事例

2. 目次
 自己紹介
 DynamoDBの用途について
 弊社事例紹介
 データ集計の実装方法

3. 自己紹介

4. 自己紹介
 名前 伊藤 祐策
 所属 株式会社マイネット
 肩書き アーキテクト
 業務内容
インフラ設計
アプリケーション設計
エンジニア教育

5. 会社紹介
 会社名 株式会社マイネット
 業種 インターネットサービス業
 主な事業内容
Android専用ソーシャルゲームの提供

6. DynamoDBの用途について

7. DynamoDBの用途は2通り
 DynamoDBの用途は２つに大分できる
for BIGDATA
 大量のデータを収集・蓄積・分析する
for Application
 無限の負荷分散能力を以て大規模サービスを実現する
※弊社事例は for Application です

8. DynamoDBのスゴイところ
 無制限に性能を拡張することができる
 性能が足りなくなったら課金額を増やすだけ
 負荷が高くなっても応答速度が低下しな
い
 負荷対策に掛けていた工数を大幅カットできる
 データ保全性もバッチリ
 ３箇所のiDCにデータを分散配置
 メンテナンスフリー
 CloudWatchで負荷状況を監視するだけのお仕事

9. 弊社事例紹介

10. ファルキューレの紋章
 Android専用アプリ
 登録ユーザー数 約70万

11. ファルキューレの紋章
 DynamoDBを使って実装された初めてのサー
ビス
 最初はDynamoDBのみで実装されていた
 のちにMySQLハイブリッド型へ移行
 国内初のDynamoDB for Application事例
 サービス開始以来、DBのメンテナンスは課金
額の調整のみ

12. 大激闘！キズナバトル
 Android専用アプリ
 登録ユーザー数 約15万

13. 大激闘！キズナバトル
 ファルキューレの紋章の開発で得られた知見を
最大限に生かし、DynamoDBに最適化した実装
を導入。
 最初からMySQLハイブリッド型の構成にした。
 メインデータベースとしてDynamoDB
 集計用データベースとしてMySQL
 リリース以来、DBメンテナンスは課金額の調整
のみ

14. 大激闘！キズナバトル
 毎日12時、19時、22時にチームバトルが開催
されるゲーム仕様のため、スパイク型の負荷
が発生する。
 22:00:00に約15倍の負荷が突然発生する
 バトルで使うテーブルは性能をかなり高めに
設定
 しかし予約性能を超えない限りは応答速度の低下
は発生しない
 RDBでは難しい芸当もDynamoDBなら余裕でこ
なす

15. システム構成
DynamoDB
WebServers
BatchServers
ELB
RDS
(MySQL)
SQS
Internet

16. AWS利用料金比率
大激闘! キズナバトル 2013年6月度
EC2 (73%)
DynamoDB
(11%)
RDS (4%)
Others (12%)

17. DynamoDBを採用して良かった
事
 スケールアウトの事を心配しなくて良くなった
 MySQLだとレプリカを沢山つくってReadのスケール
アウトはできたけど、Writeのスケールアウトが難し
い。
 スケールする仕組みを作ろうとすると、耐障害性設計
も大変になって、コストも手間も跳ね上がる。
 データ保全の事を心配しなくて良くなった
 物理故障に対する対策を自前で用意する必要がなく
なった。

18. DynamoDBを採用して良かった
事
 意外と料金が安い！
 しっかり実装するとDB費用をかなり安く抑えること
ができる。
 定期的に値下げのアップデートが空から降ってくる。
 性能と費用のバランスコントロールがしやすい
 「ここは強気にいきたいからお金を掛けてでも！」
 「ここはどうでもいいから費用を最小限に」
 ただし相応の技術力が必要

19. DynamoDBを採用して良かった
事
 ミドルウェア以下の勉強をする必要性から解放された
 分散データベースはただでさえ高度な知識が必要。
 RDBでも大規模システムの構築となると必要となる知識量も
検証に必要な時間も半端ではなくなる。
 我々はサービスを作りたいのであって、システム構築の勉強
を
したいわけではない。
 勉強や動作検証に使っていた時間をアプリケーションの実装
や品質向上のための時間に充てることができる。

20. DynamoDBを採用して苦労した
事
 トランザクションとバックアップの仕組みをアプリ
ケーション側で実装しなければならなくなった
 トランザクションはSQSと楽観的ロックを組み合わ
せて実装
 バックアップはスキーマ設計にジャーナルの概念を取
り入れて代替
 苦手な事もあるので他システムとの組み合わせが必要
 検索と集計ができないので、MySQLを併用すること
にした

21. DynamoDBを採用して苦労した
事
 ソースコードの品質を２段階くらい上げなければならな
くなった
 ちょっとでも汚いコードを書くとすぐにデータの論理破壊が発
生する
 酷いときは無限ループに陥る
 テストも普通の手法ではバグを見つけきれない
 エンジニアの教育が大変になった
 RDBというぬるい環境に慣れきった頭を切り替えさせる必要が
ある
 特性を理解してコードを書かないと分散DBのメリットを生かせ
ない
 情報工学の基礎から教えなければならないことも

22. データ集計処理の実装

23. データ集計処理の実装パターン
 方法は２つ
DynamoDB-MySQLレプリケーション
小～中規模向け
DynamoDB-EMR連携
大規模向け

24. DynamoDB-MySQLレプリケー
ション
 DynamoDB内のレコードが更新されるたびに
MySQLへ１レコード単位でコピーする。
 SQSを使って非同期にコピーを行う。
 SQLで集計を行い結果を得る。
 処理は全てアプリケーション側で実装。

25. DynamoDB-MySQLレプリケー
ション
DynamoDB MySQL

26. DynamoDB-MySQLレプリケー
ション
非同期にコピー
SQS
DynamoDB MySQL

27. DynamoDB-MySQLレプリケー
ション
SQLで集計
DynamoDB MySQL

28. DynamoDB-MySQLレプリケー
ション
 メリット
 SQLが使えるので柔軟な集計ができる
 システム構成が小規模で済む
 開発が簡単
 デメリット
 規模が大きくなるとRDSインスタンスの性能がボ
トルネックになる

29. DynamoDB-MySQLレプリケー
ション
 適している場面
 ユーザー数10万人以下の活動データの集計
 単純な売上集計ならリアルタイムでも集計可能
 1日1回の集計でよければ100万人規模でも大丈夫
 集計対象が頻繁に変わる案件
 イベントや新規施策の効果測定等
データの発生量が処理可能データ量を
超えるまではビッグデータではない！

30. DynamoDB-EMR連携
 RDBで処理しきれない規模になったら取る手
段
 DynamoDBに蓄積されたデータをEMR連携を
使って一気にダンプしてHadoopクラスタへ流
し込む！
 Map Reduceで集計・解析処理を行い、結果を
RDBまたはDynamoDBへ記録する。

31. DynamoDB-EMR連携
EMR
Hadoop Cluster
DynamoDB
DynamoDB
RDS
for Application
for BIGDATA

32. DynamoDB-EMR連携
 メリット
 大量のデータでも高速に処理できる
 お金を掛ければ掛けるほど速くなる！
 デメリット
 お金がたくさん掛かる
 システム構成が大掛かりになる
 開発が大変

33. まとめ

34. DynamoDBはこんな方にオスス
メ
 for Applicationとして使う場合
 同時接続1万人以上にも耐えられるシステムの構築に
挑戦したい
 費用も安く抑えたい
 データベースのメンテナンスはもうしたくない
 ミドルウェア以下の勉強はもうしたくない
 ソースコードの品質には自信がある

35. DynamoDBはこんな方にオスス
メ
 for BIGDATAとして使う場合
 ストレージ容量を気にするのはもう嫌だ
 データ保全の事を気にするのはもう嫌だ
 データベースの拡張メンテをするのはもう嫌だ
 お金を掛けてもいいから読み出し性能をもっと欲し
い
 お金を掛けてもいいから書き込み性能をもっと欲し
い
 Hadoop万歳！MapReduce万歳！

36. 終