确认Amazon ElastiCache for Redis服务更新时连接中断的时间（停机时间）

2 年 ago
科, 雅
1 minute

目标

    ElastiCache for Redis のサービス更新通知が来た。AWS社(公式)の説明によると、サービス更新実施時の影響は数秒程度の断とのこと。本当にそうなのか？と心配なため、検証環境にて実際の接続断時間(ダウンタイム)を確認する。

2. 给予学习机会

    AWS社(公式)による説明はこちら。接続断時間に関する記載部分を引用。

当客户或Amazon ElastiCache对一个或多个Redis集群进行服务更新时，每次只会在每个分片内应用一个节点的更新，直到选择的所有集群都被更新为止。节点的更新可能会导致几秒钟的停机时间，但其他Redis集群将继续处理流量。

以前のアップデートの際に、既に実機確認している記事が何個かあり、AWSの言う通り、数秒程度の接続断の様子。

ElastiCache for Redis サービス更新適用時のダウンタイムを調べてみた
ElastiCache Redisのサービス更新時のダウンタイムを調査した
Amazon ElastiCache (Redis) のservice updateをやってみた / elasticache-20210615-002 の適用

既に二番煎じ以降ではあるものの、環境や設定などによって動作も変わる可能性もあるため、改めて自分で確認してみることにする。

3. Redis的ElastiCache环境

    • 今回アップデートを適用する環境は以下の通り。

モード: 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本並行で実施)
#!/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秒以上に開くことで接続断時間を検出できる。
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
redis10.png

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 更新操作说明（详细）

redis02b.png
redis03a.png
    該当の「elasticache-20230315-001」を選択すると、未適用のクラスター一覧が表示される。今回作業対象のクラスターを選択し、「今すぐ適用」を実行する。ここからは全て自動でアップデート処理が実行される。
redis04a.png
    作業対象のクラスターの更新ステータスが、「Waiting-to-start」⇒「In-progress」と推移する。
redis05a.png
redis06a.png
    ノードのステータスが「Available」⇒「Modifying」に推移したのち、primaryとreplicaが入れ替わる。(元々002がreplicaだったが、primaryに昇格)
redis07b.png
redis08a.png
    primaryとreplicaの入れ替わり後、引き続き新replica(ノード001)の更新が行われている(と思われる)。
redis09a.png
    適用が完了すると、該当クラスターの「サービスの更新」(elasticache-20230315-001)のステータスが「In-progress」から「Complete」に変化する。
redis11.png
    また、 クラスターの更新ステータスの画面にて、ノードが2台とも更新完了(2/2)と表示される。
redis12.png

6. 触动之处

    今回の構成においては、接続断時間が無し、もしくは非常に短い(1秒未満)であることが確認できた。作業実施の判断のため、作業影響を事前把握することは重要なため、なるべく正確な確認ができるよう心掛けていきたい。
bannerAds