AOF 대 RDB 영속성 성능 절충 비교

Redis는 밀리초 미만의 지연 시간으로 유명할 정도로 빠른 속도로 정평이 나 있습니다. 하지만 영속성(재시작 후 복구를 위해 데이터를 디스크에 저장하는 기능)이 활성화되면 개발자는 메커니즘을 선택해야 합니다. Redis의 두 가지 주요 영속성 방법은 스냅샷팅(RDB)과 Append-Only File(AOF)입니다. 각 방식의 성능 영향, 내구성 특성 및 구성 절충점을 이해하는 것은 속도 대 데이터 안전성에 대한 특정 애플리케이션 요구 사항을 충족하도록 Redis를 튜닝하는 데 매우 중요합니다.

이 가이드는 RDB와 AOF를 철저히 검토하고, 작동 방식, 지연 시간에 미치는 각자의 성능 발자취를 자세히 설명하며, 고성능 Redis 배포를 위해 올바른 영속성 전략을 선택하는 데 대한 실용적인 통찰력을 제공합니다.

Redis 영속성 이해하기

Redis는 전체 데이터셋을 휘발성 메모리에 저장합니다. 영속성 메커니즘은 서비스 중단이나 재부팅 시 데이터 가용성을 보장하기 위해 이 데이터를 디스크로 이동시켜 Redis가 재시작 시 데이터셋을 다시 로드할 수 있도록 하는 데 필요합니다. RDB와 AOF 모두 근본적으로 다른 접근 방식을 통해 이 목표를 달성하며, 이는 뚜렷하게 다른 성능 프로필로 이어집니다.

1. Redis 데이터베이스(RDB) 스냅샷팅

RDB는 지정된 간격으로 전체 데이터셋의 간결한 시점 스냅샷을 생성합니다. 이 데이터는 바이너리 파일(dump.rdb)에 저장됩니다.

RDB 작동 방식 및 성능 영향

RDB 영속성은 BGSAVE 명령(백그라운드 저장)에 크게 의존합니다. 저장이 트리거되면:

포크(Forking): Redis는 주 프로세스를 자식 프로세스로 포크(분리)합니다.
스냅샷팅: 자식 프로세스는 전체 데이터셋을 디스크의 RDB 파일에 씁니다.
주 스레드 영향 최소화: 자식이 디스크 I/O를 처리하므로 주 Redis 스레드는 쓰기 작업 중에 차단되지 않고 클라이언트 요청 처리를 계속합니다.

성능 고려 사항:

쓰기 지연 시간: 일반적으로 RDB는 저장 작업 중 쓰기 지연 시간에 미치는 영향이 최소화되는데, 작업이 오프로드되기 때문입니다. 주요 성능 비용은 포크가 발생할 때와 대용량 파일 쓰기 중에 필요한 CPU 스파이크와 초기 I/O 버스트입니다.
복구 시간: RDB는 최적화된 단일 파일이므로 재시작 시 매우 빠르게 로드되어 복구 지연 시간을 최소화합니다.
내구성 절충: Redis가 예약된 저장(예: 5분마다) 사이에 충돌하면 마지막 저장 이후 발생한 모든 쓰기가 손실됩니다. 이로 인해 RDB는 AOF보다 내구성이 떨어집니다.

RDB 저장 구성

RDB 저장은 redis.conf 파일에서 save 지시문을 사용하여 시간 간격과 변경 횟수를 지정하여 구성됩니다.

save 900 1     # 900초(15분) 동안 키 1개 변경 시 저장
save 300 10    # 300초(5분) 동안 키 10개 변경 시 저장
save 60 10000  # 60초(1분) 동안 키 10000개 변경 시 저장

2. Append-Only File (AOF) 영속성

AOF는 Redis 서버가 수신하는 모든 쓰기 작업을 추가 전용 로그 파일에 기록합니다. Redis가 재시작되면 이 명령들을 순차적으로 재생하여 데이터셋을 재구성합니다.

AOF 작동 방식 및 성능 영향

RDB와 달리 AOF는 트랜잭션 로깅에 중점을 둡니다. 성능 프로필은 Redis가 버퍼링된 데이터를 물리적 디스크에 기록하도록 강제하는 빈도를 결정하는 fsync 정책에 크게 좌우됩니다.

AOF Fsync 정책:

정책	`appendfsync` 설정	내구성	성능 영향
매초	`everysec`	좋음 (~1초 데이터 손실)	좋은 균형; 사소한 오버헤드. 권장 기본값.
동기화 안 함	`no`	나쁨 (OS 버퍼에 의존)	가장 빠름; OS 충돌 시 데이터 손실 위험 최대.
항상	`always`	우수함 (원자적 쓰기)	가장 느림; 모든 쓰기 시 필수 디스크 I/O로 인해 지연 시간 크게 증가.

성능 고려 사항:

쓰기 지연 시간: appendfsync always를 사용할 때 모든 쓰기 명령은 디스크 동기화 지연 시간을 수반하여 RDB나 인메모리 작업에 비해 작업을 현저히 느리게 만듭니다. everysec를 사용하면 fsync 작업을 버퍼링하고 덜 자주 수행하여 이를 상당히 완화합니다.
복구 시간: AOF 파일이 커질 수 있으며 수백만 개의 명령을 재생하는 것은 간결한 RDB 파일을 로드하는 것보다 오래 걸릴 수 있어 재시작 중 가동 중지 시간이 길어집니다.
파일 크기: AOF 파일은 데이터 구조의 최종 상태가 아닌 명령(예: SET key value)을 저장하므로 일반적으로 RDB 파일보다 훨씬 큽니다.

