[🔴Redis Master/Slave + Redis Sentinel 구성] 초보자도 쉽게 이해하기 !!

 

 

Redis를 운영하다 보면 다음과 같은 권장사항을 자주 접하게 됩니다.

“Redis Master/Slave + Redis Sentinel 구성을 권장합니다.”

처음 보면 이런 궁금증이 생깁니다.

• Master와 Slave는 무엇일까?
• Sentinel은 또 다른 Redis 서버일까?
• Master/Slave와 Sentinel은 어떤 차이가 있을까?
• Sentinel을 꼭 설치해야 할까?

이번 글에서는 Redis를 처음 접하는 분도 이해할 수 있도록 차근차근 설명해 보겠습니다. 😊

---

1. Redis란 무엇인가요? 🤔

Redis는 데이터를 메모리에 저장하는 빠른 데이터 저장소입니다.

일반적인 데이터베이스는 데이터를 디스크에 저장하지만, Redis는 주로 메모리를 사용하기 때문에 데이터 조회와 처리 속도가 매우 빠릅니다.

Redis는 다음과 같은 용도로 많이 사용됩니다.

• 로그인 세션 관리
• 인증번호 임시 저장
• 캐시 데이터 저장
• 실시간 순위 관리
• 장바구니 정보 저장
• 메시지 및 작업 대기열 관리
• API 응답 속도 개선

하지만 Redis 서버를 한 대만 운영하면 문제가 생길 수 있습니다.

사용자 → 애플리케이션 → Redis 서버 1대

Redis 서버가 장애로 중단되면 애플리케이션에서도 Redis 데이터를 사용할 수 없게 됩니다.

이를 방지하기 위해 사용하는 것이 바로 Master/Slave 복제 구성입니다.

---

2. Redis Master/Slave란? 🖥️

Redis Master/Slave는 하나의 Redis 데이터를 다른 Redis 서버에 복제하는 구성입니다.

최근 Redis에서는 Master/Slave 대신 다음 용어를 권장합니다.

• Master → Primary
• Slave → Replica

기존 문서나 시스템에서는 아직 Master/Slave라는 표현을 많이 사용하므로 두 용어를 함께 알아두면 좋습니다.

Master(Primary)
   │
   ├── 데이터 복제 → Slave 1(Replica)
   └── 데이터 복제 → Slave 2(Replica)

Master에서 데이터가 변경되면 해당 내용이 Slave로 복제됩니다.

예를 들어 Master에 다음 정보가 저장되었다고 가정해 보겠습니다.

사용자 ID: user01
로그인 상태: 로그인 완료

이 데이터는 Slave에도 복제됩니다. 따라서 Master에 장애가 발생해도 Slave에는 복제된 데이터가 남아 있을 수 있습니다.

---

3. Master와 Slave의 역할은 무엇인가요? 📌

Master의 역할

Master는 Redis 구성에서 중심 역할을 담당합니다.

• 데이터 쓰기
• 데이터 읽기
• Slave로 데이터 복제
• 애플리케이션 요청 처리

애플리케이션에서 데이터를 추가하거나 수정할 때는 일반적으로 Master에 요청합니다.

애플리케이션 → Master → 데이터 저장

Slave의 역할

Slave는 Master의 데이터를 복제해 보관합니다.

• Master 데이터 복제
• 데이터 백업 역할
• 읽기 요청 분산
• Master 장애 시 대체 서버 후보

일반적으로 Slave는 읽기 전용으로 사용합니다.

쓰기 요청 → Master
읽기 요청 → Master 또는 Slave

읽기 요청이 많은 서비스에서는 Slave를 활용해 Master의 부하를 줄일 수도 있습니다.

---

4. Master/Slave만 구성하면 안전할까요? ⚠️

데이터 복제 측면에서는 Redis 서버 한 대만 운영하는 것보다 안전합니다.

하지만 Master/Slave 구성만으로는 완전한 자동 장애조치가 되지 않습니다.

예를 들어 기존 Master에 장애가 발생했다고 가정해 보겠습니다.

Master ❌ 장애 발생
   │
   ├── Slave 1 정상
   └── Slave 2 정상

Slave에 데이터가 남아 있어도 다음 작업이 필요합니다.

1. 관리자가 Master 장애를 확인합니다.
2. 어떤 Slave를 새로운 Master로 사용할지 선택합니다.
3. 선택한 Slave를 Master로 승격합니다.
4. 나머지 Slave를 새로운 Master에 연결합니다.
5. 애플리케이션이 새로운 Master에 접속하도록 변경합니다.

