Redis 지속성 옵션: RDB와 AOF 상세 설명
Redis는 인메모리 데이터 구조 저장소로서 뛰어난 속도로 잘 알려져 있으며, 흔히 캐시 또는 메시지 브로커로 사용됩니다. 그러나 데이터가 속도 향상을 위해 주로 RAM에 상주하는 반면, 운영 환경 배포에서는 재시작 또는 충돌 시 데이터가 보존되도록 보장하는 메커니즘이 필요합니다. 이때 지속성이 중요한 역할을 합니다. Redis는 두 가지 주요 내장 지속성 메커니즘을 제공합니다: Redis 데이터베이스 백업 (RDB)과 추가 전용 파일 (AOF). 이 두 가지 방식 간의 장단점을 이해하는 것은 애플리케이션의 내구성 및 성능 요구사항에 맞춰 Redis를 적절하게 구성하는 데 필수적입니다.
이 가이드에서는 RDB와 AOF가 어떻게 작동하는지, 각 방식의 장점과 단점을 비교하고, 어떤 전략을 언제 사용해야 하는지에 대한 지침을 자세히 설명합니다.
Redis 지속성 이해
Redis의 지속성은 인메모리 데이터셋의 현재 상태를 디스크에 쓰는 과정을 의미합니다. 이를 통해 Redis는 서버 재시작 시 데이터를 다시 로드할 수 있습니다. 지속성이 활성화되지 않으면 종료 시 모든 데이터가 손실됩니다.
Redis는 RDB와 AOF를 동시에 지원하여, 두 방식의 최고의 기능을 결합한 하이브리드 접근 방식을 제공합니다.
1. Redis 데이터베이스 백업 (RDB)
RDB (Redis Database Backup)는 Redis의 기본 지속성 메커니즘입니다. 지정된 간격으로 전체 데이터셋의 주기적인 스냅샷을 수행합니다.
RDB 작동 방식
RDB는 주 Redis 프로세스를 포크하여 작동합니다. 이 자식 프로세스는 현재 메모리 내용을 dump.rdb라는 압축된 이진 파일로 디스크에 씁니다. 스냅샷이기 때문에 특정 시점의 데이터를 캡처합니다.
구성 및 스냅샷
RDB 구성은 redis.conf 파일의 save 지시어를 통해 관리됩니다. 이 지시어들은 자동 저장이 발생하는 조건을 정의합니다:
# 1분 안에 1000개의 키가 변경되면 DB를 저장합니다.
save 600 1000
# 10분 안에 10개의 키가 변경되면 DB를 저장합니다.
save 300 10
# 1초 안에 10000개의 키가 변경되면 DB를 저장합니다.
save 1 10000
RDB 지속성을 완전히 비활성화하려면 모든 save 지시어를 주석 처리하거나 SAVE 명령을 수동으로만 사용할 수 있습니다.
RDB의 장점
- 컴팩트한 파일: RDB 파일은 고도로 최적화되고 압축되어 있으며 컴팩트하여 백업 및 빠른 전송에 이상적입니다.
- 빠른 복구: 단일 스냅샷 파일이므로 재시작 시 데이터 로딩이 매우 빠릅니다.
- 성능: 저장은 프로세스를 포크하여 비동기적으로 발생하므로, 주 스레드는 쓰기 작업 중 차단되지 않습니다 (포크 자체는 약간의 지연 시간 급증을 유발할 수 있음).
RDB의 단점
- 데이터 손실 위험: Redis가 예약된 저장 시점 사이에 충돌하면, 마지막 스냅샷 이후에 발생한 모든 쓰기 작업이 손실됩니다.
- 포킹 오버헤드: 매우 큰 데이터셋의 경우, 스냅샷을 생성하는 데 필요한 포크 작업이 상당한 시스템 리소스를 소비하고 짧은 지연 시간을 유발할 수 있습니다.
2. 추가 전용 파일 (AOF)
AOF (Append-Only File)는 더 높은 수준의 데이터 내구성을 제공합니다. 스냅샷 대신, AOF는 서버가 수신한 모든 쓰기 작업을 추가 전용 형식으로 기록합니다.
AOF 작동 방식
지속성이 활성화되면 Redis는 모든 쓰기 명령(예: SET, LPUSH)을 디스크의 AOF 파일로 리디렉션합니다. Redis가 재시작되면 이 명령들을 순차적으로 재생하여 종료 전과 정확히 동일한 데이터셋을 재구성합니다.
AOF 구성
AOF 지속성은 기본적으로 비활성화되어 있으며 redis.conf에서 명시적으로 활성화해야 합니다:
appendonly yes
결정적으로, AOF는 fsync 정책을 구성하여 쓰기 작업이 디스크에 강제로 동기화되는 빈도를 결정할 수 있습니다:
| fsync 정책 | 설명 | 내구성 vs. 성능 |
|---|---|---|
no |
OS가 동기화를 처리 (가장 드물게). | 가장 빠르지만, 손실 위험이 가장 높음. |
everysec |
초당 한 번 동기화 (기본값 및 권장). | 좋은 균형. 최대 1초 분량의 데이터 손실. |
always |
모든 명령 후 동기화. | 최고의 내구성, 잠재적으로 상당한 성능 저하. |
AOF의 장점
- 높은 내구성:
fsync를always로 설정하면 거의 데이터 손실 없이 작동할 수 있습니다. - 로그 재생: AOF 파일에는 작업의 시간 순서 로그가 포함되어 있어 잠재적인 데이터 손상을 디버깅하기 쉽습니다.
AOF의 단점
- 더 큰 파일: AOF 파일은 최종 데이터 상태 대신 명령을 저장하기 때문에 일반적으로 해당 RDB 파일보다 훨씬 큽니다.
- 느린 재시작: 시작 시 잠재적으로 수천 개의 명령을 재생하는 데 단일 RDB 스냅샷을 로드하는 것보다 시간이 더 오래 걸립니다.
- 쓰기 증폭: 명령이 개별적으로 기록되므로 RDB 스냅샷 방식에 비해 쓰기 오버헤드가 약간 더 높을 수 있습니다.
AOF 재작성
파일 크기 증가에 대응하기 위해 Redis는 AOF 재작성을 구현합니다. 이 프로세스는 현재 상태에 도달하는 데 필요한 명령만 포함하는 새로운 최적화된 AOF 파일을 비동기적으로 생성하여, 중복되거나 더 이상 사용되지 않는 명령(동일한 키에 대한 여러 업데이트와 같은)을 효과적으로 폐기합니다.
RDB vs. AOF: 직접 비교
RDB, AOF 또는 둘 다를 선택하는 것은 복구 시간 및 데이터 손실 허용 오차에 대한 애플리케이션의 요구사항에 전적으로 달려 있습니다.
| 기능 | RDB (스냅샷) | AOF (추가 전용 파일) |
|---|---|---|
| 내구성/데이터 손실 | 잠재적인 데이터 손실이 더 높음 (마지막 저장 이후). | 최소한의 데이터 손실 (최대 1초, 또는 fsync=always 설정 시 0). |
| 파일 크기 | 매우 컴팩트하고 최적화됨. | 명령 로깅으로 인해 더 큼. |
| 재시작 시간 | 스냅샷 로딩이 매우 빠름. | 느리며, 명령 재생이 필요함. |
| 복잡성 | 간단하며, 시간 간격으로 구성. | fsync 정책의 신중한 구성이 필요함. |
| 사용 사례 | 최근 데이터 손실이 허용되는 백업, 재해 복구. | 높은 내구성이 요구되는 주된 지속성 메커니즘. |
모범 사례: RDB와 AOF 결합
대부분의 현대적인 운영 환경 배포에서 권장되는 접근 방식은 RDB와 AOF 지속성을 동시에 활성화하는 것입니다.
두 가지 모두 활성화 시:
1. AOF는 주된, 높은 내구성을 가진 로그를 제공합니다.
2. RDB는 빠르고 컴팩트한 백업 스냅샷을 제공합니다.
재시작 시 Redis는 완전한 내구성을 위해 AOF 파일 로드를 선호합니다. AOF 파일이 없거나 손상된 경우, RDB 파일 로드로 대체됩니다. 또한, AOF 재작성 프로세스는 종종 RDB 파일을 효율적인 시작점으로 사용하여 두 가지 방법의 장점을 결합합니다.
두 가지 모두 활성화 방법
redis.conf에서 두 구성이 모두 설정되었는지 확인하세요:
# AOF 활성화
appendonly yes
# RDB 구성 유지 (예: 매 시간 자동 저장)
save 3600 1
# AOF에 권장되는 fsync 정책
appendfsync everysec
AOF 재작성 팁:
BGREWRITEAOF명령을 사용하여 언제든지 수동으로 AOF 재작성을 트리거할 수 있습니다. 이는 대규모 대량 데이터 로드 또는 중요한 데이터 삭제 작업 후에 AOF 파일 크기를 즉시 줄이는 데 특히 유용합니다.