[Redis] 데이터 영속성을 위한 RDB와 AOF 그리고 운영 환경에서 지양하는 이유

Posted Oct 1, 2025

By Hoon

6 min read

Redis 데이터 영속성

Redis는 메모리 기반의 Key-Value 저장소이기 때문에 서버가 종료되면 데이터도 휘발된다.
이를 방지하기 위해 Redis는 데이터 영속성(Persistence)을 위한 두 가지 방식을 제공한다.

RDB(Snapshot)
AOF(Append Only File)

RDB란?

RDB는 Redis Database의 약자로, 현재 메모리 상태를 스냅샷(Snapshot) 형태로 디스크에 저장하는 방식이다.
따로 설정하지 않더라도 기본적으로 900초(15분)마다 1회 스냅샷을 생성하도록 설정되어 있다.

이 스냅샷의 dump.rdb 파일은 Redis 서버가 시작될 때 자동으로 로드되어 이전 상태를 복원할 수 있다.
dump.rdb 파일은 바이너리 형식으로 저장되며, AOF 방식에 비해 저장 공간이 적게 필요하다.
그래서 로딩 속도가 AOF 방식에 비해 빠르다는 장점이 있다.

하지만, 스냅샷을 생성하는 과정이 시간이 오래 걸리고,
스냅샷 생성 주기 사이에 발생한 데이터는 유실될 수 있다는 단점이 있다.

RDB 기본 설정

  
save 900 1 # 900초(15분) 동안 1회 이상의 변경이 있을 경우 스냅샷 생성
save 300 10 # 300초(5분) 동안 10회 이상의 변경이 있을 경우 스냅샷 생성
save 60 10000 # 60초(1분) 동안 10000회 이상의 변경이 있을 경우 스냅샷 생성

AOF란?

AOF는 Append Only File의 약자로,
조회를 제외한 Redis의 모든 입력/수정/삭제 명령이 실행될 때마다 해당 명령을 로그 파일에 기록하는 방식이다.

이 로그 파일은 appendonly.aof라는 이름으로 저장되며,
Redis 서버가 재시작될 때 로그에 기록된 명령을 재실행하는 방식으로 데이터를 복원한다.

RDB와 달리 연산마다 로그를 기록하기 때문에 데이터 유실이 거의 없고,
로그 파일이 텍스트 형식이기 때문에 사람이 읽을 수 있다는 장점도 있다.

하지만, 모든 연산을 로그로 기록하기 때문에 용량이 크고,
재실행 시 명령을 재실행하기 때문에 로딩 속도가 느리다는 단점이 있다.

AOF 방식은 Rewrite 기능을 제공하여, 불필요한 로그를 정리하고 파일 크기를 줄일 수 있다.

AOF 기본 설정

AOF는 기본적으로 비활성화되어 있으며, appendonly yes로 설정하여 활성화할 수 있다.

  
appendonly no # AOF 비활성화

AOF 옵션

  
appendfsync always # 모든 명령을 디스크에 동기화 (가장 안전하지만 느림)
appendfsync everysec # 1초마다 디스크에 동기화 (균형 잡힌 옵션, 기본값)
appendfsync no # 운영체제에 맡김 (가장 빠르지만 데이터 유실 위험)

AOF Rewrite 옵션

  
auto-aof-rewrite-percentage 100 # AOF 파일 크기가 마지막 Rewrite 이후 100% 증가할 때 Rewrite 수행
auto-aof-rewrite-min-size 64mb # AOF 파일 크기가 최소 64MB 이상일 때 Rewrite 수행

운영 환경에서 지양하는 이유

비용 대비 효과가 낮고, 오히려 지연(Latency)/메모리/운영 복잡도가 증가한다.
RDB Snapshot / AOF Rewrite는 자식 프로세스가 fork()로 생성되며 Copy-On-Write가 발생
- 순간적으로 메모리 사용량이 튀고, 페이지 복사로 CPU/디스크 부하가 증가
- 서비스 장애의 원인이 될 수 있음
Redis 역할과 불일치
운영 복잡도 및 비용
- AOF 파일 관리, Rewrite 정책, 디스크 용량 모니터링, 스냅샷 스케줄링 등 운영 항목이 늘어남
- I/O 비용이 붙고, 대형 인스턴스/고성능 디스크가 필요해짐

운영 시 권장하는 방법

캐시 전용
- appendonly no, save ""로 설정하여 RDB와 AOF를 비활성화
- TTL + Warm-up 전략 사용
- Replica/Clustering 으로 가용성 확보
- 장애 발생 시 “캐시는 비워지고 다시 채워진다”가 기본 가정
Source of Truth는 RDBMS로 유지
Master-Slave 사용 시 필요하다면 Slave에서만 RDB와 AOF 활성화 고려

Redis