ElastiCache（Redis）に書き込みできなくなる操作とその時間について調べてみた

#Amazon ElastiCache

#AWS

菅野昌孝

2016.06.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

菅野です。
ElastiCache（Redis）のプライマリノードのリプレースメントがイベントに登録された時の選択肢として、何もしないで自動で置き換えされるのを待つ方法もありますが、レプリケーショングループを使っているならリードレプリカを昇格させて対応する方法もあります。
ただ、運用中のシステムでプライマリの切り替えを行った時にどれくらいの時間 ElastiCache が使えなくなるのか、AWSの資料だけではわからないのでうかつに作業できません。

今回、リードレプリカを昇格させた時に ElastiCache に対してどれ位の間書き込みできなくなるのかと、その他の操作ではどのような状態になるか調べましたのでその結果について書いておきます。

Multi-AZの有効/無効を切り替えた時の影響

Multi-AZ が有効だとリードレプリカをプライマリに昇格させることができません。
一度 Multi-AZ を無効にする必要があるのでその時に ElastiCache に対して書き込みができなくなるのかを調べました。
調べるためのコマンドは以下を使い、EC2上で動かして様子をみます。
ncコマンドを使ってElastiCacheに対して接続し、「aaa」に"bbb"を書き込み、1秒後にquitしています。

$ while true; do date; (echo set aaa "bbb"; sleep 1; echo quit;) | nc xx.xxxxx.ng.0001.apne1.cache.amazonaws.com 6379; done

このコマンドを平常時に動かした時は以下のような出力になります。

2016年  5月 31日 火曜日 10:19:47 UTC
+OK
2016年  5月 31日 火曜日 10:19:48 UTC
+OK
2016年  5月 31日 火曜日 10:19:49 UTC
+OK
2016年  5月 31日 火曜日 10:19:50 UTC
+OK
2016年  5月 31日 火曜日 10:19:51 UTC
+OK

では、Multi-AZ を無効にしてみましょう。設定は Replication Groups を選択し、Modify ボタンをクリックして表示される以下のポップアップで変更できます。

先ほどのコマンドを実行した状態で Multi-AZ を無効にしましたが、以下のように「set aaa "bbb"」がエラーになることはありませんでした。 Multi-AZ を無効から有効にした時も同様です。

2016年  5月 31日 火曜日 08:59:35 UTC
+OK
+OK
2016年  5月 31日 火曜日 08:59:36 UTC
+OK
2016年  5月 31日 火曜日 08:59:37 UTC
+OK
〜 中略 〜
2016年  5月 31日 火曜日 09:02:27 UTC
+OK
2016年  5月 31日 火曜日 09:02:28 UTC
+OK
+OK
2016年  5月 31日 火曜日 09:02:29 UTC
+OK
+OK
2016年  5月 31日 火曜日 09:02:30 UTC
+OK

リードレプリカをプライマリに昇格させた時の影響

次にリードレプリカをプライマリに昇格させて様子をみましょう。
Replication Groups を選択すると、画面下部に以下のようなクラスター一覧が表示されます。
プライマリの昇格はリードレプリカの行の一番右にある「Promote」ボタンをクリックして行います。

では、先ほどのコマンドを実行しつつリードレプリカを昇格させてみましょう。

2016年  5月 31日 火曜日 09:07:42 UTC
+OK
2016年  5月 31日 火曜日 09:07:43 UTC
-READONLY You can't write against a read only slave.
2016年  5月 31日 火曜日 09:07:44 UTC
-READONLY You can't write against a read only slave.
2016年  5月 31日 火曜日 09:07:45 UTC
-READONLY You can't write against a read only slave.
2016年  5月 31日 火曜日 09:07:46 UTC
+OK
2016年  5月 31日 火曜日 09:07:47 UTC
+OK

「-READONLY You can't write against a read only slave.」とエラーメッセージが表示され、一時的に書き込みできなくなったことがわかります。
この時は約3秒程の間でしたが、何回かテストすると時間にばらつきがあり、およそ3〜10秒くらいの間書き込みができないという結果になりました。

クラスタ・ノードの再起動

まずは Multi-AZを有効に戻しておきます。先ほども書いたように問題なく書き込めていました。
では、クラスタのリブートをやってみます。

私としては、Multi-AZは有効にしてあるし、レプリケーショングループに属しているし、きっと劇的にリードレプリカがプライマリに昇格してくれるのだろう、一時的に書き込みできなくなるんだろうと想像していました。結果は以下の通りです。

2016年  5月 31日 火曜日 10:18:50 UTC
+OK
2016年  5月 31日 火曜日 10:18:51 UTC
+OK
2016年  5月 31日 火曜日 10:18:52 UTC
+OK
〜 中略 〜
2016年  5月 31日 火曜日 10:20:22 UTC
+OK
2016年  5月 31日 火曜日 10:20:23 UTC
+OK
2016年  5月 31日 火曜日 10:20:24 UTC
+OK

一切のエラーもなく、全て書き込みに成功しています。また、リードレプリカが昇格してプライマリになるなんて事もありませんでした。
ノードの再起動もやってみましたが結果は同じです。

まとめ

マネジメントコンソールから行える、ElastiCacheの動作に影響しそうな操作を行った結果は以下となりました。 Multi-AZの設定切り替え　　　　　　・・・影響なし
プライマリノードの切り替え　　　　・・・3〜10秒程書き込み不可。その後復旧し切り替え完了
プライマリクラスタ・ノードの再起動・・・影響なし

さいごに

いかがでしたでしょうか。
稼働中のシステムに対してなんらかの操作を行う時、どの程度のサービス停止時間があるのかは運用している側としてはとても気になります。
今回の内容はElastiCacheのメンテナンスに対して「ノードが置き換え対象となった場合に実行可能なアクション」について検討していた際に気になったので検証した結果となります。
この検証結果がお役に立てば幸いです。

※ElastiCacheは、時々メールでお知らせしてもらえない「ノードの置き換え」がイベントに登録されている事がありますので注意が必要です。