タグ: KVS

第3回クラウド勉強会

~NoSQL(KVS)大集合~

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

場所:ベルサール西新宿

ustream

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

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

利用する製品

・グリーのFlare
・kumofs
で検討

Flareを検討する

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

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

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

検討結果

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

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

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

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

現在の利用状況

・16ユーザ
・レコード600万
・サイズ94GB(レプリケーションがあるので実際はこれの2倍)

利用事例

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

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

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

Flareを使ってみての注意点

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

運用上の問題

・インデックスサーバの冗長化ができない
・flush_allコマンドがレプリケーションされない
・操作インタフェースがtelnetのみ
・tokyocabinetの仕様により、デフォルトで1データベースファイルの容量が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やtmpfsを使用でしのいだ
  • Network Trafifc
    アクセス数が多くするとネットワーク量の問題が出てくる
  • Security
    油断してしまう場所
    エスケープがおざなり
    例:プロトコルのデリミタである改行
    GET <key>の<key>の部分に
    「1\nflush_all」と指定して、flush_allを実行してしまった

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

okuyama

OSS分散KVS

java製

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

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

クライアント

JavaとPHPが実装済み

マスターノード

プロトコル

  • オリジナル
  • Memcached(テキスト)
  • HTTP(GET)

データ入出力

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

制限なしに冗長化可能

ネットワークの仕組み

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

データノード

最大3ノードに保存

連鎖的ダウンの予防

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

データ保存形式

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

データ一貫性

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

スケールアウト

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

ユニーク機能

  • タグをデータに追加できる(いくつでも)
  • javascriptをデータノードで実行できる

性能

1台のマスターノード、データノードで実験
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機能
他のプレイヤーに挨拶する機能
時間制限がある(2hに一回だけなど)
最後にPOKEした時刻を記憶させておき、再リクエスト時の期間チェックにつかう

kumofsを使用→………

KVSの選び方

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

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