#9 💾 퍼시스턴스: RDB·AOF·복구 체크

"Redis는 메모리 DB니까 꺼지면 다 날아가지 않나요?" — 아닙니다! RDB와 AOF로 데이터를 안전하게 보관하는 방법을 알아봅니다.

❓ "Redis 꺼지면 데이터 다 사라지나요?"

"Redis는 메모리에 데이터를 올려놓는 DB잖아요. 서버가 꺼지거나 재시작되면 데이터가 다 날아가는 거 아닌가요?" 이 질문은 Redis를 처음 배우는 분들이 가장 많이 하는 질문 중 하나입니다.

반은 맞고 반은 틀립니다. 기본 설정에서는 데이터가 유실될 수 있습니다. 하지만 Redis는 디스크 퍼시스턴스 기능을 제공하며, 올바르게 설정하면 재시작 후에도 데이터를 복구할 수 있습니다.

Redis의 퍼시스턴스 방식은 크게 두 가지입니다. RDB(Redis Database)는 특정 시점의 메모리 스냅샷을 디스크에 저장합니다. AOF(Append Only File)는 모든 쓰기 명령을 로그 파일에 기록합니다. 둘을 함께 쓰는 하이브리드 방식도 있습니다.

어떤 방식을 선택하느냐에 따라 데이터 유실 범위, 복구 속도, 디스크 사용량이 달라집니다. 이번 편에서 각 방식의 특징을 이해하고 Lab 8을 통해 직접 확인해 봅니다.

💡 퍼시스턴스가 필요 없는 경우도 있습니다
순수 캐시로만 사용할 때는 퍼시스턴스를 끄는 것이 성능상 유리합니다. DB에서 언제든 다시 채울 수 있는 캐시 데이터라면 굳이 디스크에 저장할 필요가 없죠. 용도에 따라 선택하세요.

📸 핵심 개념 1: RDB — 스냅샷 방식

RDB는 특정 시점(Point-in-Time)의 메모리 전체를 dump.rdb 파일로 저장합니다. 마치 게임의 저장 지점처럼, 특정 순간의 상태를 디스크에 찍어 둡니다.

RDB는 fork()를 사용한 백그라운드 저장을 지원합니다. 자식 프로세스가 스냅샷을 저장하는 동안 부모 프로세스는 계속 요청을 처리합니다. 덕분에 저장 중에도 성능 영향이 적습니다.

RDB 설정 (redis.conf)

redis.conf

# X초 동안 Y번 이상 쓰기가 있으면 자동 저장
save 3600 1      # 1시간에 1번 이상 변경 시
save 300 100     # 5분에 100번 이상 변경 시
save 60 10000    # 1분에 10000번 이상 변경 시

# RDB 파일 이름과 저장 경로
dbfilename dump.rdb
dir /var/lib/redis

RDB 장단점

장점	단점
파일이 작음 (압축 저장)	마지막 스냅샷 이후 변경사항 유실 가능
재시작 시 복구 속도 빠름	큰 데이터셋에서 fork() 비용 발생
특정 시점 백업에 적합	유실 허용 범위가 분 단위

📝 핵심 개념 2: AOF — 쓰기 로그 방식

AOF는 모든 쓰기 명령을 appendonly.aof 파일에 순서대로 기록합니다. Redis가 재시작될 때 이 로그를 순서대로 재실행하여 데이터를 복구합니다. 마치 블랙박스처럼 모든 쓰기 기록을 남깁니다.

AOF의 내구성은 appendfsync 설정에 따라 달라집니다. fsync는 OS 버퍼에 있는 데이터를 디스크에 강제로 쓰는 작업입니다.

appendfsync 값	동작	내구성	성능
always	매 쓰기마다 fsync	최상 (손실 없음)	가장 느림
everysec	1초마다 fsync (기본값)	최대 1초치 손실	균형 ⭐ 권장
no	OS 결정 (보통 30초)	손실 클 수 있음	가장 빠름

redis.conf — AOF 설정

appendonly yes               # AOF 활성화
appendfsync everysec         # 1초 단위 fsync (권장)
auto-aof-rewrite-percentage 100  # AOF 파일 크기 2배 시 재작성
auto-aof-rewrite-min-size 64mb   # 최소 64MB 이상일 때만 재작성

