고가용성 Redis 설계 Sentinel과 Cluster

KUN·2025년 7월 1일

Redis

목록 보기

4/6

계기

이전 시간에는 Redis의 마스터-슬레이브 복제 전략에 대해 살펴보았다.
이 구조를 통해 서비스가 중단되지 않고 이어서 처리할 수는 있었지만,
장애 발생 시 슬레이브를 수동으로 마스터로 승격해야 한다는 단점이 있었다.

Redis 공식 문서를 참고해보니,
이러한 한계를 보완하기 위해 Sentinel과 Cluster라는 구조가 제공된다는 것을 확인할 수 있었다.

이번 글에서는 이 두 가지 구조에 대해 자세히 알아보고,
각각이 어떤 상황에서 적합한지 함께 살펴보겠다.

목표

Redis Sentinel의 개념과 역할 이해하기
Redis Cluster의 구조와 특징 살펴보기
Sentinel과 Cluster의 차이점 비교 분석
실습 환경 구축 및 테스트 (선택)

Sentinel ( 공식자료 )

개념

Redis의 고가용성을 지원하기 위한 구성 요소로,
마스터 장애 시 자동으로 복구하고,
클라이언트가 새로운 마스터에 계속 연결할 수 있도록 도와주는 관리 도구이다.

즉, Redis Sentinel은 Redis Cluster를 사용하지 않는 환경에서 고가용성을 보장하는 솔루션이다.

고가용성?
- 서비스가 중단되지 않고 계속 작동하도록 보장하는 시스템 특성이다.

역할

Sentinel이 제공하는 주요 기능은 다음과 같다

미리 요약본
모니터링 - 마스터와 레플리카가 정상 동작하는지 지속적으로 확인한다..
알림 - 장애 발생 시 관리자나 시스템에 알림을 보낸다.
자동 장애 조치 - 마스터가 죽으면 레플리카를 자동으로 승격시킨다.
구성 제공자 - 클라이언트에게 현재 마스터의 주소를 알려준다.

모니터링
  Sentinel은 마스터 및 레플리카 인스턴스들이 정상적으로 작동하는지 지속적으로 점검한다.

알림
  Redis 인스턴스에 문제가 발생하면 Sentinel은 
  시스템 관리자나 외부 프로그램에 API를 통해 이를 통지할 수 있다.

자동 장애 조치
  마스터에 장애가 발생하면 Sentinel이 자동으로 장애 조치를 수행한다.
  이 과정에서 특정 레플리카를 새로운 마스터로 승격시키고, 
  나머지 레플리카들은 새 마스터를 따라가도록 재구성된다.
  이와 동시에, Redis를 사용하는 애플리케이션들에게도 새로운 마스터의 주소가 전달된다.

구성 제공자
  Sentinel은 클라이언트에게 현재 마스터의 주소를 알려주는 서비스 디스커버리 역할도 수행한다.
  클라이언트는 Sentinel에 접속해 현재 유효한 마스터의 정보를 요청하며, 
  장애 발생 시 새로운 마스터 정보도 이 경로를 통해 전달받는다.

Cluster

자료1 : Redis 공식 문서
저료2 : Gitlab

개념

Redis Cluster는 데이터를 샤드 단위로 분산 저장하며,
수평적 확장 및 고가용성을 지원하는 Redis의 분산 구조이다.
데이터 세트를 최대 수천 노드에 걸쳐 나눠 저장하며, 프록시 없이, 비동기 복제 기반으로 작동한다.

샤드? ( shard )
  큰 데이터를 작게 나눈 것을 바로 샤드(shard) 라고 한다.
  그리고 각 조각을 다른 서버(노드)에 나눠서 저장하는 방식이 바로 샤딩(sharding) 이라고 한다.
  
예를 들어, 총 1만명의 회원이 있는 웹 사이트의 데이터를
단일 서버(마스터) 1개에 넣으면 한계가 찾아오는데 이런 부분을 분산하게 끔 한다.
(메이플에서 하나의 서버 안에 여러 채널이 존재해 유저들을 분산시키는 구조와 유사하다.)

구조

기존 방식 : 마스터 1개에 슬레이브 여러개
Cluster 방식 : 마스터 여러개 슬레이브 어러개

특징

장점

					샤딩
데이터를 16,384 슬롯으로 나누어 여러 마스터에 분산 저장함으로써 대용량 처리가 가능하다.

					수평 확장  
노드를 추가하는 것만으로 성능과 저장 용량을 자연스럽게 확장할 수 있다.

					자동 장애 복구
마스터 노드 장애 시 슬레이브가 자동으로 승격되어 서비스를 지속할 수 있다.

					프록시 없는 라우팅
별도의 프록시 없이 클러스터 자체가 클라이언트 요청을 올바른 노드로 전달한다.

					분산 장애 감지
노드 간 상태 정보를 주기적으로 교환하며 다수 합의로 장애를 감지한다.

					내장 고가용성
Sentinel 없이도 클러스터만으로 장애 감지와 복구를 자체 수행할 수 있다.

단점

					멀티 키 명령 제한