즉, 데이터는 복제되어 있지만 장애 발생 시 사람이 직접 조치해야 할 수 있습니다.

이 문제를 해결하기 위해 사용하는 것이 Redis Sentinel입니다.

---

5. Redis Sentinel이란? 👀

Sentinel은 영어로 감시자 또는 보초라는 뜻입니다.

Redis Sentinel도 이름 그대로 Redis 서버의 상태를 감시합니다.

중요한 점은 Sentinel이 실제 Redis 데이터를 저장하는 서버는 아니라는 것입니다.

Sentinel은 다음과 같은 관리 역할을 담당합니다.

• Master 상태 감시
• Slave 상태 감시
• Master 장애 여부 판단
• Slave를 새로운 Master로 자동 승격
• 나머지 Slave의 복제 대상 변경
• 애플리케이션에 현재 Master 정보 제공
• 장애 및 구성 변경 알림

쉽게 비유하면 다음과 같습니다.

• Master: 실제 업무를 처리하는 팀장
• Slave: 팀장의 업무를 공유받는 팀원
• Sentinel: 팀장과 팀원의 상태를 확인하는 관리자

팀장에게 문제가 생기면 Sentinel이 정상적인 팀원 한 명을 새로운 팀장으로 지정하는 것입니다.

---

6. Sentinel은 장애를 어떻게 처리할까요? 🔄

정상적인 Redis 구성은 다음과 같습니다.

Master A
 ├── Slave B
 └── Slave C

Sentinel은 Master A와 Slave B, C의 상태를 계속 확인합니다.

1단계: Master 장애 감지

Sentinel이 Master에 주기적으로 신호를 보내 정상 응답 여부를 확인합니다.

Sentinel → Master A: 정상인가요?
Master A → Sentinel: 정상입니다.

Master가 일정 시간 동안 응답하지 않으면 Sentinel은 장애 가능성이 있다고 판단합니다.

Sentinel → Master A: 정상인가요?
Master A → 응답 없음

2단계: Sentinel끼리 장애 여부 확인

Sentinel을 여러 대 구성한 경우, Sentinel들은 서로 의견을 확인합니다.

Sentinel 한 대만 장애라고 판단했다고 바로 Master를 변경하는 것은 아닙니다. 여러 Sentinel이 Master 장애에 동의해야 실제 장애로 판단합니다.

이를 통해 일시적인 네트워크 지연이나 Sentinel 한 대의 오판으로 Master가 불필요하게 변경되는 것을 줄일 수 있습니다.

3단계: 새로운 Master 선정

Master 장애가 확정되면 정상적인 Slave 중 하나를 선택합니다.

Master A ❌
Slave B ✅
Slave C ✅

Sentinel은 Slave B 또는 Slave C 중 적절한 서버를 새로운 Master로 선정합니다.

4단계: Slave를 Master로 승격

예를 들어 Slave B가 선택되었다면 다음과 같이 변경됩니다.

기존 Master A ❌

새로운 Master B ✅
   └── Slave C

이 과정을 Failover, 즉 장애조치라고 합니다.

5단계: 복제 구조 변경

Sentinel은 나머지 Slave들이 새로운 Master를 복제하도록 설정을 변경합니다.

새로운 Master B
   └── Slave C

기존 Master A가 복구되면 일반적으로 새로운 Master의 Slave로 다시 연결될 수 있습니다.

---

7. Sentinel은 왜 3대를 권장할까요? 🗳️

Sentinel은 일반적으로 3대 이상, 가능하면 홀수로 구성하는 것을 권장합니다.

Sentinel 1
Sentinel 2
Sentinel 3

그 이유는 장애 여부를 여러 Sentinel의 판단으로 결정하기 때문입니다.

예를 들어 Sentinel 한 대가 네트워크 문제로 Master에 접속하지 못했다고 가정해 보겠습니다.

Sentinel 1: Master가 장애인 것 같습니다.
Sentinel 2: Master는 정상입니다.
Sentinel 3: Master는 정상입니다.

이 경우 Master 자체의 장애가 아니라 Sentinel 1의 네트워크 문제일 가능성이 있습니다.

반대로 여러 Sentinel이 장애라고 판단하면 실제 장애일 가능성이 높습니다.

