프로덕션 환경에서 Redis 사용량이 늘어나면 팀은 반드시 중요한 아키텍처 결정 앞에 서게 됩니다. Redis를 Redis Sentinel로 운영해야 할까요, 아니면 Redis Cluster로 전환해야 할까요?
안타깝게도 이 결정은 종종 성능 저하, 메모리 고갈, 가용성 장애가 발생한 이후에야 촉박하게 내려지곤 합니다. 그러나 Sentinel과 Cluster는 서로 전혀 다른 문제를 해결하는 기술이며, 잘못 선택하면 고통스러운 재설계 작업을 피할 수 없습니다.
핵심을 먼저 정리하면 다음과 같습니다. Redis Sentinel은 '가용성'을 위한 기술이고, Redis Cluster는 '확장성'을 위한 기술입니다. 이 둘을 혼동하는 것이 Redis 아키텍처 설계에서 가장 흔히 발생하는 실수입니다.
Redis Sentinel이 해결하는 핵심 문제
Redis Sentinel은 단일 Redis 데이터셋에 대한 고가용성(High Availability)을 제공하도록 설계되었습니다. 주요 역할은 다음과 같습니다.
- Redis 마스터 및 복제본(replica) 노드 모니터링
- 장애 감지
- 자동 페일오버(failover) 수행
- 새로운 마스터 정보를 클라이언트에 갱신
Sentinel은 데이터를 샤딩하지 않습니다. 모든 키를 보유하는 논리적 Redis 인스턴스는 언제나 하나뿐입니다. 마스터에 장애가 발생하면 Sentinel이 복제본을 마스터로 승격시키며, 애플리케이션 입장에서는 최소한의 중단으로 Redis가 계속 동작합니다.
Redis Sentinel의 내부 동작 방식
일반적인 Sentinel 구성은 다음 요소들로 이루어집니다.
- 하나의 Redis 마스터
- 하나 이상의 Redis 복제본
- 이들을 감시하는 복수의 Sentinel 프로세스
Sentinel은 지속적으로 마스터의 상태를 점검하며, 쿼럼(quorum)에 해당하는 Sentinel들이 마스터 다운에 합의하면 페일오버가 트리거됩니다. 이후 한 복제본이 마스터로 승격되고, 나머지 복제본들은 새 마스터를 따르도록 재구성됩니다.
여기서 중요한 점은 데이터의 크기와 구조는 그대로 유지된다는 것입니다. 어떠한 키 재분배도 일어나지 않습니다.
Redis Sentinel이 하지 못하는 것
Redis Sentinel은 다음 기능을 제공하지 않습니다.
- 단일 노드를 넘어서는 메모리 용량 확대
- 단일 코어를 넘어서는 쓰기 처리량 증대
- 데이터 샤딩 및 분산 저장
Redis 인스턴스의 메모리나 CPU가 부족하다면 Sentinel을 추가해도 소용이 없습니다. Sentinel은 Redis를 '더 크게' 만드는 것이 아니라 '계속 사용 가능하게' 유지할 뿐입니다.
Redis Cluster가 해결하는 핵심 문제
Redis Cluster는 단순한 가용성을 넘어 확장성 문제를 해결합니다. 구체적으로 다음 한계를 극복합니다.
- 단일 머신의 메모리 용량 한계
- 싱글 스레드 실행 구조로 인한 처리량 한계
Redis Cluster는 데이터를 여러 마스터 노드에 샤딩(sharding)하며, 각 마스터는 전체 키스페이스(keyspace)의 일부를 담당합니다. 복제는 가용성 확보를 위해 사용되지만, 샤딩이야말로 Cluster의 본질적인 특징입니다.
Redis Cluster의 동작 원리
Redis Cluster는 전체 키스페이스를 16,384개의 해시 슬롯(hash slot)으로 나눕니다. 각 마스터 노드는 슬롯의 일부를 소유하고, 키는 해시 함수를 기반으로 특정 슬롯에 할당됩니다.
클라이언트가 명령을 보내면 해당 슬롯을 담당하는 노드로 라우팅됩니다. 마스터에 장애가 발생하면 Sentinel과 유사하게 복제본이 자동으로 승격되지만, 이 과정은 해당 샤드에만 국한됩니다.
가용성 모델 비교
Redis Sentinel이 제공하는 것:
- 한 번에 하나의 활성 마스터
- 단일 노드에 전체 데이터셋 저장
- 자동 페일오버
Redis Cluster가 제공하는 것:
- 복수의 마스터 노드
- 노드 간 분산된 데이터
- 샤드 단위의 페일오버
즉, Sentinel은 노드 장애로부터 시스템을 보호하고, Cluster는 노드 장애와 용량 한계 양쪽 모두로부터 보호합니다.
확장 특성의 차이
Redis Sentinel은 수직적(scale-up) 확장 방식입니다. 더 큰 서버로 이전하거나 메모리를 추가하고 빠른 CPU를 탑재할 수 있지만, 결국 물리적 한계에 부딪힙니다.
반면 Redis Cluster는 수평적(scale-out) 확장 방식입니다. 노드를 추가할 때마다 메모리와 처리량이 함께 늘어나며, 각 노드는 데이터셋의 일부만 처리하면 됩니다. 단일 Redis 노드로 더 이상 감당하기 어려운 시점이 오면, Sentinel만으로는 해결이 불가능합니다.
애플리케이션 설계에 미치는 영향
Redis Sentinel은 애플리케이션에 거의 투명합니다. 애플리케이션은 여전히 하나의 Redis 인스턴스와 통신한다고 인식하며, 페일오버 발생 시 클라이언트가 새 마스터로 재연결됩니다.
반면 Redis Cluster는 클러스터 인식(cluster-aware) 클라이언트를 필수로 요구합니다. 애플리케이션은 다음 사항을 직접 처리해야 합니다.
- MOVED/ASK 등 리디렉션 응답 처리
- 해시 슬롯 경계 준수
- 지원되지 않는 멀티 키 연산 회피
따라서 Cluster 도입은 키 설계와 데이터 모델링 전반에 상당한 영향을 미칩니다.
멀티 키 연산과 트랜잭션의 차이
Redis Sentinel 환경에서는:
- 모든 키가 하나의 마스터에 존재
- MGET, SUNION 등 멀티 키 연산이 정상 동작
- 트랜잭션(MULTI/EXEC)과 Lua 스크립트가 기대대로 작동
Redis Cluster 환경에서는:
- 키가 서로 다른 노드에 분산될 수 있음
- 멀티 키 연산은 같은 해시 슬롯에 속한 키에 한해서만 가능
- 크로스 슬롯(cross-slot) 연산은 실패 처리
이 단 하나의 차이가 Redis Cluster로 전환하는 개발팀에게 가장 큰 장벽으로 작용하는 경우가 많습니다.
운영 복잡도 비교
Redis Sentinel은 중간 수준의 운영 복잡도를 가집니다. 관리 대상은 마스터·복제본 구성, Sentinel 쿼럼 설정, 페일오버 동작 정도입니다.
반면 Redis Cluster는 훨씬 높은 운영 난이도를 요구합니다.
- 복수의 마스터와 복제본 관리
- 슬롯 할당 및 리밸런싱
- 리샤딩(resharding) 작업 수행
- 클라이언트 호환성 검증
결국 Cluster는 더 강력한 운영 역량과 규율을 요구하는 선택입니다.
Redis Sentinel이 적합한 경우
다음 조건에 해당한다면 Sentinel이 좋은 선택입니다.
- 데이터셋이 한 대의 머신에 여유 있게 들어가는 경우
- 쓰기 처리량이 단일 코어 범위 내에 있는 경우
- 고가용성 확보가 주된 목표인 경우
- 애플리케이션 로직이 멀티 키 연산에 의존하는 경우
실제로 많은 시스템이 Sentinel만으로 수년간 안정적으로 운영되고 있습니다.
Redis Cluster가 적합한 경우
다음 조건에 해당한다면 Cluster가 적합합니다.
- 메모리 요구량이 단일 노드 용량을 초과하는 경우
- 처리량 요구가 지속적으로 증가하는 경우
- 수평 확장이 필수적인 경우
- 샤딩을 고려한 데이터 설계가 가능한 경우
Cluster는 단순한 페일오버 메커니즘이 아니라 확장 전략이라는 점을 기억해야 합니다.
흔히 저지르는 마이그레이션 실수
많은 팀이 다음과 같은 실수를 반복합니다.
- 필요 이상으로 이른 시점에 Cluster 도입
- Sentinel과 Cluster를 상호 교체 가능한 기술로 오해
- 키 설계에 미치는 영향 간과
- 멀티 키 연산 제약을 너무 늦게 발견
이런 실수들은 대개 일정에 쫓기는 성급한 리팩토링으로 이어지므로, 사전에 충분한 검토가 필요합니다.
간단한 의사결정 기준
선택 기준을 단순화하면 다음과 같습니다.
- Redis Sentinel: 데이터 모델을 변경하지 않으면서 고가용성만 확보하고 싶을 때
- Redis Cluster: Redis를 한 대의 머신을 넘어 확장해야 할 때
Cluster를 선택하기로 했다면, 당장 활성화하지 않더라도 초기 설계 단계부터 샤딩 가능한 키 구조를 염두에 두는 것이 현명합니다.
마무리 요약
Redis Sentinel과 Redis Cluster는 서로 다른 시스템 요구에 대응하는 상호 보완적인 기술입니다. Sentinel은 단일 데이터셋의 서비스 연속성을 보장하고, Cluster는 Redis가 여러 머신에 걸쳐 확장될 수 있는 길을 열어줍니다. 올바른 선택은 궁극적으로 지금 시스템의 우선순위가 '가용성'인지 '확장성'인지에 달려 있습니다. 두 기술의 목적을 정확히 이해하고 있다면, 불필요한 재설계 없이 Redis 인프라를 안정적으로 성장시킬 수 있을 것입니다.