ElastiCache 메인터넌스 업그레이드를 하며 알게된것들

AWS 공식 용어로는 cluster mode disabled / enabled 인데, 이 글에서는 각각 레플리카 모드 / 클러스터 모드라고 부르겠습니다. 레플리카 모드는 primary + read replica 구조이고, 클러스터 모드는 shard를 여러개로 나누는 구조입니다.

ElastiCache 메인터넌스가 다 비슷해보이긴 하는데, 막상 해보면 뭘 바꾸느냐에 따라 성격이 좀 다릅니다. 자주 만나는건 인스턴스 타입 변경이랑 엔진 업그레이드 두가지인데, 둘 다 maintenance window에서 돌릴 수 있지만 WAS가 체감하는 타이밍이 다르거든요. AWS 문서 기준으로 유형 변경은 온라인 vertical scaling, 엔진은 별도 engine upgrade 절차로 나뉩니다.

유형 변경 — 마지막 전환에서 흔들림

유형 변경은 쉽게 생각하면 새 노드로 갈아끼우는 작업이라고 보시면 될것같습니다.

AWS 문서상 흐름을 정리하면,

1. 새 타입 노드 준비
2. 데이터 복제/동기화
3. DNS를 새 노드로 전환
4. 기존 노드 정리

이런 순서인데, AWS는 이 과정에서 endpoint를 바꿀 필요가 없고 auto failover enabled cluster면 온라인 상태로 요청을 계속 처리하도록 설계했다고 설명하고 있습니다.

실제로 순단이 느껴지는건 3번, DNS 전환 시점입니다. 복제/동기화 진행중에는 별 일이 없고, DNS가 바뀌면서 기존 연결이 끊길때 reconnect, timeout이 수초 정도 나옵니다.

레플리카 모드에서는 primary가 하나뿐이니까 이게 전체 keyspace에 걸쳐서 느껴지는데, primary endpoint를 쓰고 있으면 connection string 자체를 바꿀 필요는 없습니다.

엔진 업그레이드랑 비교하면, failover 없이 DNS 전환만으로 끝나는거라서 좀 더 예측 가능한 작업이라고 생각하시면 될것같습니다.

엔진 업그레이드 — failover가 핵심

엔진 업그레이드는 유형 변경보다 한단계 무겁습니다. 노드만 바꾸는게 아니라 엔진 소프트웨어 자체를 바꾸는거거든요.

AWS도 업그레이드 시 기존 client connection을 종료한다고 명시하고 있고, major upgrade면 parameter group까지 같이 봐야 합니다.

작업 순서를 보면 왜 민감한지 바로 이해가 됩니다.

1. replica를 먼저 업그레이드 — 이 구간은 write 영향 없음
2. replica 끝나면 primary 처리 — 여기가 순단 구간
3. primary failover — 업그레이드된 replica 중 하나가 새 primary로 승격
4. 구 primary가 새 엔진으로 올라와서 replica로 합류

multi-shard면 shard들이 병렬로 진행될 수 있는데, primary는 shard 전체에서 한번에 하나씩 순차 처리됩니다.

WAS에서 체감하는것도 2~3번 구간입니다. 기존 연결 끊기고, 새 primary로 재연결 일어나고, retry 늘고, 짧은 write failure나 timeout spike가 보일 수 있습니다.

참고로 AWS 기준 Redis OSS 5.0.6 이상에서는 업그레이드중에 읽기는 전체 기간 동안 가능하고, 쓰기도 failover 몇초 빼면 대부분 가능하다고 합니다. 근데 single-node이거나 Multi-AZ가 꺼져있으면 primary가 못받는 구간이 더 길어질 수 있습니다.

“작업시간 2030분”걸리긴 하지만, “서비스가 2030분 멈춘다”는 다른 얘기입니다. 실제로 앱이 크게 느끼는건 primary failover 전후 짧은 구간에 몰려있거든요.

레플리카 모드 vs 클러스터 모드 — 메인터넌스에서는 어떤 차이가?

레플리카 모드

shard가 하나, primary도 하나입니다. 유형 변경이든 업그레이드든, primary를 건드리면 전체 keyspace의 write path가 같이 영향을 받습니다.

failover가 오면 전체 write가 잠깐 멈추고 모든 클라이언트가 동시에 reconnect하는데, 구조가 단순한만큼 오히려 예측이 쉽습니다. 순단이 오면 전부 오고, 끝나면 전부 끝나는 구조죠.

클러스터 모드

shard가 여러개이고, 메인터넌스도 shard 단위로 진행됩니다.

