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

後悔しない
もんごもんごの使い方
∼サーバ編∼
桑野章弘(@kuwa_tw)
13年8月1日木曜日

自己紹介

自己紹介
•桑野章弘
•渋谷の緑のサーバサイドエンジニア
•Twitter: @kuwa_tw
•#qpstudy の中の人
•あだな：銀河

ピグやってました

今日の話
•運用を楽にしたい分散データベース
•ユースケースについて

基本的な話

データ構造
•BSONオブジェクトとしてデータもつ
•_idはプライマリキーで、Indexも貼ら
れる
•スキーマレス
•データへのアクセスがしやすい、実装
しやすい

データ構造
{
"_id" : "45feae009015221f",
"45feae009015221f" : {
"name" : "あきひろ",
"job" : {
"level" : 15,
"exp" : 24
}
}
}

データ構造{
"_id" : "45feae009015221f",
"45feae009015221f" : {
"name" : "あきひろ",
"job" : {
"level" : 15,
"exp" : 24
},
"subjob" : {
"level" : 1,
"exp" : 1
}
}
}

データ構造
•データへのアクセスのしやすさや実装
のしやすさは後半で説明される（は
ず）！

アプリケーション
サーバ
mongos
mongoc
Mongod[ShardB]
Mongod[ShardC]
Mongod[ShardA]
一般的（？）な構成

ReplicaSets
•相互死活監視と投票により冗長化
•Oplogの受け渡しによるデータ同期

ReplicaSets
プライマリ
セカンダリセカンダリ
プライマリに行
われた更新をセ
カンダリにも適
用させる
Oplog
OplogOplog

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

ReplicaSets
プライマリ
セカンダリ->プライマリセカンダリ
生きているサー
バで投票が行わ
れ新しいプライ
マリが選ばれる

Sharding
•データを細かいデータ範囲に分割し、
複数のmongodで処理する

アプリケーション
サーバ
mongos
mongoc
Mongod[ShardB]
Mongod[ShardC]
Mongod[ShardA]
Sharding
Sharding
データをChunk
の単位に分ける
mongocはシャ
ーディング情報を
持つ
ChunkA -> ShardA
ChunkB -> ShardB
ChunkC -> ShardC

このへんはもうい
いですよね？

運用を楽にしたい
分散データベース

ユースケース
•MongoDBにかぎらず、NoSQLはで
きる、できない、がハッキリしている
•NoSQL使うならできる部分を伸ばす必
要があり、できない部分を突き詰める
とRDBMSになる

では実際のユース
ケースの話

こんな形です

良い
•ゲーム系Webアプリケーション
•一時的ログ解析基盤

悪い
•ソーシャル系等のWebアプリケーシ
ョン
•継続的 or 統合的ログ解析基盤

基本的な考え方

•まず最初にMongoDBを使うにあ
たって基本的な考え方を
•ここからの話もコレにそって話が進
みます

•永続化メモリDB
•完全にそうではなく、異論反論ある
かと思います。
•が、一面からみて事実
•アクセスしたデータがメモリに収ま
っている場合に置いて高速

•永続化メモリDB
•メモリとディスクのいいとこどりは
可能（完全には無理）
•ioDrive的な物と組み合わせる

•ロック
•書き込みはデータベースロック
•ロック粒度の制御はデータベース分
離を行うことで実施
•更新割合の多すぎるアプリケーショ
ンは厳しい

•シャーディング
•ある程度の規模感になると絶対苦労
する
•どんなクラスタデータストア使って
も苦労しなかったことが無い

•シャーディング
•ノード数でスケールはする→シャー
ドとしてのメモリ量の数が増えるた
め

こんなかんじ

では細かい部分を
見て行きましょう

ユースケース
•どのような使い方ですか？
•アクセスパターン
•データ量
•データ増分

アクセスパターン
•ホットデータの存在しないアプリケ
ーションは厳しい

ホットデータ？

ホットデータ
•よくアクセスされるデータがある
•例）全体データの5%のみアクセス
する

アクセスパターン
•有利なパターン
•データ量が少ないがアクセスが頻
発するパターン
•データ量は多いがアクセスが少な
いパターン

