インフラ

EC2でRedisを使う場合はHVM

以前、こんな記事を書いたんですが、

RedisがDisk書き込みのタイミングで接続出来なくなる
Redisの処理能力の限界

解決しました。
EC2にr3インスタンスが追加された際に、仮想化方式がHVMしか選択出来なかったので、HVMで起動してRedisサーバにしたのですが、上記問題のどちらも解決しました。

公式ドキュメントにXenとの相性が悪い旨は書いてあったので、前からEC2でのパフォーマンスが悪いことは知っていたのですが、r3インスタンスへのリプレースでHVMになることで、解決してしまいました。

RedisのSlaveはMasterよりも容量を大きくした方がよさそう

結論から先に書くと、
RedisのSlaveは、Masterよりも容量を大きくとった方がいい。
理由は、同一容量だと、Masterが容量をフルで使っている場合、このマスターデータ全てをSlaveにSETすることが出来ないから。

主な設定は、
maxmemory 2gb
maxmemory-policy allkeys-lru

症状
Masterがこの容量をフルに使ってる場合、新たにSlaveが同期を開始すると、途中で同期が止まる。
再現性は100%
最初は、Masterのclient-output-buffer-limitで切られていることを疑ったが違った。
おそらく全ての同期を完了する前に、Slaveの容量がいっぱいになってしまっている模様。
このレプリケーションではallkeys-lruの挙動になっていないらしく、新しめのデータがSETされていないことが多い。
ログでは正常に終了した形になっている。

Master
db0:keys=8942214,expires=8778923

Slave
master_link_status:up
db0:keys=8309380,expires=8176889

こんな形で、Slaveとして正常に動いているが、データには差異が出来てしまっている。
Slaveの容量を少しMasterよりも大きくすることで解決。

RedisがDisk書き込みのタイミングで接続出来なくなる

Redisはデフォルトで定期的にDiskへバックアップをとるようになっていますが、
このタイミングでクライアントからRedisに対して接続出来なくなるようです。

僅かな差分であれば、一瞬で終るのですが、
それなりの更新があると書き込みにかかる時間も増えるのでその間、ずっと繋がらなくなります。

マニュアルには、

BGSAVE()
データベースの保存をバックグラウンドで行います。 OK コードは直ちに返って来ます。Redisはフォークし、親のプロセスはクライアントに対して処理をし続け、子のプロセスはデータベースをディスクに保存したあと死にます。クライアントから保存が無事に終わったかを LASTSAVE コマンドを使って確認することが出来ます。

とあるので、疑問だったのですが、
親プロセスが処理を「受け」続けるとは書いていないので、間違ってはいないのかな。

ということで、Disk書き込みを無効にして、スレーブの方でDisk保存するようにしました。
もし再起動などの際に、Diskに保存したい場合は、BGSAVE()を手動で発行すればOK。

Redisの処理能力の限界

sysctlで、ファイルディスクリプタやsomaxconn、ポートレンジの対応はした上でですが、
Redisの処理能力の限界がだいたい分かった。

Redisはシングルスレッドなので、マルチコアはあまり意味がないのでEC2のm1.mediumを使ってるんですが、
このインスタンスでだいたい、instantaneous_ops_per_secが12000辺りで頭打ちになる。
この時のCPU使用率が90%超えなので、CPUバウンドでしょう。

—-
この記事は、
ec2でredisを使う場合はhvmで書いたように、仮想化方式がPra-Virtualでのものなので、HVMだとかなりパフォーマンスが向上します。
c3のCPUであれば、35000~40000req/secほど出ます。