Redis 영속성 & Failover 정리 (RDB / AOF / Failover)

 지금까지 Redis 아키텍처까지 정리했습니다.

“Redis는 메모리 저장소인데 서버가 죽으면 데이터는 어떻게 되는가?”

“Redis 장애가 발생하면 서비스는 어떻게 복구되는가?”

 

이번 글에서는

• RDB
• AOF
• Failover

처럼 Redis 운영에서 반드시 알아야 하는 핵심 개념을 정리해 보겠습니다

---

Redis 영속성

Redis는 모든 데이터를 메모리에 저장합니다.

그래서 매우 빠른 대신 서버 장애 시 데이터 유실 가능

이를 방지하고자 Redis는 영속성(Persistence) 기능을 제공합니다

 

여기서 AOF와 RDB에 저장되는 데이터는

 AOF는 레디스 프로토콜 형태로 RDB는 바이너리 형태로 저장되기 때문에 사람이 읽을 수 없습니

---

RDB (Redis Database Snapshot)

RDB는

특정 시점의 메모리 데이터를 파일로 저장하는 방식입니다.

즉,

 

• 스냅숏 기반 저장
• 일정 주기마다 dump.rdb 생성
• RDB는 Command는 저장하지 않고 결과만 저장합니다 

 

동작 방식

메모리 데이터 → 특정 시점 → dump.rdb 저장

 

 

예를 들어 5분마다 1000개 변경 발생 시 처럼 조건 기반으로 RDB에 파일로 데이터를 저장할 수 있습니다 

 

장점

 

• 파일 크기 작음
• 복구 속도 매우 빠름
• 백업 용도로 좋음

 

 

단점

• 마지막 저장 이후 데이터 유실 가능

예를들어 

5분마다 snapshot 이면 최대 5분 데이터 손실이 일어날 수 있습니다 

---

AOF (Append Only File)

AOF는 모든 Write 명령을 로그처럼 기록하는 방식입니다.

특징은 RDB처럼 결과만 저장하는 게 아니라 발생한 Command 모두를 기록합니다 

즉,

SET user:1 donguk
INCR view:1
LPUSH queue job1

이 모든 명령이 파일에 저장됩니다

 

장점

 

• 데이터 유실 최소화
• 거의 실시간 복구 가능

 

 

단점

 

• 파일 크기 증가 (커맨드를 다 저장함으로 )
• 재작성(rewrite) 필요

 

fsync 정책

AOF는 저장 정책을 선택할 수 있습니다.

 

always

• 매 Write마다 디스크 저장
• 매우 안전
• 매우 느림

 

 

everysec

• 1초마다 저장
• 가장 많이 사용

no

• OS에 맡김
• 성능 좋음
• 위험

---

RDB vs AOF 선택

레디스를 캐시로만 사용하면 이 기능이 필요 없을 수 있습니다 

 

만약 백업은 필요하지만 어느 정도 데이터 손실이 발생해도 괜찮은 경우?

• RDB 단독 사용
• redis.conf 파일에서 SAVE 옵션을 적절히 사용
• 예) SAVE 900 1 (900초 동안 1개 이상의 키가 변경되었을 때 RDB 파일을 다시 작성하라)

 

만약 장애 상황 직전까지의 모든 데이터가 보장되어야 할 경우?

• AOF 사용
• APPENDSYNC 옵션이 everysec 인 경우 최대 1초 사이의 데이터 유실 가능 (기본설정)

 

가장 강한 내구성이 필요한 경우 

• RDB & AOF 동시 사용

---

Redis Failover

Failover는 Master Redis가 장애 발생 시 자동으로 Replica를 Master로 승격하는 과정입니다.

 

Master Down 
    ↓ 
Sentinel / Cluster 감지 
    ↓ 
Replica 승격 
    ↓ 
Client 재연결

 

즉, 서비스Redis 구조가 복구됩니다

 

종류

• Coordinator 기반 Failover
• VIP/DNS 기반 Failover
• Redis Cluster의 사용

가 있습니다 이제 각각을 간단하게라도 알아보겠습니다 

---

Coordinator 기반 Failover

 

Coordinaor 란?

실제 일을 하지 않고 여러 서비스 호출 순서 관리, 트랜잭션 흐름 조율, 이벤트 전달 등 흐름을 지휘하는 역할을 합니다 

 

이 Coordinaor 기반 Failover가 어떻게 동작하는지 과정을 알아보면

1. 처음에 redis 1번을 쓰다가 (코디네이터가 어떤 서버로 갈지 알려줌 )
2. 1번레디스가 죽으면 
3. 뒤에 헬스체커가  2번을  primary(master)로 승격 시키고
4. 코디네이터에게 이제 current redis 는 2번이라고 업데이트를 해준다 
5. 그럼 코디네이터가 api server에 현재 어떤 redis 서버를 쓸지 알려준다

 

장점

• Coordinator 기반으로 설정을 관리한다면 동일한 방식으로 관리가 가능
• 해당 기능을 이용하도록 개발이 필요

단점

• 이미 만들어진 다른 설루션 사용이 어려움

---

VIP/DNS 기반 페일오버 

 

VIP는 Virtual Ip로 가상 IP를 말합니다

우리가 AWS에서 Private Subnet에서 쓰는 IP와 비슷한 의미를 가지고 있습니다

 

과정은 다음과 같습니다 

1. API 서버는 VIP 10.0.1.1 로만 접속한다
2. 현재 Master 는 Redis 1번 서버고 VIP 역시 10.0.1.1 이다
3. Redis 1번 서버가 다운되면
4. Redis 2번 서버가 페일오버 되어 Master로 승격되고 
5. VIP(10.0.1.1)는 Redis 1번서버에서 Redis 2번서버로 부여한다
6. API 서버는 내부 동작과 상관없이  VIP 10.0.1.1 로만 접속한다

 

DNS 방식도 똑같다 바뀐 점은 VIP를 DNS로 바꾼 것이다!

 

장점

• 클라이언트에 추가적인 구현이 필요 없다 (클라이언트 코드가 안 바뀜)
• VIP 기반은 외부 서비스를 제공해야 하는 서비스 업자에 유리하다 (예를 들어 클라우드 업체)

단점

• DNS 기반은 사용하는 언어별 DNS 캐싱 정책을 잘아야 한다 
• 툴에 따라서 한번 가져온 DNS 정보를 다시 호출하지 않는 경우도 존재한다 

 

---

마무리

Redis는 빠른 성능을 제공하지만 영속성과 장애 대응 전략을 함께 고려해야 안정적으로 사용할 수 있습니다.

사실 캐시로만 사용하게 되면 영속성 기능은 꺼두는 게 성능상 유리하다 

 

정리하면

 

• RDB → Snapshot 백업
• AOF → Write 로그 기반 복구
• Failover → 자동 장애 대응

이 세 가지 정도다!

 

다음 글에서는 Redis 운영시 위험한 명령어, 메모리 폭발 문제, 모니터링, 권장 설정  등 다루겠습니다