2013-07-16 株式会社マイネット 伊藤　祐策

DynamoDB 活用事例

目次

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

自己紹介

自己紹介

名前　　伊藤　祐策 所属　　株式会社マイネット 肩書き　アーキテクト 業務内容

インフラ設計 アプリケーション設計 エンジニア教育

会社紹介

会社名　株式会社マイネット 業種　　 インターネットサービス業 主な事業内容

Android 専用ソーシャルゲームの提供

DynamoDBの用途について

DynamoDB の用途は 2 通り DynamoDB の用途は２つに大分できる

for BIGDATA 大量のデータを収集・蓄積・分析する

for Application 無限の負荷分散能力を以て大規模サービスを実現する

※ 弊社事例は for Application です

DynamoDB のスゴイところ 無制限に性能を拡張することができる

性能が足りなくなったら課金額を増やすだけ 負荷が高くなっても応答速度が低下しない

負荷対策に掛けていた工数を大幅カットできる データ保全性もバッチリ

３箇所の 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 を採用して苦労した事

ソースコードの品質を２段階くらい上げなければならなくなった ちょっとでも汚いコードを書くとすぐにデータの論理破壊が発

生する 酷いときは無限ループに陥る テストも普通の手法ではバグを見つけきれない

エンジニアの教育が大変になった RDB というぬるい環境に慣れきった頭を切り替えさせる必要がある

特性を理解してコードを書かないと分散 DB のメリットを生かせない

情報工学の基礎から教えなければならないことも

データ集計処理の実装

データ集計処理の実装パターン

方法は２つ DynamoDB-MySQL レプリケーション

小～中規模向け DynamoDB-EMR連携

大規模向け

DynamoDB-MySQL レプリケーション

DynamoDB 内のレコードが更新されるたびに MySQL へ１レコード単位でコピーする。

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 万歳！

終