AmebaのMongoDB活用事例

AmebaのMongoDB活用事例

株式会社サイバーエージェントアメーバ事業本部ピグディヴィジョン

　　　　　　　　　　　　　　　　桑野　章弘

12年8月24日金曜日

アジェンダ

nAmebaのサービスnサービス環境の変遷nサービスを支えるMongoDBn困ったことなどn運用についてnまとめ


n桑野章弘lサイバーエージェント

lAmeba を運営しています。lピグソーシャルゲームの運用／構築を担当

lTwitterl @kuwa_tw

lBloglhttp://d.hatena.ne.jp/akuwano/

自己紹介


http://d.hatena.ne.jp/akuwano/

http://d.hatena.ne.jp/akuwano/

ピグライフ


ピグライフ

nサービス情報l2011/05/31オープンl会員数360万人（2012/01現在）lサービス開始3週間で100万人突破l接続数：20万同時接続


ピグアイランド


ピグアイランド

nサービス情報l2012/05/22オープンlサービス開始5日で100万人突破l接続数：約10万同時接続


ピグカフェ


ピグカフェ

nサービス情報l2012/08/21オープン


様々なサービスをピグプラットフォームで

展開中12年8月24日金曜日

これらのサービスは全てMongoDBを使っ

ています12年8月24日金曜日

サービス環境の変遷


nまずは弊社サービスの成長の変遷について説明します


アーキテクチャ

nアプリケーションサーバlNode.jslNginx

nデータストアサーバlMongoDB


アーキテクチャ

staticサーバ Socketサーバ

mongodbサーバ

WebSocket接続

Node.jsサーバ

ユーザ（ブラウザ：Flash）

FrontEndBackEnd

Flashデータ→リクエスト/取得

・ユーザ情報・チャットデータ→リクエスト/取得

必要なデータの取得

ユーザ/エリア等の状態データ

HTTP


[ピグライフ]の変遷


ピグライフ

nリリースから現在lβテスト時代lリリース後l現在


ピグライフ

nリリースから現在lβテスト時代lリリース後l現在

どんなフェーズを経たか


ピグライフ：βテスト時代

n4/26～5/31lテストユーザ数5000～30000 l毎日リリース、機能追加、インフラ構成変更lサーバも最小限を用意


ピグライフ：βテスト時代

Staticサーバ Node.jsサーバ MongoDB Log

MongoDB

×6

行動ログの保存

mongos

βテスト時に実装


ピグライフ：リリース後

n問題点洗い出しのフェーズlNode.jsのサーバや、mongodbも、パフォーマンスが出ていなかったため増設

lSwfファイルをnode.jsのサーバから静的ファイル専用のサーバへと切り出す



n5/31 ～lピグライフ、正式リリースl人気が爆発、予想以上の伸びl開始3週間(6/22)で100万人突破lとにかく増設の時期


リリース時構成

Staticサーバ Node.jsサーバ MongoDB Log

MongoDB

×44

行動ログの保存サーバにも取得

1シャード追加 (合計4シャー

ド)

大量追加

mongos

×3



nパフォーマンス確保のフェーズlボトルネック調査l状況を見つつサーバ台数、リソースの確保


ピグライフ：現在

n9/1 ～l順調な成長l開始3ヶ月弱(8/22)で200万人突破


現在時構成

Staticサーバ_A系 Node.jsサーバ_A系

MongoDB

×10

行動ログの保存DB統合

23シャード追加(合計27シャード＝81

台)

高スペックサーバにリプレイス

mongos

・・・・・

×5

Staticサーバ_B系

mongos

×10Node.jsサーバ_B系

×5

リリース時切替


ピグライフ：現在

n運用改善のフェーズlメンテ時間短縮のため稼働グループを分割

lA系、B系での切替

l構成はシンプルにしていくlCDNなどの導入検討（CDNを入れられるように仕様変更）


ピグライフ：成長速度

n成長速度lリリースから3ヶ月程度で、サーバ規模としては8倍に。それにともなって、トラフィック(1.3Gbps)、総コネクション数(18万)も増加。

lその期間は3ヶ月余り。3週間の伸びは単位にすれば30倍

サービスの予想以上の成長


サービスを支えるMongoDB


この成長速度を支えたMongoDBの基本的

な機能12年8月24日金曜日

MongoDBの構成アプリケーションサー

バ

mongos

mongoc

Mongod[ShardB]

Mongod[ShardC]

Mongod[ShardA]


アーキテクチャについて

nシステムアーキテクチャlスキーマレス l冗長化

lReplicaSets

lスケーラビリティlSharding


アーキテクチャの課題

nスキーマレスなデータ構造による柔軟なデータ管理lユーザ情報なども柔軟に持つことができるので、機能追加時等が比較的楽

l次ページ例



nスキーマレスなデータ構造lユーザーコレクションに趣味を追加したい場合

{ "_id" : "1234567889", "userid" : "akuwano",

"username" : "Akihiro Kuwano"}

{ "_id" : "1234567889", "userid" : "akuwano", "hobby" : “Movie”,

"username" : "Akihiro Kuwano"}



