Rest Term

Redisの監視/分析系ツールまとめ

Pocket

Redis関連の監視/データ分析系ツールについてメモしておきます。

随時追記予定。実務で有用なツールが他にありましたら教えていただけると嬉しいです。

環境

CentOS 5.9, Ubuntu 12.04 (x86_64)
Redis 2.6.10
(※ CentOSの6.x系への移行は足踏み状態。相当大変ですよね。。)

以下の順に紹介していきます。

  • Redisコマンド
  • Redis Sentinel
  • Redis Live
  • Redis Faina
  • Redis Sampler
  • redis-top
  • Nagiosプラグイン
  • Zabbixテンプレート
  • Muninプラグイン
  • Cactiプラグイン

最後のCactiプラグイン以外は実際に導入して試してみました。以降、見出しに各プロダクトへのリンクを貼っておきます。

Redisコマンド

ツール紹介の前にまずは基本から。Redisには監視やデータ解析用途で使えるコマンドがいくつか用意されています。後で紹介する各ツールはこれらのコマンドの出力を利用しているものがほとんどです。

PINGコマンド

Redisサーバに対してpingを打ちます。死活監視用。

INFOコマンド

Redisサーバの設定情報とメモリ使用量など現在の各種統計情報を出力してくれます。Redisのバージョンによって項目名が変更されているので注意しておきます。

Redisサーバが使用可能なメモリ量の上限は CONFIG GET maxmemory で取得できるので、INFOコマンドの used_memory の値を使えばメモリ使用率も計算できます。また、保存されているキーの数を調べるだけならDBSIZEコマンドも利用できます。

スレーブ側でINFOコマンドを実行した時は Replication 項目にも注目します。

レプリケーションが正常に動作しているかどうかは master_link_status の項目で判断できます(up/down)。

CONFIG GETコマンド

Redisサーバの各設定パラメータ値を確認できるコマンドです。

SLOWLOGコマンド

スロークエリログを管理するコマンドです。スロークエリだと判断するクエリ実行時間は設定ファイルの slowlog-log-slower-than で指定できます(デフォルト 10000マイクロ秒)。また、このスロークエリログはメモリ内に保存されるためファイルには書き出されません。

MONITORコマンド

クエリ情報をリアルタイムに出力します(tail -fのように)。このMONITORコマンドの出力情報を集めておけば、どのキーに対してどんな操作が行われたか統計をとることができます。

実験/検証でならともかく、実際のWebサービスだと利用されるデータ型/コマンドは一部のものに偏ることが多いと思います。MONITORコマンドの全ての出力を集めてHadoopに分析させてた知人がいますけど、全データ取らなくても少量のサンプリングデータで傾向推定できるし、実務だと運用負荷増えるだけで無駄が多いよって言ったら顔真っ赤にしてました。

Redis Sentinel

Redis本家プロジェクトで開発されている、Redisサーバの死活監視/通知および自動フェイルオーバー機能を提供する管理サーバ(redis-sentinel)です。v2.4.16または2.6.0-rc6以降のバージョンから利用可能になりました。公式ドキュメントを参考にしつつ動作確認をします。

導入

最新版のRedisのソースコードをコンパイルすると src ディレクトリに redis-sentinel という名前の実行可能バイナリが出来上がりますが、実体は redis-server でファイル名が異なるだけです。

構成

ここでは2つのホストでSlaveを2プロセス、Sentinelを3プロセスの構成で試します。

* Master db0:6379
* Slave db0:6380, db1:6379
* Sentinel db0:26379, db0:23680, db1:26379

Sentinelの動作確認は公式ドキュメント APPENDIX Bの手順を参考に。

設定

設定項目

各設定項目について表にしています。Sentinelによるクラスタ監視はいわゆるQuorumベース投票の方式を採ります。複数のSentinelがMasterを監視していて、その内しきい値数以上のSentinelがMasterのダウンを検知したらフェイルオーバー処理を開始します。