データ増分
•データ量が爆発的に増えるパターン
のデータは苦手
→アクセスパターンの話と同じ

なぜこのようにな
るか

元凶は
MongoDBのメモリ管理

メモリ管理
•アクセスしたデータファイルは
mmapとしてキャッシュ
•メモリからあふれた場合はアクセス
された物を入れて、使われてないもの
を削除
•LRU的な仕組みはなく、OS任せ

メモリ管理[mmap]
mmapdatafile.2datafile.0
mmap
datafile.1
mongodb

メモリ管理
•ホットデータがある場合はメモリを
使いまわしながら効率よくアクセス
が可能

mmap
dataﬁle.1
mongodb

mmapdatafile.0
mmap
datafile.1
mongodb
datafile.3datafile.2

メモリ管理
•単位時間に必要のあるデータへの過
剰なアクセス
•何が起きるか→ホットデータのない
アクセスパターンではディスクへのア
クセスが頻繁に起きる

mmap
dataﬁle.1
mongodb
メモリ量以上のデ
ータアクセス毎に
メモリ<ｰ>ディスク
へのアクセスが頻
発する

メモリ管理
•このアクセスパターンは例えば？
•継続的なログ解析基盤などの全体
データへのアクセス
•SNSの全データにアクセスする頻
度の多いアクセスパターン

じゃあログ
とかは使えない？

そこでこれ

CappedCollection
•保存できるデータ量が制限（Cap）
されたコレクション
•一定データが常に残される
•Insertのみ、Updateは不可（デー
タ肥大化しない）
•シャード環境ではTTLCollectionが

CappedCollection
mmap
新しいデータ
削除
新しいデータ
データ量は一定データ量＜使用メモリ量

CappedCollection
•データ量が制限されることにより、
メモリのキャッシュが常に使わせる
•データ量が少ないため大量データに
は使えない

ログ解析基盤
•ログ解析基盤としてシャードで組も
うとするとハマる

「データをいくらでも入
れられるぜー、でも解析
はおせーんだぜー」

「それ意味ないで
すよね？」

ログ解析基盤
•CappedCollectionでメモリよりデ
ータ量が増えない＝安定アクセス
•ﬂuentd+mongodbでjsベースのお
手軽リアルタイムログ解析基盤が作成
できる

ログ解析基盤
•複雑なデータアクセスが発生しない
のでシャーディングは組まないで、ア
プリ側で複数ノードにアクセスする
ような形にするのも良い

ログ解析基盤
•容量増やす場合は？
•1つはメモリの量をデータの最大量
と割りきる形でシャードを組む
（TTLCollection等も有効）
•後は？

ioDrive使うｔ（ｒｙ

TREASURE DATA使うｔ（ｒｙ

Webアプリ
•データの取得がしやすい、データ構
造の自由度が高い、と言った部分が
生きてくる
•ソーシャルゲームなどでのデータアク
セスは一般的に全データ舐める事は
少ない

Webアプリ
•ランキング等は全データ舐めてしま
う様な実装になりがちなので、別シス
テム、別データストアで実装する
（例：Redis、MySQL

Webアプリ
•シャードもノードを増やせばとりあ
えずスケールする部分は大きい
•クラウド環境などが生きる

「アクセスが増えたらイ
ンスタンスを増やせば
いいじゃない?」

「まあアクセス減ったら
減らせばいいしね」

まとめ
•MongoDBが使いやすいパターン
•アクセスデータ量（保存データ量）
が少ないもの
•書き込み回数が極端に多くない。
•読み込み回数は多くてもおｋ

まとめ
•速いWebサービス立ち上げに
MongoDBは一つの選択肢と思います
•データ構造／楽なスケーラブル等、お
いしい部分を活かす様な運用を行なっ
てみる事で見えなかった物が見えるか
もしれません。
•もんごもんご

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

宣伝！
•WEB+DB PRESS Vol.
75 に「MongoDB実
践入門」を書きました！

後半はアプリ実装
について
@matsukaz
からです！

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

More Related Content