Mongo Tokyo 2012で発表した資料。 Animal LandでMongoDBを利用する際に考慮した点などなど。

1. ソーシャルゲームにおける
MongoDB適用事例
Masakazu Matsushita
Cyberagent, Inc.

2. About Me
• 松下 雅和 / Masakazu Matsushita
• @matsukaz
• Cyberagent, Inc. - SocialApps Division
- Ameba Pico (2011/01∼)
• 海外向けピグ
- Animal Land (2011/03∼)
• DevLOVE Staff

3. Agenda
• サービス概要
• システム構成
• MongoDB採用のポイント
• MongoDB利用時に考慮した点
• 発生した障害
• 今後の課題
• etc

4. サービス概要

5. Demo

6. 開発期間
• 2011/03から開発スタート
• 初ミーティングが 3.11
• 本格的な開発は2011/05から
• 2011/12/09 リリース

7. 開発メンバー
• Producer 2
• Designer 1
• Flash Developer 3
• Engineer 4
+α

8. システム構成

9. 利用サービス
• Amazon Web Services
- EC2 (Instance Store + EBS)
- S3
- CloudFront
- Route53
- Elastic Load Balancing
• Google Apps
• Kontagent

10. システム間のつながり
iframe 各種API呼び出し
課金コールバック
Web
HTML
サーバ
JSON
Flash
Command
AMF サーバ
AMF : Actionscript Message Format

11. L m1.large
サーバ構成 XX
EBS
m2.2xlarge
EBS
ELB ELB
S3
Web L 3 Command L 4 CloudFront
nginx nginx Route 53
Tomcat Tomcat
バッチ L
mongos mongos
バッチ
MySQL
Shard 5 MySQL L memcached L 2
monitor L
MongoDB XX MySQL memcached
EBS munin
mongod
MySQL L nagios
MongoDB XX
MySQL admin L ビルド L
mongod EBS
nginx redmine
MongoDB XX MongoDB XX 3 Tomcat jenkins
mongod mongoc
EBS EBS mongos Maven SVN
EBS
Secondary

12. ミドルウェア
• nginx 1.0.x
• Tomcat 7.0.x
• MongoDB 2.0.1
• MySQL 5.5.x
• memcached 1.4.x

13. フレームワーク／ライブラリ
• Spring Framework、Spring MVC
• BlazeDS、Spring Flex
• Spring Data - MongoDB 1.0.0 M4
• mongo-java-driver 2.6.5
• Ehcache
• spymemcached
• RestFB
• MyBatis

14. MongoDB
採用のポイント

15. • Ameba Picoでの利用実績
http://apps.facebook.com/amebapico/

16. • MongoDBの良さ
- ReplicaSetによる耐障害性
- Auto-Shardingによるスケールしやすさ
- 複雑なデータ構造を扱える
- Index、Advanced Queries
- 開発チームがアクティブ
- 敷居が低い

17. • Animal Landの要件に合う
- 複雑なデータ構造 (街のグリッド情報、
ユーザ／建築物のパラメータ、etc)
- シーケンシャル処理中心で、同時更新が
少ない
- メンテナンスレス
• データ構造の動的変更
• 耐障害性
• スケールアウト

18. • 苦手な部分は他の方法で解決
- 特性に合わないデータは他のDBで
• 信頼性が必要な課金関連はMySQL
• 一時的なデータはmemcached
- トランザクションは利用しない

19. MongoDB
利用時に考慮した点

20. アプリケーション開発時
• トランザクションがいらないデータ構造に
- ユーザ情報などは、1ドキュメントで保
持して一括更新
ユーザ情報
{ facebookId : xxx,
イメージ
status : { lv : 10, coin : 9999, ... },
layerInfo : 1¦1¦0¦1¦2¦1¦1¦3¦1¦1¦4¦0... ,
structure : {
1¦1 : { id : xxxx, depth : 3, width : 3, aspect : 1, ... }, ...
},
inventory : [ { id : xxx, size : xxx, ... }, ... ],
neighbor : [ { id : xxx, newFlg : false, ... }, ... ],
animal : [ { id : xxx, color : 0, pos : 20¦20 , ... } ],
...
}

21. アプリケーション開発時
• データ量を可能な限り削減
- 街のグリッド情報を1つのデータで保持
するなど (プログラム側で展開)
- 設計時の構造（500 KB）
layerInfo : {
1¦1 : 0,
1¦2 : 1,
....
}
- 現在の構造（50 KB）
layerInfo : 1¦1¦0¦1¦2¦1¦1¦3¦1¦1¦4¦0...

22. アプリケーション開発時
• フィールド数は多すぎないように
- 2万以上のフィールド (144x144の街の
グリッド情報 )を持つと、find()にっかる
時間は5秒以上に・・・
- データ量だけでなく、BSONのパースに
かかる時間も考慮する

23. アプリケーション開発時
• Shard Keyは以下の方針で決定
- カーディナリティが低い値は使わない
- よく使われるデータがメモリ上に乗る
- 使われないデータはメモリ上に乗らない
- 参照や更新が多いデータはバランスよく
各Shardに分散
- Targetedオペレーション
での利用を意識 (後述)
おすすめ書籍 →

24. アプリケーション開発時
• Targetedオペレーションを中心に
- Shard Keyでデータを操作
- Shard Key以外の操作はIndexを利用
Operation Type
db.foo.find({ShardKey : 1}) Targeted
db.foo.find({ShardKey : 1, NonShardKey : 1}) Targeted
db.foo.find({NonShardKey : 1}) Global
db.foo.find() Global
db.foo.insert(<object>) Targeted
db.foo.update({ShardKey : 1}, <object>) Targeted
db.foo.remove({ShardKey : 1})
db.foo.update({NonShardKey : 1}, <object>) Global
db.foo.remove({NonShardKey : 1})