monitor Masterのホストとポートおよび状態がODOWN(objectively down)に移行するための定足数(quorum)
down-after-milliseconds Master/Slaveのダウン検知後、状態がSDOWN(subjectively down)に移行するまでの時間(ms)
failover-timeout フェイルオーバー処理のタイムアウト(ms)
can-failover フェイルオーバー処理が実行可能か(yes/no)
parallel-syncs SlaveをMasterに昇格させた後、いくつのSlaveと同期させるか

SentinelはMasterとSlave両方の死活監視をしてくれますが、状態がODOWNに遷移するのはMasterのみなので注意してください。can-failover を no にして起動したSentinelプロセスはフェイルオーバー処理自体は行わず(他のSentinelに任せる)、自身はダウン検知と投票処理のみを行います。

起動

Sentinel起動前にレプリケーションが動作していることを確認しておきます。

続けて3つのSentinelプロセスを立ち上げます。

ログにて各SlaveおよびSentinelと接続したことを確認できます。

また、Sentinel起動後はINFOコマンドでSentinel関連の情報を確認ができます。

Sentinelプロセス自体の監視は一番下の項目を見るようにすれば良いかと思います。Sentinel監視のためのZabbixの設定例については後述します。

フェイルオーバー処理の動作確認の為、ここでMasterを落とします。

ログにてフェイルオーバー処理の進捗を確認できます。

SentinelがMasterのダウンを検知すると状態がSDOWNに、quorumパラメータで指定した数のSDOWNが揃うと次はODOWNへと遷移、その後フェイルオーバー処理が開始されます。

最後に新しいMasterとSlaveで正常稼働していることを確認します。

以上、Sentinelによるフェイルオーバー機能の動作確認まで試してみました。

Sentinel API

SentinelはいくつかのAPIを提供しているので簡単に紹介したいと思います。

Sentinel関連の管理ツールを作る際にはこのSentinel APIをサポートしたクライアントライブラリを使うと楽かと思います。ライブラリ側でどういった実装をすれば良いかという議論はGoogleグループの以下のトピックを参考に。
参考: Redis Sentinel: let's improve clients detection of failover events

以下、フェイルオーバー処理の挙動に関する部分をピックアップして紹介します。

昇格させるSlaveの選択

当然ですがSlaveとして正常に稼働しているプロセスが対象となります。細かい条件を省いてざっくり言うと、Masterとの接続が安定していて(ダウンタイムが少ない)、SentinelからのPING/INFOコマンドに直近5000ms以内に応答しているSlaveが対象になります(詳細は公式ドキュメントと src/sentinel.c を参照)。

対象となるSlaveが複数ある場合は slave_priority の値が小さいSlaveを選択します。

同じ slave_priority のSlaveが存在する場合は run_id が小さいSlaveを選択します。

2013/06現在は slave_priority の変更を行うAPIは公開されていないようですので、単に run_id が若いSlaveが選択されることになります。Slave選択のアルゴリズムは今後変更されることもあるでしょう。

Sentinels/Slavesの自動検出

Sentinelの設定にSlaveのリストを持たせる必要がないのは、SentinelがPub/Subによる情報共有を行っているからです。途中で別のSentinelやSlaveをオンラインで追加しても他のSentinelにその情報は伝わります。

メッセージの内容は host:port:run_id:can-failover となっていて、__sentinel__:hello チャンネルに5秒毎にpublish、全てのSentinelはこのチャンネルをsubscribeして情報共有しています。

レプリケーションの注意点

RedisのレプリケーションはMySQLなどのRDBMSのレプリケーションとは異なる部分が多いです。Redisはレプリケーション開始時に全てのデータをディスクに書き出してからSlaveに転送するのでI/Oやネットワーク帯域には注意してください(Redis v2.8ではPSYNC(Partial Resynchronization)が実装されるようなので、この問題は解消されると思われます)。

また、Sentinel自体まだunstableなプロダクトなので実務でもし使う場合もいろいろ注意してください(というか利用は許可されないかな)。この間、Disaster Recoveryのシミュレーションで東西の自社データセンター間を跨いだSentinelの運用検証もしてみたのですけど、いろいろとつまづいた所がありました。例えば、状態がODOWNになった時にSentinel間でPub/Subの疎通が上手く取れずにフェイルオーバー処理が開始されないケースなどが目立ちました。

