mongodb: case study for amn

MongoDB: Case Study for AMN小山哲志@アジャイルメディア・ネットワーク

@koyhoge

about me

‣小山哲志 - koyhoge‣アジャイルメディア・ネットワーク社員‣合同会社ほげ技研 代表社員‣PHPユーザ会スタッフ‣日本UNIXユーザ会幹事‣その他いろいろ

about AMN

‣アジャイルメディア・ネットワーク株式会社‣http://agilemedia.jp/‣2007年2月設立‣ソーシャルメディアマーケティング / キャンペーン、イベント運営等‣広告配信もやってます。今日はその話。

ＡＭＮパートナーブロガー

‣2007年に6ブログからスタート‣2011年11月現在で91ブログ‣他に Tweet アドネットワークが 16媒体

配信規模

‣ブログアドネットワーク‣月間 2000万 imps (公式)‣Tweetアドネットワーク‣月間 2500万 imps (公式)‣通常は 20～120 req/s、ピーク時で 300 req/s くらい

サーバ構成

‣フロントWebサーバ2台‣Apache + PHP 5.3 + memcached‣フレームワークなし‣静的ファイル配信用Webサーバ1台‣nginx‣DBサーバ2台(マスター/レプリケーション)‣PostgreSQL 9.0

Log! Log! Log!

‣広告配信なので表示数の記録はたいへん重要‣以前は配信ログも PostgreSQL に記録していた‣AM 4:00 に集計バッチ処理が走る‣2011年4月のサーバ構成変更時にログDBもマスター/レプリケーションにしたところ、負荷に負け始める

PostgreSQLとの闘い

‣パラメータチューニング‣起動直後は安定して処理をさばく‣数分～数十分後(不定)に処理に負け始め、接続数不足に陥る‣cronで5分おきに再起動を仕掛ける回避策‣そうして逃げてる間に抜本的な解決策を探る

Key Value Store

‣シンプルなデータを大量に保存するので、KVS 向きだった‣ただし集計用に group by 機能が欲しい‣まずは AWS SimpleDB を試してみる‣すいません、クラウドサービス使いたかったんですw

Amazon SimpleDB

‣http://aws.amazon.com/jp/simpledb/‣AWSサービス群のひとつ‣PHP用の公式 AWS SDK があるのでそれを使う‣使い方はすごく簡単‣SQLのような select 構文が使える

SimpleDBの結果?

‣インサートが遅かった‣バッチ挿入も試したが少しましな程度‣複数台に分散してインサートすると良い?‣ということでキュー (Queue) に入れることにしてみる

Amazon SQS + SDB

‣Simple Queue Service‣REST APIでキュー/デキューできる‣処理の流れ‣WebサーバからSQSにデータを突っ込む‣SQSから取り出してSDBに入れるワーカーをEC2でつくる‣ワーカーを増やせばスケールするんじゃね?

SQS+SDB?

‣インサート速度は申し分なし‣PHPで書いたワーカーも無事に動作した‣本番サービスにテスト的に追加‣PostgreSQL と同時に SQS にもログ保存‣一日運用したコストが$130‣かなりお高いです...

いよいよMongoDB‣SaaS な KVS は諦め、ソフトウェアを探す‣MongoDB良さそうだったので、開発用の仮想マシンサーバ上にテスト環境を構築‣ReplSet 3 x Sharding 3 = 9台‣バージョンは当時の安定版 1.8.1‣Mongo用のPHPドライバも無事動作‣インサートすごく速い‣負荷めちゃ軽い

MongoDBをEC2で

‣AWS EC2上にMongoDBのテストベッド構築‣Microインスタンス3台で ReplSet‣ただしそれぞれのリージョンは分ける‣東京A, 東京B, シンガポールA‣Shardingもやろうとしたけどうまく動かなかった‣ストレージは EBS 1TB

EC2テストベッド続き

‣データ入力部分が出来たところで、本番データを流し始める‣Microインスタンスでも問題なく処理可能‣その環境をターゲットにバッチ処理部分の開発を進める

EC2 Smallの限界?

‣ある程度バッチ処理の開発ができてきた‣Mongoに対しても、日時の集計処理を走らせるようにcron設定‣翌日集計は完了していたが、ReplSetの Primary が東京A → 東京B に変わっていた。‣さらに翌日には、Primary が東京Aに戻っていた。

Primaryピンポン‣バッチ処理が走る‣groupを呼び出す比較的重い処理が複数‣Primaryが過負荷になってSecondaryの要求に応えなくなる‣S「Primary落ちてるんじゃね?」‣S「わーい投票投票」‣S(東京B)「俺近いし次プライマリーやるわ」‣P(東京A)「仕事をしていたらいつの間にかプライマリーではなくなっていた...」

本番環境はLargeに

‣御存知の通りMongoDBは 32bit Linux では実用にならない。‣EC2 Small インスタンスでは 64bit Linux は使えない。‣自動的に Large 3台構成に‣配置は Micro の時と同じ‣Large だとさすがにピンポンは起きませんでしたw

ある日のプライマリーさん

知見

‣Shardingなしでも十分速い‣大規模障害対策として、AWS 東京+シンガポールは使える‣シンガポールのSecondaryを見ても、ほとんど遅れなく同期している

‣JSスキーにとってはMongoかわいい

EC2使用料

‣Large x 3‣CloudWatch (Monitoring)‣Reserved Instances‣月額 $800 くらい

まとめ

‣MongoDB のおかげで急激なトラフィックにも恐れること無く、枕を高くして眠ることができます。‣doryokujinさんいつもありがとうございます。‣Fluent 使いたいです！‣Aggregation Mongo 使いたいです!!

提供アジャイルメディア・ネットワーク株式会社