[Redis] 운영환경에서 AWS ElastiCache(Valkey)를 사용할 때 알아야 할 지식: 기본 구조, ClusterMode, MultiAZ, 업그레이드 동작방식

개요

---

 

최근 Redis To Valkey 업그레이드 전환을 주도하면서 실제 작업을 통해 배운 운영 환경에서의 ElastiCache 사용방법에 대해 정리한다.

 

1. ElastiCache 기본 구조

---

1.1. Shard와 Node

ElastiCache를 생성할 때 Cluster Mode로 생성하면, Shard, Node 구성을 선택해야 한다. Shard와 Node(Replicas Per Shard)의 역할은 각각 다음과 같다.

1.1.1. Shard

• 데이터를 여러 샤드에 나눠 저장하여 CPU, 메모리 사용량을 분산한다.
• 각 Shard는 데이터에 대한 Slot을 나눠서 가진다.
  • key-value Store인 ElastiCache는 각 key에 대해 Hash Slot을 할당하고, Slot Number를 기준으로 key-value 데이터 쌍을 관리한다. (여러 키가 Slot을 공유한다.) 이렇게 하는 이유는, Shard가 추가되고 줄어들 때, Slot 단위로 데이터를 움직이게 하기 위해서다. 또한, get/set 데이터 라우팅의 기준이 되기도 한다. Client가 명령을 보낼 때마다 CRC16 (key) mod 16384로 Slot을 계산하고, 그 slot을 소유한 Shard로 명령을 보낸다.
  • 만약 Key-Shard가 직접적으로 매핑된다면 Shard가 바뀔 때마다 매핑이 흔들리게 된다. Shard가 바뀔 때마다 전체 데이터의 이동이 필요해지기 때문이다. 따라서 Slot 단위로 묶고 리샤딩 때도, 데이터는 Slot 단위로 이동한다.

1.1.2. Node

노드는 key-value 데이터가 실제 RAM에 사는 물리적 단위다. 하나의 Shard는 Master Node 1개 + Replica 0~5개의 Node로 구성된다. [위 그림 참고]

• Master(Primary): 해당 Slot 범위의 모든 Wirte를 처리한다. Read도 가능하다.
• Replica: Master를 async로 복제한 사본이다. 1) Read 분산에 사용되고, 2) Master 장애 시, Failover 대상(HA)이다.

 

1.2. Replica의 활용 2가지

1.2.1. HA (자동 Failover)

• Multi-AZ 활성화, Replica가 1대 이상이 조건이다.
• Master 장애가 감지되면 가장 최신 Replica를 Master로 승격한다. 뒤에서 자세히 설명할 테지만 이때 Node DNS Topology가 변경되어 Client Connection은 끊긴 후에 재연결되며 애플리케이션과 ElastiCache 사이의 Topology 갱신이 필요하다. (클라이언트 설정으로 컨트롤 가능하다.)

 

1.2.2. Read 분산

• Replica로 Read 트래픽을 분산한다. 노드당 Read 부하를 감소시킬 수 있다.
• ElastiCache는 Reader Endpoint를 제공한다. 일반적으로는 Client의 READONLY 옵션 등을 통해 직접 분산시킨다.
• 만약 강한 일관성이 필요한 Read라면 Master로 보내야한다. (예컨대, Wirte 직후 즉시 Read가 필요함)

 

1.3. 현재 인프라 구성

기본적으로 우리 인프라에서는 Master 1 + Replica 1 구조를 갖는다. 이렇게 한 이유는 SRE팀 인프라 표준 AZ 정책을 기반으로, 각 Zone 설정 통합을 위해서다. EKS 워커 노드들도 A, C Zone에만 배치되도록 표준화되어있다.

 

추가로, 경험 상 Replica를 2대 이상 둘 가치가 있는 상황은 다음과 같다.

• Failover 진행 중에도 Read 가용성을 유지해야 할 때
• Read 트래픽이 압도적으로 많은 패턴의 애플리케이션

 서비스 특성을 고려해서 필요하다면 Replica를 2대 이상 둘 수 있도록, 사내 플랫폼에서 Self-Service 기능을 제공하고 있다. 

 

 

2. Cluster Mode와 MultiAZ

---

2.1. Cluster Mode

클러스터 모드는 Sharding을 하냐/하지 않냐에 따라 나뉜다. 세부적으로 달라지는 부분들이 있지만 크게 중요한 건 다음과 같다.

• Cluster Mode Enabled를 통해 데이터를 여러 샤드에 분산해서 CPU/메모리 사용량을 분산시킬 수 있다. 즉, 수평 확장이 가능하다.
• Cluster Mode Enabled 클러스터의 Parameter Group 설정은 반드시 cluster_enabled=true 값을 설정해야 한다.

 

2.2. MultiAZ(Availability Zone)