AOF 활성화 및 구성

AOF는 기본적으로 비활성화되어 있으며 redis.conf에서 appendonly yes를 설정하여 활성화됩니다. 가장 중요한 설정은 appendfsync입니다.

appendonly yes
appendfilename "appendonly.aof"
# 내구성 대 속도 절충을 위한 권장 설정
appendfsync everysec

성능 절충 분석: AOF 대 RDB

RDB와 AOF 중 선택하려면 처리량(지연 시간) 또는 보장된 데이터 복구 중 무엇을 우선시할지 결정해야 합니다.

지연 시간 및 처리량

RDB (원시 속도에 최고): 쓰기가 백그라운드 프로세스에 의해 처리되므로 주 Redis 스레드는 저장 중에 직접적인 I/O 영향을 거의 받지 않습니다. 이는 시스템이 BGSAVE 포크 발생 시 과부하 상태가 아닌 한 일반적으로 전반적인 쓰기 지연 시간을 낮춥니다.
AOF (always 모드): 이 구성은 모든 클라이언트 쓰기 명령에 디스크 지연 시간이 직접 도입되므로 가장 느리며 p99 지연 시간이 높아집니다.
AOF (everysec 모드): fsync 작업이 버퍼링되고 덜 자주 발생하므로 대부분의 작업에 대해 RDB와 유사한 성능을 제공합니다.

내구성 및 데이터 손실 위험

AOF (내구성에 최고): 특히 appendfsync always를 사용할 때 가장 높은 내구성을 제공합니다. everysec를 사용하더라도 데이터 손실은 1초로 제한됩니다.
RDB (내구성에 최악): 데이터 손실은 저장 일정에 따라 몇 분 또는 몇 시간 동안 발생할 수 있습니다.

복구 시간

RDB (빠른 복구): 최적화된 간결한 바이너리 형식 덕분에 재시작 시간이 더 빠릅니다.
AOF (느린 복구): 대규모 명령 로그를 재생하는 것은 스냅샷을 로드하는 것보다 오래 걸릴 수 있어 재시작 중 가동 중지 시간이 늘어납니다.

모범 사례: 두 가지 영속성 방법 모두 사용

높은 성능과 강력한 내구성 보장이 모두 필요한 환경의 경우, RDB 및 AOF 영속성을 모두 활성화하는 것이 권장되는 접근 방식입니다.

둘 다 활성화되면 Redis는 시작 중 재생을 위해 AOF 파일을 사용하여 최대 데이터 일관성을 달성합니다. 주기적으로 RDB 스냅샷을 계속 생성합니다.

둘 다 사용하는 이유:

더 빠른 복구: AOF 파일이 손상되거나 매우 커지면 Redis는 가장 최근의 RDB 스냅샷을 시작 지점으로 사용하여 후속 AOF 재생 프로세스를 상당히 가속화할 수 있습니다.
AOF 재작성 효율성: Redis는 가장 최근의 RDB 스냅샷을 기반으로 중복 명령을 폐기하여 새롭고 간결한 AOF 파일을 생성하는 AOF 재작성 작업을 자동으로 트리거할 수 있으며, 이는 기존 AOF 로그에서만 재작성하는 것보다 종종 더 효율적입니다.

두 가지 모두를 위한 구성 조각:

# 1. RDB 활성화
save 900 1

# 2. 'everysec' 동기화로 AOF 활성화
appendonly yes
appendfsync everysec

AOF 파일 크기 관리(재작성)

AOF의 주요 운영상의 관심사는 파일 크기 증가입니다. AOF는 이전 값을 덮어쓰는 모든 수정을 기록하므로 시간이 지남에 따라 AOF 파일이 방대해질 수 있습니다. 이를 방지하기 위해 Redis는 AOF 재작성을 제공합니다.

AOF 재작성은 데이터셋의 현재 상태를 재구성하는 데 필요한 최소한의 명령 집합만 포함하는 새롭고 최적화된 AOF 파일을 생성합니다. 이 프로세스는 현재 AOF 파일 크기가 기본 크기의 특정 배수를 초과할 때 자동으로 트리거됩니다.

auto-aof-rewrite-percentage 100  # AOF 파일이 기본 크기보다 100% 클 때 재작성
auto-aof-rewrite-min-size 64mb    # 파일이 최소 64MB가 아닌 한 재작성하지 않음

재작성에 대한 경고: RDB 저장과 마찬가지로 AOF 재작성은 프로세스 포크를 수반합니다. 시스템의 메모리가 부족한 경우 이 임시적인 메모리 사용량 두 배(실행 중인 인스턴스 + 재작성 중인 복사본)는 불안정 또는 스와핑을 유발할 수 있습니다.

결론

Redis 영속성 선택은 지연 시간과 내구성 사이의 직접적인 균형 잡기입니다. RDB는 빠른 복구와 최소한의 쓰기 오버헤드에서 탁월하지만 데이터 손실 위험이 있습니다. AOF는 우수한 데이터 안전성을 제공하지만 fsync 정책에 따라 쓰기 지연 시간을 유발할 수 있습니다.

합리적인 안전성을 갖춘 높은 처리량을 우선시하는 대부분의 프로덕션 워크로드의 경우, appendfsync everysec으로 AOF를 활성화하는 것이 표준 권장 사항입니다. 거의 제로 데이터 손실이 필요한 임무 수행에 중요한 시스템의 경우, RDB와 AOF를 모두 활성화하면 최고의 운영 복원력과 성능 튜닝 유연성을 제공합니다.