やりたいこと
- ElastiCache for Redisの設計をしたい（まずは方式レベル）
- 用途はアプリケーションのセッション管理
- 可用性要件が高く、AZ障害の際にもダウンタイムを最小限にしたい
参考文献
- 公式ドキュメントだとこれがドンピシャ
- 2年前ですが分かりやすい公式スライド
- 基本のおさらいには安定のクラメソさんブログ
これらより、まずは「クラスターモード」を採用すべきか否か、の判断のためフェイルオーバー所要時間を実測してみる。
試したこと
準備
-
非クラスターモードのRedisクラスターを作成
- クラスター名：single-shard
- マルチAZ：有効
- レプリカ数：2
- AZの配置（ノード）
- プライマリ：ap-northeast-1a
- レプリカ1：ap-northeast-1a
- レプリカ1：ap-northeast-1c
-
クラスターモードのRedisクラスターを作成
- クラスター名：multi-shard
- マルチAZ：有効
- シャード数：3
- レプリカ数：2
- AZの配置（ノード）
- プライマリ：ap-northeast-1a
- レプリカ1：ap-northeast-1a
- レプリカ1：ap-northeast-1c
手動フェイルオーバーの実行
ElastiCacheではAuroraのように手動でフェイルオーバーが実行できる！
お手軽なので今回はこれで試してみる。
-
まずは非クラスターモードのクラスター（ややこしい）でプライマリノードを選択し「プライマリをフェイルオーバー」を実行
-
すると 約20秒 でプライマリノードが001号機から003号機へ切り替わった！
-
お次はクラスターモードのクラスター（ややこしい）でシャードをどれか1つ選択し「プライマリをフェイルオーバー」を実行
※マネコンのノードリストが階層式で見やすくて嬉しい😊
-
実行はしたものの非クラスターモードのときと異なり、ノード一覧にプライマリ/セカンダリがマネコン上表示されていないため切り替わり完了時刻を確認できず。苦笑（CloudTrailも見たものの所要時間は確認できず）
-
ただし、そもそもクラスターモードではマルチシャード構成のため、単一AZ障害＝部分的なシャード障害に陥ったとしても、シャード内のノード昇格を待たずして、生きているAZ上のシャードへそのまま書き込み可能なはず。そのため書き込みダウンタイムはほぼ発生しない？ ※ここは要確認。
分かったこと
- ElastiCache for Redisのシャード内におけるノード昇格所要時間はマネコン表示上、数十秒。（実測サンプルの一例として）
- その書き込みダウンタイムが許容できない場合、クラスターモードを有効にしてマルチシャード構成を利用すべし！
ちなみに手動フェイルオーバーの実行クォータは1日5回までのようなので、実験する方は注意。
おやつは1日５袋まで！（謎）
（Zennヒット率が個人的に高い山原さん。いつもありがとうございます！）
最後に一言
MemoryDB for Redis、早く大阪リージョン対応しないかなぁ (´ー｀)