AZ는 한 리전 안에서 물리적으로 분리된 데이터센터를 의미한다. 예를 들어 ap-northeast-2a, ap-northeast-2b 요런식...

AZ를 분리하면 한 AZ가 통째로 죽어도, 다른 AZ는 멀쩡하도록 분리되어있다. 서비스 안정성을 위해 각 존별로 노드를 띄우는 전략을 취하기도 한다. 

 

 

3. ElastiCache 노드 유형, 노드 버전 업그레이드 작동 방식

---

3.1. ElastiCache 노드 유형

선택할 수 있는 노드 유형은 대표적으로 t, m, r 시리즈가 있다. 큰 차이는 다음과 같다.

• T: 가장 저렴하고 사양이 낮은 노드 유형이다. T 시리즈는 저렴하긴 하지만 개발 환경에서만 권하고 있다. t 시리즈는 필요할 때만 순간적으로 성능을 높이는 Burst Credit 기반의 인스턴스이기 때문이다. 실제로 적은 사용량에 메모리가 충분함에도 불구하고 메모리 스왑이 지속적으로 발생하는 경우도 있었다.
• M: General Purpose. 메모리 집약적인 연산이 없는 일반적인 캐시의 경우, M 시리즈 사용을 권장한다.
• R: 메모리 성능에 특화된 유형으로, vCPU 당 메모리가 가장 많은 유형이다. 같은 사이즈(.large)로 비교하면, R이 M보다 메모리가 약 2배 정도다. 

3.2. ElastiCache 노드 유형/버전 업그레이드 동작방식

노드 유형 업그레이드와 노드 버전 업그레이드는 기본적인 메커니즘이 같다. 이번에 Redis To Valkey 전환 작업을 주도하면서 가장 많이 살펴봤던 것이 해당 부분이다. 

 

3.2.1. in-place 업그레이드

ElastiCache 노드 업그레이드는 in-place 방식으로 진행된다. [참고 문서] 새로운 클러스터를 만들어서 데이터를 옮기는 것(blue-green 등)이 아니라, 지금 쓰는 클러스터를 그대로 둔 채로 노드 버전을 올리는 것이다. 애플리케이션 입장에서는 접속 Endpoints DNS가 바뀌지 않는다. 덕분에 클라이언트 재배포 없이 업그레이드가 가능하지만, 대신 순단은 감수해야 한다.

 

3.2.2. 실제 동작 순서

Redis Note

 

3.2.3. 업그레이드와 Topology 갱신

in-place 방식대로 업그레이드를 진행한다면 짧은 순단(Write 실패)이 발생한다. 동기화 단계에서는 기존 노드가 정상적으로 트래픽을 처리하기 때문에 영향이 없고, 전환 시점에 한해서 기존 Primary로의 connection이 끊긴다. 실제 전환 시에 샤드당 단절 수준은 N초 정도였지만, 에러율은 최대 5분까지 이어졌다.

 

새로운 connection을 위해 클라이언트는, 재연결 후 Cluster Topology를 갱신해서(CLUSTER SLOTS/ CLUSTER NODES) 새 노드를 찾아야 한다. Redis To Valkey로의 전환을 권장하기 위해 아래와 같이 언어별 가이드를 만들어서 배포했다.

 

 

경험으로 배운 운영 지식

• 토폴로지 갱신이 느리거나 MOVED/ASK Redirect를 따라가지 못하느 클라이언트는 짧은 순단동안 에러를 낸다.
• 각 클라이언트별로 Redis Version과 호환성을 잘 체크해야한다.
  • 예컨대, go-redis v8은 Redis 6.x와 호환된다. Valkey 7.x로의 업그레이드를 위해서는 go-redis를 v9로 업그레이드하는 선행 작업이 요구된다. 실제로 클라이언트 라이브러리 업그레이드를 놓치고 Valkey 전환을 진행했을 때 Valkey 연결에 지속적인 Panic이 발생하기도 했었다.

{"level":"panic","error":"got 4 elements in cluster info address, expected 2 or 3","time":"2026-06-01T09:27:37Z","message":"redis.New(session) failed"}

• Write보다 Read 연산이 압도적으로 많은 작업을 하는 클러스터라면, 미리 Replica를 늘리고 전환을 시도하는 것이 순단 영향을 많이 줄여줄 수 있다.

결론은 Client별 재연결/Topology Refresh, Max Redirec 설정 등 클라이언트 설정을 미리 점검해두는 것이 순단 영향을 줄이는 것의 핵심이었다.

 

나의 경우는 사내 배포 플랫폼에 AWS API를 구조적으로 구성하여 전사 모든 클러스터의 전환 과정이 동일했다. AWS 콘솔에서 직접 진행하는 경우는 전환 이후의 Parameter Group 설정이나 cluster_enabled같은 값이 의도대로 잘 넘어왔는지 확인하는 것도 좋을 듯하다.