영속성과 백업 설계

Redis는 메모리에서 빠르게 동작한다. 그래서 많은 사람이 Redis 데이터를 일시적인 것으로 생각한다. 캐시라면 맞는 말이다. 원본 DB에서 다시 만들 수 있는 데이터라면 Redis가 비어도 서비스는 복구될 수 있다.

하지만 Redis에 세션, 큐, 랭킹, 이벤트 로그, 임시 주문 상태를 저장하기 시작하면 이야기가 달라진다. 이때 Redis 장애는 단순 캐시 미스가 아니라 데이터 손실이 될 수 있다. 영속성 persistence은 Redis 데이터를 디스크에 남겨 재시작 후 다시 읽을 수 있게 하는 기능이다. 핵심 질문은 하나다.

Redis 데이터를 어느 시점까지 반드시 되살려야 하는가?

AI 생성 이미지

먼저 정할 것: 얼마나 잃어도 되는가

영속성 설정을 보기 전에 데이터별 손실 허용 범위를 정해야 한다. 모든 데이터를 같은 수준으로 보호하려고 하면 성능과 운영 비용이 커진다. 반대로 Redis가 빠르다는 이유만으로 아무 보호도 하지 않으면 장애 때 예상보다 큰 손실을 만난다.

운영에서는 보통 두 가지 기준을 사용한다.

• RPO Recovery Point Objective: 장애가 났을 때 최대 어느 정도의 데이터 손실을 허용할 것인가

• RTO Recovery Time Objective: 장애 후 어느 시간 안에 서비스를 복구해야 하는가

예를 들어 상품 상세 캐시는 몇 분치가 사라져도 DB에서 다시 채우면 된다. 이 데이터는 RPO가 느슨하다. 반면 결제 완료 이벤트를 Redis Stream에만 저장하고 있다면 몇 초 손실도 문제가 될 수 있다. 이 경우 Redis만 믿기보다 원본 DB, outbox, 별도 메시지 브로커까지 함께 설계해야 한다.

Redis 영속성은 크게 RDB와 AOF로 나뉜다. RDB는 특정 시점의 스냅샷을 저장한다. AOF는 변경 명령을 계속 덧붙여 기록한다. 둘은 경쟁 관계가 아니라 서로 다른 손실 구간과 복구 특성을 가진 도구다.

RDB: 특정 시점의 사진을 남긴다

RDB는 Redis 데이터셋의 특정 시점을 하나의 바이너리 파일로 저장하는 방식이다. 기본 파일 이름은 보통 dump.rdb다. 사진을 찍듯이 어느 순간의 전체 상태를 남긴다고 이해하면 쉽다.

설정은 다음처럼 표현한다.

save 900 1
save 300 10
save 60 10000

save 900 1은 900초 동안 최소 1개의 변경이 있으면 스냅샷을 만든다는 뜻이다. 여러 조건을 함께 둘 수 있고, 조건 중 하나가 만족되면 저장이 시도된다. 수동으로는 BGSAVE를 실행해 백그라운드 스냅샷을 만들 수 있다. Redis는 이 과정에서 자식 프로세스를 만들고, 자식 프로세스가 임시 RDB 파일을 쓴 뒤 완료되면 기존 파일을 원자적으로 교체한다¹.

RDB의 장점은 명확하다.

첫째, 파일이 하나의 완성된 스냅샷이라 백업에 적합하다. 특정 시점의 파일을 외부 저장소에 보관하면 그 시점으로 되돌릴 수 있다.

둘째, AOF처럼 모든 쓰기 명령을 계속 기록하지 않으므로 평상시 쓰기 부하가 작다. 캐시나 재생성 가능한 데이터에는 부담이 적다.

셋째, 재시작 시 로딩이 비교적 단순하다. Redis는 RDB 파일을 읽어 메모리 상태를 복원한다. 명령을 처음부터 재생하는 방식보다 큰 데이터셋에서 빠르게 시작할 수 있는 경우가 많다.

하지만 RDB의 약점도 분명하다. 마지막 스냅샷 이후의 변경은 장애 시 사라질 수 있다. 예를 들어 5분마다 스냅샷을 만들도록 설정했다면, 장애 시점에 따라 최대 몇 분치 변경을 잃을 수 있다. 전원 장애나 서버 강제 종료처럼 Redis가 마지막 저장을 끝내지 못한 상황에서는 이 손실 구간을 피할 수 없다.

또 하나의 운영 포인트는 스냅샷 생성 비용이다. BGSAVE는 백그라운드에서 수행되지만 공짜는 아니다. 자식 프로세스를 만들 때 메모리 사용량이 순간적으로 늘 수 있고, 큰 RDB 파일을 쓰는 동안 디스크 I/O가 증가한다. 변경량이 많은 시간대에 스냅샷이 겹치면 지연 시간이 튈 수 있다. 그래서 운영 환경에서는 저장 주기를 짧게 잡는 것만이 답이 아니다. 손실 허용 시간, 메모리 여유, 디스크 성능을 함께 봐야 한다.

