dynamodb活用事例 株式会社マイネット
DESCRIPTION
http://kokucheese.com/event/index/97770/ AWSセミナー『AWSのビッグデータサービスを使いこなせ!』 セッション2 講演内容TRANSCRIPT
2013-07-16 株式会社マイネット 伊藤 祐策
DynamoDB 活用事例
目次
自己紹介 DynamoDB の用途について 弊社事例紹介 データ集計の実装方法
自己紹介
自己紹介
名前 伊藤 祐策 所属 株式会社マイネット 肩書き アーキテクト 業務内容
インフラ設計 アプリケーション設計 エンジニア教育
会社紹介
会社名 株式会社マイネット 業種 インターネットサービス業 主な事業内容
Android 専用ソーシャルゲームの提供
DynamoDBの用途について
DynamoDB の用途は 2 通り DynamoDB の用途は2つに大分できる
for BIGDATA 大量のデータを収集・蓄積・分析する
for Application 無限の負荷分散能力を以て大規模サービスを実現する
※ 弊社事例は for Application です
DynamoDB のスゴイところ 無制限に性能を拡張することができる
性能が足りなくなったら課金額を増やすだけ 負荷が高くなっても応答速度が低下しない
負荷対策に掛けていた工数を大幅カットできる データ保全性もバッチリ
3箇所の iDC にデータを分散配置 メンテナンスフリー
CloudWatch で負荷状況を監視するだけのお仕事
弊社事例紹介
ファルキューレの紋章
Android 専用アプリ 登録ユーザー数 約 70 万
ファルキューレの紋章 DynamoDB を使って実装された初めての
サービス 最初は DynamoDB のみで実装されていた
のちに MySQL ハイブリッド型へ移行 国内初の DynamoDB for Application 事
例 サービス開始以来、 DB のメンテナンスは課
金額の調整のみ
大激闘!キズナバトル
Android 専用アプリ 登録ユーザー数 約 15 万
大激闘!キズナバトル ファルキューレの紋章の開発で得られた知見を
最大限に生かし、 DynamoDB に最適化した実装を導入。
最初から MySQL ハイブリッド型の構成にした。 メインデータベースとして DynamoDB 集計用データベースとして MySQL
リリース以来、 DB メンテナンスは課金額の調整のみ
大激闘!キズナバトル 毎日 12 時、 19 時、 22 時にチームバトルが
開催されるゲーム仕様のため、スパイク型の負荷が発生する。 22:00:00 に約 15 倍の負荷が突然発生する
バトルで使うテーブルは性能をかなり高めに設定 しかし予約性能を超えない限りは応答速度の低下
は発生しない RDB では難しい芸当も DynamoDB なら余裕で
こなす
システム構成
DynamoDB
WebServers
BatchServers
ELB
RDS (MySQL)
SQS
Internet
AWS 利用料金比率
大激闘 ! キズナバトル 2013 年 6 月度
EC2 (73%)
DynamoDB (11%)
RDS (4%)
Others (12%)
DynamoDB を採用して良かった事
スケールアウトの事を心配しなくて良くなった MySQL だとレプリカを沢山つくって Read のスケー
ルアウトはできたけど、 Write のスケールアウトが難しい。
スケールする仕組みを作ろうとすると、耐障害性設計も大変になって、コストも手間も跳ね上がる。
データ保全の事を心配しなくて良くなった 物理故障に対する対策を自前で用意する必要がなく
なった。
DynamoDB を採用して良かった事
意外と料金が安い! しっかり実装すると DB費用をかなり安く抑えること
ができる。 定期的に値下げのアップデートが空から降ってくる。
性能と費用のバランスコントロールがしやすい 「ここは強気にいきたいからお金を掛けてでも!」 「ここはどうでもいいから費用を最小限に」 ただし相応の技術力が必要
DynamoDB を採用して良かった事
ミドルウェア以下の勉強をする必要性から解放された 分散データベースはただでさえ高度な知識が必要。 RDB でも大規模システムの構築となると必要となる知識量も検証に必要な時間も半端ではなくなる。
我々はサービスを作りたいのであって、システム構築の勉強をしたいわけではない。
勉強や動作検証に使っていた時間をアプリケーションの実装や品質向上のための時間に充てることができる。
DynamoDB を採用して苦労した事
トランザクションとバックアップの仕組みをアプリケーション側で実装しなければならなくなった トランザクションは SQS と楽観的ロックを組み合わせて実装
バックアップはスキーマ設計にジャーナルの概念を取り入れて代替
苦手な事もあるので他システムとの組み合わせが必要 検索と集計ができないので、 MySQL を併用すること
にした
DynamoDB を採用して苦労した事
ソースコードの品質を2段階くらい上げなければならなくなった ちょっとでも汚いコードを書くとすぐにデータの論理破壊が発
生する 酷いときは無限ループに陥る テストも普通の手法ではバグを見つけきれない
エンジニアの教育が大変になった RDB というぬるい環境に慣れきった頭を切り替えさせる必要がある
特性を理解してコードを書かないと分散 DB のメリットを生かせない
情報工学の基礎から教えなければならないことも
データ集計処理の実装
データ集計処理の実装パターン
方法は2つ DynamoDB-MySQL レプリケーション
小~中規模向け DynamoDB-EMR連携
大規模向け
DynamoDB-MySQL レプリケーション
DynamoDB 内のレコードが更新されるたびに MySQL へ1レコード単位でコピーする。
SQS を使って非同期にコピーを行う。 SQL で集計を行い結果を得る。 処理は全てアプリケーション側で実装。
DynamoDB-MySQL レプリケーション
DynamoDB MySQL
DynamoDB-MySQL レプリケーション
非同期にコピー
SQS
DynamoDB MySQL
DynamoDB-MySQL レプリケーション
SQL で集計DynamoDB MySQL
DynamoDB-MySQL レプリケーション
メリット SQL が使えるので柔軟な集計ができる システム構成が小規模で済む 開発が簡単
デメリット 規模が大きくなると RDS インスタンスの性能がボトルネックになる
DynamoDB-MySQL レプリケーション
適している場面 ユーザー数 10 万人以下の活動データの集計
単純な売上集計ならリアルタイムでも集計可能 1 日 1回の集計でよければ 100 万人規模でも大丈夫
集計対象が頻繁に変わる案件 イベントや新規施策の効果測定等
データの発生量が処理可能データ量を超えるまではビッグデータではない!
DynamoDB-EMR連携 RDB で処理しきれない規模になったら取る手段
DynamoDB に蓄積されたデータを EMR連携を使って一気にダンプして Hadoop クラスタへ流し込む!
Map Reduce で集計・解析処理を行い、結果をRDBまたは DynamoDB へ記録する。
DynamoDB-EMR連携
EMR
Hadoop Cluster
DynamoDB
DynamoDB
RDS
for Application
for BIGDATA
DynamoDB-EMR連携 メリット
大量のデータでも高速に処理できる お金を掛ければ掛けるほど速くなる!
デメリット お金がたくさん掛かる システム構成が大掛かりになる 開発が大変
まとめ
DynamoDB はこんな方にオススメ
for Application として使う場合 同時接続 1 万人以上にも耐えられるシステムの構築
に挑戦したい
費用も安く抑えたい データベースのメンテナンスはもうしたくない ミドルウェア以下の勉強はもうしたくない ソースコードの品質には自信がある
DynamoDB はこんな方にオススメ
for BIGDATA として使う場合 ストレージ容量を気にするのはもう嫌だ データ保全の事を気にするのはもう嫌だ データベースの拡張メンテをするのはもう嫌だ お金を掛けてもいいから読み出し性能をもっと欲し
い お金を掛けてもいいから書き込み性能をもっと欲し
い Hadoop 万歳! MapReduce 万歳!
終