Redisを使っていくうちにわかったどうでもいい話です。
#ディスク消費量は50%を超えてはいけない
Redis は毎分ごとに全データをディスクに書き込む仕様になっています。
その時の方法は既存のデータとは別に新しいデータファイルを作り、そこにメモリの内容のスナップショットを一気に書き込み、書き込みが完了したら新しいデータで古いデータを上書きします。そのため、新しい内容を書き終えた瞬間には古いデータと新しいデータの2つがディスク上に共存することになり、それはつまり現在保持しているデータ量の倍のデータが瞬間的に消費されるということになります。
Redis単体で稼働しているサーバ上でディスク消費量が50%を超えると容量が足りず保存処理が失敗します。保存処理が失敗すると再度成功するまでRedisは書き込みを拒否するようになりますので実質サービスダウンとなります。実際のところこの制限に触れてしまうケースはあまりないかとは思います。
#メモリ消費量は50%を超えてはいけない
データ保存をするためにはある瞬間のメモリのスナップショットを取る必要があります。そのためにRedisはプロセスを fork し、子プロセスの内容をそれ以上変更されないようにした上でこの子プロセスのデータをディスクに保存します。
このとき copy on write の恩恵によりfork直後は子プロセスのためにメモリを追加で確保する必要はありません。しかし、もし親プロセスでデータの書き込みが行われるとその部分はダーティとなりコピーが発生します。
まあでも書き込みはそんなにたくさんしてないからせいぜい数%のコピーしか発生しないと思うかもしれませんが、意外とそんなことはありません。まずダーティ判定はページ単位で行われます。Linuxにおいてはページのデフォルトサイズは4KBなのでたった1バイトしか書き込んで無いつもりでも4KB分のコピーが発生します。またRedisのデータ構造は巨大なハッシュのようなものなので、データは分散されて保存されています。なので例えば全体のキーの1%しか書き込んで無いと思っても、ページサイズとの組み合わせにより大部分のメモリがダーティとなる可能性があります。また、データ量が増えるに連れて保存が完了するための時間がよりかかるようになります。これはつまりその保存の間にダーティとなる割合がデータ量に比例して大きくなるということです。つまりデータ量x書き込みデータの割合というペースで消費メモリ量が最初は増えていくことになります。サービス開始後は余裕だったのに、ということは少なくないと思います。
というわけで、メモリ消費量が50%を超えていると保存処理時にメモリが不足してしまう可能性があります。メモリが不足すると保存失敗となり、再度保存に成功するまで Redis は書き込みを拒否します。平常時でのメモリ消費量が50%を超えないようにモニタリングするか、Redisのログを監視したほうがよいでしょう。
#Redisのデータがある程度大きくなるようなら他のサービスと同居させてはいけない
Redis は最初データ量が少ないうちはなんのオーバーヘッドも感じない小さなサービスという感じなのでカジュアルに他のサービスと同居させてしまうかもしれませんが、データ量が増えてくるとサーバへの書き込み負荷は線形に伸びていきます。
特に1分ごとに全データを保存する仕様なので、10GB級のメモリを消費している場合は常時ディスクへの大量書き込みが起きているという認識でいたほうがよいです。インメモリDBではありますが、おそらく他のどのデータベースより書き込み量の多いDBだと思います。少ししかデータが書き換わってないのに全データを書き出す必要があるためです。
この書き込みは通常線形アクセスなので高速なのですが、もしほかのプロセス(例えば他の種類のデータベース)が頻繁に書き込みをしているようだと実質ランダムアクセスとなり Redis 自体の保存処理にも時間がかかるようになります。時間がかかると copy on write の量も余計に増えるので嬉しくありません。
まとめ
ということで、データ量の小さい Redis とデータ量の大きな Redis とでは子猫とベヒーモスくらいの差があるという認識でいましょう。