後悔しないもんごもんごの使い方 〜サーバ編〜

6,794 views

Published on

bpstudy #71 で @matsukaz さんとお話した内容です!

0 Comments
32 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,794
On SlideShare
0
From Embeds
0
Number of Embeds
2,033
Actions
Shares
0
Downloads
30
Comments
0
Likes
32
Embeds 0
No embeds

No notes for slide

後悔しないもんごもんごの使い方 〜サーバ編〜

  1. 1. 後悔しない もんごもんごの使い方 ∼サーバ編∼ 桑野 章弘(@kuwa_tw) 13年8月1日木曜日
  2. 2. 自己紹介 13年8月1日木曜日
  3. 3. 自己紹介 •桑野 章弘 •渋谷の緑のサーバサイドエンジニア •Twitter: @kuwa_tw •#qpstudy の中の人 •あだな:銀河 13年8月1日木曜日
  4. 4. ピグやってました 13年8月1日木曜日
  5. 5. ピグやってました 13年8月1日木曜日
  6. 6. ピグやってました 13年8月1日木曜日
  7. 7. ピグやってました 13年8月1日木曜日
  8. 8. ピグやってました 13年8月1日木曜日
  9. 9. 今日の話 •運用を楽にしたい分散データベース •ユースケースについて 13年8月1日木曜日
  10. 10. 基本的な話 13年8月1日木曜日
  11. 11. データ構造 •BSONオブジェクトとしてデータもつ •_idはプライマリキーで、Indexも貼ら れる •スキーマレス •データへのアクセスがしやすい、実装 しやすい 13年8月1日木曜日
  12. 12.   データ構造 { "_id" : "45feae009015221f", "45feae009015221f" : { "name" : "あきひろ", "job" : { "level" : 15, "exp" : 24 } } } 13年8月1日木曜日
  13. 13.   データ構造{ "_id" : "45feae009015221f", "45feae009015221f" : { "name" : "あきひろ", "job" : { "level" : 15, "exp" : 24 }, "subjob" : { "level" : 1, "exp" : 1 } } } 13年8月1日木曜日
  14. 14. データ構造 •データへのアクセスのしやすさや実装 のしやすさは後半で説明される(は ず)! 13年8月1日木曜日
  15. 15. アプリケーション サーバ mongos mongoc Mongod[ShardB] Mongod[ShardC] Mongod[ShardA] 一般的(?)な構成 13年8月1日木曜日
  16. 16. ReplicaSets •相互死活監視と投票により冗長化 •Oplogの受け渡しによるデータ同期 13年8月1日木曜日
  17. 17. ReplicaSets プライマリ セカンダリセカンダリ プライマリに行 われた更新をセ カンダリにも適 用させる Oplog OplogOplog 13年8月1日木曜日
  18. 18. ReplicaSets プライマリ セカンダリセカンダリ 13年8月1日木曜日
  19. 19. ReplicaSets プライマリ セカンダリ->プライマリセカンダリ 生きているサー バで投票が行わ れ新しいプライ マリが選ばれる 13年8月1日木曜日
  20. 20. Sharding •データを細かいデータ範囲に分割し、 複数のmongodで処理する 13年8月1日木曜日
  21. 21. アプリケーション サーバ mongos mongoc Mongod[ShardB] Mongod[ShardC] Mongod[ShardA] Sharding Sharding データをChunk の単位に分ける mongocはシャ ーディング情報を 持つ ChunkA -> ShardA ChunkB -> ShardB ChunkC -> ShardC 13年8月1日木曜日
  22. 22. このへんはもうい いですよね? 13年8月1日木曜日
  23. 23. 運用を楽にしたい 分散データベース 13年8月1日木曜日
  24. 24. ユースケース •MongoDBにかぎらず、NoSQLはで きる、できない、がハッキリしている •NoSQL使うならできる部分を伸ばす必 要があり、できない部分を突き詰める とRDBMSになる 13年8月1日木曜日
  25. 25. ユースケース •MongoDBにかぎらず、NoSQLはで きる、できない、がハッキリしている •NoSQL使うならできる部分を伸ばす必 要があり、できない部分を突き詰める とRDBMSになる 13年8月1日木曜日
  26. 26. ユースケース •MongoDBにかぎらず、NoSQLはで きる、できない、がハッキリしている •NoSQL使うならできる部分を伸ばす必 要があり、できない部分を突き詰める とRDBMSになる 13年8月1日木曜日
  27. 27. では実際のユース ケースの話 13年8月1日木曜日
  28. 28. こんな形です 13年8月1日木曜日
  29. 29. 良い •ゲーム系Webアプリケーション •一時的ログ解析基盤 13年8月1日木曜日
  30. 30. 悪い •ソーシャル系等のWebアプリケーシ ョン •継続的 or 統合的 ログ解析基盤 13年8月1日木曜日
  31. 31. 基本的な考え方 13年8月1日木曜日
  32. 32. 基本的な考え方 •まず最初にMongoDBを使うにあ たって基本的な考え方を •ここからの話もコレにそって話が進 みます 13年8月1日木曜日
  33. 33. 基本的な考え方 •永続化メモリDB •完全にそうではなく、異論反論ある かと思います。 •が、一面からみて事実 •アクセスしたデータがメモリに収ま っている場合に置いて高速 13年8月1日木曜日
  34. 34. 基本的な考え方 •永続化メモリDB •メモリとディスクのいいとこどりは 可能(完全には無理) •ioDrive的な物と組み合わせる 13年8月1日木曜日
  35. 35. 基本的な考え方 •ロック •書き込みはデータベースロック •ロック粒度の制御はデータベース分 離を行うことで実施 •更新割合の多すぎるアプリケーショ ンは厳しい 13年8月1日木曜日
  36. 36. 基本的な考え方 •シャーディング •ある程度の規模感になると絶対苦労 する •どんなクラスタデータストア使って も苦労しなかったことが無い 13年8月1日木曜日
  37. 37. 基本的な考え方 •シャーディング •ノード数でスケールはする→シャー ドとしてのメモリ量の数が増えるた め 13年8月1日木曜日
  38. 38. こんなかんじ 13年8月1日木曜日
  39. 39. では細かい部分を 見て行きましょう 13年8月1日木曜日
  40. 40. ユースケース •どのような使い方ですか? •アクセスパターン •データ量 •データ増分 13年8月1日木曜日
  41. 41. アクセスパターン •ホットデータの存在しないアプリケ ーションは厳しい 13年8月1日木曜日
  42. 42. ホットデータ? 13年8月1日木曜日
  43. 43. ホットデータ •よくアクセスされるデータがある •例)全体データの5%のみアクセス する 13年8月1日木曜日
  44. 44. アクセスパターン •有利なパターン •データ量が少ないがアクセスが頻 発するパターン •データ量は多いがアクセスが少な いパターン 13年8月1日木曜日
  45. 45. データ増分 •データ量が爆発的に増えるパターン のデータは苦手 →アクセスパターンの話と同じ 13年8月1日木曜日
  46. 46. なぜこのようにな るか 13年8月1日木曜日
  47. 47. 元凶は MongoDBのメモリ管理 13年8月1日木曜日
  48. 48. メモリ管理 •アクセスしたデータファイルは mmapとしてキャッシュ •メモリからあふれた場合はアクセス された物を入れて、使われてないもの を削除 •LRU的な仕組みはなく、OS任せ 13年8月1日木曜日
  49. 49. メモリ管理[mmap] mmapdatafile.2datafile.0 mmap datafile.1 mongodb 13年8月1日木曜日
  50. 50. メモリ管理 •ホットデータがある場合はメモリを 使いまわしながら効率よくアクセス が可能 13年8月1日木曜日
  51. 51. mmapdatafile.2datafile.0 mmap datafile.1 mongodb 13年8月1日木曜日
  52. 52. mmapdatafile.0 mmap datafile.1 mongodb datafile.3datafile.2 13年8月1日木曜日
  53. 53. メモリ管理 •単位時間に必要のあるデータへの過 剰なアクセス •何が起きるか→ホットデータのない アクセスパターンではディスクへのア クセスが頻繁に起きる 13年8月1日木曜日
  54. 54. mmapdatafile.2datafile.0 mmap datafile.1 mongodb メモリ量以上のデ ータアクセス毎に メモリ<ー>ディスク へのアクセスが頻 発する 13年8月1日木曜日
  55. 55. メモリ管理 •このアクセスパターンは例えば? •継続的なログ解析基盤などの全体 データへのアクセス •SNSの全データにアクセスする頻 度の多いアクセスパターン 13年8月1日木曜日
  56. 56. じゃあログ とかは使えない? 13年8月1日木曜日
  57. 57. そこでこれ 13年8月1日木曜日
  58. 58. CappedCollection •保存できるデータ量が制限(Cap) されたコレクション •一定データが常に残される •Insertのみ、Updateは不可(デー タ肥大化しない) •シャード環境ではTTLCollectionが 13年8月1日木曜日
  59. 59. CappedCollection mmap 新しいデータ 削除 新しいデータ データ量は一定 データ量<使用メモリ量 13年8月1日木曜日
  60. 60. CappedCollection •データ量が制限されることにより、 メモリのキャッシュが常に使わせる •データ量が少ないため大量データに は使えない 13年8月1日木曜日
  61. 61. ログ解析基盤 •ログ解析基盤としてシャードで組も うとするとハマる 13年8月1日木曜日
  62. 62. 「データをいくらでも入 れられるぜー、でも解析 はおせーんだぜー」 13年8月1日木曜日
  63. 63. 「それ意味ないで すよね?」 13年8月1日木曜日
  64. 64. ログ解析基盤 •CappedCollectionでメモリよりデ ータ量が増えない=安定アクセス •fluentd+mongodbでjsベースのお 手軽リアルタイムログ解析基盤が作成 できる 13年8月1日木曜日
  65. 65. ログ解析基盤 •複雑なデータアクセスが発生しない のでシャーディングは組まないで、ア プリ側で複数ノードにアクセスする ような形にするのも良い 13年8月1日木曜日
  66. 66. ログ解析基盤 •容量増やす場合は? •1つはメモリの量をデータの最大量 と割りきる形でシャードを組む (TTLCollection等も有効) •後は? 13年8月1日木曜日
  67. 67. ioDrive使うt(ry 13年8月1日木曜日
  68. 68. ioDrive使うt(ry 13年8月1日木曜日
  69. 69. TREASURE DATA使うt(ry 13年8月1日木曜日
  70. 70. TREASURE DATA使うt(ry 13年8月1日木曜日
  71. 71. Webアプリ •データの取得がしやすい、データ構 造の自由度が高い、と言った部分が 生きてくる •ソーシャルゲームなどでのデータアク セスは一般的に全データ舐める事は 少ない 13年8月1日木曜日
  72. 72. Webアプリ •ランキング等は全データ舐めてしま う様な実装になりがちなので、別シス テム、別データストアで実装する (例:Redis、MySQL 13年8月1日木曜日
  73. 73. Webアプリ •シャードもノードを増やせばとりあ えずスケールする部分は大きい •クラウド環境などが生きる 13年8月1日木曜日
  74. 74. 「アクセスが増えたらイ ンスタンスを増やせば いいじゃない?」 13年8月1日木曜日
  75. 75. 「まあアクセス減ったら 減らせばいいしね」 13年8月1日木曜日
  76. 76. まとめ •MongoDBが使いやすいパターン •アクセスデータ量( 保存データ量) が少ないもの •書き込み回数が極端に多くない。 •読み込み回数は多くてもおk 13年8月1日木曜日
  77. 77. まとめ •速いWebサービス立ち上げに MongoDBは一つの選択肢と思います •データ構造/楽なスケーラブル等、お いしい部分を活かす様な運用を行なっ てみる事で見えなかった物が見えるか もしれません。 •もんごもんご 13年8月1日木曜日
  78. 78. ご清聴 ありがとう ございました! 13年8月1日木曜日
  79. 79. 宣伝! •WEB+DB PRESS Vol. 75 に 「MongoDB実 践入門」を書きました! 13年8月1日木曜日
  80. 80. 後半はアプリ実装 について @matsukaz からです! 13年8月1日木曜日
  81. 81. ご清聴 ありがとう ございました! 13年8月1日木曜日

×