SAVE 명령은 서버를 막고 동기적으로 저장하므로 운영 중에는 보통 피한다. 일반적으로는 BGSAVE나 설정 기반 자동 저장을 사용한다.

AOF: 변경 명령을 계속 기록한다

AOF Append Only File은 Redis에 들어온 쓰기 명령을 파일 뒤에 계속 덧붙이는 방식이다. 설정은 다음처럼 시작한다.

appendonly yes
appendfsync everysec

AOF가 켜져 있으면 Redis는 데이터셋을 바꾸는 명령을 AOF에 기록한다. 재시작할 때는 이 명령들을 다시 실행해 메모리 상태를 복원한다². RDB가 사진이라면 AOF는 작업 일지에 가깝다.

AOF에서 가장 중요한 설정은 appendfsync다. 여기서 fsync는 운영체제의 페이지 캐시에 쓴 데이터를 실제 디스크에 밀어 넣는 동작이다. 단순히 파일에 write했다고 해서 전원 장애 후 반드시 남는 것은 아니다. fsync 정책이 데이터 손실 구간과 성능을 결정한다.

• appendfsync always: 쓰기마다 fsync를 수행한다. 가장 안전한 편이지만 매우 느릴 수 있다.

• appendfsync everysec: 보통 1초마다 fsync한다. Redis에서 일반적으로 권장되는 균형점이며, 장애 시 최근 약 1초 정도의 데이터 손실을 감수한다.

• appendfsync no: Redis가 fsync를 직접 호출하지 않고 운영체제에 맡긴다. 빠르지만 장애 시 손실 범위가 커지고 예측하기 어렵다.

대부분의 서비스에서는 everysec가 현실적인 출발점이다. always는 모든 쓰기 지연 시간이 디스크 내구성과 강하게 연결된다. 초당 쓰기량이 많으면 Redis의 장점인 낮은 지연 시간을 잃을 수 있다. 반대로 no는 데이터 보존이 중요하지 않은 캐시 성격의 데이터가 아니라면 신중해야 한다.

AOF는 계속 커진다. SET user:1:name kim 다음에 SET user:1:name lee가 실행되면 최종 상태에는 마지막 명령만 필요하지만, AOF에는 둘 다 남을 수 있다. 그래서 Redis는 AOF rewrite를 제공한다. 현재 메모리 상태를 기준으로 더 짧은 AOF를 새로 만들고, 완료되면 기존 파일을 교체한다. Redis 7부터는 AOF가 base 파일과 incremental 파일, manifest를 사용하는 다중 파일 구조로 관리될 수 있다³.

rewrite는 데이터 보존을 위한 정리 작업이지만, 운영 비용이 있다. 백그라운드 프로세스 생성, 디스크 쓰기, 변경 명령 추적이 필요하다. 데이터가 크고 쓰기가 많은 시간대에는 메모리와 I/O가 동시에 압박받을 수 있다. 따라서 자동 rewrite 설정은 파일 크기 증가율과 최소 크기를 보고 조정해야 한다.

예를 들면 다음 설정을 검토할 수 있다.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

AOF가 마지막 rewrite 이후 100% 이상 커지고, 최소 64MB를 넘었을 때 rewrite를 시도한다는 의미다. 실제 운영에서는 64MB가 너무 작을 수 있다. 데이터 크기와 디스크 성능에 맞춰 조정한다.

RDB와 AOF를 함께 사용할 때

RDB와 AOF는 함께 켤 수 있다. 이 경우 Redis는 재시작 시 일반적으로 AOF를 사용해 데이터를 복원한다. AOF가 더 최신 변경을 포함할 가능성이 높기 때문이다⁴.

함께 사용하는 구성은 실무에서 자주 쓰인다.

• RDB는 백업과 특정 시점 보관에 유리하다.

• AOF는 장애 직전 데이터 손실을 줄이는 데 유리하다.

• 둘을 함께 쓰면 복구 선택지가 늘어난다.

예를 들어 AOF everysec와 RDB 주기 저장을 함께 사용하면, 일반 재시작은 AOF로 최대한 최신 상태를 복원한다. 동시에 RDB 파일을 외부 저장소에 주기적으로 보관해 잘못된 배포, 운영 실수, 데이터 오염 같은 상황에 대비할 수 있다.

다만 둘을 켠다고 모든 문제가 사라지는 것은 아니다. 애플리케이션이 잘못된 값을 Redis에 썼다면 그 잘못된 값도 RDB와 AOF에 남는다. 영속성은 정상 데이터를 지켜 주는 기능이지, 논리적 오류를 자동으로 되돌리는 기능이 아니다. 그래서 백업 보관과 복원 지점 관리가 필요하다.

