데이터 손실 방지를 위한 모범 사례: RDB vs AOF 구성

Redis 지속성은 오해하기 쉽습니다. Redis는 데이터베이스처럼 느껴지지만 메모리처럼 동작하기 때문입니다. 지속성 없이 재시작하면 데이터가 사라집니다. 지속성을 활성화했지만 부주의하게 조정하면 최근 쓰기 작업이 손실되거나, 디스크 압력 중에 클라이언트가 중단되거나, 장애 발생 시 Redis 프로세스와 동일한 실패한 볼륨에 데이터의 유일한 복사본이 있는 것을 발견할 수 있습니다.

올바른 Redis 데이터 손실 전략은 한 가지 솔직한 질문에서 시작됩니다. 마지막 몇 초, 몇 분 또는 몇 시간 동안의 쓰기 작업이 사라지면 어떻게 될까요? 제품 페이지의 캐시는 일반적으로 다시 빌드할 수 있습니다. 세션 저장소는 사용자를 짜증나게 할 수 있지만 비즈니스를 파괴하지는 않습니다. 대기열, 속도 제한 원장, 장바구니 저장소 또는 기능 플래그 저장소는 훨씬 더 엄격한 내구성이 필요할 수 있습니다. RDB와 AOF는 Redis가 제공하는 두 가지 도구이며, 이 문제의 다른 부분을 해결합니다.

Redis 지속성 메커니즘 이해

Redis에는 두 가지 주요 지속성 모드가 있습니다.

RDB 스냅샷

RDB는 일반적으로 dump.rdb로 데이터 세트의 특정 시점 스냅샷을 디스크에 씁니다. Redis는 자식 프로세스를 포크하고, 자식은 데이터 세트를 직렬화하며, 부모는 계속해서 클라이언트에 서비스를 제공합니다. 이로 인해 RDB는 백업, 복제본 및 빠른 재시작에 유용하지만 명확한 절충점이 있습니다. 마지막으로 성공한 스냅샷 이후에 기록된 모든 것은 프로세스나 호스트가 실패하면 손실될 수 있습니다.

일반적인 RDB 설정은 다음과 같습니다.

save 900 1       # 15분 후에 저장, 최소 1개 키 변경 시
save 300 10      # 5분 후에 저장, 최소 10개 키 변경 시
save 60 10000    # 1분 후에 저장, 최소 10000개 키 변경 시
dbfilename dump.rdb
dir /var/lib/redis

이러한 save 줄은 Redis가 정확히 해당 일정에 저장한다는 약속이 아닙니다. 이는 트리거 규칙입니다. 간격 동안 충분한 키가 변경되면 Redis는 백그라운드 저장을 시작합니다. 디스크가 느리거나, 데이터 세트가 방대하거나, 호스트의 메모리가 부족하면 백그라운드 저장이 실패하거나 포크 및 쓰기 중 복사 압력으로 인해 지연 시간이 발생할 수 있습니다.

RDB는 컴팩트한 스냅샷과 빠른 복원 동작을 원할 때 가장 강력합니다. 최근 데이터 손실에 대한 허용 오차가 낮을 때 가장 취약합니다.

AOF 로깅

AOF(추가 전용 파일 지속성)는 쓰기 명령을 기록하여 Redis가 재시작 시 이를 재생할 수 있도록 합니다. 일반적으로 RDB보다 더 나은 내구성을 제공합니다. 스냅샷 일정보다 더 자주 쓰기 작업을 플러시할 수 있기 때문입니다. 절충점은 더 많은 디스크 I/O, 재작성 전에 더 큰 파일, 그리고 Redis가 큰 로그를 재생해야 하는 경우 때때로 더 느린 시작입니다.

핵심 설정은 다음과 같습니다.

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb
aof-rewrite-incremental-fsync yes

