TerraformでElastiCache(Redis)を管理している時にはまった罠


Your Amazon ElastiCache node(s) listed below are scheduled for replacement due to maintenance, which includes mandatory patches to improve security, reliability and operational performance. The maintenance will occur during the time range provided for each node. Please note that this is mandatory maintenance that will begin in your cluster’s maintenance window but may finish outside the window depending on the data and the load on the node(s).

というメールがAWS様から来たの何とかしないといけなくなった。

そして、その時に色々な地雷にはまったのでまとめておく。

replication_group_idを17文字以上にするとノード追加ができなくなる

ノード追加時(number_cache_clustersを増やす)にエラーになった。

error creating Elasticache Cache Cluster (adding replica): InvalidParameterValue: The parameter CacheClusterIdentifier is not a valid identifier because it is longer than 20 characters.

しかし、新規立ち上げの時は怒られないのがタチが悪い…。

幸い、開発用のRedisクラスターだったので作り直す事で解決。

AWSのコンソールからノードを消すとTerraform適用できなくなる

1台追加して、プライマリーにして、既存の2台を消してみた。

差分をとって実は良い感じに動くかな?と思ったが…。

planしてみると

snapshot_retention_limit

0 => 3

みたいな謎の差分が出る。

applyすると…。Node Not Found!

refreshとかしても改善しないので詰んだ。

プライマリは何が何でも1番目のノードに割り当てられる

001 -> primary
002 -> replica

という状態で2台とも作り直したかったので

  1. リードレプリカ追加(003)
  2. 003のノードをプライマリーに昇格
  3. number_cache_clustersを1にする

という手順を考えていた。

003はプライマリーだから、001/002が殺されるだろうと…。

しかし…。現実はもっと残酷だった…。

  1. 001がプライマリーに昇格
  2. 002/003が削除される

という結果に…。

↑こいつがサポートされていればこんな事にはならなかったのに…。

結局どうするか?

  1. リードレプリカ追加(003)
  2. 003のノードをプライマリーに昇格
  3. AWSのメンテを待つ
  4. 終わったら001をプライマリーに昇格
  5. 003引退

で行くしかないかなぁと…。これから試すから結果はどうなるか…。