Redis RDB 스냅샷과 AOF의 기록·복구 조건

Redis는 메모리 데이터셋을 RDB 스냅샷, AOF(Append Only File), 두 방식의 조합 또는 영속성 비활성화로 운용할 수 있습니다. RDB는 설정된 조건이나 명령에 따라 특정 시점의 데이터셋을 파일로 저장하므로 백업·이관에 유용하지만, 마지막 스냅샷 이후 변경분은 장애 시 복구되지 않을 수 있습니다. AOF는 서버가 받은 변경 명령을 기록해 재시작 시 다시 실행합니다. 둘 다 켜면 Redis 버전과 설정에 따라 재시작 시 AOF가 우선 적용될 수 있으므로 현재 버전 문서를 확인해야 합니다.

전문가 관점: Redis 기술 비교 자료의 운영상 절충

Redis가 공개한 RDB와 AOF 비교 자료는 저장 주기와 fsync 정책을 데이터 손실 허용도와 성능 요구에 맞춰 고르도록 안내합니다. appendfsync everysec는 대체로 약 1초 주기로 fsync를 시도하는 기본적인 절충이지만, 비정상 종료 시 손실 범위가 항상 정확히 1초 이하라는 보장은 아닙니다. OS와 저장장치가 flush를 어떻게 처리하는지, 장애 종류, 스케줄링 지연이 영향을 줍니다. appendfsync always도 모든 상황에서 완전 무손실을 보증하지 않습니다. 명령 실행 후 응답 전 동기화를 요청하지만 장치·파일시스템의 안정성 경계와 복제·백업은 별도로 검토해야 합니다.

RDB 생성과 AOF 재작성의 운영 비용

백그라운드 BGSAVE와 AOF 재작성은 자식 프로세스를 사용하는 환경에서 fork를 일으킬 수 있습니다. 부모와 자식은 처음에는 메모리 페이지를 공유하고 쓰기 시 Copy-on-Write가 발생하므로, 메모리 압박과 쓰기율에 따라 추가 RAM이 크게 늘 수 있습니다. fork 단계의 지연도 데이터셋 크기와 OS 조건에 따라 요청 지연에 영향을 줍니다. “고정된 메모리 여유율이면 안전”이라는 보편 수치는 없습니다. 운영 부하를 재현해 peak RSS, fork 시간, CoW, 디스크 여유 공간을 측정해야 합니다. AOF 재작성은 기존 로그를 압축된 상태 표현으로 재구성하며, 전체 쓰기 명령을 무한히 보존하는 감사 로그가 아닙니다.

백업·복제와 복구 검증

RDB나 AOF 파일은 백업 전략의 한 부분이지, 장애 조치나 시점 복구를 자동으로 해결하지 않습니다. 복제는 복구 목표를 보완할 수 있지만 비동기 복제의 지연·장애 구간에서 데이터 손실 가능성이 남습니다. 복구를 실제로 검증하려면 저장 파일의 보존과 무결성, 백업 복사본 분리, 키·모듈 호환 버전, 복구 시간, 복제 전환 절차를 시험합니다. Redis Software와 Redis Open Source는 제공되는 설정·기능이 다를 수 있으므로 제품별 지침을 구분하고, 데이터 손실 허용도에 따라 fsync·스냅샷 주기와 복제 정책을 정하세요.

복구 시각을 대입해 보는 가상 사례

Redis 7.x 한 대에서 RDB만 사용한다고 가정해 보겠습니다. 성공한 RDB가 담고 있는 논리적 데이터 시점이 12:00이고, 그때 job:done이 40이었다고 가정합니다. 백그라운드 파일 저장은 이 시점 이후에도 계속될 수 있으므로, 저장 완료 시각과 스냅샷이 나타내는 데이터 시점을 구분해야 합니다. 12:02에 41, 12:04에 42로 바뀐 뒤 다음 RDB가 완료되기 전 12:05에 장애가 나면, 복구에 쓰는 파일은 12:00 시점이므로 해당 키는 40으로 돌아갑니다. 41과 42는 그 스냅샷에 포함되지 않습니다. 이것은 시점을 설명하기 위한 가상 값이며, 실제 손실량은 스냅샷 완료 시각과 장애 상황에 달려 있습니다(Redis persistence documentation).

AOF의 appendfsync everysec는 보통 1초마다 동기화를 요청하는 정책이지, 장애 시 손실량을 정확히 1초로 제한하는 보증이 아닙니다. Redis 문서는 버퍼링·fsync와 운영체제·저장장치의 동작을 설명하지만, 이 설정을 모든 실패 모드의 확정 손실 상한으로 읽어서는 안 됩니다. RPO가 중요하다면 설정값만 기록하지 말고, 격리된 복구 시험에서 복구된 키와 애플리케이션 불변조건을 비교하세요.

실무 복구 점검은 다음 순서로 기록할 수 있습니다.

  1. 백업 파일 또는 AOF 파일 세트를 원본과 분리해 복사하고, 체크섬·크기와 생성 시각을 기록합니다. Redis 7 이상 multipart AOF는 파일 일부가 아니라 manifest가 가리키는 세트를 보존해야 합니다.
  2. 운영 인스턴스를 덮어쓰지 말고, 동일한 Redis 릴리스와 필요한 모듈을 갖춘 격리 인스턴스에서 복구합니다. 로드 오류·잘림 경고와 persistence 상태를 기록합니다.
  3. 복구 시각을 기준으로 예상되는 키·값과 애플리케이션 불변조건을 검사합니다. 전체 키 수만 맞는다고 값의 정확성까지 입증되는 것은 아닙니다.
  4. 대표 읽기·쓰기 경로, 복구 소요 시간, 복제 전환 절차를 확인하고, 시험한 백업의 시각과 검증 범위를 남깁니다.

이 절차는 팀이 시험 항목을 빠뜨리지 않게 돕는 운영 체크리스트입니다. 데이터 정합성이나 복구 가능성을 시험 없이 보증하지 않습니다.

참고 자료