중요한 줄은 appendfsync입니다. everysec를 사용하면 Redis는 운영 체제에 대략 1초에 한 번씩 AOF를 플러시하도록 요청합니다. 일반적인 Redis 프로세스 충돌에서는 일반적으로 손실이 약 1초 이내의 쓰기로 제한됩니다. 전체 호스트 충돌 또는 스토리지 장애의 경우 정확한 손실은 OS, 파일 시스템, 디스크 캐시 및 스토리지 동작에 따라 달라지므로 수학적 보장으로 설명하지 마십시오.

appendfsync always는 모든 쓰기 후에 플러시하며 훨씬 더 비용이 많이 듭니다. 쓰기 볼륨이 적당한 소규모의 중요한 Redis 배포에 적합할 수 있지만 실제 트래픽에서는 지연 시간에 심각한 영향을 줄 수 있습니다. appendfsync no는 OS가 플러시 시점을 결정하도록 합니다. 빠르지만 훨씬 더 넓고 예측 불가능한 손실 창을 제공합니다.

데이터 손실 방지를 위한 모범 사례

Redis가 로드할 파일을 이해하는 경우에만 둘 다 사용

많은 프로덕션 Redis 배포는 RDB와 AOF를 모두 활성화합니다. Redis가 재구축하기 어려운 데이터를 저장하는 경우 이는 합리적인 기본값입니다. RDB는 컴팩트한 백업 아티팩트를 제공합니다. AOF는 더 작은 최근 손실 창을 제공합니다.

다음과 같은 구성을 사용하십시오.

save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

복원 중에 한 가지 세부 사항이 중요합니다. AOF가 활성화되면 Redis는 일반적으로 시작 시 AOF 데이터를 로드합니다. 이는 RDB 스냅샷보다 더 완전할 것으로 예상되기 때문입니다. Redis가 RDB를 먼저 로드한 다음 AOF로 대체할 것이라고 가정하지 마십시오. 특히 최신 다중 파트 AOF 형식을 사용하는 Redis 버전의 경우 Redis 버전 및 배포 레이아웃에 대한 복원 경로를 테스트하십시오.

손실 창에서 거꾸로 appendfsync 선택

Redis 설정이 아닌 비즈니스 영향부터 시작하십시오.

Redis가 일회용 캐시인 경우 RDB만으로 충분할 수 있으며, 애플리케이션이 안전하게 다시 채우는 경우 지속성이 전혀 없어도 됩니다. Redis에 세션이 포함된 경우 appendfsync everysec이 실용적인 균형인 경우가 많습니다. Redis가 승인된 쓰기 손실이 실제 비즈니스 피해를 생성하는 워크플로의 일부인 경우 Redis 지속성만으로는 올바른 내구성 경계가 아닐 수 있습니다. Redis 외부에 기본 데이터베이스, 내구성 있는 대기열 또는 애플리케이션 수준의 쓰기 전 로그 동작이 필요할 수 있습니다.

대부분의 운영 Redis 사용의 경우 다음부터 시작하십시오.

appendonly yes
appendfsync everysec

그런 다음 always 쪽으로 이동하거나 AOF에서 멀어질지 결정하기 전에 지연 시간, 디스크 쓰기 시간, AOF 재작성 동작 및 재시작 시간을 모니터링하십시오.

RDB 스냅샷 유지, 하지만 너무 공격적으로 만들지 마십시오

빈번한 RDB 저장은 스냅샷 간에 손실되는 데이터 양을 줄이지만 포크 빈도도 증가시킵니다. 대규모 Redis 프로세스를 포크하는 것은 비용이 많이 들 수 있으며, 자식 저장 중 쓰기는 쓰기 중 복사 메모리 압력을 생성합니다. Redis 인스턴스에 40GB 데이터 세트가 있고 쓰기 속도가 높은 경우 매분 저장하면 호스트가 메모리 및 디스크 압력 아래에서 너무 많은 시간을 보내기 때문에 신뢰성이 저하될 수 있습니다.

