Open3

Redis Cluster modeにおける最小のmaster node数について

Lil-lonLil-lon

背景

  • ローカルでRedis Cluster modeをOnにしたRedis Clusterを作成して検証をしようとした。
  • Redisの公式ドキュメントを見ながら、「一旦サクッと作るか」と以下のdocker-composeファイルとコマンドでmaster node1台、slave node1台でクラスターを作成しようとしたところErrorが発生した。
docker-compose.yml
version: '3'
services:
  redis-master-1:
    image: redis:7.0
    command: redis-server --cluster-enabled yes --cluster-config-file nodes.conf --cluster-node-timeout 5000 
    ports:
      - '6379:6379'

  redis-slave-1:
    image: redis:7.0
    command: redis-server --cluster-enabled yes --cluster-config-file nodes.conf --cluster-node-timeout 5000 --port 6380
    ports:
      - '6380:6380'
redis-cli --cluster create 127.0.0.1:6379 127.0.0.1:6380 --cluster-replicas 1

Error message

*** ERROR: Invalid configuration for cluster creation.
*** Redis Cluster requires at least 3 master nodes.
*** This is not possible with 2 nodes and 1 replicas per node.
*** At least 6 nodes are required.

Note that the minimal cluster that works as expected must contain at least three master nodes. For deployment, we strongly recommend a six-node cluster, with three masters and three replicas.

  • 可用性の観点から複数台あった方が良さそうなのは推測できたが、"3"という数字の背景が気になったので少し調査してみた。が依然明確な理由はわからず。今後何か発見があれば書き溜めるようにスクラップを作成。
  • もしご存知の方などいらっしゃれば教えていただきたい所存🙇

これまで調べたこと

ChatGPTに聞いてみたところ以下の回答を得た。

Redis Clusterが期待通りに動作する最小限の構成として、少なくとも3つのマスターノードが必要です。そして、本番環境にデプロイする際には、3つのマスターと3つのレプリカを含む6ノードのクラスターが強く推奨されています。
理由

  1. 合意形成(Consensus): Redis Clusterでは、ノード間での合意形成が必要です。特に、マスターノードがダウンした場合には、そのマスターのレプリカが新しいマスターに昇格する必要があります。3つのマスターノードがあれば、過半数(2/3)が合意を形成し、故障したノードに対するアクション(例えば、新しいマスターの選出)がスムーズに行えます。
  2. データの可用性: 3つのマスターノードと3つのレプリカがあれば、1つまたは2つのノードが故障しても、残りのノードでデータの可用性を維持できます。また、レプリカが各マスターに存在するため、マスターが失敗した場合でもデータの損失が最小限に抑えられます。
  3. 負荷分散: 複数のマスターノードがあれば、データの書き込みと読み取りの負荷が分散され、全体としてのパフォーマンスが向上します。
  4. シャーディング: Redis Clusterは、データを複数のマスターノードに分散(シャーディング)します。これにより、1つのマスターノードに負荷が集中することを避け、スケーラビリティを向上させることができます。
    以上のような理由から、少なくとも3つのマスターノードが推奨されています。そして、本番環境においては、各マスターに対するレプリカも含めた6ノード構成が理想とされています。

どの点についても納得感はある。
当然ながら負荷分散やシャーディングの観点で3台以上でClusterを構成した方が良さそう。
合意形成の部分についてはmasterが1台落ちた時は残りのmasterは2台になってしまうのでは?との疑問もあるのでもう少し深掘りして調べたい。

Stack overflowでも昔だが同様の質問とその理由を推測をしているものを見つけた。
https://stackoverflow.com/questions/34523797/why-redis-cluster-requires-at-least-3-master-nodes
しかし公式が提供している情報はまだ見つけられていないので引き続き時間があれば探すことにする。

Lil-lonLil-lon

Elasticache

Elasticache Redisではmaster nodeの数が2つでも問題ないとする議論を見つけた
https://stackoverflow.com/questions/75666176/does-numnodegroups2-in-elasticache-violate-redis-minimal-cluster-recommendation
可用性の観点では問題ない気もするが、failoverの検知がnode2つで正しくできるのかが気になる

少し古いがAWS Deep diveの資料でもClster modeでどのようにしてfailoverを検知しているのかについて詳細は触れられておらずよくわからなかった
https://pages.awscloud.com/rs/112-TZM-766/images/Session 1 - ElastiCache-DeepDive_v2_rev.pdf

OSS Redisにおけるfailoverとgossip protocol

上記一つ目のStackoveflowでgossip protocolについて言及されていたので少し調べてみた。
いくつか参考になる記事を見つけた(あくまでブログなので正確性は調査が必要)
https://deeptimittalblogger.medium.com/redis-gossip-is-backbone-for-healthy-cluster-41771e2e7f76
https://alibaba-cloud.medium.com/understanding-the-failover-mechanism-of-redis-cluster-3b979dcf3441

Lil-lonLil-lon

Gossip protocol

気になったのでRedisでどうgossip protocolが実装・利用されているのか少し深掘り
Redis document

client向けに解放しているポート番号に10000を足したポートでnode間で通信しているらしい