～NoSQL（KVS）大集合～

URL:http://atnd.org/events/10152

場所：ベルサール西新宿

ustream

さくらインターネット株式会社大久保様「KVSのマルチテナント化について」 http://bit.ly/hTl06D
グリー株式会社藤本様「Flareについて」 http://bit.ly/fL89tF
株式会社神戸デジタル・ラボ岩瀬様「okuyama」 http://bit.ly/gSLcPn
楽天株式会社西澤様「ROMA ユーザ拡張性の高い NoSQL DB 」 http://bit.ly/fXVcQH
株式会社ドリコム川上様「Redis & Resque」 http://bit.ly/go61tk
株式会社ドワンゴ小野様「ニコニコ生放送におけるRedis利用事例」 http://bit.ly/ggnuim
株式会社ワークスアプリケーションズ川中様「間違った方向にCassandraを使ってみた。イベント開催支援ツール http://PARTAKE.IN 」 http://bit.ly/dEreET
株式会社gumi 堀内様「ソーシャルゲーム KVSの使いどころ」 http://bit.ly/dR3vOh

「KVSのマルチテナント化」
（さくらインターネット株式会社大久保修一氏）

Ustream:http://www.ustream.tv/recorded/11463341

利用する製品

・グリーのFlare
・kumofs
で検討

Flareを検討する

・インデックスサーバ
・ストレージサーバ（マスタ/スレーブこれらをまとめてパーティションと呼ぶ）
・プロキシサーバ
で構成

マルチテナント化に当たって複数ユーザで利用するための方法を検討

・キーの名前空間（ユーザをキーにしてユーザを区別）
・ポート別複数プロセス（ユーザごとにポートを分ける）
・仮想マシン、VLAN分割（ユーザごとに環境を用意）

検討結果

・キーの名前空間
低オーバヘッド ◎
標準実装☓
隔離性○

・ポート別複数プロセス
低オーバヘッド○
標準実装○
隔離性○

・仮想マシン、VLAN分割
低オーバヘッド☓
標準実装○
隔離性◎

→ポート別複数プロセスが無難と判断

現在の利用状況

・１６ユーザ
・レコード６００万
・サイズ９４GB（レプリケーションがあるので実際はこれの２倍）

利用事例

・とある櫻花の画像生成
・douj.in（短縮URLサービス）

Flareを使ってみての良いところ

・高速
・setのFlagオプションやCASコマンドにも対応
・シンプルアーキテクチャ
・サーバ間通信もｍｅｍｃａｃｈｅｄプロトコル
・インストール・設定が簡単
・大量データ、高負荷でも安定稼働
→一億レコード、２００ＧＢ程度まで確認

Flareを使ってみての注意点