서로 다른 슬롯에 위치한 키들에 대해 MGET, MSET 등 다중 키 명령을 사용할 수 없다.

					비동기 복제
마스터와 슬레이브 간의 복제가 실시간이 아니기 때문에, 장애 시 데이터 유실 가능성이 존재한다.

					운영 복잡성
클러스터 구성, 재조정, 장애 복구 절차 등이 Sentinel보다 복잡하고 어렵다.

					클라이언트 제약
클러스터의 리다이렉션 응답(-MOVED, -ASK)을 처리할 수 있는 클러스터 호환 클라이언트를 사용해야 한다.

차이점 비교 분석

구조적 차이
Sentinel: 하나의 마스터와 여러 슬레이브로 구성된 단일 인스턴스 구조
Cluster: 여러 마스터(샤드)와 각 마스터마다 복제본이 있는 분산 구조
고가용성 처리 방식
Sentinel: 외부 프로세스(Sentinel 노드)가 마스터를 감시하고 슬레이브를 승격
Cluster: 클러스터 내부 노드들이 직접 장애 감지 및 자동 failover 수행
데이터 저장 방식
Sentinel: 모든 데이터가 마스터에 집중되어 있음 (복제만 가능)
Cluster: 데이터를 슬롯 단위로 샤딩하여 여러 마스터에 분산 저장
확장성
Sentinel: 수직 확장만 가능 (스케일 업), 수평 확장은 불가능
Cluster: 마스터 노드를 추가해 수평 확장(스케일 아웃) 가능
적용 적합성
Sentinel: 데이터가 작고, 단순한 고가용성만 필요한 경우 적합
Cluster: 데이터 양이 크고, 고성능 분산 처리가 필요한 경우 적합

즉 정리하면?

Sentinel은 단일 Redis 인스턴스를 안정적으로 운영하기 위한 고가용성 솔루션이고,
Cluster는 대용량 데이터를 분산 저장하고 자동 장애 복구까지 포함한 고성능 확장형 구조이다.

실습환경 구축

Sentinel ( Tistory. 개발놀이터 )

위 블로그의 방법대로 따라해봤다. ( 만든 환경은 여기서 설명하지 않겠다. )

잘 구축되었고 성공적으로 실행이 되고 있다.
실제로 마스터를 다운하고 [ 리더선출 ] 투표를 통해 진행 되는 과정을 보겠다.

( 마찬가지로 sentinel3 ) 도 있으나 패스

최종 Slave 1 마스터로 승격되었음을 확인했다.

( 실제로는 이거 한번 보기위해 6시간 걸렸다. - 알수없는 오류로 인해... )

또 궁금하지 않은가? 마스터로 승격된 슬레이브에서
만약, 다시 마스터가 부활 한다면?

마스터가 슬레이브가 되는 걸 확인할 수 있다.

마무리

이번 글에서는 Redis Sentinel과 Cluster의 구조, 특징, 그리고 차이점까지 실제 실습과 함께 정리해보았다.

특히 Sentinel 실습을 통해 장애 상황에서도 자동으로 레플리카가 마스터로 승격되는 과정을 직접 확인할 수 있었고,
이를 통해 단순히 개념을 아는 것보다 직접 경험하는 것이 훨씬 더 확실한 이해로 이어진다는 걸 깨달았다.

반면 Redis Cluster는 이미 구조적인 다이어그램만 보아도 어떻게 데이터가 분산되고 고가용성이 확보되는지 한눈에 들어온다.
구축 난이도나 운영 복잡도를 고려했을 때, 실습까지는 하지 않아도 전체 흐름을 충분히 이해할 수 있었다.

리더 선출 문제

이전 DB 락 전략에서 리더 선출 문제를 잠시 다뤘다.

리더를 하나 뽑는 건 말로 하면 쉬운데, 분산 시스템에서는 다음과 같은 제약이 있다.
1. 누가 살아 있고 죽었는지 모른다.
2. 메시지가 늦게 도착함
3. 동시에 여러 노드가 "내가 리더야!" 라고 주장할 수 있다.
4. 네트워크가 갈라질 수도 있음

이런 불확실한 상황에서도 단 하나의 리더만을 정확하게 뽑아야 하는 문제다.

=================이해가 안된다면 비유를 거쳐보자 ====================
팀에 5명이 있는데, 서로 얼굴도 모른 채 팀장을 뽑아야 한다.

1. 누가 연락 가능한 상태인지도 모르고
2. 누군가가 늦게 답장할 수도 있으며
3. 한 명 이상이 동시에 내가 팀장 할게라고 말할 수도 있고
4. 어떤 사람들은 서로 연결조차 안 될 수도 있다.
이런 혼란스러운 조건 속에서도, 팀장은 반드시 1명만 뽑혀야 한다.

우리가 흔히 쓰는 Redis 가 Eventual Leader Election 개념을 사용한다.

Eventual Leader Election ?

리더가 사라진 상황에서,  
시스템이 즉시 결론을 내리진 못하더라도  
충분한 시간이 지나면 결국 단 하나의 리더가 선출되는 방식이다.
( 장점 : 단 하나의 리더를 보장 받는다. )
( 단점 : 시간이 오래 걸린다. )