최고의 Redis 지속성 전략 선택하기: RDB 대 AOF

인 메모리 데이터 구조 저장소인 Redis는 캐시, 세션 저장소, 메시지 브로커로서의 속도와 다용도로 유명합니다. 주요 작동은 인 메모리에서 이루어지지만, 프로덕션 배포 환경에서는 데이터 내구성과 복구 가능성을 보장하는 것이 종종 중요합니다. 이때 Redis 지속성(Persistence)이 등장하며, 데이터 세트의 상태를 디스크에 저장할 수 있게 해줍니다.

올바른 지속성 전략을 선택하는 것은 데이터 무결성, 복구 시간 및 성능에 미치는 영향을 균형 있게 고려해야 하는 중요한 결정입니다. Redis는 두 가지 주요 지속성 메커니즘인 Redis 데이터베이스 백업(RDB)과 추가 전용 파일(AOF)을 제공합니다. 각 방식의 미묘한 차이점, 장점, 상충 관계를 이해하면 특정 데이터 내구성 및 복구 요구 사항에 맞게 Redis를 최적으로 구성할 수 있습니다.

이 문서는 RDB와 AOF를 자세히 살펴보고, 각 방식의 작동 원리, 장단점, 실제 구성 예시, 그리고 강력한 데이터 보호를 위해 두 가지를 결합하는 방법을 탐구합니다. 이 글을 마치면 Redis 배포에 대해 정보에 입각한 결정을 내릴 수 있는 준비를 갖추게 될 것입니다.

Redis 지속성 이해하기

Redis에서의 지속성은 서버 재시작 또는 충돌 후 다시 로드할 수 있도록 인 메모리 데이터 세트를 디스크에 저장하는 기능을 의미합니다. 지속성이 없으면 Redis에 저장된 모든 데이터는 서버가 중지되거나 충돌할 경우 손실됩니다. Redis는 이를 달성하기 위해 두 가지 뚜렷한 방법을 제공합니다:

RDB (Redis Database Backup): 데이터 세트의 특정 시점 스냅샷입니다.
AOF (Append-Only File): 서버에서 수행된 모든 쓰기 작업의 로그입니다.

두 방법 모두 고유한 특성을 가지고 있으며 서로 다른 시나리오에 적합합니다.

Redis 데이터베이스 백업 (RDB)

RDB 지속성은 지정된 간격으로 Redis 데이터 세트의 특정 시점 스냅샷을 수행합니다. RDB 저장 작업이 트리거되면 Redis는 자식 프로세스를 포크(fork)합니다. 그런 다음 자식 프로세스는 전체 데이터 세트를 임시 RDB 파일에 씁니다. 파일 작성이 완료되면 이전 RDB 파일은 새 파일로 대체됩니다.

RDB 작동 방식

포크: Redis 서버는 새로운 자식 프로세스를 포크합니다.
스냅샷 생성: 자식 프로세스는 전체 데이터 세트를 임시 RDB 파일에 쓰기 시작합니다.
완료: 자식 프로세스가 쓰기를 완료하면 새 임시 파일로 이전 RDB 파일을 대체합니다.
정리: 자식 프로세스가 종료됩니다.

이 프로세스는 스냅샷을 찍는 동안에도 부모 프로세스가 응답 상태를 유지하므로 Redis가 클라이언트 요청을 계속 처리할 수 있도록 보장합니다.

RDB의 장점

압축된 백업: RDB 파일은 바이너리 압축되어 Redis 데이터 세트의 매우 간결한 표현을 제공합니다. 이는 백업 및 재해 복구에 이상적입니다.
빠른 재시작: 특히 대용량 데이터 세트의 경우, RDB 파일을 다시 로드하는 것이 AOF 파일을 재생하는 것보다 훨씬 빠릅니다. 단일 형식화된 바이너리 파일을 로드하기만 하면 되기 때문입니다.
최소한의 디스크 I/O: RDB 저장은 구성된 간격에서만 발생하므로 Redis는 저장하지 않을 때 최소한의 디스크 I/O만 수행합니다. 이는 일반 작업 중 더 높은 성능으로 이어질 수 있습니다.
전송 용이성: 단일의 압축된 파일이므로 RDB 백업은 재해 복구 또는 보관 목적으로 원격 데이터 센터로 쉽게 전송할 수 있습니다.