선택 기준은 데이터 성격에 따라 달라진다.

Redis를 운영 저장소처럼 쓸수록 AOF와 백업이 중요해진다. 하지만 강한 영속성과 감사 추적이 필요한 데이터라면 Redis만으로 설계를 끝내지 않는 편이 안전하다.

백업은 파일을 복사하는 일이 아니라 복구 절차다

RDB 파일은 백업에 적합하지만, Redis 서버 안에 파일이 하나 있다는 것만으로는 백업이 아니다. 서버 디스크가 망가지거나 운영자가 파일을 삭제하면 함께 사라진다. 백업은 별도 위치에 보관되어야 한다. 공식 문서에서도 RDB 스냅샷을 시간별·일별로 보관하는 방식을 재해 복구 전략으로 설명한다⁵.

운영 절차는 다음처럼 잡는다.

1. 보관 대상 정하기
   RDB를 사용한다면 dump.rdb를 보관한다. AOF를 사용한다면 AOF 디렉터리, base 파일, incremental 파일, manifest를 함께 다뤄야 한다. Redis 7 이후 다중 파일 AOF에서는 일부 파일만 복사하면 복구가 깨질 수 있다.

2. 외부 저장소로 복사하기
   같은 서버의 다른 디렉터리는 백업이 아니다. 오브젝트 스토리지, 백업 서버, 다른 가용 영역 같은 장애 범위가 분리된 곳에 저장한다. 민감한 데이터가 있다면 암호화와 접근 권한도 함께 설정한다.

3. 보관 주기와 만료 정책 정하기
   예를 들어 최근 24시간은 시간 단위, 최근 30일은 일 단위로 보관할 수 있다. 모든 백업을 영구 보관하면 비용과 보안 위험이 커진다. 반대로 너무 빨리 지우면 데이터 오염을 뒤늦게 발견했을 때 돌아갈 지점이 없다.

4. 복원 리허설하기
   백업은 복원해 보기 전까지 믿을 수 없다. 별도 Redis 인스턴스에 백업 파일을 넣고 기동한다. DBSIZE, 샘플 키 조회, TTL 확인, 애플리케이션 스모크 테스트를 수행한다. 복원에 걸린 시간도 기록한다. 이것이 실제 RTO 판단 근거가 된다.

5. 설정 변경 이력 남기기
   save, appendonly, appendfsync, dir, dbfilename, appenddirname, auto-aof-rewrite-*, maxmemory-policy 같은 설정은 Git이나 변경 관리 시스템에 남긴다. 장애 후에는 데이터 파일뿐 아니라 당시 설정도 필요하다.

관리형 Redis를 사용할 때도 주의해야 한다. 클라우드의 persistence 기능은 노드 장애 후 재수화 rehydrate를 돕는 기능일 수 있으며, 장기 보관 백업이나 원하는 시점 복구 PITR과는 다를 수 있다. 손상된 데이터가 저장되면 그 손상도 함께 보존될 수 있다⁶. 관리형 서비스를 쓴다면 백업 파일 접근 가능 여부, export 기능, 보관 개수, 복원 대상 크기 제한을 반드시 확인해야 한다.

운영 체크리스트

영속성 설정은 한 번 켜고 끝나는 기능이 아니다. 다음 항목을 주기적으로 확인한다.

• RDB 마지막 저장 성공 시각을 확인하는가

• BGSAVE 실패나 AOF rewrite 실패 알림이 있는가

• 디스크 사용량이 AOF 증가 속도를 감당하는가

• fsync 지연으로 Redis 응답 시간이 튀지 않는가

• 백업 파일이 외부 저장소에 정상 업로드되는가

• 복원 리허설을 최근에 수행했는가

• 장애 시 어떤 파일로 복구할지 절차서가 있는가

• Redis에 저장하면 안 되는 원장성 데이터가 섞여 있지 않은가

Redis의 빠른 속도는 메모리에서 나온다. 영속성은 그 속도에 안전장치를 더하는 기능이다. RDB는 특정 시점으로 돌아갈 수 있는 사진을 제공한다. AOF는 장애 직전 손실을 줄이는 작업 일지를 제공한다. 백업은 이 파일들을 안전하게 보관하고 실제로 되살릴 수 있음을 확인하는 운영 절차다.

좋은 Redis 운영은 빠르게 쓰는 것에서 끝나지 않는다. 사라져도 되는 데이터와 사라지면 안 되는 데이터를 구분하고, 각 데이터에 맞는 손실 구간을 설계하는 데서 시작한다.

참고

¹Redis persistence 문서

²Redis persistence 문서

³Redis persistence 문서

⁴Redis persistence 문서

⁵Redis persistence 문서

⁶Azure Managed Redis persistence 문서