nReplicaSetsl相互死活監視＆投票により冗長性を保つ。最小単位は3台。

セカンダリ

プライマリ

セカンダリ



nReplicaSetsl相互死活監視＆投票により冗長性を保つ。最小単位は3台。

セカンダリセカンダリ　→　プライマリ

プライマリ生きているサーバで投票が行われ新しいプライマリが選ばれる



nShardinglデータをChunkの細かい粒度に分割する。各mongodに分散して渡すことで各サーバの負荷を分散します



バ

ShardingデータをChunkの単位に分ける

mongos

mongoc

Mongod[ShardB]

ReplicaSetsによりサーバの冗長性を確保

Mongod[ShardC]

Mongod[ShardA]

DATA



バ


mongocはシャーディング情報を持つ

mongos

mongoc

Mongod[ShardB]


ChunkA -> ShardAChunkB -> ShardBChunkC -> ShardC

Mongod[ShardC]

Mongod[ShardA]

ChunkCChunkAChunkB



バ

ChunkA


mongocはシャーディング情報を持つ

mongos

mongoc

Mongod[ShardB]


ChunkB

ChunkCChunkA -> ShardAChunkB -> ShardBChunkC -> ShardC

Mongod[ShardC]

Mongod[ShardA]ChunkA

ChunkB



nMongoDBのこれらの基本機能により、アプリ側の実装コストは軽くなります。

n前述した、9台→100台への変更においても、アプリ側のDB接続部分の変更点は殆どありません。

nスケーラビリティを保ったまま、シンプルなサービス構築を行うことができています。


使いどころ


まとめ

nデータ量が大き過ぎないn書き込みが多過ぎないn単位時間あたりの処理データが各シャードのメモリ量を超えない処理は得意l現在のピグ系のリアルタイム処理には合っている

nホットデータが無い様なデータの使い方は苦手


困ったことについて


運用中に困ったことについて


nクラスターのスローダウンl必要なデータを一気にデータをインポートした場合loplogデータ量範囲を超えてレプリケーションが停止l一度に入れたため、PrimaryShardにChunkが溜まってしまいI/Oバウンドに

l負荷が高いのでBalancerは動かないためクラスタのスローダウン

→Oplogの容量を増やすことができるのでそれらで対応


nシャード設定のスローダウンlほんとに突然パフォーマンスダウンする「10分前は動いてたけど、、、」

lPrimaryShardはリソースを潤沢な状態にするl各シャードのmmapの容量が実メモリを超えてきたら注意する

→シャード設定は定期的に確認＆シャードの設定を自動化


nデータ肥大l運用していくに連れてデータの肥大化が起きますl定期的なデータのコンパクションが必要ですl repairコマンドは、データ容量と同容量のスペースを利用するので注意

lデータ容量が小容量かつ、一時的にMongoDBのクラスタを止められるなら、データdrop→データresoreの方が簡単です。


nドライバ関連lNode.jsのドライバのバージョンによってデータの持ち方などが異なる場合があった（現在は解消）ので、バージョンアップは慎重に行ないましょう


日々の運用


ここからは実際の運用でやっていること


nMongoDBに使用するハードウェアlCPU

l（現在は）CPUはあまり負荷が来ないためそれほど良い物でなくて良い

lそのかわりノードを増やすことになるのであればラックの効率を上げるため消費電力の少ないものを選択する


nMongoDBに使用するハードウェアlメモリ

l積めば積むほどキャッシュが効くのでできるだけ積むl現在は1ノード32GBのサーバを用意


nMongoDBに使用するハードウェアlDISK

lこちらも書き込み、読み込みが早いに越したことは無いl今までは、SAS * 4 RAID10 -> SSD * 2 RAID0となっている。

l現在はSSDはSASの3倍のiopsが出ています。lFileSystemはxfs or ext4（高速なfallocate()がサポートされている必要があるため）


nMongoDBに使用するハードウェアlDISK

l ioDriveでの検証に関しては、現状では8000opsを超えた位でReplicaSetsのoplogの転送が止まる事を確認しています。

l速度は3倍以上出ていたので、単体で使用するようなデータには使えるかもしれません。（試してないです）

l2.2以降では改善されている可能性があるので再検証予定


nバックアップlmongodumplReplicaSetsのDelay


nバックアップlmongodump

lmongosに対してmongodump実行するのはバックアップとしては一番簡単です。

l稼働中にかけると完全なポイントイン・タイムのバックアップにはなりません


nバックアップl稼働中にスナップショットバックアップを取得

l１，mongos経由でAutoBalancingをOff l２，各レプリカセットにfsync lockをかけるl３，各mongodからデータを取得する（AWSならSnapshotがいいですね）

l４，各レプリカセットにfsync unlockl５，mongos経由でAutoBalancingをOn


バックアップの構成アプリケーションサー

バ

1、Chunkがバックアップ中に移動させない

mongos

mongoc

Mongod[ShardB]

２，fsync lockをかけることで更新を止める

Mongod[ShardC]

Mongod[ShardA] ３，各シャードからデータを取得


nバックアップlReplicasetsのDelay

