タグ: Redis

Redis 2.4.17 x CentOS 6.3

/opt/srcにソースを、/opt/redisに実行ファイル、設定ファイル、ログを配置する。

準備

ビルドに必要なツールをインストール。

 yum install -y make gcc (makeに必要)
 yum install -y tcl (make testに必要)

ビルド

#mkdir /opt/src
#cd /opt/src
#curl -o redis-2.4.17.tar.gz http://redis.googlecode.com/files/redis-2.4.17.tar.gz
#tar -xvf redis-2.4.17.tar.gz
#cd redis-2.4.17
#make

    cd src && make all
    make[1]: ディレクトリ `/opt/src/redis-2.4.17/src' に入ります
    MAKE hiredis
    :
    :
    :
    CC slowlog.o
    CC bio.o
    CC memtest.o
    LINK redis-server

    Hint: To run 'make test' is a good idea ;)

#make test

    cd src && make test
    make[1]: ディレクトリ `/opt/src/redis-2.4.17/src' に入ります
    /usr/bin/tclsh8.5
    Cleanup: may take some time... OK
    Starting test server at port 11111
    [ready]: 18539
    Testing unit/printver
    :
    :
    :
    \o/ All tests passed without errors!

    Cleanup: may take some time... OK
    make[1]: ディレクトリ `/opt/src/redis-2.4.17/src' から出ます

インストール

PREFIXがないと/usr/local/binにインストールされます。

#PREFIX=/opt/redis make install

設定ファイルと起動スクリプトの設置

このスクリプトでは、/etc/init.dに配置されるファイル名がredis_ポート番号となる。
今回は一台のみで名前をredisにしたいので、一部修正する。

#cd utils/
#vi ./install_server.sh

下記行のIF文のの間にスペースを入れる。

61行目

if [ !"$REDIS_CONFIG_FILE" ] ; then
↓
if [ ! "$REDIS_CONFIG_FILE" ] ; then

71行目

if [ !"$REDIS_LOG_FILE" ] ; then
↓
if [ ! "$REDIS_LOG_FILE" ] ; then

80行目

if [ !"$REDIS_DATA_DIR" ] ; then
↓
if [ ! "$REDIS_DATA_DIR" ] ; then

起動スクリプトのファイル名を変更する

104~105行目

INIT_SCRIPT_DEST="/etc/init.d/redis_$REDIS_PORT"
PIDFILE="/var/run/redis_$REDIS_PORT.pid"
↓
INIT_SCRIPT_DEST="/etc/init.d/redis"
PIDFILE="/var/run/redis.pid"

168~169行目

chkconfig --add redis_$REDIS_PORT && echo "Successfully added to chkconfig!"
chkconfig --level 345 redis_$REDIS_PORT on && echo "Successfully added to runlevels 345!"
↓
chkconfig --add redis && echo "Successfully added to chkconfig!"
chkconfig --level 345 redis on && echo "Successfully added to runlevels 345!"

172行目

/etc/init.d/redis_$REDIS_PORT start || die "Failed starting service..."
↓
/etc/init.d/redis start || die "Failed starting service..."

インストールスクリプトの実行

#mkdir -p /opt/redis/log
#PATH=/opt/redis/bin:$PATH ./install_server.sh

    Welcome to the redis service installer
    This script will help you easily set up a running redis server

    Please select the redis port for this instance: [6379]
    Selecting default: 6379
    Please select the redis config file name [/etc/redis/6379.conf] /opt/redis/etc/redis.conf
    Please select the redis log file name [/var/log/redis_6379.log] /opt/redis/log/redis.log
    Please select the data directory for this instance [/var/lib/redis/6379] /opt/redis/data
    Please select the redis executable path [/opt/redis/bin/redis-server]
    Copied /tmp/6379.conf => /etc/init.d/redis
    Installing service...
    Successfully added to chkconfig!
    Successfully added to runlevels 345!
    Starting Redis server...
    Installation successful!

動作確認

#service redis start (install_server.sh直後であればすでに起動しているので不要)

#/opt/redis/bin/redis-cli
    redis 127.0.0.1:6379> set foo bar
    OK
    redis 127.0.0.1:6379> get foo
    "bar"
    redis 127.0.0.1:6379> quit
広告

第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つの観点から製品を決定する