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

後悔しないもんごもんごの使い方

～サーバ編～桑野　章弘(@kuwa_tw)

13年8月1日木曜日

自己紹介

13年8月1日木曜日

自己紹介

•桑野　章弘

•渋谷の緑のサーバサイドエンジニア

•Twitter: @kuwa_tw

•#qpstudy の中の人

•あだな：銀河

13年8月1日木曜日

ピグやってました

13年8月1日木曜日

ピグやってました

13年8月1日木曜日

ピグやってました

13年8月1日木曜日

ピグやってました

13年8月1日木曜日

ピグやってました

13年8月1日木曜日

今日の話

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

•ユースケースについて

13年8月1日木曜日

基本的な話

13年8月1日木曜日

データ構造•BSONオブジェクトとしてデータもつ

• _idはプライマリキーで、Indexも貼られる

•スキーマレス

•データへのアクセスがしやすい、実装しやすい

13年8月1日木曜日

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

13年8月1日木曜日

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

13年8月1日木曜日

データ構造

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

13年8月1日木曜日

アプリケーションサーバ

mongos

mongoc

Mongod[ShardB]

Mongod[ShardC]

Mongod[ShardA]

一般的（？）な構成

13年8月1日木曜日

ReplicaSets

•相互死活監視と投票により冗長化

•Oplogの受け渡しによるデータ同期

13年8月1日木曜日

ReplicaSets

プライマリ

セカンダリセカンダリ

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

Oplog

OplogOplog

13年8月1日木曜日

ReplicaSets

プライマリ

セカンダリセカンダリ

13年8月1日木曜日

ReplicaSets

プライマリ

セカンダリ->プライマリセカンダリ

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

13年8月1日木曜日

Sharding

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

13年8月1日木曜日

アプリケーションサーバ

mongos

mongoc

Mongod[ShardB]

Mongod[ShardC]

Mongod[ShardA]

Sharding

ShardingデータをChunkの単位に分ける

mongocはシャーディング情報を持つ

ChunkA -> ShardAChunkB -> ShardBChunkC -> ShardC

13年8月1日木曜日

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

13年8月1日木曜日

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

13年8月1日木曜日

ユースケース

•MongoDBにかぎらず、NoSQLはできる、できない、がハッキリしている

•NoSQL使うならできる部分を伸ばす必要があり、できない部分を突き詰めるとRDBMSになる

13年8月1日木曜日

ユースケース

•MongoDBにかぎらず、NoSQLはできる、できない、がハッキリしている

•NoSQL使うならできる部分を伸ばす必要があり、できない部分を突き詰めるとRDBMSになる

13年8月1日木曜日

ユースケース

•MongoDBにかぎらず、NoSQLはできる、できない、がハッキリしている

•NoSQL使うならできる部分を伸ばす必要があり、できない部分を突き詰めるとRDBMSになる

13年8月1日木曜日

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

13年8月1日木曜日

こんな形です

13年8月1日木曜日

良い

•ゲーム系Webアプリケーション

•一時的ログ解析基盤

13年8月1日木曜日

悪い

•ソーシャル系等のWebアプリケーション

•継続的 or 統合的 ログ解析基盤

13年8月1日木曜日

基本的な考え方

13年8月1日木曜日

基本的な考え方

•まず最初にMongoDBを使うにあたって基本的な考え方を

•ここからの話もコレにそって話が進みます

13年8月1日木曜日

基本的な考え方•永続化メモリDB

•完全にそうではなく、異論反論あるかと思います。

•が、一面からみて事実

•アクセスしたデータがメモリに収まっている場合に置いて高速

13年8月1日木曜日

基本的な考え方

•永続化メモリDB

•メモリとディスクのいいとこどりは可能（完全には無理）

• ioDrive的な物と組み合わせる

13年8月1日木曜日

基本的な考え方•ロック

•書き込みはデータベースロック

•ロック粒度の制御はデータベース分離を行うことで実施

•更新割合の多すぎるアプリケーションは厳しい

13年8月1日木曜日

基本的な考え方

•シャーディング

•ある程度の規模感になると絶対苦労する

•どんなクラスタデータストア使っても苦労しなかったことが無い

13年8月1日木曜日

基本的な考え方

•シャーディング

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

13年8月1日木曜日

こんなかんじ

13年8月1日木曜日

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

13年8月1日木曜日

ユースケース

•どのような使い方ですか？

•アクセスパターン

•データ量

•データ増分

13年8月1日木曜日

アクセスパターン

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

13年8月1日木曜日

ホットデータ？

13年8月1日木曜日