lバックアップと言うよりはオペミスの防止l常に最新の状態よりも一定期間古い状態となる、Replicasetsを追加します


RS Delayの構成アプリケーションサー

バ

mongos

mongocMongod[ShardB]

この Replica Sets のみ、他のRSよりも3時間前のデータを持つ

Mongod[ShardC]

Mongod[ShardA]


n Indexl indexが効いているかはexplain()で確認lできるだけPK=_id で検索する実装にする

replSetTest1001:PRIMARY> db.User.find({'Field01': 'test'}).explain(){ "cursor" : "BtreeCursor testIndex_1", "nscanned" : 1, "nscannedObjects" : 1, "n" : 1, "millis" : 7, "nYields" : 0,


nロックl同じサーバ上に異常に書き込みの多いコレクションがあるとクラスタ全体のアクセスに影響するため、コレクションを分ける

lアプリ実装はコレクション間を疎結合で作るl2.2系でDBレベルロックが実装されるとDBを分ければよいのでこの様な手順は要らない


nロック

Collection A Collection B Collection C


nロック

Collection A Collection BCollection C


nロック

Collection BCollection CCollection A


n運用効率化lどうしても台数が多くなる傾向にあります。lそのため「標準のコマンドだと表示が多すぎて見づらい」「今のマスターの一覧が簡単に出したい」等の不満がでます。

lこれらはスクリプト作成等で対応しています、このあたりもJSONで各種データを取ってこれるために管理ツールなどは作りやすいです。


n運用効率化：運用スクリプトの内容lロックタイムの取得lシャードに入っているmongod一覧のリスト出力lレプリカセットのマスター検索lレプリカセットのpriority検索lprintShardingStatusの整形lレプリカセット一括作成／設定変更（現在のRSにDelayホスト追加するなど）


n各種コマンド、ステータスなどlトレンドが見たいl現状が把握したい


n各種コマンド、ステータスなどlmongostatlmongotoplmongosniff


$ ./mongostat --host 192.168.8.41:27018,192.168.8.62:27018 insert query update delete getmore command flushes mapped vsize res faults locked % idx miss % qr|qw ar|aw netIn netOut conn set repl time192.168.8.41:27018 0 361 132 0 209 437 0 36.1g 76.2g 14.3g 1 2.2 0 0|0 2|0 85k 698k 3056 RSTest1001 M 11:16:57192.168.8.62:27018 0 384 164 0 245 480 0 30.1g 63.9g 15.6g 0 2 0 0|0 2|0 96k 652k 2587 RSTest1002 M 11:16:57

nmongostatlクエリや、プロセスの現状を確認するコマンド


nmongostat - 見るべき項目l faults - 1秒当りのページフォールト数lLocked % - グローバルライトロックの時間割合l idx miss % - indexのヒット率の時間割合lqr|qw - 読み込みキュー|書き込みキューの大きさ


nmongostat - 見るべき項目l faults が多い場合キャッシュメモリ溢れの可能性があるので、メモリ、もしくはサーバを増設

lLocked % が高い場合書き込みのクエリを見直す or クラスタ分割。

lqr|qw が高い場合サーバ負荷が低ければ、ロックの可能性を疑う。負荷が高ければ単純なクエリ増による高負荷を疑う。


$ /usr/local/mongodb2_1/bin/mongotop --host mongos_ip --port 27018connected to: mongos_ip ns total read write 2012-05-23T02:14:12 local.oplog.rs 1929ms 1929ms 0ms life_prd_main.TestOnline 0ms 500ms 10ms life_prd_main.Test2Soil 8ms 0ms 8ms

writeに時間がかかってい

nmongotopl現在重いmongodのどのcollectionへアクセスがかかっているかを確認したりとかできまする。

l障害の時がメイン


nmongosniffl最後はパケットキャプチャですので、何か会った際のアクセス状況の確認が可能

lmongosのアクセス状況とか、複雑なクエリを見たい場合はこれで見るのが良い

# mongosniff --source NET eth0 27017# 以下にパケットがズラズラっと並ぶ

127.0.0.1:55858 -->> 127.0.0.1:27017 testdatabase.TestCol1 89 bytes id:kjkjkjkj 14086840 query: { _id: "1234567891234567" } ntoreturn: -1 ntoskip: 0127.0.0.1:27017 <<-- 127.0.0.1:55858 205 bytes id:77383268 2000171624 - 14086840


nステータス確認・変更lprofilingl loglevel変更ldb.adminCommand("connPoolStats")ldb.serverStatus()ldb.currentOp()ldb.collection.stat()ldb.stats()


まとめ


まとめ

nまだ各所に未熟な点はありますが、運用を安定させる事で、綺麗な構成でスケーラビリティを確保したサービスを構築することができるプロダクトになる可能性がMongoDBにはあると考えています。


まとめ

n今後のアップデートなども様々な物が控えており、現在の問題点も徐々に改善されると考えております。


まとめ

nただ、NoSQLは適材適所、という言葉もあり、徐々に使って慣れていくのが大事だと思います。スモールスタートでまずは使ってみてはどうでしょうか。


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


Documents

AmebaのMongoDB活用事例