본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
강의 요약
오늘 강의에서는 저번 강의에 이어서 대기열 시스템의 대기열 등록 api, 진입 요청 api 실습 강의를 진행했다. 실습 강의인 김에 이번 기회에 이전에 정리하지 못했던 Redis 영속성 메커니즘 중 AOF, 하이브리드 방식을 중점적으로 학습하였다.
AOF(Append Only File): 변경 명령어 로그 방식
AOF는 명령어 로그를 통해 Redis의 상태를 복원할 수 있도록 보장하는 실시간 영속화 방식이다.
처리 흐름
- 클라이언트가 쓰기 명령 실행
- Redis는 명령어를 AOF 내부 버퍼에 먼저 기록
- 이후 OS 파일 시스템 캐시에 flush (write 또는 writev 호출)
- 마지막으로 fsync 또는 fdatasync로 디스크에 물리적 반영
버퍼는 Redis 내부에 존재하며 여러 명령어를 일시적으로 쌓아둔다. flush는 버퍼 내용을 OS 파일 시스템 캐시(RAM)에 쓰는 단계이고, fsync는 파일 시스템 캐시의 내용을 디스크에 강제 반영하는 단계이다. 이 분리된 구조를 통해 Redis는 성능과 데이터 안정성 사이에서 균형을 조절할 수 있다.
AOF 설정 및 활성화
redis.conf에서 필수 설정 항목들을 지정한다.
# AOF 기능 활성화
appendonly yes
# AOF 파일 이름 설정
appendfilename "appendonly.aof"
# AOF fsync 정책: 1초마다 디스크 반영
appendfsync everysec
# 저장 경로 (RDB와 공유)
dir /var/lib/redis
# AOF 리라이팅 조건 설정
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
- appendonly를 yes로 설정해야 AOF 기능이 활성화되며, appendfsync 정책이 디스크 반영 빈도를 결정한다.
- 영구 적용을 위해서는 CONFIG REWRITE 명령으로 현재 설정을 redis.conf에 반영한다.
fsync 정책과 트레이드오프
AOF의 내구성은 fsync 정책에 따라 결정된다. Redis는 세 가지 정책을 제공한다. 대부분의 서비스에서는 everysec 정책이 권장된다. RDB보다 유실 가능성이 낮으면서도 충분히 빠른 성능을 제공하기 때문이다.
appendfsync always
- 모든 명령 실행 후 즉시 fsync를 수행한다.
- 가장 안전하지만 성능이 매우 느리다.
- 그러나 Redis는 여러 클라이언트의 명령을 배치로 처리하여 group commit을 지원하므로, 실제로는 단일 fsync로 여러 명령을 함께 반영할 수 있다.
appendfsync everysec (기본값, 권장)
- 1초마다 fsync를 수행한다.
- 백그라운드 스레드가 fsync를 처리하므로 메인 스레드의 성능에 미치는 영향이 적다.
- 장애 발생 시 최대 1초의 데이터만 손실될 수 있으므로 성능과 안정성의 균형이 우수하다.
appendfsync no
- fsync를 Redis가 직접 수행하지 않고 OS에 맡긴다.
- 가장 빠르지만 가장 위험하다.
- Linux는 일반적으로 30초마다 디스크에 flush하지만, 이는 커널 설정에 따라 달라질 수 있다.
AOF 파일 리라이팅
명령어 누적 기록 시 파일 크기가 지속적으로 증가한다. 리라이팅은 현재 데이터셋을 재현하는 최소 명령어 집합으로 파일을 재작성하는 과정이다.
필요성
- SET key 1, SET key 2, SET key 3이 순차 실행되면 최종 상태는 SET key 3 하나로 충분하지만, AOF에는 세 개의 명령이 모두 기록된다. 시
- 간이 지날수록 파일 크기가 증가하여 디스크 공간 소모와 복구 시간 증가로 이어진다.
동작 방식
- Redis는 현재 메모리 상태 기준으로 최소 명령 집합을 생성한다.
- 새 AOF 파일을 백그라운드에서 작성한 뒤 기존 파일과 교체한다.
- 기존 파일은 쓰기 중단 없이 계속 append되므로 리라이팅 실패 시에도 데이터 안정성이 보장된다.
- auto-aof-rewrite-percentage와 auto-aof-rewrite-min-size 설정으로 자동 트리거를 제어한다.
AOF의 장단점
장점
- 높은 데이터 보존성을 제공한다.
- everysec 기준으로도 최대 1초 이내 손실만 발생하며, 명령어 기반으로 사람이 읽을 수 있어 수동 분석 및 복구가 용이하다.
- 실시간 반영으로 상태 변경 직후에도 복원 가능하며, RDB와 병행하여 빠른 재시작과 정밀 복원을 조합할 수 있다.
단점
- 파일 크기가 RDB보다 크며, 복구 속도도 느리다.
- 명령어 순차 실행으로 인해 재시작 시간이 길어지고, 잘못된 명령도 그대로 기록되어 복구 시 재현될 수 있다.
- 설정에 따라 디스크 I/O로 인한 TPS 성능 저하 가능성이 있다.
하이브리드 구성의 필요성
RDB는 빠른 재시작과 작은 파일 크기를 제공하지만, 최근 데이터 손실 가능성이 있다. AOF는 정밀한 복구를 제공하지만, 파일 크기가 크고 복구 속도가 느리다. 하이브리드 방식은 두 방식의 장점을 결합하여 복구 성능과 데이터 정합성을 모두 확보한다.
실제 동작 구조
- RDB는 메모리 상태의 스냅샷을 저장하여 빠른 초기 로딩을 담당하고, AOF는 RDB 저장 이후의 변경 명령을 기록하여 최신 상태까지 정밀 복원을 담당한다.
- save 설정 조건 충족 시 RDB 파일이 생성되며, 이후 발생한 쓰기 명령은 AOF에 순차 기록된다.
- 복구 시에는 Redis가 RDB 파일로 메모리 상태를 먼저 복원한 후, AOF 파일의 명령어를 순차 실행하여 최신 상태를 반영한다.
- AOF에는 RDB 이후의 명령만 포함되므로 중복 실행이 없다.
설정 방식과 구성 예시
RDB와 AOF 설정을 함께 활성화한다.
# RDB 설정
save 900 1
save 300 10
# AOF 설정
appendonly yes
appendfsync everysec
# 저장 위치
dir /var/lib/redis
- RDB와 AOF 파일 모두 dir 경로에 저장된다.
- 복구 시 RDB를 먼저 로드한 후 AOF 명령을 재실행하며, AOF에는 RDB 이후 명령만 포함되므로 중복 실행이 없다.
하이브리드 구성의 장단점
장점
- RDB로 빠른 재시작이 가능하다.
- AOF로 정밀한 복구가 가능하며 최대 1초 단위 보존이 가능하다.
- 중복 저장 없이 명확한 복구 흐름을 확보할 수 있다.
단점
- 디스크 사용량이 증가한다.
- 두 파일 모두 저장되므로 공간 소모가 크다.
- 설정 관리 복잡도가 증가한다. 주기, 경로, 정책 등 이중 관리가 필요하다.
참고 출처
- https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/
- https://engineeringatscale.substack.com/p/redis-persistence-aof-rdb-crash-recovery