합리적인 RDB 저장 규칙은 쓰기 속도 및 복구 기대치에 따라 다릅니다. 소규모 캐시는 문제 없이 자주 스냅샷을 찍을 수 있습니다. 대규모 세션 저장소는 최근 내구성을 위해 더 적은 수의 RDB 스냅샷과 AOF가 필요할 수 있습니다. Redis 구성 파일뿐만 아니라 BGSAVE 중 INFO persistence, Redis 로그 및 호스트 메모리를 모니터링하십시오.

AOF 재작성을 긴급 상황이 아닌 일반 유지 관리로 취급

AOF 파일은 쓰기를 기록하기 때문에 커집니다. Redis는 백그라운드에서 이를 컴팩트한 표현으로 재작성합니다. 기본값은 종종 괜찮은 시작점입니다.

aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb

이는 Redis가 최소 크기 이상일 때 이전 재작성 후 크기와 비교하여 AOF가 크게 증가한 경우 재작성을 고려한다는 것을 의미합니다. 재작성이 지속적으로 발생하면 최소 크기를 늘리거나 시끄러운 쓰기 패턴을 조사하십시오. 재작성 없이 AOF가 오랫동안 커지면 로그, 디스크 공간 및 INFO persistence를 확인하십시오.

수동으로 재작성을 트리거할 수 있습니다.

redis-cli BGREWRITEAOF

가능하면 사용량이 적은 시간에 수행하십시오. 재작성은 파일이 영원히 커지도록 두는 것보다 안전하지만 여전히 CPU, 디스크 대역폭 및 쓰기 중 복사 메모리를 소비합니다.

지속성 파일을 다른 곳에 백업

지속성은 백업이 아닙니다. 동일한 호스트의 지속성 파일은 Redis 프로세스 재시작으로부터 보호합니다. 디스크 손실, 실수로 인한 삭제, 데이터 디렉토리를 덮어쓰는 잘못된 배포 또는 FLUSHALL을 실행하는 운영자 실수로부터 보호하지 않습니다.

RDB 및 AOF 파일을 별도의 스토리지에 복사하십시오. 파일 시스템 스냅샷 또는 클라우드 볼륨 스냅샷을 사용하는 경우 별도의 인스턴스에서 복원을 테스트하십시오. RDB 복사본의 경우 쓰여지고 있는 파일보다는 완료된 스냅샷 파일을 복사하는 것이 좋습니다. AOF의 경우 파일 이름을 중심으로 백업 스크립트를 작성하기 전에 Redis 버전의 파일 레이아웃을 이해하십시오.

데이터 손실을 예측하는 신호 관찰

인시던트 중 유용한 명령은 다음과 같습니다.

redis-cli INFO persistence

실패한 백그라운드 저장, AOF 재작성 상태, 마지막 저장 시간 및 지연된 fsync 표시기를 찾으십시오. 이를 호스트 메트릭(디스크 지연 시간, 여유 디스크 공간, 메모리 여유 공간 및 커널 OOM 이벤트)과 결합하십시오. BGSAVE가 몇 시간 동안 실패하고 아무도 알아차리지 못하면 Redis 구성은 안전해 보일 수 있지만 실제 복구 지점은 점점 더 오래됩니다.

가용성을 위해 복제 또는 Sentinel 사용, 유일한 백업으로 사용하지 마십시오

복제본, Redis Sentinel 및 Redis Cluster는 가용성에 도움이 됩니다. 모든 데이터 손실 문제를 자동으로 해결하지는 않습니다. 잘못된 쓰기, 실수로 인한 삭제 또는 애플리케이션 버그는 빠르게 복제될 수 있습니다. 장애 조치(failover)는 복제 지연이 있는 경우 최근 쓰기가 누락된 복제본을 승격시킬 수도 있습니다. 설계에 지속성, 백업 및 복원 테스트를 포함시키십시오.

많은 팀의 실용적인 설정은 appendfsync everysec이 있는 AOF, 합리적인 주기의 RDB 스냅샷, 외부 백업, 지속성 실패 모니터링 및 테스트된 복원 실행 설명서입니다. Redis는 이러한 형태로 안정적일 수 있지만 지속성을 체크리스트가 아닌 운영 시스템으로 취급하는 경우에만 가능합니다.