RDB의 단점

잠재적인 데이터 손실: 주된 단점은 데이터 손실 가능성입니다. Redis가 저장 지점 사이에 충돌하면 마지막 성공적인 RDB 저장 이후에 기록된 모든 데이터가 손실됩니다.
포크 중 성능 급증: 데이터 세트가 매우 큰 경우, 초기 fork() 작업은 특히 메모리 사용량이 높을 때 느릴 수 있으며 Redis 서버를 잠시 동안 차단할 수 있습니다.
실시간 지속성 아님: RDB는 실시간 데이터 지속성을 위해 설계되지 않았습니다. 몇 분간의 데이터 손실이 허용되는 시나리오에 가장 적합합니다.

RDB 구성

RDB 지속성은 redis.conf에서 save 지시어를 사용하여 기본적으로 활성화됩니다. 여러 save 규칙을 지정할 수 있습니다.

# 키가 1개 이상 변경되면 900초(15분)마다 데이터베이스 저장
save 900 1

# 키가 10개 이상 변경되면 300초(5분)마다 데이터베이스 저장
save 300 10

# 키가 10000개 이상 변경되면 60초마다 데이터베이스 저장
save 60 10000

# RDB 지속성 비활성화 (모든 save 지시어 주석 처리 또는 명시적으로 아래와 같이 설정)
# save ""

또한 redis-cli에서 SAVE(차단) 또는 BGSAVE(비차단) 명령을 사용하여 RDB 저장을 수동으로 트리거할 수 있습니다.

추가 전용 파일 (AOF)

AOF 지속성은 Redis 서버에서 수신하는 모든 쓰기 작업을 기록합니다. AOF는 전체 데이터 세트를 주기적으로 저장하는 대신 데이터 세트를 수정하는 명령을 기록합니다. Redis가 재시작될 때 AOF 파일에 있는 이 명령들을 재실행하여 원래의 데이터 세트를 재구성합니다.

AOF 작동 방식

명령어 로깅: Redis에 의해 실행되는 모든 쓰기 명령어는 AOF 파일에 추가됩니다.
fsync 정책: Redis에는 AOF 버퍼를 디스크에 동기화하는 빈도를 제어하기 위한 다양한 fsync 정책이 있습니다.
- appendfsync always: 모든 명령어 후에 동기화합니다. 최고의 내구성을 제공하지만 가장 느립니다.
- appendfsync everysec: 1초에 한 번 동기화합니다. 내구성과 성능 간의 좋은 균형을 제공합니다(기본값이며 권장됨).
- appendfsync no: 운영 체제가 AOF 버퍼를 디스크에 플러시하도록 의존합니다. 최고의 성능을 제공하지만 내구성은 가장 낮습니다.
AOF 재작성: 시간이 지남에 따라 AOF 파일은 중복된 명령(예: 동일한 키를 여러 번 업데이트하는 경우)으로 인해 매우 커질 수 있습니다. AOF 재작성은 현재 데이터 세트를 재구성하는 데 필요한 명령만 포함하는 새롭고 작은 AOF 파일을 생성하여 AOF 파일을 최적화합니다. 이 과정은 RDB의 포크 메커니즘과 유사합니다.

AOF의 장점

향상된 내구성: appendfsync always 또는 everysec를 사용하면 AOF는 RDB에 비해 우수한 데이터 내구성을 제공합니다. ( everysec의 경우 최대 1초, always의 경우 데이터 손실 없음)의 데이터만 손실할 수 있습니다.
적은 데이터 손실: 충돌 발생 시, fsync 정책에 따라 손실되는 데이터가 훨씬 적거나 전혀 없을 수 있습니다.
사람이 읽을 수 있음: AOF 파일은 사람이 읽을 수 있으므로 작업 기록을 이해하기가 더 쉽습니다. 이는 특정 시나리오에서 디버깅 또는 데이터 복구에 유용할 수 있습니다.

AOF의 단점