엔진 업그레이드를 예로 들면,

1. shard 0001의 replica들 업그레이드
2. shard 0001의 primary failover — 이 shard의 slot 범위만 순단
3. 끝나면 shard 0002로 넘어감
4. shard 0002 진행중에 shard 0001은 이미 정상

3-shard 구성이면 메인터넌스 중에도 항상 2/3는 정상 서비스가 됩니다. 유형 변경도 마찬가지로 shard 단위 cutover가 진행되구요. AWS의 TestFailover도 전체 클러스터가 아니라 특정 shard(node group) 대상으로 수행됩니다.

이 차이가 곧 레플리카 모드와 클러스터 모드의 차이라고 보시면 됩니다.

근데 클라이언트가 더 할일이 많다

클러스터 모드는 메인터넌스 중에 클라이언트가 처리할게 늘어납니다.

• MOVED 응답 처리 — failover로 slot 주인이 바뀌면 클라이언트가 새 노드로 다시 요청해야함
• topology refresh — slot map을 주기적으로 갱신해야함
• 부분적 reconnect — 전체가 아니라 특정 shard만 끊기는 상태를 제대로 처리해야함

레플리카 모드에서는 “끊기면 전부 reconnect”라서 오히려 단순한데, 클러스터 모드는 “일부만 끊기고 일부는 살아있는” 상태를 잘 다뤄야 합니다. topology refresh가 느리거나 MOVED 처리가 안되는 클라이언트면 오히려 더 혼란스러울 수 있거든요.

AWS 문서에서도 클러스터 모드는 configuration endpoint + cluster-aware client가 필수라고 하고, 일부 수정은 제한적이라 백업해서 새로 만들어야 하는 경우도 있다고 안내합니다. 다운타임 / 임팩트는 줄일 수 있지만, 운영 복잡도도 같이 올라갑니다.

1-shard 클러스터 모드라면?

shard가 하나뿐이면 영향 분산 효과가 없습니다. cluster protocol 복잡도만 올라가고 blast radius는 레플리카 모드랑 다를게 없어서, 클러스터 모드의 메인터넌스 이점은 2 shard 이상부터 의미가 있다고 생각합니다.

둘 다 해야 한다면

사실 Redis 에 손을 댈 일이 많지않아, 오랫동안 방치하다보면 “Engine Upgrade”와 “구형 인스턴스의 유형변경” 모두 진행해야 할일이 다가옵니다.

AWS 문서에도 immediate scale-up이랑 immediate engine upgrade가 서로 block될 수 있다고 나오는데, AWS도 이 둘을 별개 변경으로 보고 있는것같습니다.

순서를 정해야 한다면,

• 업사이즈 목적 → 유형 변경 먼저 (headroom 확보) → 업그레이드
• 다운사이즈 목적 → 업그레이드 먼저 → 유형 줄이기

snapshot, replication, failover, backup 같은 작업에 여유 메모리가 중요하다는 점이랑 scaling 시 reserved-memory 검토가 필요하다는 AWS 권고를 보면, **“먼저 여유를 만들고, 그다음 무거운 변경”**이 기본 원칙이라고 생각합니다.

레플리카 추가/제거

앞의 두 작업에 비하면 훨씬 가볍습니다. AWS도 replica count 증감은 no cluster downtime으로 설명하거든요.

레플리카 모드에서는 reader endpoint가 replica로 연결을 분산하고, primary endpoint는 승격 같은 변경에도 계속 primary를 가리키도록 되어있어서 node direct endpoint를 직접 쓰지 않는다면 daytime non-peak에도 할 수 있는 변경입니다.

다만 add랑 remove는 성격이 좀 다릅니다.

추가(add) — 초기 sync + 복제 부하 때문에 작업중 primary 부담이 커질 수 있습니다. write-heavy일수록 민감하구요.

제거(remove) — 작업중 부담은 덜한데, 작업 후 HA랑 read 여유가 줄어듭니다. Multi-AZ랑 failover를 중요하게 본다면 remove는 “작업 자체”보다 “작업 후 구조”를 더 신경써야 합니다.

마무리

유형 변경은 마지막 cutover에서 흔들리고, 업그레이드는 primary failover에서 흔들립니다. 레플리카 모드랑 클러스터 모드의 차이는 그 흔들림이 전체에 한번에 오느냐, shard 단위로 나뉘느냐에 있습니다.

AWS 문서 읽으면 작업 절차가 보이고, 운영 경험으로 풀어보면 결국 중요한건 **“언제 reconnect가 터지고, 그 영향이 어디까지 퍼지느냐”**입니다.