MongoDBのアレをアレする

19,380 views

Published on

MongoDB Casual Talksの資料です!

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

No Downloads
Views
Total views
19,380
On SlideShare
0
From Embeds
0
Number of Embeds
6,114
Actions
Shares
0
Downloads
0
Comments
0
Likes
49
Embeds 0
No embeds

No notes for slide

MongoDBのアレをアレする

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

×