더 큰 파일 크기: AOF 파일은 명령을 저장하고 데이터를 압축하지 않기 때문에 동일한 데이터 세트의 RDB 파일보다 일반적으로 훨씬 큽니다.
느린 복구: 시작 시 큰 AOF 파일을 재생하는 것은 Redis가 각 명령을 실행해야 하므로 RDB 파일을 로드하는 것보다 느릴 수 있습니다.
성능 영향: fsync 정책에 따라 AOF는 더 많은 디스크 I/O를 발생시켜 쓰기 성능에 잠재적인 영향을 줄 수 있습니다. appendfsync always는 특히 영향을 많이 줍니다.
AOF 재작성 오버헤드: AOF 재작성이 파일 크기 관리에 도움이 되지만, 재작성 프로세스 자체가 CPU 및 I/O 리소스를 소모하며, RDB 포크와 유사하게 데이터 세트가 매우 클 경우 Redis를 일시적으로 차단할 수 있습니다.

AOF 구성

AOF를 활성화하려면 redis.conf에서 appendonly yes를 설정해야 합니다.

# AOF 지속성 활성화
appendonly yes

# 추가 전용 파일 이름 (기본값: "appendonly.aof")
appendfilename "appendonly.aof"

# appendfsync 옵션: always, everysec, no
appendfsync everysec

# 기본 크기보다 2배 크기가 되고 최소 64MB가 되면 AOF 파일 자동 재작성
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

RDB 대 AOF: 비교 개요

특징	RDB (Redis 데이터베이스 백업)	AOF (추가 전용 파일)
메커니즘	특정 시점 스냅샷 (바이너리 파일)	모든 쓰기 작업 기록 (텍스트 기반 명령어)
데이터 손실	저장 지점 간 데이터 손실 가능성 (분 단위)	데이터 손실 최소화 (`everysec` 사용 시 초 단위, `always` 사용 시 없음)
성능	일반 작업 중 더 높은 쓰기 성능, `fork()` 시 차단 가능성	강력한 `fsync` 사용 시 쓰기 속도 저하, 더 일관적인 I/O
파일 크기	매우 압축된 바이너리 파일	일반적으로 더 큼, 작업에 따라 증가
복구 시간	대용량 데이터 세트에 더 빠름	대용량 데이터 세트에 더 느림 (명령어 재생)
백업 용이성	단일 압축 파일; 백업/재해 복구에 용이	재작성 없이는 관리하기 더 큰 파일
가독성	사람이 읽을 수 없음	사람이 읽을 수 있음 (명령어)
Redis 기본값	예 (`save` 지시어 포함)	아니요 (`appendonly no`가 기본값)

하이브리드 접근 방식: RDB와 AOF 함께 사용 (Redis 4.0+)

Redis 4.0 이후부터는 RDB 및 AOF 지속성을 결합하는 것이 가능하며 종종 권장됩니다. 둘 다 활성화되면 Redis는 더 나은 내구성을 보장하므로 시작 시 데이터 세트를 재구성하는 데 주로 AOF 파일을 사용합니다. 그러나 Redis 4.0+의 AOF 재작성 프로세스는 RDB 접두어로 시작하고 그 뒤에 AOF 명령을 추가하는 하이브리드 AOF 파일을 생성합니다. 이는 두 가지 장점을 결합합니다.

더 빠른 재작성: 하이브리드 AOF의 RDB 부분은 재작성 프로세스를 위한 훨씬 더 빠른 초기 스냅샷을 제공합니다.
더 빠른 재시작 (잠재적으로): Redis가 다시 시작될 때, 먼저 AOF 파일의 RDB 부분을 로드하여 더 빠르게 처리한 다음 후속 AOF 명령을 재생합니다.
향상된 내구성: AOF의 최소한의 데이터 손실 이점을 여전히 누릴 수 있습니다.

이 하이브리드 모드를 활성화하려면 appendonly yes와 RDB save 지시어가 모두 구성되어 있으면 됩니다.

올바른 지속성 전략 선택하기

이상적인 지속성 전략은 데이터 내구성, 성능 및 복구 시간에 대한 애플리케이션의 특정 요구 사항에 따라 달라집니다.

1. RDB만 사용해야 하는 경우

