Redis Sentinel 정리, Master 장애를 자동으로 복구하는 구조 이해하기 (1)

 

Redis를 사용하다 보면 처음에는 대부분 단일 Redis로 시작한다.

캐시를 저장하거나, 세션을 관리하거나, 임시 데이터를 빠르게 조회할 때 Redis 한 대만 있어도 충분한 경우가 많다.

구조도 단순하다.

App Server -> Redis Master

 

애플리케이션 서버는 Redis Master에 요청을 보내고, Redis는 메모리에 있는 데이터를 빠르게 읽고 쓴다.

처음에는 이 구조가 가장 편하다.
설정도 단순하고, 운영도 어렵지 않다.

그런데 운영 환경에서 Redis를 계속 사용하다 보면 한 가지 문제가 생긴다.

Redis Master가 죽으면 어떻게 하지?

단순 캐시라면 DB에서 다시 조회하면 된다고 생각할 수 있다.
하지만 Redis를 세션, 인증 토큰, 접속 상태, 실시간 상태값 같은 곳에 사용하고 있다면 이야기가 달라진다.

Redis 한 대가 죽었을 때 서비스 일부가 바로 영향을 받을 수 있다.

이런 상황에서 Redis의 고가용성을 위해 사용할 수 있는 구조가 Redis Sentinel이다.

Redis Sentinel은 왜 필요할까?

Redis Master 한 대만 사용하는 구조를 다시 보자.

App Server -> Redis Master

 

이 구조에서 Redis Master가 죽으면 애플리케이션은 더 이상 Redis에 정상적으로 접근할 수 없다.

App Server -> Redis Master 장애

 

그래서 보통 Redis Master에 Replica를 붙인다.

Redis Master
   |
Redis Replica

 

Replica는 Master의 데이터를 복제한다.

Master에 쓰기 요청이 들어오면, 그 데이터가 Replica로 복제된다.

이렇게 하면 Master에 문제가 생겼을 때 Replica에 데이터가 어느 정도 남아 있을 수 있다.

하지만 여기서 끝이 아니다.

Master가 죽었을 때 Replica가 자동으로 Master가 되지 않는다면, 운영자가 직접 장애를 확인하고 수동으로 전환해야 한다.

예를 들면 이런 흐름이다.

1. Redis Master 장애 발생
2. 운영자가 장애 확인
3. Replica를 새로운 Master로 승격
4. 애플리케이션 Redis 접속 정보 변경
5. 서비스 복구

 

이 과정은 번거롭고, 장애가 새벽에 발생할 수도 있고, 운영자가 바로 확인하지 못할 수도 있다.
그리고 수동으로 전환하는 과정에서 실수할 가능성도 있다.

그래서 Redis는 이런 장애 감지와 자동 전환을 위해 Sentinel이라는 구조를 제공한다.

Redis Sentinel이 하는 일

Redis Sentinel은 Redis 데이터를 저장하는 서버가 아니다.

Sentinel은 Redis Master와 Replica를 감시하고, 장애가 발생했을 때 자동으로 Replica를 Master로 승격하는 역할을 한다.

구조는 대략 이렇다.

App Server
   |
Redis Master
   |
Redis Replica

Sentinel 1
Sentinel 2
Sentinel 3

 

Sentinel은 Redis Master가 살아 있는지 계속 확인한다.

만약 Master가 일정 시간 동안 응답하지 않으면 Sentinel은 장애로 판단한다.

그리고 여러 Sentinel이 장애라고 판단하면, Replica 중 하나를 새로운 Master로 승격한다.

즉 Redis Sentinel의 역할은 크게 세 가지로 볼 수 있다.

1. Monitoring
2. Notification
3. Automatic Failover

 

1. Monitoring

Sentinel은 Redis Master와 Replica를 계속 감시한다.

주기적으로 ping을 보내면서 Redis 서버가 정상인지 확인한다.

Sentinel -> Redis Master: 살아있어?
Redis Master -> Sentinel: 응답

 

Redis Master가 정상이라면 응답을 한다.

하지만 일정 시간 동안 응답하지 않으면 Sentinel은 Master에 문제가 있다고 판단한다.

여기서 바로 장애 조치가 일어나는 것은 아니다.

