1. 目的
- ElastiCache for Redis のサービス更新通知が来た。AWS社(公式)の説明によると、サービス更新実施時の影響は数秒程度の断とのこと。本当にそうなのか？と心配なため、検証環境にて実際の接続断時間(ダウンタイム)を確認する。
2. 予習
- AWS社(公式)による説明はこちら。接続断時間に関する記載部分を引用。
お客様または Amazon ElastiCache により 1 つ以上の Redis クラスターにサービス更新が適用されると、選択したすべてのクラスターが更新されるまで、一度に 1 つのノードの更新をそれぞれのシャード内で適用します。ノードの更新には数秒のダウンタイムが発生しますが、それ以外の Redis クラスターは引き続きトラフィックを処理します。
-
以前のアップデートの際に、既に実機確認している記事が何個かあり、AWSの言う通り、数秒程度の接続断の様子。
-
既に二番煎じ以降ではあるものの、環境や設定などによって動作も変わる可能性もあるため、改めて自分で確認してみることにする。
3. ElastiCache for Redisの環境
- 今回アップデートを適用する環境は以下の通り。
- モード: Redis
- エンジンバージョン: 5.0.6
- ノード数: 2
- ノードタイプ: cache.r5.large
- クラスターモード: 無効
- 適用する「サービスの更新」(パッチみたいなもの): elasticache-20230315-001
- ノード数1のシングル構成だったり、クラスターモードが有効になっていたりすると、また挙動が違うかもしれない。
4. 接続断時間確認の方法
- ElastiCache for Redisと同一VPC内に、Redisクライアント(redis-cli)をインストールしたインスタンスを用意する。
- アップデート作業中、ElastiCache for Redis のプライマリエンドポイントに対し、1秒間隔でキー(mykey1)の値のインクリメント、および読み出しアクセスを行うスクリプトを実行する。(実際には、キー名だけ変えたスクリプトを念のため計3本並行で実施)
check.sh
#!/bin/bash
mykey="mykey1"
host="XXXXXXXXXXXXXXXXXX.apne1.cache.amazonaws.com" # プライマリエンドポイント
redis-cli -h ${host} set ${mykey} "1"
for i in $(seq 1 3600); do
date
redis-cli -h ${host} incr ${mykey}
redis-cli -h ${host} get ${mykey}
sleep 1
done
- 平常時のスクリプト実行ログは以下のようになる。アップデート適用中に接続断が発生した場合、redis-cliコマンドが応答待ちになり、1秒間隔での実行ができなくなる。スクリプトの出力する時刻の値が1秒以上に開くことで接続断時間を検出できる。
スクリプトの出力結果.txt
Wed Apr 12 12:37:51 JST 2023
125
125
Wed Apr 12 12:37:52 JST 2023
126
126
Wed Apr 12 12:37:53 JST 2023
127
127
Wed Apr 12 12:37:54 JST 2023
128
128
- Redis Clientと、ElastiCache for Redisの構成のイメージは以下となる。
5. アップデート動作と接続断時間の確認
5.1 アップデート動作(概要)
- アップデート動作の流れは大まかには以下の通り(今回は1～4まで所要約30分)。
- 対象のクラスター、及び適用するサービスの更新(今回は「elasticache-20230315-001」)を選択し、「今すぐ適用」を実行すると、アップデートが開始される。
- まずreplica側のノードがアップデートされる。
- replicaとprimaryが切り替わる。(作業前にreplicaだったノードがprimaryになる)
- 新しくreplicaになったノードがアップデートされ、作業完了。
5.2 接続断時間の確認
- アップデート適用中にスクリプトをずっと流していたが、今回は接続断は検出されなかった（スクリプト内のredis-cliコマンドの応答が遅延することはなかった）。そのため、1秒以上の接続断は発生していなかったと判断する。
- 旧replicaノードがprimaryに昇格するタイミングで接続先ノードが切り替わるため、その際の接続断を想定していたが、今回の確認方法(1秒間隔でのチェック)では接続断は検出されなかった。
5.3 アップデート動作(詳細)
-
アップデート実施時、動作の流れの把握のため随時画面キャプチャを行った。
-
今回作業対象となるクラスターはこちら。
-
クラスターに2台ノードがあり、ノード001がprimary、ノード002がreplicaの状態。
-
このクラスターに適用可能なサービスの更新の一覧が表示される。2021/6頃に出たものは適用済。今回は「elasticache-20230315-001」を適用する。
- 該当の「elasticache-20230315-001」を選択すると、未適用のクラスター一覧が表示される。今回作業対象のクラスターを選択し、「今すぐ適用」を実行する。ここからは全て自動でアップデート処理が実行される。
- 作業対象のクラスターの更新ステータスが、「Waiting-to-start」⇒「In-progress」と推移する。
- ノードのステータスが「Available」⇒「Modifying」に推移したのち、primaryとreplicaが入れ替わる。(元々002がreplicaだったが、primaryに昇格)
- primaryとreplicaの入れ替わり後、引き続き新replica(ノード001)の更新が行われている(と思われる)。
- 適用が完了すると、該当クラスターの「サービスの更新」(elasticache-20230315-001)のステータスが「In-progress」から「Complete」に変化する。
- また、 クラスターの更新ステータスの画面にて、ノードが2台とも更新完了(2/2)と表示される。
6. 所感
- 今回の構成においては、接続断時間が無し、もしくは非常に短い(1秒未満)であることが確認できた。作業実施の判断のため、作業影響を事前把握することは重要なため、なるべく正確な確認ができるよう心掛けていきたい。