주요 사용 사례: 캐시 / 중요하지 않은 데이터: Redis를 주로 캐시로 사용하여 충돌 시 데이터 손실이 허용되거나 데이터가 다른 소스에서 쉽게 재구성될 수 있는 경우.
높은 성능 요구 사항: 쓰기 성능이 가장 중요하고 간헐적인 데이터 손실이 허용되는 경우.
재해 복구 백업: RDB 파일은 장기 보관 또는 재해 복구를 위한 주기적인 스냅샷 생성에 탁월합니다. BGSAVE를 cron으로 예약하고 .rdb 파일을 외부 위치로 이동할 수 있습니다.
메모리 효율성: 디스크 공간이 매우 제한적인 경우.

2. AOF만 사용해야 하는 경우

주요 사용 사례: 절대적인 내구성: 모든 쓰기 작업이 중요하고 몇 초의 데이터 손실도 용납되지 않는 경우(예: 금융 거래, 중요한 사용자 데이터). 이 경우 상당한 성능 비용이 발생하지만 appendfsync always를 고려할 수 있습니다.
디버깅/감사: AOF의 사람이 읽을 수 있는 특성은 데이터 변경 사항을 이해하는 데 유용할 수 있습니다.

3. RDB와 AOF 모두 사용해야 하는 경우 (대부분의 중요 애플리케이션에 권장)

균형 잡힌 내구성과 복구: 데이터 내구성이 중요하지만 효율적인 재시작 및 백업도 원하는 프로덕션 시스템에 일반적으로 권장되는 접근 방식입니다.
견고성: 추가적인 보호 계층을 제공합니다. 한 가지 지속성 방법이 손상되더라도 다른 방법으로 복구할 수 있을 수 있습니다.
Redis 4.0+: 최적화된 AOF 재작성 및 잠재적으로 더 빠른 복구를 위해 RDB 접두사 AOF 형식을 활용합니다.

실제 팁 및 모범 사례

디스크 사용량 모니터링: RDB와 AOF 모두 상당한 디스크 공간을 차지할 수 있습니다. 특히 AOF 재작성 또는 RDB 저장 전에 공간이 부족해지지 않도록 디스크 사용량을 모니터링하십시오.
fsync 정책: AOF의 경우, appendfsync everysec이 가장 일반적이고 권장되는 선택으로, 내구성과 성능 간의 균형을 잘 제공합니다. 중요한 데이터에 대해서는 appendfsync no를 피하십시오.
AOF 재작성: 리소스 소모가 과도하지 않으면서 AOF 파일이 정기적으로 최적화되도록 auto-aof-rewrite-percentage 및 auto-aof-rewrite-min-size를 신중하게 구성하십시오.
별도의 디스크/위치: 가능하다면 운영 체제 및 애플리케이션 로그와 다른 디스크 또는 파티션에 지속성 파일(AOF 및 RDB)을 저장하여 I/O 경합을 방지하십시오.
외부 백업: 지속성 전략에 관계없이 강력한 재해 복구를 위해 RDB 및 AOF 파일을 정기적으로 외부 위치(예: S3, Google Cloud Storage)에 백업하십시오.
복구 테스트: 선택한 지속성 전략으로 복구 프로세스를 주기적으로 테스트하여 데이터가 성공적으로 복원될 수 있는지 확인하십시오.

결론

Redis 지속성은 안정적인 데이터 관리의 초석입니다. RDB와 AOF 모두 고유한 장점과 상충 관계를 제공합니다. RDB는 빠른 재시작 및 백업을 위한 압축된 스냅샷을 제공하므로 중요도가 낮은 데이터 또는 주기적인 보관에 이상적입니다. AOF는 모든 명령을 기록하여 우수한 내구성을 제공하므로 최소한의 데이터 손실이 가장 중요한 중요 데이터 세트에 적합합니다.

대부분의 프로덕션 환경에서는 RDB와 AOF 모두(특히 Redis 4.0+의 하이브리드 형식을 사용)를 활용하는 것이 가장 강력한 솔루션을 제공하며, 효율적인 복구와 강력한 데이터 내구성을 모두 제공합니다. 애플리케이션 요구 사항을 각 지속성 방법의 특성과 신중하게 비교하여 귀중한 데이터를 보호하고 Redis 배포의 복원력을 보장하는 정보에 입각한 결정을 내릴 수 있습니다.