ソーシャルゲームにおけるMongoDB適用事例 - Animal Land

21,793 views

Published on

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

Published in: Technology
0 Comments
62 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
21,793
On SlideShare
0
From Embeds
0
Number of Embeds
4,947
Actions
Shares
0
Downloads
145
Comments
0
Likes
62
Embeds 0
No embeds

No notes for slide

ソーシャルゲームにおけるMongoDB適用事例 - Animal Land

  1. 1. ソーシャルゲームにおける MongoDB適用事例 Masakazu Matsushita Cyberagent, Inc.
  2. 2. About Me• 松下 雅和 / Masakazu Matsushita• @matsukaz• Cyberagent, Inc. - SocialApps Division - Ameba Pico (2011/01∼) • 海外向けピグ - Animal Land (2011/03∼)• DevLOVE Staff
  3. 3. Agenda• サービス概要• システム構成• MongoDB採用のポイント• MongoDB利用時に考慮した点• 発生した障害• 今後の課題• etc
  4. 4. サービス概要
  5. 5. Demo
  6. 6. 開発期間• 2011/03から開発スタート• 初ミーティングが 3.11• 本格的な開発は2011/05から• 2011/12/09 リリース
  7. 7. 開発メンバー• Producer 2• Designer 1• Flash Developer 3• Engineer 4 +α
  8. 8. システム構成
  9. 9. 利用サービス• Amazon Web Services - EC2 (Instance Store + EBS) - S3 - CloudFront - Route53 - Elastic Load Balancing• Google Apps• Kontagent
  10. 10. システム間のつながりiframe 各種API呼び出し 課金コールバック Web HTML サーバ JSON Flash Command AMF サーバ AMF : Actionscript Message Format
  11. 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 バッチ MySQLShard 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 mongocEBS EBS mongos Maven SVN EBS Secondary
  12. 12. ミドルウェア• nginx 1.0.x• Tomcat 7.0.x• MongoDB 2.0.1• MySQL 5.5.x• memcached 1.4.x
  13. 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. 14. MongoDB採用のポイント
  15. 15. • Ameba Picoでの利用実績 http://apps.facebook.com/amebapico/
  16. 16. • MongoDBの良さ - ReplicaSetによる耐障害性 - Auto-Shardingによるスケールしやすさ - 複雑なデータ構造を扱える - Index、Advanced Queries - 開発チームがアクティブ - 敷居が低い
  17. 17. • Animal Landの要件に合う - 複雑なデータ構造 (街のグリッド情報、 ユーザ/建築物のパラメータ、etc)- シーケンシャル処理中心で、同時更新が 少ない- メンテナンスレス • データ構造の動的変更 • 耐障害性 • スケールアウト
  18. 18. • 苦手な部分は他の方法で解決 - 特性に合わないデータは他のDBで • 信頼性が必要な課金関連はMySQL • 一時的なデータはmemcached - トランザクションは利用しない
  19. 19. MongoDB利用時に考慮した点
  20. 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. 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. 22. アプリケーション開発時• フィールド数は多すぎないように - 2万以上のフィールド (144x144の街の グリッド情報 )を持つと、find()にっかる 時間は5秒以上に・・・ - データ量だけでなく、BSONのパースに かかる時間も考慮する
  23. 23. アプリケーション開発時• Shard Keyは以下の方針で決定 - カーディナリティが低い値は使わない - よく使われるデータがメモリ上に乗る - 使われないデータはメモリ上に乗らない - 参照や更新が多いデータはバランスよく 各Shardに分散- Targetedオペレーション での利用を意識 (後述) おすすめ書籍 →
  24. 24. アプリケーション開発時• Targetedオペレーションを中心に - Shard Keyでデータを操作 - Shard Key以外の操作はIndexを利用 Operation Typedb.foo.find({ShardKey : 1}) Targeteddb.foo.find({ShardKey : 1, NonShardKey : 1}) Targeteddb.foo.find({NonShardKey : 1}) Globaldb.foo.find() Globaldb.foo.insert(<object>) Targeteddb.foo.update({ShardKey : 1}, <object>) Targeteddb.foo.remove({ShardKey : 1})db.foo.update({NonShardKey : 1}, <object>) Globaldb.foo.remove({NonShardKey : 1})
  25. 25. アプリケーション開発時• 更新頻度をなるべく減らす - マスタ情報はサーバ上でキャッシュ - ユーザ操作はまとめて処理 (5秒に1度) • Flash側でキューの仕組みを用意 • サーバ側はキューから取り出してシーケ ンシャルに処理 シーケンシャル処理 ユーザ操作 キューで保持 キュー Command Flash サーバ まとめて送信
  26. 26. アプリケーション開発時• O/Rマッパーで開発を効率化 - Spring Data - MongoDBとラッパーク ラスを用意して効率よく開発 @Autowired protected MongoTemplate mongoTemplate; public void insert(T entity) { mongoTemplate.save(entity); } - オブジェクトをそのまま利用できるの で、RDBのO/Rマッパーより扱いやすい - Javaでも言うほど大変じゃない
  27. 27. アプリケーション開発時• ロールバック出来ない前提で実装 - ある程度のデータ不整合は諦める - 必ずユーザが不利益を被らないようにす る
  28. 28. インフラ構築時• 従来のDBと同様に見積もり - データ量/1ユーザ (50 KB) - 想定ユーザ数 (DAU 70万) - データの更新頻度 - 各サーバの最大同時接続数 - 各サーバの台数、スペック、コスト - 想定ユーザ数を超えた場合のスケールの ポイント整理
  29. 29. インフラ構築時• 性能検証 - 帯域幅を確認 (350Mbps程度) - MongoDBを検証 (MongoDB 2.0.1、 ReplicaSetのShardを2つ、ジャーナリ ング有効) • 参照/更新の処理性能 • マイグレーション時の性能比較 • Javaドライバー経由の性能比較 - アプリケーションを通した性能を確認
  30. 30. インフラ構築時• 障害を想定した動作検証 - mongodが落ちた場合 • PRIMARYへ昇格するか • 起動したらデータが同期されるか • SECONDARYが落ちても問題ないか - mongocが落ちた場合 • 全体の動作に影響がないか - バックアップから戻せるか → 全て問題ナシ
  31. 31. インフラ構築時• ReplicaSet、Shardの構成と配置を決定 - メモリサイズを大きめ - ディスクI/Oが高速 - mongocはmongodと別サーバに - 信頼性を高めるためにEBS利用 (負荷軽 減のためSECONDARY専用に)• ジャーナリングを有効に• oplogsizeを10GBに (デフォルトの全体の 5%が多すぎるため)
  32. 32. インフラ構築時• 必要なIndexはあらかじめ作成しておく - 通常のIndex作成中は、全てのオペレー ションがブロックされてしまうため - 20万件のデータ (それぞれ50KB程度) にIndexを貼ると、2分程度かかる - あとから追加する場合は、メンテ中に作 成するか、バックグラウンドで作成
  33. 33. インフラ構築時• コネクションプールをチューニング ※ mongosに対するコネクションプール 項目 意味 値 connectionsPerHost コネクション数 100 threadsAllowedToBlockFor 1コネクション辺りの 4 ConnectionMultiplier 接続待ち数- nginxのworker数、TomcatのThread数 とのバランスを考慮して設定- プールが足りなくなったときのエラー (Out of Semaphores) に注意 上記例では、100 + (100 * 4) = 500
  34. 34. 運用時• db.printShardingStatus()でShard間の chunkの偏りを定期的にチェック - 必要があれば手動でchunk移動• 新しいCollectionの追加は慎重に - 最初はPrimary Shardにデータが偏り、 急激な負荷がかかる可能性があるため
  35. 35. 発生した障害
  36. 36. mongodとmongocダウン• mongoc1台 & mongod1台 (SECONDARY) が落ちた• 原因はEC2インスタンスの仮想サーバホス トの障害、MongoDBは悪くない• サービスへの影響はゼロ!• プロセスを起動するだけで復旧!!
  37. 37. 今後の課題
  38. 38. オンライン・バックアップ• やはり難しい• 当面はメンテを入れてバックアップ• 以下のSECONDARYバックアップも検討中1. balancerをオフに2. SECONDARYでwrite lockをかけて ディレクトリ毎バックアップ3. SECONDARYのロックを解除
  39. 39. Upgrade• サービスを運用しているとUpgradeのタイ ミングが難しい• 以下のアップグレードの手順が必要 1. Arbiterを停止、Upgrade、起動 2. SECONDARYを停止、Upgrade、起動 3. PRIMARYを停止、Upgrade、起動
  40. 40. Shardの追加• Shard追加は可能だが、追加時のバランシングがパフォーマンスに与える影響が読めない- Picoではパフォーマンスの影響が問題と なったため、メンテ中に対応している
  41. 41. 最適なchunksize• ユーザ情報のデータサイズが大きかったた め、デフォルトの64MBだとマイグレー ションが多発• データサイズに合わせて調整する必要があ るCollectionごとにchunksizeが設定出来るようになって欲しいです・・・
  42. 42. データの分析• ユーザ情報を1つにまとめたため、データ の分析がやりづらい• 必要に応じてIndexを貼って対応中 - MapReduceも試したが、検証時にパ フォーマンスに影響が出たので利用して いない
  43. 43. ご清聴ありがとうございました

×