25. アプリケーション開発時
• 更新頻度をなるべく減らす
- マスタ情報はサーバ上でキャッシュ
- ユーザ操作はまとめて処理 (5秒に1度)
• Flash側でキューの仕組みを用意
• サーバ側はキューから取り出してシーケ
ンシャルに処理
シーケンシャル処理
ユーザ操作
キューで保持
キュー
Command
Flash
サーバ
まとめて送信

26. アプリケーション開発時
• O/Rマッパーで開発を効率化
- Spring Data - MongoDBとラッパーク
ラスを用意して効率よく開発
@Autowired
protected MongoTemplate mongoTemplate;
public void insert(T entity) {
mongoTemplate.save(entity);
}
- オブジェクトをそのまま利用できるの
で、RDBのO/Rマッパーより扱いやすい
- Javaでも言うほど大変じゃない

27. アプリケーション開発時
• ロールバック出来ない前提で実装
- ある程度のデータ不整合は諦める
- 必ずユーザが不利益を被らないようにす
る

28. インフラ構築時
• 従来のDBと同様に見積もり
- データ量／1ユーザ (50 KB)
- 想定ユーザ数 (DAU 70万)
- データの更新頻度
- 各サーバの最大同時接続数
- 各サーバの台数、スペック、コスト
- 想定ユーザ数を超えた場合のスケールの
ポイント整理

29. インフラ構築時
• 性能検証
- 帯域幅を確認 (350Mbps程度)
- MongoDBを検証 (MongoDB 2.0.1、
ReplicaSetのShardを2つ、ジャーナリ
ング有効)
• 参照／更新の処理性能
• マイグレーション時の性能比較
• Javaドライバー経由の性能比較
- アプリケーションを通した性能を確認

30. インフラ構築時
• 障害を想定した動作検証
- mongodが落ちた場合
• PRIMARYへ昇格するか
• 起動したらデータが同期されるか
• SECONDARYが落ちても問題ないか
- mongocが落ちた場合
• 全体の動作に影響がないか
- バックアップから戻せるか
→ 全て問題ナシ

31. インフラ構築時
• ReplicaSet、Shardの構成と配置を決定
- メモリサイズを大きめ
- ディスクI/Oが高速
- mongocはmongodと別サーバに
- 信頼性を高めるためにEBS利用 (負荷軽
減のためSECONDARY専用に)
• ジャーナリングを有効に
• oplogsizeを10GBに (デフォルトの全体の
5%が多すぎるため)

32. インフラ構築時
• 必要なIndexはあらかじめ作成しておく
- 通常のIndex作成中は、全てのオペレー
ションがブロックされてしまうため
- 20万件のデータ (それぞれ50KB程度)
にIndexを貼ると、２分程度かかる
- あとから追加する場合は、メンテ中に作
成するか、バックグラウンドで作成

33. インフラ構築時
• コネクションプールをチューニング
※ mongosに対するコネクションプール
項目 意味 値
connectionsPerHost コネクション数 100
threadsAllowedToBlockFor 1コネクション辺りの
4
ConnectionMultiplier 接続待ち数
- nginxのworker数、TomcatのThread数
とのバランスを考慮して設定
- プールが足りなくなったときのエラー
(Out of Semaphores) に注意
上記例では、100 + (100 * 4) = 500

34. 運用時
• db.printShardingStatus()でShard間の
chunkの偏りを定期的にチェック
- 必要があれば手動でchunk移動
• 新しいCollectionの追加は慎重に
- 最初はPrimary Shardにデータが偏り、
急激な負荷がかかる可能性があるため

35. 発生した障害

36. mongodとmongocダウン
• mongoc1台 & mongod1台
(SECONDARY) が落ちた
• 原因はEC2インスタンスの仮想サーバホス
トの障害、MongoDBは悪くない
• サービスへの影響はゼロ！
• プロセスを起動するだけで復旧！！

37. 今後の課題

38. オンライン・バックアップ
• やはり難しい
• 当面はメンテを入れてバックアップ
• 以下のSECONDARYバックアップも検討
中
1. balancerをオフに
2. SECONDARYでwrite lockをかけて
ディレクトリ毎バックアップ
3. SECONDARYのロックを解除

39. Upgrade
• サービスを運用しているとUpgradeのタイ
ミングが難しい
• 以下のアップグレードの手順が必要
1. Arbiterを停止、Upgrade、起動
2. SECONDARYを停止、Upgrade、起動
3. PRIMARYを停止、Upgrade、起動

40. Shardの追加
• Shard追加は可能だが、追加時のバランシ
ングがパフォーマンスに与える影響が読め
ない
- Picoではパフォーマンスの影響が問題と
なったため、メンテ中に対応している

41. 最適なchunksize
• ユーザ情報のデータサイズが大きかったた
め、デフォルトの64MBだとマイグレー
ションが多発
• データサイズに合わせて調整する必要があ
る
Collectionごとにchunksizeが設定出来るよ
うになって欲しいです・・・

42. データの分析
• ユーザ情報を１つにまとめたため、データ
の分析がやりづらい
• 必要に応じてIndexを貼って対応中
- MapReduceも試したが、検証時にパ
フォーマンスに影響が出たので利用して
いない

43. ご清聴
ありがとうございました