MongoDBのアレをアレする

MongoDBのアレをアレする

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

桑野章弘

12年7月8日日曜日

アジェンダ

 MongoDBCasual
 もんごたんについておさらい
 運用時にあったこと集
 障害時何見る？
 まとめ


自己紹介

 桑野章弘
 サイバーエージェント
 Ameba を運営しています。
 ピグライフの運用／構築を担当

 Twitter
 @kuwa_tw

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

 著書／活動
 「MySQLによるタフなサイトの作り方」


MongoDBCasual
ですね！


Casualですね！


なんかカジュアルじゃ
ないっぽい、、、


という人のためにこれ
がカジュアルだとい
うのを見せます
5

俺だ！俺たちがカジュ
アルだ！

5

と、

5

その前にちょっと宣伝

5

ピグゲーム
 ピグのキャラクターで遊べるゲームのラインナップ
 ピグライフ
 ピグアイランド

6

ピグゲーム

3

サービス情報

 ピグライフ
 2011/05/31オープン
 会員数360万人（2012/01現在）

 ピグアイランド
 2012/05/22オープン
 リリース後5日で会員数100万人突破

8

ピグライフのアーキテクチャ：全体構成
BackEnd
FrontEnd

ユーザ/エリ
staticサーバ Node.jsサーバ
Socketサーバア等の状態
データ

mongodbサーバ
Flashデータ必要なデータ
→リクエスの取得
ト/取得
HTTP

WebSocket接続

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

11

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

mongos Mongod[ShardA]

Mongod[ShardB]

mongoc
Mongod[ShardC]


アーキテクチャについて

 システムアーキテクチャ
 冗長化
 ReplicaSets

 スケーラビリティ
 Sharding

13

アーキテクチャの課題

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

プライマリ

セカンダリセカンダリ

23


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

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

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

24


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

19

MongoDBの構成
Sharding
アプリケーションサー ReplicaSetsに
データをChunk
バよりサーバの冗長
の単位に分ける
性を確保
DATA

mongos

Mongod[ShardA]

Mongod[ShardB]

mongoc

Mongod[ShardC]

20

MongoDBの構成
Sharding
データをChunk
性を確保
ChunkA ChunkB ChunkC

mongos

mongocは
Mongod[ShardA]
シャーディング情
報を持つ

Mongod[ShardB]

mongoc

ChunkA -> ShardA
ChunkB -> ShardB Mongod[ShardC]
ChunkC -> ShardC

21

MongoDBの構成
Sharding
データをChunk 性を確保

mongos

mongocは
ChunkA Mongod[ShardA]
シャーディング情
報を持つ

ChunkB Mongod[ShardB]

mongoc

ChunkA -> ShardA
ChunkB -> ShardB ChunkC Mongod[ShardC]
ChunkC -> ShardC

22


 MongoDBのこれら機能により、アプリ側の実
装コストは軽く、スケーラビリティを保ったシス
テム構築を手軽に使うことができます。
 サーバレベルの細かなチューニングは基本的には
必要ありません（できない）と言う所は大きなメ
リット
 サーバアーキテクチャをもんごに合わせていくイ
メージ

25

とはいえ

26

ハマる部分はあるわけ
で

26

もんごたんのきもちしりたい
おっおっおっお（＾ω＾＝＾ω＾）

26

ということで

26

運用時にあったこと集

26

 あれ、クラスターが遅いよ？
 必要なデータを一気にデータをインポートする
 oplogデータ量範囲を超えてレプリケーションが停止
 一度に入れたため、PrimaryShardにChunkが溜まって
しまいI/Oバウンドに
 負荷が高いのでBalancerは動かない

＿人人人人＿
＞突然の死＜
￣Y^Y^Y^Y￣

32

 あれ、クラスターが遅いよ？
 シャードするコレクションを、シャード設定漏れ
 PrimaryShardでデータファイルが多くなり続けてメモリ
マップドファイルのサイズを超えたためI/Oバウンドに
 シャードしてないのでもちろんBalancerは動かない

＿人人人人＿
＞突然の死＜
￣Y^Y^Y^Y￣

32

 シャード設定の不備に関して
 ほんとに突然パフォーマンスダウンする
「10分前は快調だった、、、」「みんなそういうの」
 PrimaryShardは潤沢な状態にしておく
 シャード設定は定期的に確認、もしくはシャードの設定を自
動化する

32

 運用スクリプト
 台数がおおくなってくると「標準のコマンドだと表示
が辛いとか」「今のマスターの一覧が欲しいな」とか
があるのでそのへんはスクリプト作成して対応
 このへんが作りやすいのは魅力

32

 運用スクリプト：内容
 ロックタイムの取得
 シャードに入っているmongod一覧のリスト出力
 レプリカセットのマスター検索
 レプリカセットのプライオリティ検索
 printShardingStatusの整形
 レプリカセット一括作成

