Redis 지속성 옵션: RDB 대 AOF 설명
Redis RDB(스냅샷)와 AOF(추가 전용 파일) 지속성 간의 중요한 선택을 마스터하세요. 이 가이드는 각 방법이 데이터를 캡처하고 복구하는 방법, 성능 및 내구성의 장단점 비교, 프로덕션 환경에서 두 전략을 모두 활성화하는 것이 최선의 방법인 이유를 자세히 설명합니다.
Redis 영속성 옵션: RDB와 AOF 설명
Redis 영속성은 Redis 서버가 재시작 또는 충돌 후 얼마나 많은 데이터를 복구할 수 있는지를 결정합니다. 두 가지 주요 옵션은 RDB 스냅샷과 AOF 로그이며, 올바른 선택은 애플리케이션이 손실을 감당할 수 있는 최근 데이터의 양에 따라 달라집니다.
Redis는 속도를 위해 데이터를 메모리에 유지합니다. 영속성은 Redis가 나중에 데이터를 재구축할 수 있도록 충분한 상태를 디스크에 기록합니다. RDB, AOF, 둘 다, 또는 아무것도 사용하지 않을 수 있지만, 프로덕션 시스템은 의도적으로 선택해야 합니다.
Redis 영속성 이해
Redis의 영속성은 인메모리 데이터셋의 현재 상태를 디스크에 기록하는 프로세스를 말합니다. 이를 통해 Redis는 서버가 재시작될 때 데이터를 다시 로드할 수 있습니다. 영속성이 활성화되지 않으면 모든 데이터는 종료 시 손실됩니다.
Redis는 RDB와 AOF를 동시에 지원하여 두 가지의 최상의 기능을 결합한 하이브리드 접근 방식을 제공합니다.
RDB 스냅샷
RDB는 데이터셋의 특정 시점 스냅샷을 생성하여 일반적으로 dump.rdb라는 이름의 컴팩트한 바이너리 파일에 기록합니다.
RDB 작동 방식
RDB는 일반적으로 Redis 프로세스를 포크하여 작동합니다. 자식 프로세스는 데이터셋을 디스크에 기록하는 동안 부모는 계속해서 클라이언트에 서비스를 제공합니다. RDB는 스냅샷이기 때문에 한 순간에 존재했던 데이터를 캡처합니다.
구성 및 스냅샷
RDB 구성은 redis.conf의 save 지시문으로 관리됩니다. 이러한 지시문은 Redis가 자동 스냅샷을 생성해야 하는 시점을 정의합니다:
# 1분 안에 1000개의 키가 변경되면 DB 저장
save 600 1000
# 10분 안에 10개의 키가 변경되면 DB 저장
save 300 10
# 1초 안에 10000개의 키가 변경되면 DB 저장
save 1 10000
자동 RDB 스냅샷을 비활성화하려면 save 지시문을 제거하거나 다음을 설정하세요:
save ""
필요할 때 BGSAVE 명령으로 수동 백그라운드 스냅샷을 트리거할 수도 있습니다.
RDB의 장점
- 컴팩트한 파일: RDB 파일은 백업, 복사 및 재해 복구 아카이브에 효율적입니다.
- 빠른 복구: 하나의 스냅샷을 로드하는 것이 일반적으로 긴 명령 로그를 재생하는 것보다 빠릅니다.
- 낮은 정상 쓰기 오버헤드: Redis는 모든 명령을 영속성 파일에 기록하지 않습니다.
RDB의 단점
- 데이터 손실 위험: 스냅샷 사이에 Redis가 충돌하면 마지막 성공적인 스냅샷 이후의 쓰기가 손실됩니다.
- 포킹 오버헤드: 대규모 데이터셋은
fork()를 비용이 많이 들게 하고 지연 시간 급증을 유발할 수 있습니다. - 전체 감사 로그가 아님: RDB는 최종 상태를 저장하며, 그 상태로 이어진 모든 쓰기를 저장하지 않습니다.
AOF 로그
AOF(추가 전용 파일)는 더 높은 수준의 데이터 내구성을 제공합니다. 스냅샷 대신 AOF는 서버가 수신한 모든 쓰기 작업을 추가 전용 형식으로 기록합니다.
AOF 작동 방식
AOF가 활성화되면 Redis는 SET, HSET, LPUSH와 같은 쓰기 명령을 추가 전용 파일에 기록합니다. 재시작 시 Redis는 해당 파일을 재생하여 데이터셋을 재구축합니다.
AOF 구성
AOF 영속성은 기본적으로 비활성화되어 있으며 redis.conf에서 명시적으로 활성화해야 합니다:
appendonly yes
중요하게도, AOF는 fsync 정책 구성을 허용하여 디스크에 쓰기가 강제되는 빈도를 결정합니다:
| fsync 정책 | 설명 | 내구성 vs. 성능 |
|---|---|---|
no |
OS가 동기화를 처리합니다(가장 드물게). | 가장 빠름, 손실 위험 가장 높음. |
everysec |
약 1초에 한 번 동기화합니다. | 좋은 균형. 일반적으로 서버 충돌 시 약 1초로 손실을 제한합니다. |
always |
모든 명령 후에 동기화합니다. | 가장 높은 내구성, 잠재적으로 상당한 성능 저하. |
AOF의 장점
- 더 높은 내구성:
appendfsync everysec은 일반적인 프로덕션 균형입니다.always는 더 엄격하지만 느립니다. - 읽기 가능한 의도: AOF는 쓰기 명령을 저장하므로 RDB 바이너리 파일보다 검사하기 쉬울 수 있습니다.
- 자동 압축: AOF 재작성은 큰 로그를 현재 상태를 재구축하는 데 필요한 최소 명령으로 축소할 수 있습니다.
AOF의 단점
- 더 큰 파일: AOF 파일은 명령을 저장하기 때문에 RDB 스냅샷보다 큰 경우가 많습니다.
- 느린 재시작: 긴 AOF를 재생하는 것은 RDB 스냅샷을 로드하는 것보다 오래 걸릴 수 있습니다.
- 더 많은 쓰기 오버헤드: Redis는 쓰기 명령을 추가하고
appendfsync설정에 따라 동기화해야 합니다.
AOF 재작성
파일 크기 증가를 방지하기 위해 Redis는 AOF 재작성을 구현합니다. 이 프로세스는 비동기적으로 현재 상태에 도달하는 데 필요한 명령만 포함하는 새롭고 최적화된 AOF 파일을 생성하여 중복되거나 오래된 명령(예: 동일한 키에 대한 여러 업데이트)을 효과적으로 폐기합니다.
RDB vs. AOF: 직접 비교
RDB, AOF 또는 둘 다 중에서 선택하는 것은 전적으로 복구 시간 및 데이터 손실 허용 오차에 대한 애플리케이션의 요구 사항에 따라 달라집니다.
| 기능 | RDB (스냅샷) | AOF (추가 전용 파일) |
|---|---|---|
| 내구성/데이터 손실 | 더 높은 잠재적 데이터 손실 (마지막 저장 이후). | 최소 데이터 손실 (1초 이하, 또는 fsync=always로 0). |
| 파일 크기 | 매우 컴팩트하고 최적화됨. | 명령 로깅으로 인해 더 큼. |
| 재시작 시간 | 스냅샷 로딩이 매우 빠름. | 느림, 명령 재생 필요. |
| 복잡성 | 간단함, 시간 간격으로 구성. | fsync 정책의 신중한 구성 필요. |
| 사용 사례 | 최근 데이터 손실이 허용되는 백업, 재해 복구. | 높은 내구성이 필요한 기본 영속성 메커니즘. |
모범 사례: RDB와 AOF 결합
많은 프로덕션 배포에서 RDB와 AOF를 모두 활성화하면 유용한 안전망을 제공합니다.
둘 다 활성화된 경우:
- AOF는 기본적인 고내구성 로그를 제공합니다.
- RDB는 빠르고 컴팩트한 백업 스냅샷을 제공합니다.
둘 다 활성화되면 Redis는 재시작 시 AOF를 로드합니다. 이는 일반적으로 마지막 RDB 스냅샷보다 더 완전하기 때문입니다. RDB는 여전히 복사, 테스트 및 보관하기 쉬운 컴팩트한 백업 파일을 제공합니다.
둘 다 활성화하는 방법
redis.conf에서 두 구성이 모두 설정되었는지 확인하세요:
# AOF 활성화
appendonly yes
# RDB 구성 유지 (예: 매시간 자동 저장)
save 3600 1
# AOF에 권장되는 fsync 정책
appendfsync everysec
AOF 재작성 팁:
BGREWRITEAOF명령을 사용하여 언제든지 수동으로 AOF 재작성을 트리거할 수 있습니다. 이는 대량 데이터 로드 또는 상당한 삭제 작업 후에 AOF 파일 크기를 즉시 줄이는 데 특히 유용합니다.
결론
컴팩트한 백업이 필요하고 마지막 스냅샷 이후의 최근 쓰기 손실을 감당할 수 있을 때 RDB를 사용하세요. Redis가 충돌 시 최소한의 손실로 생존해야 하는 데이터를 보유할 때 AOF를 사용하세요. 중요한 프로덕션 데이터의 경우 appendfsync everysec으로 AOF를 활성화하고, 백업용으로 RDB 스냅샷을 유지하며, 장애가 발생하기 전에 복원 시간을 테스트하세요.