CyberAgentにおけるMongoDB

CyberAgentにおけるMongoDB

株式会社サイバーエージェントアメーバ事業本部テクノロジーグループ Ameba Infra. Unit

　　　　　　　　　　　　　　　　桑野　章弘

13年12月12日木曜日

アジェンダ

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自分の庭の育成ゲーム


ピグアイランド


ピグアイランド

nサービス情報l2012/05/22オープンl自分の島育成ゲーム


ピグカフェ


ピグカフェ

nサービス情報l2012/08/21オープンlカフェ経営ゲーム


ピグワールド


ピグワールド

nサービス情報l2012/11/27オープンl自分の街をつくろうゲーム


なぞってピグキッチン


なぞってピグキッチン

nサービス情報l2013/11/19オープンlスマートフォンのブラウザゲームlパズルをクリアして自分のキッチンを育てようゲーム


ゲーム概要

nPClユーザ数は100万ユーザ～300万ユーザ以上lピーク帯同時接続数10万以上lオンプレミス

nSPサービスlリリースしたばかりlAWS上で構築


全ゲームMongoDBを使用


サービス環境の変遷


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の基本的

な機能13年12月12日木曜日

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スケーラビリティを保ったまま、シンプルなサービス構築を行うことができています。


ユースケース


ユースケース

nMongoDBにかぎらず、NoSQLはできる、できない、がハッキリしています

nNoSQL使うならできる部分を伸ばす必要があります。もし、できない部分を突き詰めるとRDBMSとなります


ユースケース：得意なもの

nデータ量が大き過ぎないn書き込みが多過ぎないn単位時間あたりの処理データが各シャードのメモリ量を超えない処理は得意

n得意なユースケースlゲーム系Webアプリケーションl一時的ログ解析基盤


ユースケース：苦手なもの

nホットデータが無い様なデータの使い方は苦手lデータ量が爆発的に増えるl常に全データへのアクセスを行うような

n苦手なユースケースlソーシャル系等のWebアプリケーションl継続的 or 統合的ログ解析基盤


なぜか？


ユースケース

nMongoDBのメモリ管理lアクセスしたデータファイルはmmapとしてキャッシュ

lメモリからあふれた場合はアクセスされた物を入れて、使われてないものを削除

lLRU的な仕組みはなく、OS任せ


ユースケース

mmapdatafile.2datafile.0

mmap

datafile.1

mongodb


ユースケース

mmapdatafile.0

mmap

datafile.1

mongodb

datafile.3datafile.2


ユースケース

mmapdatafile.1 datafile.2

mmap

datafile.0

mongodb

メモリ量以上のデータアクセス毎にメモリ<ｰ>ディスクへのアクセスが頻発


困ったことについて


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


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の方が簡単です。

lRS組んでいるならローリングコンパクション


日々の運用


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


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

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

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


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

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


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

lこちらも書き込み、読み込みが早いに越したことは無いl今までは、SAS * 4 RAID10 -> SSD * 2 RAID0l現在はSSDはSASの3倍のiopslFileSystemはxfs or ext4- 高速なfallocate()がサポートが必要


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

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

lがバージョン2.4ではこの現象はない＝ioDrive 等を上手く活用することでサーバ台数を減らすことができる


nバックアップlmongodump

lmongos経由の実行lポイントイン・タイムバックアップ

lReplicaSetsのDelay


nバックアップlmongodump

lmongosに対してmongodump実行するのはバックアップとしては一番簡単- 稼働中ではポイントイン・タイムバックアップではない

lmongodumpはmongodが起動していなくてもデータファイルに直接かけてBSONファイルを取得できるので、これを利用してポイントイン・タイムのバックアップを実装しています


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

lRSメンバとしてarbiterとnovoteのプロセスを起動l１，mongos経由でAutoBalancingをOff l２，各レプリカセットのnovoteプロセスをダウンl３，各mongodからmongodumpでデータ取得l4 ， mongos経由でAutoBalancingをOnl5 ，各Dumpデータの収集 l


バックアップの構成

アプリケーションサーバ 1、Chunkがバックアップ中に移動させない

mongos

mongocMongod[ShardB] ２，no vote

プロセスダウン

Mongod[ShardC]

Mongod[ShardA]Arbiter

Arbiter

Arbiter

no vote

no vote

no vote

✕ Dump

バックアップサーバ

5，各シャードからデータを取得

3，各シャードでDumpデータを

生成


nバックアップlReplicasetsのDelay

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


MMS

nMongoDB Management Service(MMS)l監視

lMuninプラグインとして提供

lバックアップlシャード環境でのポイントイン・タイムバックアップを提供-


MMS

nMongoDB Management Service(MMS)l監視

lMuninプラグインとして提供

lバックアップlシャード環境でのポイントイン・タイムバックアップを提供-


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, "nChunkSkips" : 0, "isMultiKey" : false, "indexOnly" : false,


n Indexl詳しいオプティマイザの実行結果が欲しい場合は .explain(true)

replSetTest1001:PRIMARY> db.User.find({'_id': 'test'}).explain(true) "allPlans" : [ { "cursor" : "BtreeCursor _id_", "n" : 1, "nscannedObjects" : 1, "nscanned" : 1, "indexBounds" : { "start" : { "_id" : "test" },


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

lアプリ実装はコレクション間をできるだけ疎結合にl2.2以降DBレベルロックなのでDB分割


nロック

Collection A Collection B Collection C


nロック

Collection A Collection BCollection C


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変更lWorking Set Analyzerldb.adminCommand("connPoolStats")ldb.serverStatus()ldb.currentOp()ldb.collection.stat()ldb.stats()


まとめ


まとめ

nMongoDBを上手く使用することで、以下の様なことが実現できていますl運用の安定l構成を変えずスケーラビリティを確保lJSONを直接扱える事で開発スピードを早く


まとめ

nですが、運用するにあたって気をつけなければならない点などがあり、上手い運用にはある程度のノウハウが必要とも考えています

nその辺りは私達もこのような場で適宜露出していますし、サポートしていただける所も今後増えていくのではないでしょうか。


まとめ

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


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


質疑応答


Documents

CyberAgentにおけるMongoDB