Sentinel 하나만 Master를 장애라고 판단했다고 해서 바로 Failover를 하면 위험할 수 있다.

예를 들어 특정 Sentinel과 Master 사이의 네트워크만 잠깐 끊겼을 수도 있다.

그래서 Sentinel은 여러 개를 두고, 여러 Sentinel이 함께 판단하도록 구성한다.

SDOWN과 ODOWN

Redis Sentinel을 보다 보면 SDOWN, ODOWN이라는 개념이 나온다.

처음 보면 조금 낯설지만 어렵게 볼 필요는 없다.

SDOWN은 Subjective Down이다.

하나의 Sentinel이 봤을 때 Redis Master가 죽은 것 같다고 판단한 상태다.

SDOWN = 한 Sentinel이 보기에 장애로 판단한 상태

 

예를 들어 Sentinel 1이 Master에 ping을 보냈는데 응답이 없다고 해보자.

그러면 Sentinel 1은 Master를 SDOWN 상태로 볼 수 있다.

하지만 Sentinel 1만 그렇게 판단한 것일 수도 있다.

그래서 여러 Sentinel의 판단이 필요하다.

ODOWN은 Objective Down이다.

여러 Sentinel이 Master 장애에 동의한 상태다.

ODOWN = 여러 Sentinel이 동의한 장애 상태

 

즉 SDOWN은 “내가 보기엔 죽은 것 같다”에 가깝고,
ODOWN은 “여러 Sentinel이 봐도 장애가 맞다”에 가깝다.

이후 ODOWN 상태가 되면 Failover 과정이 진행될 수 있다.

2. Notification

Sentinel은 Redis 상태 변화를 감지하고 알릴 수 있다.

예를 들어 이런 이벤트들이 발생할 수 있다.

Master Down
Failover Start
Replica Promoted
New Master Selected

 

운영 환경에서는 이런 이벤트를 로그로 남기거나, 모니터링 시스템과 연결해서 확인할 수 있다.

물론 단순히 로컬 테스트를 할 때는 Notification까지 깊게 보지 않아도 된다.

하지만 운영 환경에서는 Redis Master가 바뀌는 순간을 확인하는 것이 중요하다.

애플리케이션이 정상적으로 새 Master로 붙었는지,
기존 Master가 다시 살아났는지,
Replica 구성이 정상으로 돌아왔는지 확인해야 하기 때문이다.

3. Automatic Failover

Sentinel의 가장 중요한 역할은 자동 장애 조치다.

Master가 죽으면 Sentinel들이 장애를 감지한다.

그리고 Replica 중 하나를 새로운 Master로 승격한다.

예를 들어 이런 구조가 있다고 해보자.

Redis Master A
   |
+-----------+
|           |
Replica B   Replica C

Sentinel 1
Sentinel 2
Sentinel 3

 

여기서 Master A가 죽으면 Sentinel들이 장애를 감지한다.

그리고 Replica B 또는 Replica C 중 하나를 새로운 Master로 선택한다.

Replica B -> New Master
Replica C -> New Master의 Replica로 재구성

 

장애 조치 후에는 이런 구조가 된다.

Redis Master B
   |
Replica C

기존 Master A는 장애 상태

 

나중에 기존 Master A가 다시 살아나면, 보통 새로운 Master의 Replica로 붙게 된다.

즉 Sentinel은 단순히 장애를 감지하는 것에서 끝나지 않고, Redis 구조를 새 Master 기준으로 다시 정리해준다.

Sentinel은 보통 왜 3개를 둘까?

Sentinel은 보통 3개 이상으로 구성한다.

이유는 장애 판단에 과반이 필요하기 때문이다.

Sentinel을 하나만 두면 그 Sentinel 자체가 단일 장애 지점이 될 수 있다.

Sentinel 1개
= Sentinel이 죽으면 장애 판단도 어려움

 

또 Sentinel 하나가 네트워크 문제로 Master에 접근하지 못하는 상황에서, Master가 죽었다고 잘못 판단할 수도 있다.

그래서 보통 Sentinel을 여러 개 둔다.

Sentinel 1
Sentinel 2
Sentinel 3

 

이렇게 3개를 두면 여러 Sentinel의 판단을 바탕으로 장애 여부를 결정할 수 있다.