Sentinel 1: Master 장애
Sentinel 2: Master 장애
Sentinel 3: Master 장애

이처럼 다수결 판단을 통해 잘못된 장애조치 가능성을 줄일 수 있습니다.

따라서 다음 구성이 많이 사용됩니다.

Redis Master 1대
Redis Slave 2대
Redis Sentinel 3대

단, Sentinel 3개를 동일한 서버 한 대에 모두 실행하면 해당 서버 장애 시 Sentinel도 함께 중단됩니다.

가능하면 서로 다른 서버나 장애 영역에 분산해 배치해야 합니다.

---

8. Master/Slave와 Sentinel의 차이점 📊

구분Master/SlaveRedis Sentinel

주요 목적	데이터 복제	상태 감시 및 자동 장애조치
데이터 저장	저장함	저장하지 않음
Master 장애 감지	기본 구성만으로는 부족	자동 감지
Slave의 Master 승격	수동 처리 필요	자동 승격
복제 구조 변경	수동 처리 가능성 있음	자동 변경
현재 Master 확인	별도 관리 필요	Sentinel이 정보 제공
읽기 부하 분산	가능	직접 처리하지 않음
단독 사용	가능	Master/Slave와 함께 사용
고가용성	제한적	고가용성 지원

여기서 중요한 점은 Master/Slave와 Sentinel이 서로 경쟁하거나 대체하는 기술이 아니라는 것입니다.

두 가지는 담당하는 역할이 다릅니다.

Master/Slave = 데이터 복제
Sentinel = 감시 및 자동 장애조치

---

9. 권장 구성은 어떻게 되나요? 🏗️

일반적인 권장 구성은 다음과 같습니다.

Redis Master 1대
Redis Slave 2대
Redis Sentinel 3대

전체 구조를 표현하면 다음과 같습니다.

             Sentinel 1
             Sentinel 2
             Sentinel 3
                  │
          Redis 상태 감시
                  │
                  ▼
           Master Redis
             │       │
             ▼       ▼
          Slave 1  Slave 2

이 구성에서는 다음과 같이 역할을 나눕니다.

• Master: 데이터 읽기·쓰기 처리
• Slave: Master 데이터 복제
• Sentinel: 장애 감시 및 자동 Failover 처리
• 애플리케이션: Sentinel을 통해 현재 Master 정보 확인

---

10. 애플리케이션은 Redis에 어떻게 접속할까요? 🔌

Sentinel을 사용하면 애플리케이션이 특정 Master IP 주소에만 고정 접속하지 않도록 구성해야 합니다.

예를 들어 애플리케이션이 기존 Master IP에 직접 연결되어 있다고 가정해 보겠습니다.

애플리케이션 → 192.168.0.10:6379

Sentinel이 새로운 Master를 승격해도 애플리케이션이 계속 기존 IP에 접속하면 서비스가 정상화되지 않을 수 있습니다.

Sentinel을 지원하는 Redis 클라이언트는 Sentinel에 다음과 같이 문의합니다.

애플리케이션 → Sentinel
“현재 Master가 누구인가요?”

Sentinel → 애플리케이션
“현재 Master는 192.168.0.11입니다.”

애플리케이션은 전달받은 현재 Master 주소로 접속합니다.

따라서 Sentinel을 도입할 때는 애플리케이션에서 사용하는 Redis 클라이언트가 Sentinel 연결 방식을 지원하는지도 확인해야 합니다.

---

11. Sentinel이 있으면 데이터가 절대 유실되지 않을까요? 🚨

그렇지는 않습니다.

Redis 복제는 일반적으로 비동기 방식으로 동작합니다.

Master에 데이터가 저장된 직후 Slave로 복제되기 전에 Master가 장애 나면, 최신 데이터 일부가 Slave에 전달되지 않았을 수 있습니다.

1. 애플리케이션이 Master에 데이터 저장
2. Master가 애플리케이션에 저장 완료 응답
3. Slave로 복제되기 전 Master 장애
4. 최신 데이터 일부가 Slave에 없음

Sentinel은 장애를 감지하고 Slave를 새로운 Master로 승격할 수 있지만, 복제되지 않은 데이터까지 복원해 주는 것은 아닙니다.

따라서 Sentinel은 다음 기능을 제공한다고 이해해야 합니다.

서비스 중단 시간을 줄이기 위한 자동 장애조치 기능

Sentinel이 백업을 대신하거나 데이터 유실을 완전히 방지해 주는 것은 아닙니다.

