Amazon ElastiCache for Redis のサービス更新時の接続断時間(ダウンタイム)を確認する

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

# 2. 予習
- AWS社(公式)による説明は[こちら](https://aws.amazon.com/jp/elasticache/elasticache-maintenance/)。接続断時間に関する記載部分を引用。

> お客様または Amazon ElastiCache により 1 つ以上の Redis クラスターにサービス更新が適用されると、選択したすべてのクラスターが更新されるまで、一度に 1 つのノードの更新をそれぞれのシャード内で適用します。ノードの更新には数秒のダウンタイムが発生しますが、それ以外の Redis クラスターは引き続きトラフィックを処理します。

- 以前のアップデートの際に、既に実機確認している記事が何個かあり、AWSの言う通り、数秒程度の接続断の様子。
    - [ElastiCache for Redis サービス更新適用時のダウンタイムを調べてみた](https://dev.classmethod.jp/articles/elasticache-for-redis-security-update-downtime/)
    - [ElastiCache Redisのサービス更新時のダウンタイムを調査した](https://www.karakaram.com/elasticache-service-update-downtime/)
    - [Amazon ElastiCache (Redis) のservice updateをやってみた / elasticache-20210615-002 の適用](https://qiita.com/yuji_saito/items/6e40b978dcd1e4575638)

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

# 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の構成のイメージは以下となる。
![redis10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/517e7dd6-80ce-2120-3087-cf5720d1f536.png)


# 5. アップデート動作と接続断時間の確認

## 5.1 アップデート動作(概要)
- アップデート動作の流れは大まかには以下の通り(今回は1～4まで所要約30分)。
    1. 対象のクラスター、及び適用するサービスの更新(今回は「elasticache-20230315-001」)を選択し、「今すぐ適用」を実行すると、アップデートが開始される。
    1. まずreplica側のノードがアップデートされる。
    1. replicaとprimaryが切り替わる。(作業前にreplicaだったノードがprimaryになる)
    1. 新しくreplicaになったノードがアップデートされ、作業完了。

## 5.2 接続断時間の確認   
- アップデート適用中にスクリプトをずっと流していたが、今回は接続断は検出されなかった（スクリプト内のredis-cliコマンドの応答が遅延することはなかった）。そのため、1秒以上の接続断は発生していなかったと判断する。
- 旧replicaノードがprimaryに昇格するタイミングで接続先ノードが切り替わるため、その際の接続断を想定していたが、今回の確認方法(1秒間隔でのチェック)では接続断は検出されなかった。

## 5.3 アップデート動作(詳細)
- アップデート実施時、動作の流れの把握のため随時画面キャプチャを行った。

- 今回作業対象となるクラスターはこちら。
![redis01a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/06cc937a-35a5-62ef-fde0-80292058d311.png)

- クラスターに2台ノードがあり、ノード001がprimary、ノード002がreplicaの状態。
![redis02b.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/c30af972-6912-18c6-241b-0c0a0a8dcb24.png)




- このクラスターに適用可能なサービスの更新の一覧が表示される。2021/6頃に出たものは適用済。今回は「elasticache-20230315-001」を適用する。

![redis03a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/0936e065-232b-0ea1-a6bb-e21eea1b2246.png)

- 該当の「elasticache-20230315-001」を選択すると、未適用のクラスター一覧が表示される。今回作業対象のクラスターを選択し、「今すぐ適用」を実行する。ここからは全て自動でアップデート処理が実行される。

![redis04a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/a3eb4ccb-f89a-9f4e-fb94-12f745f3e6ed.png)

- 作業対象のクラスターの更新ステータスが、「Waiting-to-start」⇒「In-progress」と推移する。

![redis05a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/2680cd4b-cf56-4700-7dee-e106d3265572.png)

![redis06a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/d67de9e7-2bd2-c1a3-747c-0c0b2671f873.png)

- ノードのステータスが「Available」⇒「Modifying」に推移したのち、primaryとreplicaが入れ替わる。(元々002がreplicaだったが、primaryに昇格)

![redis07b.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/9f0b4f57-9209-eb10-fb9c-a0e3023507a6.png)

![redis08a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/7c151ac0-66c7-e0bf-7a2a-d2417f67aeec.png)

- primaryとreplicaの入れ替わり後、引き続き新replica(ノード001)の更新が行われている(と思われる)。

![redis09a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/ead07812-3f60-5d11-1cc2-a3b890545268.png)

- 適用が完了すると、該当クラスターの「サービスの更新」(elasticache-20230315-001)のステータスが「In-progress」から「Complete」に変化する。

![redis11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/71aae94a-cdfd-de0c-5dc0-dd087628e9ea.png)

- また、 クラスターの更新ステータスの画面にて、ノードが2台とも更新完了(2/2)と表示される。

![redis12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/bc146a14-d7a9-7aa6-16cb-20f1f2ca4083.png)

# 6. 所感

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