AWS Elastic Cacheのtimeoutパラメータのデフォルト設定が0になっています。

このままだとEC2のAutoScaling等で削除した後もコネクションが残っては溜まり続けて障害に繋がる危険性があるのです。だからシステムに合わせて適切に設定していきます。

具体的には60秒あたりが無難

 

 

リリース時の注意

 

timeout設定(コンソールにて設定)

1. Cache Parameter Group新規作成
2. 新規作成したCache Parameter Groupのパラメータを編集します
   timeout 0 → 60
3. Cache Parameter Groupの付け替え
   3-1. [Cache Clusters]⇒[対象を選択]⇒[Modify]
   3-2. Cache Parameter Groupのセレクトボックスから新規作成したグループを選択して【Modify】をクリック

 

キーに必ずtimeoutを設定しておくこと

• キーにTTLの設定を必ず行って下さい
• 必ずTTLが減少して消えていくか確認する

キーが時間経過や任意のトリガーで必ず消えていくことを入念に御確認してから、システムのリリースをされると良いかと存じます。

 

TTLを設定し忘れているキーの対策 (重要)

 

Redis ElastiCache maxmemory-policy

 

Eviction 重要

• データが溜まっていってMaxMemoryに達した時の挙動

volatile-ttl

• 有効期限が古い順にデータを削除する

volatile-lru

• 有効期限古い順かつ、lruアルゴリズムでアクセスが少ない順に削除する

他にもあるよ

セッションやキャッシュ用途以外に使用しない

セッションやキャッシュなど消えて構わないもの、消えていくものに利用する。永続的な保存、長期間保存が必要なデータはRDSに保存して下さい。

 

keysコマンドを使用しない

keys * を使用しない

データがたくさん入っているとCPUが100%になる

 

Hash型などで1つのキーに大きなデータが保存されないように

• ユーザID毎にキーをわけたりしよう
• 1GBを超えるキーを作ったりしない
  キーを削除した時にmaster, slaveでデータの差が大きくなりSyncではなく、bgsaveが作動し負荷でSyncが失敗したりする。

 

 

キャパシティプランニング

 

インスタンスのメモリをすべてキャッシュには利用できない

• キャッシュ領域に実際に使えるのはインスタンスの80%

 

メモリを実際利用するのに必要量の2倍以上のインスタンスサイズを選択する

ダンプする時にエラーになる、2倍以上の余裕があること

 

メモリの利用状況を確認

 

Cloudwatch, redis-cliで使っているサイズを確認

• FreeableMemory
• SwapUsage

SWAPが発生していたら危険

 

メモリ容量を超えるとRedisに書き込めなくなり障害になります。

 

 

CPUの値について

Redisはシングルスレッド

1DBに対して、5コアでCPUを20%使っていたら「100%」利用している！！

 

 

ElastiCacheではなく、生のRedisの場合 vm.overcommit_memory=1

スワップを可能にしておく

# sysctl vm.overcommit_memory=1

 

# vi /etc/sysctl.conf

※以下を設定する

vm.overcommit_memory = 1