중요한 데이터라면 다음 항목도 함께 검토해야 합니다.

• Redis 영속성 설정
• RDB 스냅샷
• AOF 로그
• 정기 백업
• 복구 테스트
• 복제 지연 모니터링

---

12. Sentinel과 Redis Cluster는 같은 것일까요? 🧩

Sentinel과 Redis Cluster는 목적이 다릅니다.

구분Redis SentinelRedis Cluster

핵심 목적	고가용성 및 자동 장애조치	데이터 분산과 고가용성
데이터 분산 저장	지원하지 않음	지원함
샤딩	지원하지 않음	지원함
자동 Failover	지원	지원
구성 복잡도	비교적 단순	상대적으로 복잡
적합한 환경	데이터가 한 Master에 수용 가능	데이터가 크거나 처리량이 매우 많은 환경

Sentinel 구성에서는 Master의 전체 데이터가 Slave에 그대로 복제됩니다.

반면 Redis Cluster는 데이터를 여러 Master에 나누어 저장합니다. 이를 샤딩이라고 합니다.

Sentinel 구성
Master 전체 데이터 → Slave에 복제

Cluster 구성
데이터 A → Master 1
데이터 B → Master 2
데이터 C → Master 3

데이터 크기가 크지 않고 자동 장애조치가 주요 목적이라면 Sentinel 구성을 고려할 수 있습니다.

데이터 용량과 처리량이 매우 크고 여러 Redis 서버에 데이터를 나눠야 한다면 Redis Cluster가 더 적합할 수 있습니다.

---

13. 운영할 때 꼭 확인해야 할 사항 ✅

Sentinel을 서로 다른 서버에 배치하기

Sentinel 3개를 같은 서버에 설치하면 서버 한 대의 장애로 Sentinel 전체가 중단될 수 있습니다.

가능하면 서로 다른 서버, 가상머신 또는 장애 영역에 분산해야 합니다.

애플리케이션의 Sentinel 지원 확인하기

Sentinel이 새로운 Master를 선정해도 애플리케이션이 기존 Master IP만 바라보면 자동 복구가 제대로 이루어지지 않습니다.

복제 지연 확인하기

Master와 Slave 사이에 복제 지연이 크면 장애조치 과정에서 최신 데이터가 누락될 가능성이 커집니다.

백업을 별도로 구성하기

Slave는 백업 파일과 동일하지 않습니다.

Master의 데이터가 실수로 삭제되면 삭제 작업도 Slave로 복제될 수 있습니다. 따라서 RDB, AOF 및 외부 백업 정책이 필요합니다.

장애조치 테스트하기

구성만 완료하고 끝내면 안 됩니다.

실제로 Master Redis를 중단했을 때 다음 항목을 확인해야 합니다.

• Sentinel이 장애를 정상적으로 감지하는지
• Slave가 새로운 Master로 승격되는지
• 애플리케이션이 새로운 Master로 재접속하는지
• 데이터 손실이 어느 정도 발생하는지
• 서비스 복구에 얼마나 걸리는지

---

마무리 🎯

Redis Master/Slave와 Redis Sentinel의 역할은 다음 한 문장으로 정리할 수 있습니다.

Master/Slave는 데이터를 복제하고, Sentinel은 Redis를 감시해 장애 발생 시 Slave를 새로운 Master로 자동 승격합니다.

따라서 “Redis Master/Slave + Redis Sentinel 구성 권장”이라는 문구는 단순히 데이터를 복제하라는 의미가 아닙니다.

Master 장애가 발생했을 때 관리자가 직접 복구하지 않아도 되도록 다음 구조를 구성하라는 뜻입니다.

데이터 복제
Master + Slave

자동 장애조치
Sentinel

최종 구성
Master + Slave + Sentinel

다만 Sentinel은 백업 솔루션이 아니며, 데이터 유실을 완전히 방지하는 기능도 아닙니다.

안정적인 Redis 운영을 위해서는 다음 항목을 함께 준비하는 것이 좋습니다.

• Master/Slave 복제
• Sentinel 자동 장애조치
• RDB 또는 AOF 영속성 설정
• 정기 백업
• 장애조치 테스트
• 복제 지연 및 Redis 상태 모니터링

이렇게 구성하면 Redis 서버 한 대의 장애가 전체 서비스 중단으로 이어지는 위험을 크게 줄일 수 있습니다.