dshimizu/blog

とりとめのないITブログ

Amazon ElastiCache for Redis の構成要素とクラスターモード有効と無効の違いに関するメモ

はじめに

ElastiCache(Redis)をクラスターモードの有効と無効があるが、どっちを選んでもElastiCacheとしてはクラスターとなり、Redisの経験も浅い自分としてはよくわからなかったので調べた。

ElastiCache(Redis)を構成するコンポーネント

下記ドキュメントに書かれている。

登場するコンポーネントは下記。 クラスターの構成によっては、マネジメントコンソールからの見え方と、APIからの操作では、呼び方が異なるものがあり、かなり混乱する。

  • Node
    • ElastiCacheの最小の構成要素。メモリとかCPUが割り当てられている(≒インスタンスみたいなものだと思っている)。プライマリとレプリカがある。
  • Shard (NodeGroup)
    • 複数のノードをまとめたグループ。データをシャードごとに分散して保存できる。シャードにはID(NodeGroupId)が割り当てられている。1つのシャード内に複数のノードが存在することで、シャード内のノード間でデータが同期(レプリケーション)される。クラスターモードが無効のElastiCacheクラスターではシャードは常に1つとなる。クラスターモードが有効のElastiCacheクラスターではシャードは最大90個となる。
  • Cluster (ReplicationGroup)
    • シャードをまとめたグループ。クラスターにもID(ReplicationGroupID)が割り当てられる。クラスターモードが有効のElastiCacheクラスターでは、複数のシャードを作ることでデータがシャード間で分割される。

単一 Node の ElastiCache For Redis Cluster

単一 Node の ElastiCache For Redis Cluster を作成する場合、以下のように AWS::ElastiCache::CacheCluster タイプを利用する。

  ElasticacheRedisCluster:
    Type: 'AWS::ElastiCache::CacheCluster'
    Properties:
      AutoMinorVersionUpgrade: false
      CacheNodeType: cache.t3.micro
      CacheSubnetGroupName: xxxx
      CacheParameterGroupName: xxxx
      ClusterName: sandbox
      Engine: redis
      EngineVersion: 5.0.6
      NumCacheNodes: '1'
      VpcSecurityGroupIds: xxx

クラスターモード無効の ElastiCache For Redis Cluster

クラスターモードを無効にした場合、ElastiCacheとしてはMaster/Slave構成のクラスターとなる。

Redis (クラスターモードが無効) クラスターでは、スレーブノードは1台~、マスターノードは1台、シャードとクラスターも1つとなる。

CloudFormationで作成する場合は、以下のように AWS::ElastiCache::ReplicationGroup タイプを利用する。 NumCacheClusters を指定すると、クラスターモード無効の状態になる。1 の場合はプライマリ1個となり、例えば3とするとプライマリ1個、レプリカ2個となる。 NumCacheClustersの代わりに、NumNodeGroupsReplicasPerNodeGroup の組み合わせでも設定でき、この場合は NumNodeGroups を1としてShardを1つとし、ReplicasPerNodeGroup でレプリカノードの数を制御する。

  ReplicationGroup:
    Type: 'AWS::ElastiCache::ReplicationGroup'
    Properties:
      ReplicationGroupId: sandbox
      Engine: redis
      EngineVersion: 5.0.6
      NumCacheClusters: '1'   # クラスターモード無効としたい場合に指定する。1 の場合はプライマリ1個となり、例えば3とするとプライマリ1個、レプリカ2個となる 。
      #NumNodeGroups: '1'   # Shard の数を指定する。この場合は 1 つとなる。
      #ReplicasPerNodeGroup: '0'  # Shard の中のレプリカノードの数を指定する。この場合はレプリカは 0 となる。
      MultiAZEnabled: false
      CacheNodeType: cache.t3.micro    
      AutomaticFailoverEnabled: 'false'
      AutoMinorVersionUpgrade: 'false'
      CacheSubnetGroupName: xxxx
      CacheParameterGroupName: xxxx
      PreferredMaintenanceWindow: 'wed:04:30-wed:05:30'
      SnapshotRetentionLimit: '3'
      SnapshotWindow: '03:30-04:00'
      ReplicationGroupDescription: sandbox
      SecurityGroupIds: xxxx

クラスターモード有効の ElastiCache For Redis Cluster

クラスターモードを有効にした場合、ElastiCache For Redis としては Redis Clusterとなると思っている(違うかも)。マルチマスター構成となる。 Redis Cluster の場合、マスター1台とスレーブの2台の1セットが3つで計6つのノードとするのが推奨らしい。

これをElastiCache For Redisのクラスターモードを有効状態で置き換えると、最低3つのShard (NodeGroup)、各Shard (NodeGroup)の中にReplica Nodeを最低2つ(Primary Nodeは1つ)で、Nodeとしては6つ必要になる。 これでShard (NodeGroup)毎にデータを分割して保存することができるようになる。

CloudFormationで作成する場合は、以下のように AWS::ElastiCache::ReplicationGroup タイプを利用して以下のようになると思われる。

  ReplicationGroup:
    Type: 'AWS::ElastiCache::ReplicationGroup'
    Properties:
      ReplicationGroupId: sandbox
      Engine: redis
      EngineVersion: 5.0.6
      NumNodeGroups: '3'   # Shard の数を指定する。この場合は 3 つとなる。
      ReplicasPerNodeGroup: '3'  # Shard の中のレプリカノードの数を指定する。この場合はレプリカは 3 となる。
      MultiAZEnabled: true
      CacheNodeType: cache.t3.micro    
      AutomaticFailoverEnabled: 'true'
      AutoMinorVersionUpgrade: 'false'
      CacheSubnetGroupName: xxxx
      CacheParameterGroupName: xxxx
      PreferredMaintenanceWindow: 'wed:04:30-wed:05:30'
      SnapshotRetentionLimit: '3'
      SnapshotWindow: '03:30-04:00'
      ReplicationGroupDescription: sandbox
      SecurityGroupIds: xxxx
      #NodeGroupConfiguration:

まとめ

ElastiCache Redisのクラスターモードの有効/無効の違いについて、ElastiCache Redisの構成要素を調べて整理した。

単一ノードのElastiCacheクラスターと、Cluster Modeが有効なElastiCacheクラスター、Cluster Modeが無効のElastiCacheクラスターの3パターン作成できるようである。 Cluster Modeの有効の場合はより可用性の高いRedis Cluster、Cluster Modeの無効の場合はMaster/Slave構成のクラスターとなる。

いずれの構成もElastiCacheとしての制約もあるので、どっちが良いかは要件次第だと思う。

参考