こんにちわ、ミツバチワークス stoneです。
今回は、redisシリーズ第３弾、実際にredisをサービスの投入してみて、うまく行かなかった事例についてご紹介します。
redisの使用用途
今回、いくつかあるセッションデータのうち２つをMySQLからredisへ移行させました。
これらのセッションデータ、MySQL上では、セッションIDの他に複数のカラムから構成されているのですが、redis上では、この複数のカラムをserialize()して、
key(string) => value(string)という形で格納するようにしました。
ちゃんとソースコードで確認はしていないのですが、memcachedでも、TTLが設定できますが、TTLを過ぎたデータを監視してクリアしていないですよね。
また、memcached内部のslabの構成次第では、TTLまでデータが保持されずに、データがクリアされてしまうケースにも遭遇したことがあります。
(まぁ、キャッシュだから当たり前の話なのですが)
反面、redisの場合、TTLまでデータが残っていて、かつ、TTLを過ぎたデータは、定期的にクリアされています。
(これは、ソースコードレベルでも、実際の状態監視でも確認できました。)
運用中の状態
サービスに投入後の、ピークタイムでのredisの状態です。
ロードアベレージ
こんな風にギザギザのロードアベレージは、初めて見る形です。
瞬間的にロードアベレージが上がるのは、バックグラウンドでのsnapshotの保存によるもののようです。
トラフィック
どうやら、バックグラウンドでsnapshotを保存するタイミングで、リクエストが滞留したり、滞留していたリクエストが一気に解消したり、というのを繰り返しているようです。
コレはこれで問題だったので、後ほど取り上げます
メモリの使用量
最初にグラフを見たときには、とても感動しました。
問題1: リクエストが詰まる
現象
上記のredisのトラフィックが、サイト全体のパフォーマンスにまで、影響していました。redisのトラフィックが詰まるタイミングで、サイト全体のトラフィックも低下する現象が見られるようになってきたのです。
下のリバースプロキシのグラフで、ざくっと切れ込みの様にトラフィックが下がっている部分は、redisの「詰まっている」タイミングと同じタイミングで起きていました。
対処
少し調べてみたのですが、なかなか原因はつかめません。ひとまず、わかっているのは、
・snapshotの保存のタイミングで、トラフィックが低下する
・snapshotの保存のタイミングでは、CPUの使用率が上がる
の２点のみ。
そこで、保存の際に少しでもCPUの使用率を下げる為に、
rdbcompression no(デフォルトはyes)
としてみました。
また、事前に別サーバーで、redisを立ち上げて、
1) "rdbcompression yes"で１万件程度のデータをストア
2) redis-serverをシャットダウン
3) redis.confを"rdbcompression no"に変更
4) redis-serverを起動
としても、データは保全されていることを確認しました。
結果(解決)
ほぼ同じような形で見分けがつきにくいですが。。。。
redis
rev-proxy
問題2: 応答が極端に遅くなる
こちらは、残念ながら、解消できていない問題です。
現象
問題が起きた時間帯のredisのトラフィックのグラフです。
同じ時間帯のロードアベレージを見てみると。。。。
これらのグラフから見て取るに、問題の現象は、
1) 内部的に「何か」が起きる
2) ロードアベレージがじわじわ上がる
3) その「何か」が分水嶺を超える
4) トラフィックが乱れる
というシナリオのようです。
この状態になると、redis-cliでも、応答が悪くなりました。
それにつれて、サイト全体のパフォーマンスが悪化して行きました。
対処
この現象が起きた場合、redis-serverを再起動すると、すんなりと問題が解消します。が、TERMシグナルを発行しても、サさってシャットダウンできない場合もあり、実際に人のオペレーションが必要な状況でした。
問題が発覚してから、数日は、夜中まで監視を行い、問題が起きた場合はリスタート、という運用をしていたのですが、さすがに数人で運用してる現状では、無理がかかりすぎるため、MySQLに戻しました。
redis導入後、このトラブルが起きていないケースもあるので、原因の特定がまったくできていない状態です。
問題が起きていないケースでは、トラブルがあったケースに比べて、
・データのTTLが長いため、順次データがクリアされる状態になっていない
・データ件数が1/10程度
となっていて、今後、データのTTLが切れ始めるタイミングが要注意だと考えています。
今回は、トラブルに合いましたが、やはり、redisのスピード感は魅力です。
そのため、今後は、TTLが設定されない、永続的なデータについても、実験をしてみることにしています。
では、また次回に♪