・setが完了してもディスクには書き込まれない
・レプリケーション完了前にsetコマンドが完了する(set直後のgetは古い値の可能性も
・setコマンドのsyncオプションで回避可能
・単純なキーを使うとデータがうまく分散しない
→ハッシュアルゴリズムの問題と思われる

運用上の問題

・インデックスサーバの冗長化ができない
・flush_allコマンドがレプリケーションされない
・操作インタフェースがtelnetのみ
・tokyocabinetの仕様により、デフォルトで１データベースファイルの容量が64GB

今後も各KVSのNoSQLも検討する

「Flareについて」
（グリー株式会社藤本真樹氏）

Flareについて

なぜクラウドでNoSQLか？
RDBMSのスケーラビリティ問題がでてきた
↓
対策としてsharding, no joins, no transactionsがでる
↓
全部RDBMSじゃなくてもといいんじゃね？
↓
simple data models

GREEでのKVS

利用用途

cache
フィード
ストリーム
あしあと
ゲームのポイント的な物

200台のクラスタが稼働中

MySQL+Flare

CAS：KVSはトランザクションやロックがないので同時アクセス時の整合性を取るために使うしくみ

はまったところ、注意点

Disk I/O
SSDやｔｍｐｆｓを使用でしのいだ
Network Trafifc
アクセス数が多くするとネットワーク量の問題が出てくる
Security
油断してしまう場所
エスケープがおざなり
例：プロトコルのデリミタである改行
GET <key>の<key>の部分に
「1\nflush_all」と指定して、flush_allを実行してしまった

「okuyamaについて」
（株式会社神戸デジタル・ラボ岩瀬高博氏）

okuyama

OSS分散KVS

java製

フルスクラッチ
すべてオリジナル

・クライアント
・マスターノード
・データノード
の３台１セット

クライアント

JavaとPHPが実装済み

マスターノード

プロトコル

オリジナル
Memcached（テキスト）
HTTP（GET）

データ入出力

データ転送の際マスターを通過する
サポート分散アルゴリズム
・Mod
・コンセントハッシュ

制限なしに冗長化可能

ネットワークの仕組み

タスク多段キュー＋workerプール

データノード

最大３ノードに保存

連鎖的ダウンの予防

マスターノード側で分散の重みを管理

データ保存形式

永続、非永続で合計４種類用意

データ一貫性

マスターノードごとに３種類選択可能

スケールアウト

SPOFの存在しない構成
設定情報はデータノードに

ユニーク機能

タグをデータに追加できる（いくつでも）
ｊａｖａｓｃｒｉｐｔをデータノードで実行できる

性能

１台のマスターノード、データノードで実験
GET 480万/min 8万 /sec
SET 290万/min 4.8万/sec

at-linkで開発検証作業中

マルチテナント化 → 共有キャッシュサーバとして
ログサーバ化＋Hadoop → 永続化型分散基盤として
画像サーバ化 →スケールアウト型ストレージとして

ROMAについて（楽天株式会社西澤無我氏）

ROMAの最大の特徴は拡張性

プラグイン機構によって振る舞いを簡単に拡張可能

よく知られた要素技術の組み合わせで構成

最近楽天市場のお買い物マラソンを乗り切った

利用事例：楽天トラベルの「最近見た宿」

ライトニングトーク

Redis と Resqueの利用事例（株式会社ドリコム川上知成氏）

Resque＝GitHub で開発／運用している、裏にRedis を採用したジョブキューシステム。

ソーシャルアプリでResque利用場面
・デイリーランキング処理

WEBの管理画面が付いている

キューイングシステムとしては及第点

「ニコニコ生放送」Redis の利用事例（株式会社ドワンゴ小野侑一氏）

生放送はすべてリアルタイム→膨大な量の更新が必要

従来はmemcachedで実装

フロント系事例

視聴ページ
- タグ
- カウンタ
生放送一覧
- 番組リスト（各順序ごとに）
- 予約番組表

バックエンド

視聴者数集計に使っている

これまではバッチ処理

番組をキーにして値にユーザIDのリストを記録する→合計値がユニーク人数

キーを番組＋性別などにする→いろいろなターゲットでそれぞれカウント可能

リアルタイムに把握できる

注意点

早い便利だが一切スケールしない
→レプリケーションで冗長性は確保
キー数と容量に注意
→明示的にしていないとデータが消えない
→バキューム処理が必要
ファイルディスクリプタの上限に注意
→コネクション数を監視して調整

「間違った方向に Cassandra を使ってみた / イベント参加管理支援ツール PARTAKE」（株式会社ワークスアプリケーションズ川中真耶氏）

RDBの代わりにKVSを使ってみたが…

RDBには簡単にできてKVSでは面倒なこと

検索項目の追加
同時複数キー編集
→先行書き込みログを残す（自分で）
cassandraは数自体が数えられない。将来追加予定

「ソーシャルゲーム、KVSの使いどころ」（株式会社gumi 堀内康弘氏）

ソーシャルゲームでのKVS

主要機能にDBの更新機能処理が必要なることが多い

アプリがヒットするとRDBの性能を超えたリクエストがやってくる

RDBのサポートしてKVSを利用

例
POKE機能
他のプレイヤーに挨拶する機能
時間制限がある（２ｈに一回だけなど）
最後にPOKEした時刻を記憶させておき、再リクエスト時の期間チェックにつかう

kumofsを使用→………

KVSの選び方

永続性
→キャッシュかストレージか
一貫性

この２つの観点から製品を決定する