あとぜんぜん関係ないですけど、redis-server 起動時のAA(アスキーアート)が全体的にブツブツしてて生理的に気持ち悪いんですけどアレなんとかならないですかね。僕はいつもアレが表示されないようにソースコードをいじってからコンパイルしてます。。

Redis Live

(Python製)
Redisのクエリ統計解析ツール、INFO/MONITORコマンドを利用しています。"Live"と名付けられているようにリアルタイム性を重視しているようです。

導入

公式ドキュメントの通りに。WebサーバはTornadoを使います。

設定

設定ファイルはJSON形式でシンプル。監視対象のRedisサーバの場所と統計情報を保存するストレージの場所をそれぞれ指定します。ストレージにはRedisサーバかSQLite3ファイルを選択できます。

* redis-live.conf

SQLite3に保存する場合は "DataStoreType" に "sqlite" に指定すればOKです。db/redislive.sqlite ファイルにデータが保存されるようになります。

起動

あとはブラウザからRedis LiveのWebインタフェースにアクセスするだけです。デフォルトURLは http://hostname:8888/index.html なので外部から閲覧する場合は8888番ポートを開放しておきます。また、実際に運用する際には redis-monitor.py/redis-live.py は supervisor などでデーモン化して管理すると楽です。

こんな風にリアルタイムでグラフを書いてくれます。
redis_live (クリックで拡大)
ぼーっと眺めているとグラフが横に流れていくので見てて面白いです。ただし、CPU負荷がかなり高くなりますので実際に使うにはRedis Live用の監視サーバを準備する必要があります。安価なVPSなどで運用するのは難しいです。

Redis Faina

(Python製)
前述のRedis Liveと同様にMONITORコマンドを使ったクエリ統計解析ツール、Instagramで開発されました。グラフを描く機能はありませんが、Redis Liveと比較して軽量なのが嬉しいです。

導入

Redis FainaはMONITORコマンドの出力を正規表現でがんばって解析するツール。標準モジュールのみで動作し、データをディスクに書き出さずに全てオンメモリで処理するのでポータビリティが高いのがメリットです。

実行

MONITORコマンドの出力を redis-faina.py に渡すだけです。

グラフ化しなくても結構見やすい出力になっています。リアルタイム性はありませんが、Redis Liveよりも手軽に利用できるのがメリットです。

Redis Sampler

(Ruby製)
各データ型毎にキーの分布情報などをランダムサンプリングによって分析するコマンドラインツール。Salvatoreさん(Redis開発者)によって書かれています。

導入

実行

redis-sampler.rb をコマンドラインから実行するだけです。僕の手持ちの環境だと良いサンプルが作れなかったので、githubのサンプルを参照してください(antirez/redis-sampler)。

EXPIREが設定されたキーの情報なども分析することができます。この redis-sampler.rb は小さなスクリプトなのでいろいろ拡張して使うこともできそうです。

redis-top

* redis-top というCLIを書いた

日本の方が作られたコマンドラインツール。INFOコマンドの出力を dstat コマンドのように見やすく整形表示してくれます。導入は cpanm で簡単にできます(cpanm の環境がない人はgithubからファイル群を取ってくる)。

導入/実行

redis-top (クリックで拡大)

CONFIG GET で取れる値(maxmemoryやmaxclientsなど)を使って使用率が確認できるとより便利かなぁと思います。


ここからは汎用的な監視ツールのRedis用プラグインの紹介になりますので、細かい導入手順等は省略させていただきます。

Nagiosプラグイン

(Perl製)
統合監視ツール NagiosのRedis用プラグイン、check_redis.pl を紹介します。導入は通常のNagiosプラグイン追加手順と同じ。CPANのRedisモジュールが必要なので cpanm とかであらかじめインストールしておきます。ここではNRPEで外部からのActiveチェックを試します。

ブラウザから動作確認します。
nagios_check_redis_plugin

check_redis.pl をコマンドラインから利用

Nagiosプラグインなのでもちろんコマンドラインツールとしても利用できます。check_redis.pl は1ファイルで140KB近くもある大作で、オプションを組み合わせればいろんなことができる実装になっています。

Zabbixテンプレート