⚠️ AOF 파일은 계속 커집니다
같은 키를 1000번 덮어써도 AOF에는 1000줄이 쌓입니다. BGREWRITEAOF 명령이나 auto-aof-rewrite 설정으로 파일을 주기적으로 압축(재작성)해야 합니다.

🆚 RDB vs AOF vs 하이브리드

구분	RDB	AOF	RDB+AOF (하이브리드)
최대 데이터 유실	수분~수시간	최대 1초 (everysec)	최대 1초
복구 속도	빠름 ⭐	느림 (명령 재실행)	빠름 (RDB로 복구 후 AOF 적용)
파일 크기	작음 (압축)	큼	중간
주요 용도	백업, 복제 초기화	내구성 중요 서비스	내구성 + 빠른 복구
설정 예시	save 300 100	appendonly yes	aof-use-rdb-preamble yes

🔬 Lab 8: Docker 볼륨 + AOF 켜기 + 재시작 후 복구 확인

Bash — Docker

# Lab 8 — Docker 볼륨으로 데이터 유지
# 로컬 디렉토리를 Redis 데이터 디렉토리로 마운트
mkdir -p ./redis-data

docker run -d \
  --name redis-persist \
  -p 6379:6379 \
  -v ./redis-data:/data \
  redis:8.6.1 \
  redis-server --appendonly yes --appendfsync everysec

# Redis에 접속
docker exec -it redis-persist redis-cli

redis-cli — 데이터 저장

# 데이터 저장
SET persist:key1 "데이터가 살아남을까?"
SET persist:key2 "AOF 테스트"
HSET persist:user name "김철수" email "kim@example.com"

# 현재 키 확인
KEYS persist:*

# AOF 상태 확인
INFO persistence
# aof_enabled: 1  ← AOF 활성화 확인
# aof_rewrite_in_progress: 0

Bash — 컨테이너 재시작

# 컨테이너 강제 종료 (데이터 유실 시뮬레이션)
docker stop redis-persist
docker rm redis-persist

# 동일 볼륨으로 재시작
docker run -d \
  --name redis-persist \
  -p 6379:6379 \
  -v ./redis-data:/data \
  redis:8.6.1 \
  redis-server --appendonly yes

# 접속 후 데이터 확인
docker exec -it redis-persist redis-cli
GET persist:key1     # → "데이터가 살아남을까?" (복구됨!)
HGETALL persist:user # → name, email 복구됨!

✅ 성공 기준
컨테이너를 완전히 삭제하고 재시작해도 ./redis-data 디렉토리의 AOF 파일 덕분에 데이터가 복구되어야 합니다.

🚨 Docker 볼륨 없이 쓰면?

볼륨 마운트 없이 컨테이너를 삭제하면 컨테이너 내부의 데이터도 함께 사라집니다. 반드시 -v 옵션으로 호스트 디렉토리나 named volume을 마운트해야 합니다.

🐍 Lab 8: Python으로 퍼시스턴스 상태 확인

Python

# pip install redis
import redis

r = redis.Redis(host="localhost", port=6379, decode_responses=True)

def check_persistence():
    """Redis 퍼시스턴스 설정 상태 확인"""
    info = r.info("persistence")

    print("=== Redis 퍼시스턴스 상태 ===")
    print(f"RDB 활성화: {info.get('rdb_bgsave_in_progress', 0) == 0}")
    print(f"마지막 RDB 저장 시간: {info.get('rdb_last_save_time')} (Unix timestamp)")
    print(f"RDB 저장 성공 여부: {info.get('rdb_last_bgsave_status')}")
    print(f"AOF 활성화: {info.get('aof_enabled')}")
    print(f"AOF 파일 크기: {info.get('aof_current_size', 0)} bytes")
    print(f"AOF 마지막 재작성: {info.get('aof_last_rewrite_time_sec')}초")

def save_and_verify():
    """데이터 저장 후 BGSAVE 요청"""
    # 데이터 저장
    r.set("persist:python:test", "Python에서 저장한 데이터")
    r.expire("persist:python:test", 3600)

    # 백그라운드 RDB 저장 요청
    result = r.bgsave()
    print(f"\nBGSAVE 결과: {result}")
    print(f"데이터 확인: {r.get('persist:python:test')}")

if __name__ == "__main__":
    check_persistence()
    save_and_verify()

