tail -f /dev/null

If you haven't had any obstacles lately, you're not challenging. be the worst.

トップ > redis > CodeDeploy による Blue-Green deployment 時に Redis cache を flush する

CodeDeploy による Blue-Green deployment 時に Redis cache を flush する

redis

概要

  • AWS CodeDeploy による Blue-Green deployment を行っている.
  • Deployment 先は Windows Server 2016.
  • ElastiCache Redis で cache/session を管理している.
  • Release 時に新 module (green) については cache が無い状態で参照させたい.
    • 可能であれば flushall ではなく, 特定の key を削除したい.
    • 旧 module (blue) で cache 作成後, 新 module で当該の cache を読み込むとエラーになる.

検証

特定の cache key のみ削除することで, ユーザー影響を最小化できるか検証する.

※ 前提として single thread のため keys のコマンドは発行しない.

cache を削除するためには, 特定文字列を含む key を抽出する必要がある.

keys ではなく scan コマンドを利用すれば Redis は影響を受けない (thread を block しない).

$ { time -p { redis-cli -h <host> -p 6379 --scan --pattern "*-*-*" | xargs -L 1 redis-cli -h <host> -p 6379 get; } > output.log; } 2> time.txt
$ cat time.txt
real 949.92
user 65.04
sys 48.18

scan で get するのに 15min 程掛かってしまった. 当該の key はおよそ 18000件程.

keys の場合は 1.82sec で完了していたため, scan 経由だと500倍近く遅くなってしまいそう.

結果的に cache の保持期間は短いため flushall することにした. 当該の release 時間を遅い時間帯にすることで user 影響も最小限となる.

実作業

Blue-Green deployment において, Blue が BlockTraffic 後 に flushall を実行する.

前提として, sticky session は有効化して request が新旧をなるべく跨がないようにする.

Amazon ElastiCache の場合 Cluster endpoint へ向けて flushall しても片系しか削除されない為, 各 master node に対し flushall を行う.

redis-cli -h <host> -p 6379 FLUSHALL # master node 1
redis-cli -h <host> -p 6379 FLUSHALL # master node 2