MongoDB CouchDB合同勉強会-2010-12-14

Ameba Picoと

MongoDBSuguru NamuraCyberAgent, Inc.

MongoDB + CouchDB Study Session - Ameba Pico と MongoDB

About me

名村　卓 (30)

@snamura

株式会社サイバーエージェント

アメーバピグ、 Ameba Picoプーペガール、メロメロパークなど


Ameba Pico

累計登録ユーザー数 3,000,000

DAU 70,000 / MAU 560,000

Amazon EC2 上で稼働

30台くらい

MongoDBは9台


なぜ MongoDB にしたか


MongoDB導入前の構成

Distributed Database

HAProxy

Socket Servers Application Servers

Amazon S3


データベースの条件

バイナリ形式に対応している

キーに対する Range Scan が可能

Horizontal Partitioning による分散

開発チームがアクティブ


MongoDBBSON

インデクスのサポート

Sharding による分散

Chunk の分割の方式が既存のものと同じだった

開発チームが積極的でアクティブ


MongoDB導入まで


最初の計画

Arbitery

Shard 1

Primary

Secondaryconfig

mongos

Shard 1

Primary

Secondaryconfig

mongos

Shard 1

Primary

Secondaryconfig

mongos

Socket Server


導入した構成

Shard 1

Primary

Secondary

Secondaryconfig

Shard 2

Primary

Secondary

Secondaryconfig

Shard 3

Primary

Secondary

Secondaryconfig

Socket Servermongos


Amazon EC2

mongoDB は 64bit 推奨なので、最低でも Large インスタンスを使う

Replica Set のセカンダリの１台に EBS を使いデータを保護

EBS はスナップショットも取れる


Amazon EC2

Shard

Primary

Secondary

Secondaryconfig

High-CPU Extra Large

High-CPU Extra Large

Large

8 Core7.0 GB

I/O: High

2 Core7.5 GB

I/O: HighEBS


データ移行既存のデータ Key Value のデータ形式

バイナリのソート方式が違う(signed byte?)ので、Key は HEX形式の文字列に変換

{ _id: ObjectId, key: String, value: byte[] }

ObjectId は結果として必要なし

Insert 1件ずつだと時間がかかるので、bulk insert を使って 1,000 件ずつレコードを投入して移行

10,000 insert / sec くらいは普通に出る


プログラムの対応

データアクセスのレイヤーを分離していたので、小さな修正で完了

load, save, fetch, count


遭遇した問題


ファイルシステム

ext3 は extent に時間がかかる

推奨されているのは ext4, xfs

Ameba Pico は ext4


Sharding の偏り

Sharding は普通に運用すると偏る

web から各コレクションのアクセス量を確認できる

アクセス量の多いコレクションを moveChunk コマンドで移動する


Sharding の偏り

ドキュメント量の少ないコレクションは、Read, Write が偏る

適宜アプリケーションで対処する必要がある


接続プール

Java のドライバーが接続プールを使う

同時処理がプール数 x Multiplier が超えると Out of semaphores が起きる

ファイルオープン数を増やして、スレッド数やプール数を調整する


Primary 選出問題

EBS を使っている Secondary の Priority を 0 にして、 Primary に昇格しないようにしていた



Shard 1

Primary

Secondary

Secondaryconfig priority 0



oplog ちょっと古い

oplog 最新

Shard 1

Primary

Secondary




Shard 1

Primary

Secondary


oplog ちょっと古い

oplog 最新

Primary よろしく

無理です



Primary が起動していない Replica Set は、通常の方法では設定を変えられない

stepDown などが実行できない

config サーバー全台の内容を直接変更

復旧はした


よかったところ思ったよりずっと安定している

プロトコルがシンプルでノンブロッキングIOなドライバへの対応が容易

Atomic modifiers 便利

Sharding + Replica Set

mmap を活用するので、基本メモリキャッシュに乗る


気になるところ

Durability

Chunk が分割されるときのフリーズ

Sharding の安定性

Primary がダウンしたときのデータロス

ディスク容量を結構使う


Ameba PicoStatistics




今後の取り組み


アメーバピグのリアルタイム販売アイテムレポートに使用中

map reduce を活用していく

開発中のいくつかのサービスに採用


WebSocket + node.js + mongoDB

webworker 対応に期待

Java Asynchronous Driverhttps://github.com/suguru/mongo-java-async-driver

Python, Ruby


終わり

Technology

MongoDB CouchDB合同勉強会-2010-12-14