32

 バックアップ
 mongodump
 mongosに対してmongodump実行するのはバックアッ
プとしては一番簡単だけど、稼働中にかけると完全なポイン
トイン・タイムのバックアップにはならないよ

35

 バックアップ
 稼働中にスナップショットバックアップを取得するに
はこんな感じでやりましょう
 mongos経由でAutoBalancingをOff
 各レプリカセットにfsync lockをかける
 各mongodにmongodumpを実行してデータ取得
 各レプリカセットにfsync unlock
 mongos経由でAutoBalancingをOn

35

 ロック
 同じサーバ上に異常に書き込みの多いコレクションが
あるとクラスタ全体のアクセスに影響します
 現状はクラスタを複数に分けています
 アプリ実装はコレクション間を疎結合で作る必要あり
 2.2系でコレクションレベルロックが実装されるとこ
のような手間はなくなる（予定）です

36

 ロック

Collection A Collection B Collection C

37

 グローバルロック

Collection A Collection C Collection B

38

障害時何見る？

10

障害の時じゃなくてもいいんですけど
 トレンドの変化がみたいとか。
 現状が把握したいとか。
 障害でもいい。
 まずはツールで。

11

mongostat
 トレンドの変化がみたいとか。
 現状が把握したいとか。
 すべての基本です

12

$ ./mongostat --host 192.168.8.41:27018,192.168.8.62:27018
insert query update delete getmore command ﬂushes mapped vsize res faults
locked % idx miss % qr¦qw ar¦aw netIn netOut conn set repl time
192.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:57
192.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

192.168.8.41:27018 0 418 144 0 231 567 0 36.1g 76.2g 14.3g 0
1.9 0 0¦0 2¦0 100k 908k 3056 RSTest1001 M 11:16:58
192.168.8.62:27018 0 465 170 0 255 582 0 30.1g 63.9g 15.6g 1 3
0 0¦0 2¦0 108k 1m 2587 RSTest1002 M 11:16:58

13

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

12

mongostat - 見るべき項目
 faults が多い場合
キャッシュメモリ溢れの可能性があるので、メモリ、
もしくはサーバを増設
 Locked % が高い場合
書き込みのクエリを見直すか、クラスタを分ける。
 qr¦qw が高い場合
サーバ負荷が低ければ、ロックの可能性を疑う。負荷
が高ければ単純なクエリ増による高負荷を疑う。

12

mongostat
 discoverオプションで、レプリカセットのメン
バー、クラスタに入っているメンバーを全て抽出する
ことが可能なので利用すると楽

12

mongotop
 現在重いmongodのどのcollectionへアクセスがか
かっているかを確認したりとかできまする。
 障害の時がメイン
mongostatで状況確認→mongotopでサーバ確認
みたいな

15

$ /usr/local/mongodb2_1/bin/mongotop --host mongos_ip --port 27018
connected to: mongos_ip

ns total read write 2012-05-23T02:14:10
local.oplog.rs 1929ms 1929ms 0ms
life_prd_main.Test 6ms 6ms 0ms
life_prd_main.TestPoint 5ms 0ms 3ms
life_prd_main.Test2Soil 5ms 0ms 5ms
writeに時間
life_prd_main.TestMaterial 1ms 0ms 1ms がかかってい
life_prd_main.TestOnline 1ms 0ms 1ms
る
life_prd_main.Test3 1ms 1ms 0ms
life_prd_main.TestQuest 1ms 1ms 0ms
life_prd_main.TestBan 0ms 0ms 0ms

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
life_prd_main.Test 5ms 5ms 0ms
life_prd_main.TestPoint 4ms 0ms 2ms
life_prd_main.TestMaterial 2ms 0ms 2ms
life_prd_main.Test3 1ms 1ms 0ms
life_prd_main.TestQuest 1ms 1ms 0ms
life_prd_main.TestBan 0ms 0ms 0ms

17

mtop
 標準ツールじゃないよ
 mongostatと同じようなデータが取れるけど、
ちょっと足りないです。
 今流れているクエリを追える所がメリット、、、だけ
ど db.currentOp()でいいかも。

18

$ ./mtop.py -s 192.168.0.100:27218
192.168.0.100. v2.0.5, 64 bit. Conns: 1304/18696. Lock %: 0.02
Mem: 12182 resident, 37120 virtual, 16617 mapped
Ops: 2816 total, 633 getmore, 0 insert, 523 update, 602 command, 1058 query,
0 delete
ID CLIENT OP A LOCKW NS
1184788867 192.168.0.112:43976 query T
1184789134 192.168.0.149:48588 query T
1184792427 192.168.0.143:36964 query T
1184866702 192.168.0.103:58179 query T
1184867005 192.168.0.126:55974 query T
1184867347 192.168.0.102:36019 query T
1184867986 192.168.0.129:37664 query T
1184868008 192.168.0.151:59313 query T
1184868757 192.168.0.105:46522 query T
1184869686 192.168.0.154:43275 query T
1184870569 192.168.0.107:58733 query T
(snip)