⚠️ 실전 팁: 용도에 따른 퍼시스턴스 선택

사용 시나리오	권장 설정	이유
순수 캐시 (DB 재로드 가능)	퍼시스턴스 OFF	성능 최적화, 디스크 불필요
세션 저장소	AOF everysec	세션 유실 최소화 (1초 이내)
작업 큐/중요 데이터	AOF + RDB 하이브리드	내구성 + 빠른 복구
분석/로그 보조 저장소	RDB만	주기적 백업으로 충분
Sorted Set 랭킹	선택적	DB 재구성 가능하면 OFF 고려

🚫 퍼시스턴스를 켰더라도 백업은 별도로!
AOF/RDB는 Redis 재시작 시 복구를 위한 것이지, 데이터 백업 대체재가 아닙니다. 디스크 장애, 파일 손상에 대비해 주기적으로 dump.rdb, appendonly.aof 파일을 외부 스토리지(S3 등)에 복사하세요.

📌 9편 핵심 요약

1. RDB: 주기적 스냅샷, 파일 작고 복구 빠름, 수분 단위 유실 가능
2. AOF: 모든 쓰기 로그, everysec으로 최대 1초 유실
3. 하이브리드: RDB 스냅샷 + AOF 차이분 → 내구성 + 빠른 복구
4. Docker 볼륨: -v 옵션 필수, 없으면 컨테이너 삭제 시 데이터 소실
5. 순수 캐시: 퍼시스턴스를 끄는 것도 올바른 선택 (성능 우선)

✅ 9편 체크리스트

• Docker 볼륨(-v)을 마운트하고 AOF를 활성화해 Redis를 실행했다
• 데이터를 저장하고 컨테이너를 재시작한 후 복구를 확인했다
• RDB와 AOF의 차이(스냅샷 vs 로그)를 설명할 수 있다
• appendfsync의 세 가지 옵션(always/everysec/no)의 트레이드오프를 이해했다
• INFO persistence로 퍼시스턴스 상태를 확인했다
• 자신의 사용 시나리오에 어떤 퍼시스턴스가 적합한지 결정했다

🧠 퀴즈 3문항

Q1. appendfsync everysec 설정에서 최대 데이터 유실 범위는?

⏱️ 최대 1초입니다. 1초마다 OS 버퍼의 내용을 디스크에 강제로 씁니다. 따라서 최악의 경우 1초 내의 쓰기가 유실될 수 있습니다.

Q2. RDB가 AOF보다 재시작 복구가 빠른 이유는?

📸 RDB는 메모리 스냅샷이므로 파일을 메모리에 로드하면 끝입니다. AOF는 기록된 모든 쓰기 명령을 순서대로 재실행해야 하므로 데이터량에 비례해 시간이 걸립니다.

Q3. Redis를 순수 캐시로만 쓸 때 퍼시스턴스를 꺼도 되는 이유는?

♻️ 캐시는 원본 데이터(DB)에서 언제든 다시 채울 수 있기 때문입니다. 퍼시스턴스를 끄면 디스크 I/O가 없어 성능이 향상되고, RDB fork() 비용도 없어집니다. 다만 Cache Warming(캐시 예열)이 필요할 수 있습니다.

📝 과제 3가지

1. 퍼시스턴스 OFF 테스트: 볼륨 없이, --save "" 옵션으로 Docker를 실행하고, 데이터 저장 후 재시작하면 데이터가 사라지는 것을 확인하세요.
2. BGSAVE 수동 실행: BGSAVE 명령으로 RDB 스냅샷을 수동으로 저장하고, ./redis-data 디렉토리에 dump.rdb 파일이 생성되는지 확인하세요.
3. AOF 재작성: 같은 키를 100번 SET한 후 BGREWRITEAOF를 실행하고, AOF 파일 크기 변화를 확인하세요.

📚 Redis 입문 시리즈 전체 목록

• 1편: Redis 시작하기
• 2편: 키·TTL·만료
• 3편: Strings
• 4편: Hashes
• 5편: Lists·Sets
• 6편: Sorted Sets
• 7편: Pub/Sub vs Streams
• 8편: 동시성 제어
• 9편: 퍼시스턴스 ← 현재
• 10편: 복제·고가용성
• 11편: 클러스터
• 12편: 보안·성능·관측