Nagiosを紹介したのでこちらも。統合監視ツール ZabbixのRedis用テンプレートです。おそらく多くの方が自分の使いやすいテンプレートを作っているとは思うのですが、ここではrdvnさん作のテンプレートを紹介します。

テンプレートにデフォルトで設定されているアイテムは20個ありました。
zabbix_redis_template (クリックで拡大)
redis.stat[{INFOコマンドの項目}] という形式で簡単にアイテムの追加ができます。

また、最初に紹介したRedis Sentinelプロセスの監視用 UserParameter は以下のように設定しました。ただ、INFOコマンドの出力はバージョンによって変更される場合があるのでアップデート後はきちんと動作確認しておく必要があります。

設定したらZabbix Agentを再起動してZabbixサーバから動作確認します。

ZabbixはNagiosと比較されることが多いですが(Zabbix vs Nagios comparison)、国内ではまだNagiosのシェアの方が高いんでしょうか。ZabbixはストレージにMySQLを使うのでZabbixサーバ管理者にはMySQL運用の知識も必要になってきます。Webインタフェースの方はNagiosよりも洗練されていて、肩肘付いてポチポチするだけで各種設定が行えるのは楽です。僕はNagiosの方が運用経験は長いのですが、正直どちらを使ってもいいかなと思います。現在ではrpm/debパッケージもきちんと整備されていますし導入コストの差は僕は感じません。MySQLの知識がある方にはZabbixをオススメします。

Muninプラグイン

(Python製)
リソース監視ツール MuninのRedis用プラグインです。僕も昔に業務でRedis用のMuninプラグインは作ったことはありますが、ここではデフォルトで多くの項目を監視できる PyMunin というMuninプラグインを紹介したいと思います。導入は簡単で、pip または easy_install からインストールできます。

あとはブラウザからMuninのWebインタフェースにアクセスして以下のように正常にグラフが出力されているか確認します。
munin_redis_plugin (クリックで拡大)

上の画像では一部の監視項目しか見えていませんが、デフォルトでグラフ出力される監視項目を以下に挙げます。充実していますね。

  • Ping Latency (secs)
  • Active Client Connections
  • Client Connections per Sec
  • Commands Processed per Sec
  • Memory Usage (bytes)
  • Memory Fragmentation Ratio
  • CPU Utilization
  • Hits/Misses per Sec
  • Expired Keys per Sec
  • Evicted Keys per Sec
  • Subscriptions
  • RDB Pending Changes
  • RDB Dump Duration (sec)

PyMuninはRedis以外にもMySQLやmemcached, Nginxなどいろいろなミドルウェアのプラグインの詰め合わせになっているのでMuninを使っている人は導入をオススメします。

Cactiプラグイン

(PHP製)
こちらもリソース監視ツール CactiのRedis用テンプレート。
percona_redis_plugin (クリックで拡大)

すみません、Cactiの環境が手元にないのでこれだけ試せていません(いいわけ)。Cacti自体の導入が済んでいればプラグインの追加は簡単です。機能面ではこれまで紹介してきたツールと大差はありません。また、このプラグインはSSH経由でデータを取得するタイプなので、プロダクション環境のネットワークポリシー的には利用不可な場合もあるでしょう。

以上、簡単にですがRedis関連の監視/解析系ツールをまとめてみました。数百ノードの規模を分散監視する場合はNagiosやZabbixのような統合監視ツールを使うと安心ですが、じっくり腰を据えてシステム構築する必要があるので多少時間がかかります。小中規模であれば好きなプロダクトを使うといいんじゃないでしょうか。

参考:
Redis DB - Google グループ
Redis Masterclass - Part 2, Monitoring


ぜんぜん関係ないけど、NYUがDeep Learningによる画像認識デモを公開してた。これはすごい。
Image Classifier Demo
130万枚の画像からDeep Learningで学習した特徴量を使ってるらしい。僕が学生時代はニューラルネットって下火みたいな感じになってたけど、Deep Learningの登場でまた盛り上がってきた。僕も勉強せねば。

あわせて読む:

Pocket

 

Tags: , , ,

Comments: 2

Leave a reply »

 
  • Leave a Reply
     
    Your gravatar
    Your Name