19

mongosniff
 最後はパケットキャプチャですので、何か会った際の
アクセス状況の確認が可能
 mongosのアクセス状況とか、複雑なクエリを見た
い場合はこれで見るのが良い（これでみるしかない）
です。

21

# 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: 0
127.0.0.1:27017 <<-- 127.0.0.1:55858 205 bytes id:77383268 2000171624 - 14086840

22

ステータスコマンド

23

proﬁling
 遅いクエリ等の調査

24

# mongo
# プロファイルオンにする。この場合は10ms以上かかった、リード、ライトクエリが入る。
PRIMARY> db.setProfilingLevel(2,10);
{ "was" : 2, "slowms" : 100, "ok" : 1 }

（Profile確認)
{ "ts" : ISODate("2012-07-05T04:13:48.408Z"), "op" : "update", "ns" : "testdatabase.TestCol01", "query" : { "_id" :
"4334521d75462355" }, "updateobj" : { "$set" : { "747465656e80aa0b" : 10 } }, "idhack" : true, "millis" : 0, "client" :
"192.168.0.100", "Test" : "" }

# もとに戻す
PRIMARY> db.setProfilingLevel(0);
{ "was" : 2, "slowms" : 10, "ok" : 1 }

25

Loglevel変更
 これもクエリもでるし、MongoDBの動作がおかし
かった場合に必要
 ログの量が半端なくなるので注意

26

# mongo
# ログレベルを5（最大）にする。
PRIMARY> db.adminCommand({setParameter:1, logLevel:5})
{ "logLevel" : 0, "ok" : 1 }

（ログ確認する）

# もと（ログレベル0）に戻す
PRIMARY> db.setProﬁlingLevel(0);
{ "logLevel" : 5, "ok" : 1 }

27

db.adminCommand("connPo
olStats")
 シャーディング環境におけるコネクションプールの統
計

28

mongos> db.adminCommand("connPoolStats")
{
"hosts" : {
"192.168.0.241:27019::0" : {
"available" : 1,
"created" : 1

（snip）

"createdByType" : {
"master" : 175,
"set" : 24,
"sync" : 8
},
"totalAvailable" : 24,
"totalCreated" : 207,
"numDBClientConnection" : 215,
"numAScopedConnection" : 28,
"ok" : 1
}

29

db.serverStatus()
 サーバの現在の状態の確認
 mongostatとか各種状況確認はほぼこれを見ている
 見られる項目
Replicasets
Journaling
NW
Index
要するにほとんどすべて

30

PRIMARY> db.serverStatus()
{
"host" : "test-mongo01:27018",
"version" : "2.0.5",
"process" : "mongod",
"uptime" : 731083,
"uptimeEstimate" : 726409,
"localTime" : ISODate("2012-05-23T05:55:14.419Z"),
"globalLock" : {
"totalTime" : 731082571520,
"lockTime" : 21521333332,
"ratio" : 0.029437623286867328,

（snip）
},
"mem" : {

（snip）

31

（snip）

"dur" : {
"commits" : 27,
"journaledMB" : 0.548864,
"writeToDataFilesMB" : 1.069064,
"compression" : 0.48677963816836817,
"commitsInWriteLock" : 0,
"earlyCommits" : 0,
"timeMs" : {
"dt" : 3091,
"prepLogBuffer" : 3,
"writeToJournal" : 305,
"writeToDataFiles" : 17,
"remapPrivateView" : 2
}
},

31

db.currentOp()
 データベースインスタンスについて進行中の現在の操
作の確認

32

PRIMARY> db. currentOp()
MongoDB shell version: 2.0.5
connecting to: 127.0.0.1:27218/test
{
"inprog" : [
{
(snip)
"opid" : 1654293341,
"active" : false,
"lockType" : "read",
"waitingForLock" : false,
"op" : "query",
"ns" : "testdb.TestPoint",
"query" : {
"_id" : "77667f763200000"
},
"client" : "192.168.0.125:34831",
"desc" : "conn",
"threadId" : "0x7f431322f700",
"connectionId" : 53986,
"numYields" : 0
},
(snip)

33

まとめ

42

もんごたんのきもちが
わかるようになりま
したか？
5

ね？

5

Casualだったで
しょ？

5

みんなもカジュアルに
100シャード運用し
てみようね！！
5

このあともカジュアル
なトークがいっぱい
あるよ！
5

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

5

MongoDBのアレをアレする

More Related Content

MongoDBのアレをアレする