Your SlideShare is downloading. ×
0
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
MongoDBのアレをアレする
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

MongoDBのアレをアレする

16,542

Published on

MongoDB Casual Talksの資料です!

MongoDB Casual Talksの資料です!

Published in: Technology
0 Comments
48 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
16,542
On Slideshare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
0
Comments
0
Likes
48
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. MongoDBのアレをアレする 株式会社サイバーエージェント アメーバ事業本部ピグディヴィジョン                 桑野 章弘12年7月8日日曜日
  • 2. アジェンダ  MongoDBCasual  もんごたんについておさらい  運用時にあったこと集  障害時何見る?  まとめ12年7月8日日曜日
  • 3. 自己紹介  桑野章弘  サイバーエージェント  Ameba を運営しています。  ピグライフの運用/構築を担当  Twitter  @kuwa_tw  Blog  http://d.hatena.ne.jp/akuwano/  著書/活動  「MySQLによるタフなサイトの作り方」12年7月8日日曜日
  • 4. MongoDBCasual ですね!12年7月8日日曜日
  • 5. Casualですね!12年7月8日日曜日
  • 6. なんかカジュアルじゃ ないっぽい、、、12年7月8日日曜日
  • 7. という人のためにこれ がカジュアルだとい うのを見せます 512年7月8日日曜日
  • 8. 412年7月8日日曜日
  • 9. 俺だ!俺たちがカジュ アルだ! 512年7月8日日曜日
  • 10. と、 512年7月8日日曜日
  • 11. その前にちょっと宣伝 512年7月8日日曜日
  • 12. ピグゲーム  ピグのキャラクターで遊べるゲームのラインナップ  ピグライフ  ピグアイランド 612年7月8日日曜日
  • 13. ピグゲーム 312年7月8日日曜日
  • 14. サービス情報  ピグライフ  2011/05/31オープン  会員数360万人(2012/01現在)  ピグアイランド  2012/05/22オープン  リリース後5日で会員数100万人突破 812年7月8日日曜日
  • 15. ピグライフのアーキテクチャ:全体構成 BackEnd FrontEnd ユーザ/エリ staticサーバ Node.jsサーバ Socketサーバ ア等の状態 データ mongodbサーバ Flashデータ 必要なデータ →リクエス の取得 ト/取得 HTTP WebSocket接続 ・ユーザ情報 ・チャット データ →リクエス ユーザ ト/取得 (ブラウザ) 1112年7月8日日曜日
  • 16. MongoDBの構成アプリケーションサー バ mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC]12年7月8日日曜日
  • 17. アーキテクチャについて  システムアーキテクチャ  冗長化  ReplicaSets  スケーラビリティ  Sharding 1312年7月8日日曜日
  • 18. アーキテクチャの課題  ReplicaSets  相互死活監視&投票により冗長性を保つ。最小単位は 3台。 プライマリ セカンダリ セカンダリ 2312年7月8日日曜日
  • 19. アーキテクチャの課題  ReplicaSets  相互死活監視&投票により冗長性を保つ。最小単位は 3台。 生きているサーバ プライマリ で投票が行われ新 しいプライマリが 選ばれる セカンダリ セカンダリ → プライマリ 2412年7月8日日曜日
  • 20. アーキテクチャの課題  Sharding  データをChunkの細かい粒度に分割し、各 mongodに分散して渡すことで各サーバの負荷を分 散します 1912年7月8日日曜日
  • 21. MongoDBの構成 Shardingアプリケーションサー ReplicaSetsに データをChunk バ よりサーバの冗長 の単位に分ける 性を確保 DATA mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC] 2012年7月8日日曜日
  • 22. MongoDBの構成 Shardingアプリケーションサー ReplicaSetsに データをChunk バ よりサーバの冗長 の単位に分ける 性を確保 ChunkA ChunkB ChunkC mongos mongocは Mongod[ShardA] シャーディング情 報を持つ Mongod[ShardB] mongoc ChunkA -> ShardA ChunkB -> ShardB Mongod[ShardC] ChunkC -> ShardC 2112年7月8日日曜日
  • 23. MongoDBの構成アプリケーションサー ReplicaSetsに バ よりサーバの冗長 Sharding データをChunk 性を確保 の単位に分ける mongos mongocは ChunkA Mongod[ShardA] シャーディング情 報を持つ ChunkB Mongod[ShardB] mongoc ChunkA -> ShardA ChunkB -> ShardB ChunkC Mongod[ShardC] ChunkC -> ShardC 2212年7月8日日曜日
  • 24. アーキテクチャの課題  MongoDBのこれら機能により、アプリ側の実 装コストは軽く、スケーラビリティを保ったシス テム構築を手軽に使うことができます。  サーバレベルの細かなチューニングは基本的には 必要ありません(できない)と言う所は大きなメ リット  サーバアーキテクチャをもんごに合わせていくイ メージ 2512年7月8日日曜日
  • 25. とはいえ 2612年7月8日日曜日
  • 26. ハマる部分はあるわけ で 2612年7月8日日曜日
  • 27. もんごたんのきもちしりたい おっおっおっお(^ω^=^ω^) 2612年7月8日日曜日
  • 28. ということで 2612年7月8日日曜日
  • 29. 運用時にあったこと集 2612年7月8日日曜日
  • 30.  あれ、クラスターが遅いよ?  必要なデータを一気にデータをインポートする  oplogデータ量範囲を超えてレプリケーションが停止  一度に入れたため、PrimaryShardにChunkが溜まって しまいI/Oバウンドに  負荷が高いのでBalancerは動かない _人人 人人_ > 突然の死 <  ̄Y^Y^Y^Y ̄ 3212年7月8日日曜日
  • 31.  あれ、クラスターが遅いよ?  シャードするコレクションを、シャード設定漏れ  PrimaryShardでデータファイルが多くなり続けてメモリ マップドファイルのサイズを超えたためI/Oバウンドに  シャードしてないのでもちろんBalancerは動かない _人人 人人_ > 突然の死 <  ̄Y^Y^Y^Y ̄ 3212年7月8日日曜日
  • 32.  シャード設定の不備に関して  ほんとに突然パフォーマンスダウンする 「10分前は快調だった、、、」「みんなそういうの」  PrimaryShardは潤沢な状態にしておく  シャード設定は定期的に確認、もしくはシャードの設定を自 動化する 3212年7月8日日曜日
  • 33.  運用スクリプト  台数がおおくなってくると「標準のコマンドだと表示 が辛いとか」「今のマスターの一覧が欲しいな」とか があるのでそのへんはスクリプト作成して対応  このへんが作りやすいのは魅力 3212年7月8日日曜日
  • 34.  運用スクリプト:内容  ロックタイムの取得  シャードに入っているmongod一覧のリスト出力  レプリカセットのマスター検索  レプリカセットのプライオリティ検索  printShardingStatusの整形  レプリカセット一括作成 3212年7月8日日曜日
  • 35.  バックアップ  mongodump  mongosに対してmongodump実行するのはバックアッ プとしては一番簡単だけど、稼働中にかけると完全なポイン トイン・タイムのバックアップにはならないよ 3512年7月8日日曜日
  • 36.  バックアップ  稼働中にスナップショットバックアップを取得するに はこんな感じでやりましょう  mongos経由でAutoBalancingをOff  各レプリカセットにfsync lockをかける  各mongodにmongodumpを実行してデータ取得  各レプリカセットにfsync unlock  mongos経由でAutoBalancingをOn 3512年7月8日日曜日
  • 37.  ロック  同じサーバ上に異常に書き込みの多いコレクションが あるとクラスタ全体のアクセスに影響します  現状はクラスタを複数に分けています  アプリ実装はコレクション間を疎結合で作る必要あり  2.2系でコレクションレベルロックが実装されるとこ のような手間はなくなる(予定)です 3612年7月8日日曜日
  • 38.  ロック Collection A Collection B Collection C 3712年7月8日日曜日
  • 39.  グローバルロック Collection A Collection C Collection B 3812年7月8日日曜日
  • 40.  グローバルロック Collection A Collection C Collection B 3812年7月8日日曜日
  • 41. もんごたんのきもちしりたい おっおっおっお(^ω^=^ω^) 2612年7月8日日曜日
  • 42. 障害時何見る? 1012年7月8日日曜日
  • 43. 障害の時じゃなくてもいいんですけど  トレンドの変化がみたいとか。  現状が把握したいとか。  障害でもいい。  まずはツールで。 1112年7月8日日曜日
  • 44. mongostat  トレンドの変化がみたいとか。  現状が把握したいとか。  すべての基本です 1212年7月8日日曜日
  • 45. $ ./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 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 1312年7月8日日曜日
  • 46. mongostat - 見るべき項目  faults - 1秒当りのページフォールト数  Locked % - グローバルライトロックの時間割合  idx miss % - indexのヒット率の時間割合  qr¦qw - 読み込みキュー¦書き込みキュー の大きさ 1212年7月8日日曜日
  • 47. mongostat - 見るべき項目  faults が多い場合 キャッシュメモリ溢れの可能性があるので、メモリ、 もしくはサーバを増設  Locked % が高い場合 書き込みのクエリを見直すか、クラスタを分ける。  qr¦qw が高い場合 サーバ負荷が低ければ、ロックの可能性を疑う。負荷 が高ければ単純なクエリ増による高負荷を疑う。 1212年7月8日日曜日
  • 48. mongostat  discoverオプションで、レプリカセットのメン バー、クラスタに入っているメンバーを全て抽出する ことが可能なので利用すると楽 1212年7月8日日曜日
  • 49. mongotop  現在重いmongodのどのcollectionへアクセスがか かっているかを確認したりとかできまする。  障害の時がメイン mongostatで状況確認→mongotopでサーバ確認 みたいな 1512年7月8日日曜日
  • 50. $ /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 1712年7月8日日曜日
  • 51. mtop  標準ツールじゃないよ  mongostatと同じようなデータが取れるけど、 ちょっと足りないです。  今流れているクエリを追える所がメリット、、、だけ ど db.currentOp()でいいかも。 1812年7月8日日曜日
  • 52. $ ./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) 1912年7月8日日曜日
  • 53. mongosniff  最後はパケットキャプチャですので、何か会った際の アクセス状況の確認が可能  mongosのアクセス状況とか、複雑なクエリを見た い場合はこれで見るのが良い(これでみるしかない) です。 2112年7月8日日曜日
  • 54. # 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 2212年7月8日日曜日
  • 55. ステータスコマンド 2312年7月8日日曜日
  • 56. profiling  遅いクエリ等の調査 2412年7月8日日曜日
  • 57. # 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 } 2512年7月8日日曜日
  • 58. Loglevel変更  これもクエリもでるし、MongoDBの動作がおかし かった場合に必要  ログの量が半端なくなるので注意 2612年7月8日日曜日
  • 59. # mongo # ログレベルを5(最大)にする。 PRIMARY> db.adminCommand({setParameter:1, logLevel:5}) { "logLevel" : 0, "ok" : 1 } (ログ確認する) # もと(ログレベル0)に戻す PRIMARY> db.setProfilingLevel(0); { "logLevel" : 5, "ok" : 1 } 2712年7月8日日曜日
  • 60. db.adminCommand("connPo olStats")  シャーディング環境におけるコネクションプールの統 計 2812年7月8日日曜日
  • 61. 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 } 2912年7月8日日曜日
  • 62. db.serverStatus()  サーバの現在の状態の確認  mongostatとか各種状況確認はほぼこれを見ている  見られる項目 Replicasets Journaling NW Index 要するにほとんどすべて 3012年7月8日日曜日
  • 63. 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) 3112年7月8日日曜日
  • 64. (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 } }, 3112年7月8日日曜日
  • 65. db.currentOp()  データベースインスタンスについて進行中の現在の操 作の確認 3212年7月8日日曜日
  • 66. 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) 3312年7月8日日曜日
  • 67. まとめ 4212年7月8日日曜日
  • 68. もんごたんのきもちが わかるようになりま したか? 512年7月8日日曜日
  • 69. ね? 512年7月8日日曜日
  • 70. Casualだったで しょ? 512年7月8日日曜日
  • 71. みんなもカジュアルに 100シャード運用し てみようね!! 512年7月8日日曜日
  • 72. このあともカジュアル なトークがいっぱい あるよ! 512年7月8日日曜日
  • 73. ご清聴ありがとうござ いました! 512年7月8日日曜日

×