예를 들어 이런 상황을 생각해볼 수 있다.

Sentinel 1: Master 장애 같음
Sentinel 2: Master 장애 맞음
Sentinel 3: Master 정상처럼 보임

 

이때 2개 이상이 Master 장애라고 판단하면 Failover를 진행할 수 있다.

물론 실제 동작은 quorum, down-after-milliseconds, failover-timeout 같은 설정에 영향을 받는다.

하지만 기본 개념은 여러 Sentinel이 함께 판단해서 잘못된 장애 조치를 줄이는 것이다.

애플리케이션은 어떻게 현재 Master를 찾을까?

Sentinel을 쓰면 Master가 바뀔 수 있다.

처음에는 Redis Master A에 붙어 있었는데, 장애 이후에는 Replica B가 새로운 Master가 될 수 있다.

Before:
Redis Master A

After:
Redis Master B

 

그러면 애플리케이션은 새 Master 주소를 어떻게 알까?

이때 Sentinel을 지원하는 Redis 클라이언트를 사용한다.

애플리케이션은 Sentinel에게 현재 Master가 누구인지 물어본다.

App -> Sentinel: 현재 Master가 누구야?
Sentinel -> App: Redis B가 Master야
App -> Redis B로 연결

 

Go에서는 go-redis의 FailoverClient를 사용할 수 있다.

rdb := redis.NewFailoverClient(&redis.FailoverOptions{
    MasterName: "mymaster",
    SentinelAddrs: []string{
        "sentinel-1:26379",
        "sentinel-2:26379",
        "sentinel-3:26379",
    },
})

 

여기서 중요한 점은 Redis Master 주소를 직접 고정하는 것이 아니라, Sentinel 주소와 Master 이름을 넘긴다는 것이다.

MasterName: mymaster
SentinelAddrs: Sentinel 목록

 

클라이언트는 Sentinel을 통해 현재 Master 정보를 가져오고, 그 Master로 연결한다.

Redis Sentinel은 데이터를 분산하지 않는다

여기서 Redis Cluster와의 차이가 나온다.

Redis Sentinel은 데이터를 여러 Redis 서버에 나눠 저장하지 않는다.

Sentinel 구조에서는 기본적으로 하나의 Master가 쓰기를 담당한다.

App -> Redis Master
          |
       Replica

 

Replica는 Master의 데이터를 복제한다.

하지만 Redis Cluster처럼 여러 Master가 Hash Slot을 나눠 가지는 구조는 아니다.

Redis Cluster는 이런 구조다.

Master A: slot 0 ~ 5460
Master B: slot 5461 ~ 10922
Master C: slot 10923 ~ 16383

 

반면 Sentinel은 이런 구조에 가깝다.

Master 1개
Replica 여러 개
Sentinel 여러 개

 

그래서 Sentinel은 Redis 한 대의 메모리 한계를 해결해주지 않는다.

데이터가 너무 많아서 Redis 한 대에 담기 어렵다면 Sentinel이 아니라 Redis Cluster를 고려해야 한다.

Sentinel이 해결하는 문제는 데이터 분산이 아니라 Master 장애 자동 복구다.

마무리

Redis Sentinel은 Redis의 고가용성을 위한 구조다.

Redis Master와 Replica를 감시하고, Master가 죽으면 Replica를 새로운 Master로 승격한다.

처음에는 Redis Master 하나만 사용해도 충분할 수 있다.

하지만 운영 환경에서는 Redis 장애 상황을 생각해야 한다.

Master가 죽었을 때 사람이 직접 Replica를 승격하고, 애플리케이션 연결 정보를 바꾸는 방식은 부담이 크다.

Sentinel은 이 과정을 자동화해준다.

다만 Sentinel은 Redis Cluster와 다르다.

Sentinel은 데이터를 분산하지 않는다.
Redis Master 장애를 감지하고, Replica를 Master로 승격하는 구조다.

이번 글에서는 Redis Sentinel이 왜 필요한지, 어떤 역할을 하는지 정리했다.

다음 글에서는 Redis Sentinel의 장애 복구 흐름, Redis Cluster와의 차이, 그리고 어떤 상황에서 Sentinel을 선택하면 좋을지 정리해보려고 한다.