ElastiCache Redis의 노드 타입을 변경할 때 데이터 유실 없이 전환이 가능한가요?

ElastiCache Redis 노드 타입 변경 및 데이터 유지 전략

1. 어떻게 데이터 유실 없이 가능한가요?

AWS는 노드 타입을 변경할 때 '레플리카 우선 교체' 방식을 사용합니다.

1. 새 노드 프로비저닝: 요청하신 새로운 타입(예: cache.t3.medium → cache.m6g.large)의 빈 노드를 먼저 띄웁니다.

2. 데이터 동기화: 기존 노드(Old)에서 새 노드(New)로 데이터를 실시간으로 복제(Replication)합니다.

3. 역할 전환(Failover): 데이터 동기화가 완료되면 DNS를 업데이트하여 새 노드를 기본(Primary) 노드로 승격시킵니다.

4. 기존 노드 삭제: 전환이 확인되면 예전 노드를 제거합니다.

2. 클러스터 모드에 따른 차이

3. 성공적인 전환을 위한 3대 체크리스트

1. 여유 메모리 확보 (reserved-memory-percent):

   데이터 동기화 과정에서 스냅샷을 찍거나 복제 버퍼를 사용하기 때문에 메모리 사용량이 일시적으로 튑니다. 최소 25% 이상의 여유 메모리가 있는 상태에서 작업을 시작하는 것이 안전합니다.

2. Multi-AZ 활성화:

   복제본이 없는 단일 노드(Primary Only) 구성이라면 타입 변경 시 반드시 다운타임이 발생합니다. 운영 환경이라면 반드시 하나 이상의 복제본과 Multi-AZ 기능을 켜두어야 합니다.

3. 클라이언트 재연결 로직:

   DNS 가 바뀌는 찰나에 아주 짧은 접속 끊김(수 초 미만)이 발생할 수 있습니다. 애플리케이션 코드에 '지수 백오프(Exponential Backoff)'를 포함한 재연결(Retry) 로직이 구현되어 있어야 사용자가 장애를 느끼지 못합니다.

운영 확인 사항

"데이터 유실은 없지만, 네트워크 지연(Latency)은 발생할 수 있습니다. 복제 작업이 진행되는 동안 인스턴스의 CPU와 네트워크 대역폭을 많이 사용하기 때문이죠. 가급적 트래픽이 가장 적은 시간대에 작업을 수행하는 것이 '무결점 운영'의 기본입니다."