ホットデータ

•よくアクセスされるデータがある

•例）全体データの5%のみアクセスする

13年8月1日木曜日

アクセスパターン

•有利なパターン

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

•データ量は多いがアクセスが少ないパターン

13年8月1日木曜日

データ増分

•データ量が爆発的に増えるパターンのデータは苦手

→アクセスパターンの話と同じ

13年8月1日木曜日

なぜこのようになるか

13年8月1日木曜日

元凶はMongoDBのメモリ管理

13年8月1日木曜日

メモリ管理•アクセスしたデータファイルはmmapとしてキャッシュ

•メモリからあふれた場合はアクセスされた物を入れて、使われてないものを削除

•LRU的な仕組みはなく、OS任せ

13年8月1日木曜日

メモリ管理[mmap]

mmapdatafile.2datafile.0

mmap

datafile.1

mongodb

13年8月1日木曜日

メモリ管理

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

13年8月1日木曜日

mmapdatafile.2datafile.0

mmap

datafile.1

mongodb

13年8月1日木曜日

mmapdatafile.0

mmap

datafile.1

mongodb

datafile.3datafile.2

13年8月1日木曜日

メモリ管理

•単位時間に必要のあるデータへの過剰なアクセス

•何が起きるか→ホットデータのないアクセスパターンではディスクへのアクセスが頻繁に起きる

13年8月1日木曜日

mmapdatafile.2datafile.0

mmap

datafile.1

mongodb

メモリ量以上のデータアクセス毎にメモリ<ｰ>ディスクへのアクセスが頻発する

13年8月1日木曜日

メモリ管理

•このアクセスパターンは例えば？

•継続的なログ解析基盤などの全体データへのアクセス

•SNSの全データにアクセスする頻度の多いアクセスパターン

13年8月1日木曜日

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

13年8月1日木曜日

そこでこれ

13年8月1日木曜日

CappedCollection•保存できるデータ量が制限（Cap）されたコレクション

•一定データが常に残される

• Insertのみ、Updateは不可（データ肥大化しない）

•シャード環境ではTTLCollectionが

13年8月1日木曜日

CappedCollection

mmap

新しいデータ 削除

新しいデータ

データ量は一定　データ量＜使用メモリ量

13年8月1日木曜日

CappedCollection

•データ量が制限されることにより、メモリのキャッシュが常に使わせる

•データ量が少ないため大量データには使えない

13年8月1日木曜日

ログ解析基盤

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

13年8月1日木曜日

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

13年8月1日木曜日

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

13年8月1日木曜日

ログ解析基盤

•CappedCollectionでメモリよりデータ量が増えない＝安定アクセス

•fluentd+mongodbでjsベースのお手軽リアルタイムログ解析基盤が作成できる

13年8月1日木曜日

ログ解析基盤

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

13年8月1日木曜日

ログ解析基盤

•容量増やす場合は？

•1つはメモリの量をデータの最大量と割りきる形でシャードを組む（TTLCollection等も有効）

•後は？

13年8月1日木曜日

ioDrive使うｔ（ｒｙ

13年8月1日木曜日

ioDrive使うｔ（ｒｙ

13年8月1日木曜日

TREASURE DATA使うｔ（ｒｙ

13年8月1日木曜日

TREASURE DATA使うｔ（ｒｙ

13年8月1日木曜日

Webアプリ•データの取得がしやすい、データ構造の自由度が高い、と言った部分が生きてくる

•ソーシャルゲームなどでのデータアクセスは一般的に全データ舐める事は少ない

13年8月1日木曜日

Webアプリ

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

13年8月1日木曜日

Webアプリ

•シャードもノードを増やせばとりあえずスケールする部分は大きい

•クラウド環境などが生きる

13年8月1日木曜日

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

13年8月1日木曜日

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

13年8月1日木曜日

まとめ•MongoDBが使いやすいパターン

•アクセスデータ量（≠保存データ量）が少ないもの

•書き込み回数が極端に多くない。

•読み込み回数は多くてもおｋ

13年8月1日木曜日

まとめ•速いWebサービス立ち上げにMongoDBは一つの選択肢と思います

•データ構造／楽なスケーラブル等、おいしい部分を活かす様な運用を行なってみる事で見えなかった物が見えるかもしれません。

•もんごもんご

13年8月1日木曜日

ご清聴ありがとう

ございました！

13年8月1日木曜日

宣伝！

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

13年8月1日木曜日

後半はアプリ実装について

@matsukazからです！

13年8月1日木曜日

ご清聴ありがとう

ございました！

13年8月1日木曜日