Downloaded 20 times
Uploaded byTetsuji Koyama
MongoDB: Case Study for AMN
2011/11/15 に開催された「第7回 MongoDB 勉強会」で発表したプレゼンテーションです。
MongoDB: Case Study for AMN
- 1. MongoDB: Case Study forAMN 小山哲志@アジャイルメディア・ネットワーク @koyhoge
- 2. about me ‣ 小山哲志- koyhoge ‣ アジャイルメディア・ネットワーク社員 ‣ 合同会社ほげ技研 代表社員 ‣ PHPユーザ会スタッフ ‣ 日本UNIXユーザ会幹事 ‣ その他いろいろ
- 3. about AMN ‣ アジャイルメディア・ネットワーク株式会社 ‣ http://agilemedia.jp/ ‣ 2007年2月設立 ‣ ソーシャルメディアマーケティング / キャンペー ン、イベント運営等 ‣ 広告配信もやってます。今日はその話。
- 5. ＡＭＮパートナーブロガー ‣ 2007年に6ブログからスタート ‣ 2011年11月現在で91ブログ ‣他に Tweet アドネットワークが 16媒体
- 6. 配信規模 ‣ ブログアドネットワーク ‣月間 2000万 imps (公式) ‣ Tweetアドネットワーク ‣ 月間 2500万 imps (公式) ‣ 通常は 20∼120 req/s、ピーク時で 300 req/s くらい
- 7. サーバ構成 ‣ フロントWebサーバ2台 ‣Apache + PHP 5.3 + memcached ‣ フレームワークなし ‣ 静的ファイル配信用Webサーバ1台 ‣ nginx ‣ DBサーバ2台(マスター/レプリケーション) ‣ PostgreSQL 9.0
- 8. Log! Log! Log! ‣広告配信なので表示数の記録はたいへん重要 ‣ 以前は配信ログも PostgreSQL に記録していた ‣ AM 4:00 に集計バッチ処理が走る ‣ 2011年4月のサーバ構成変更時にログDBもマ スター/レプリケーションにしたところ、負荷に 負け始める
- 9. PostgreSQLとの闘い ‣ パラメータチューニング ‣ 起動直後は安定して処理をさばく ‣数分∼数十分後(不定)に処理に負け始め、接続数 不足に陥る ‣ cronで5分おきに再起動を仕掛ける回避策 ‣ そうして逃げてる間に抜本的な解決策を探る
- 10. Key Value Store ‣シンプルなデータを大量に保存するので、KVS 向きだった ‣ ただし集計用に group by 機能が欲しい ‣ まずは AWS SimpleDB を試してみる ‣ すいません、クラウドサービス使いたかったん ですw
- 11. Amazon SimpleDB ‣ http://aws.amazon.com/jp/simpledb/ ‣AWSサービス群のひとつ ‣ PHP用の公式 AWS SDK があるのでそれを使う ‣ 使い方はすごく簡単 ‣ SQLのような select 構文が使える
- 12. SimpleDBの結果? ‣ インサートが遅かった ‣ バッチ挿入も試したが少しましな程度 ‣複数台に分散してインサートすると良い? ‣ ということでキュー (Queue) に入れることにし てみる
- 13. Amazon SQS +SDB ‣ Simple Queue Service ‣ REST APIでキュー/デキューできる ‣ 処理の流れ ‣ WebサーバからSQSにデータを突っ込む ‣ SQSから取り出してSDBに入れるワーカーを EC2でつくる ‣ ワーカーを増やせばスケールするんじゃね?
- 14. SQS+SDB? ‣ インサート速度は申し分なし ‣ PHPで書いたワーカーも無事に動作した ‣本番サービスにテスト的に追加 ‣ PostgreSQL と同時に SQS にもログ保存 ‣ 一日運用したコストが$130 ‣ かなりお高いです...
- 15. いよいよMongoDB ‣ SaaS なKVS は諦め、ソフトウェアを探す ‣ MongoDB良さそうだったので、開発用の仮想 マシンサーバ上にテスト環境を構築 ‣ ReplSet 3 x Sharding 3 = 9台 ‣ バージョンは当時の安定版 1.8.1 ‣ Mongo用のPHPドライバも無事動作 ‣ インサートすごく速い ‣ 負荷めちゃ軽い
- 16. MongoDBをEC2で ‣ AWS EC2上にMongoDBのテストベッド構築 ‣Microインスタンス3台で ReplSet ‣ ただしそれぞれのリージョンは分ける ‣ 東京A, 東京B, シンガポールA ‣ Shardingもやろうとしたけどうまく動かなかっ た ‣ ストレージは EBS 1TB
- 17. EC2テストベッド続き ‣ データ入力部分が出来たところで、本番データを 流し始める ‣Microインスタンスでも問題なく処理可能 ‣ その環境をターゲットにバッチ処理部分の開発を 進める
- 18. EC2 Smallの限界? ‣ ある程度バッチ処理の開発ができてきた ‣Mongoに対しても、日時の集計処理を走らせる ようにcron設定 ‣ 翌日集計は完了していたが、ReplSetの Primary が東京A → 東京B に変わっていた。 ‣ さらに翌日には、Primary が東京Aに戻ってい た。
- 19. Primaryピンポン ‣ バッチ処理が走る ‣groupを呼び出す比較的重い処理が複数 ‣ Primaryが過負荷になってSecondaryの要求に 応えなくなる ‣ S「Primary落ちてるんじゃね?」 ‣ S「わーい投票投票」 ‣ S(東京B)「俺近いし次プライマリーやるわ」 ‣ P(東京A)「仕事をしていたらいつの間にかプラ イマリーではなくなっていた...」
- 20. 本番環境はLargeに ‣ 御存知の通りMongoDBは 32bitLinux では実 用にならない。 ‣ EC2 Small インスタンスでは 64bit Linux は 使えない。 ‣ 自動的に Large 3台構成に ‣ 配置は Micro の時と同じ ‣ Large だとさすがにピンポンは起きませんでし たw
- 21.
- 22. 知見 ‣ Shardingなしでも十分速い ‣ 大規模障害対策として、AWS東京+シンガポー ルは使える ‣ シンガポールのSecondaryを見ても、ほとん ど遅れなく同期している ‣ JSスキーにとってはMongoかわいい
- 23. EC2使用料 ‣ Large x3 ‣ CloudWatch (Monitoring) ‣ Reserved Instances ‣ 月額 $800 くらい
- 24. まとめ ‣ MongoDB のおかげで急激なトラフィックにも 恐れること無く、枕を高くして眠ることができま す。 ‣ doryokujinさんいつもありがとうございます。 ‣ Fluent 使いたいです！ ‣ Aggregation Mongo 使いたいです!!
- 25.