RDB, AOF, 그리고 잃어도 되는 것

한 줄 요약

영속성 설정은 "몇 초어치를 잃어도 되는가"라는 질문에 대한 답이다. 답이 "한 건도 안 된다"면 Redis 가 맞는 도구인지부터 다시 봐야 한다.

왜 이게 필요했나

Redis 는 인메모리 저장소입니다. 프로세스가 죽으면 메모리는 사라집니다. 그래서 두 가지 영속성 방식을 제공합니다.

RDB 는 주기적 스냅샷입니다. 설정 예를 보면 save 3600 1, save 300 100, save 60 10000 — 한 시간 안에 1건 이상 변경, 5분 안에 100건, 1분 안에 10000건 변경이면 스냅샷을 뜹니다. 장점은 파일 하나라 백업과 복구가 간단하고 재시작이 빠르다는 것입니다. 단점은 마지막 스냅샷 이후의 쓰기를 전부 잃는다는 것입니다.

AOF 는 모든 쓰기 명령을 로그로 남깁니다. appendfsync everysec 이 실무 기본값이고, 최악의 경우 1초어치를 잃습니다. always 로 두면 유실이 거의 없지만 쓰기마다 fsync 라 처리량이 크게 떨어집니다. no 는 OS 에 맡기는 것이라 유실 구간이 커집니다.

어떻게 동작하나

실무의 표준은 둘을 함께 쓰는 혼합 모드입니다. AOF 를 켜고 aof-use-rdb-preamble yes 로 두면, AOF 리라이트 시 앞부분을 RDB 형식으로 저장하고 그 뒤에 증분 명령을 붙입니다. 복구가 빠르면서 유실 구간도 1초로 유지됩니다.

Redis 7 의 Multi-Part AOF 는 이것을 한 단계 더 정리해서, 전용 디렉터리에 base 파일과 incr 파일을 나눠 둡니다. 리라이트 중 디스크 공간이 두 배로 튀는 문제가 줄었습니다.

여기서 정직하게 짚을 부분이 있습니다. 영속성을 켜도 Redis 는 데이터베이스가 아닙니다. 복제는 비동기라서 마스터가 죽는 순간 복제본에 도달하지 못한 쓰기가 있을 수 있습니다. WAIT 명령으로 일부 개선할 수 있지만 완전한 동기 복제는 아닙니다. 그래서 "절대 잃으면 안 되는" 데이터의 1차 저장소로는 적절하지 않습니다.

현장에서 만나는 모습

fsync 비용을 과소평가하는 경우가 많습니다. appendfsync always 로 바꾸고 처리량이 절반 이하로 떨어졌다는 보고가 흔합니다. 디스크가 느린 환경에서는 AOF 쓰기가 밀려 메인 스레드가 블록되기도 합니다.

RDB 스냅샷도 공짜가 아닙니다. fork 로 자식 프로세스를 만들어 스냅샷을 뜨는데, copy-on-write 때문에 쓰기가 많으면 순간적으로 메모리가 크게 늘어납니다. 4GB 인스턴스가 스냅샷 중에 6GB 를 쓰는 일이 생깁니다. maxmemory 를 물리 메모리에 딱 맞춰 잡으면 이때 OOM 이 납니다. 보통 물리 메모리의 절반 정도를 maxmemory 로 잡습니다.

다음 확인에서 볼 것

영속성 설정 변경은 실습 파드의 다른 실습에 영향을 줄 수 있어 퀴즈로 대신합니다. RDB·AOF 의 유실 범위와 복구 비용을 상황별로 구분할 수 있는지 확인하고 코스를 마칩니다.