Redis 데이터의 영속성 (Redis Persistence)

Redis는 인메모리 데이터베이스로서 빠른 속도를 자랑하지만, 메모리에 저장된 데이터를 디스크에 저장하는 영속성(Persistence) 기능도 제공합니다. 이 기능 덕분에 서버가 재시작되더라도 데이터 유실 없이 복구할 수 있습니다. 그러나 이 기능이 잘못 사용되면 장애의 원인이 되기도 합니다. 따라서 Redis의 영속성 방식인 RDB와 AOF에 대해 깊이 이해하고 적절히 사용하는 것이 중요합니다.

본론

RDB (Snapshotting) 방식

RDB는 Redis의 데이터를 특정 시점에 스냅샷 형태로 디스크에 저장하는 방식입니다. 기본적으로 Redis는 .rdb 파일에 데이터를 저장하며, 서버가 재시작될 때 이 파일을 읽어 데이터를 복구합니다. RDB 방식은 서버의 부담을 최소화하며, 백업 목적으로 유용합니다. 그러나 데이터 저장이 주기적으로 이루어지므로 마지막 스냅샷 이후의 데이터는 유실될 수 있습니다. snapshot을 추출하는데 시간이 오래걸리고 도중에 서버가 꺼지면 이후의 데이터를 모두 사라진다는 단점이 있다.  실제로 SAVE 옵션으로 50GB 의 메모리 상태를 저장한다면 7 ~ 8분 정도 소요된다고 한다.

RDB 설정 예시:

• save 900 1: 900초 동안 1번 이상 쓰기 발생 시 저장
• rdbcompression yes: 데이터를 LZF로 압축
• rdbchecksum yes: 데이터 무결성을 보장하기 위해 Checksum 사용

RDB 저장 방식에는 SAVE와 BGSAVE 두 가지가 있다.

• SAVE는 순간적으로 redis의 동작을 정지시키고 그 snapshot를 디스크에 저장.(blocking 방식) 
• BGSAVE는 백그라운드 SAVE 라는 의미로 별도의 자식 프로세스를 띄운 후, 명령어 수행 당시의 snapshot을 disk에 저장하고, redis는 동작을 멈추지 않게 된다. (non-blocking 방식)

RDB 방식은 메모리의 내용을 그대로 저장하기 때문에 서버 재시작 시 빠르게 복구할 수 있습니다. 그러나, 백업 주기에 따라 데이터 손실이 발생할 수 있으며, 백업 과정에서 많은 메모리와 시간을 소비할 수 있습니다.

AOF (Append Only File) 방식

AOF 방식은 Redis에서 발생하는 모든 쓰기 연산을 로그 파일에 기록하는 방식입니다. 기본적으로 appendonly.aof 파일에 기록되며, 서버가 재시작될 때 이 로그를 재실행하여 데이터를 복구합니다. AOF 방식은 실시간 데이터 보존에 강점을 가지며, 데이터 손실이 거의 없습니다. 또한, 텍스트 파일 형식으로 저장되므로 필요 시 편집이 가능합니다.

AOF 설정 예시:

• appendonly yes: AOF 사용 여부 설정
• appendfsync everysec: 1초마다 디스크에 동기화
• auto-aof-rewrite-percentage 100: 파일 크기가 처음의 100% 이상 커지면 Rewrite 실행

AOF 방식은 매번 명령을 기록하기 때문에 로그 파일 크기가 커질 수 있으며, 복구 시 로그를 모두 재실행해야 하므로 시간이 오래 걸립니다. 이 문제를 해결하기 위해 AOF 리라이트 기능을 제공하여 파일 크기를 줄이고 복구 시간을 단축할 수 있습니다.

선택 기준

• 데이터 중요도
  • AOF 선택 시: 데이터가 매우 중요하고 손실을 최소화해야 하는 경우입니다. 예를 들어, 금융 거래 데이터나 사용자의 중요한 개인 정보를 다루는 경우가 해당됩니다.
  • RDB 선택 시: 데이터가 일시적이거나 약간의 손실이 허용되는 경우입니다. 예를 들어, 세션 데이터나 캐시 데이터와 같이 재생성이 가능한 데이터를 다룰 때 적합합니다.
• 성능 요구사항
  • RDB 선택 시: 높은 쓰기 성능이 필요한 경우입니다. RDB는 주기적으로 스냅샷을 생성하므로 지속적인 쓰기 작업에 덜 부담을 줍니다.
  • AOF 선택 시: 데이터의 안정성이 성능보다 중요한 경우입니다. AOF는 모든 쓰기 작업을 기록하므로 더 안정적이지만, 성능에는 약간의 영향을 줄 수 있습니다.
• 복구 시간
  • RDB 선택 시: 서버 재시작 시 빠른 복구가 필요한 경우입니다. RDB는 스냅샷을 바로 로드하므로 복구 속도가 빠릅니다.
  • AOF 선택 시: 데이터의 완전한 복구가 중요한 경우입니다. AOF는 모든 작업을 재실행하므로 복구에 시간이 더 걸리지만, 더 완전한 데이터 복구가 가능합니다.
• 디스크 공간
  • RDB 선택 시: 디스크 공간이 제한적인 경우입니다. RDB는 특정 시점의 스냅샷만 저장하므로 파일 크기가 작습니다.
  • AOF 선택 시: 충분한 디스크 공간이 있는 경우입니다. AOF는 모든 작업을 기록하므로 파일 크기가 더 큽니다.
• 백업 빈도
  • RDB 선택 시: 주기적인 백업만으로 충분한 경우입니다. 예를 들어, 하루에 한 번 백업이 필요한 경우에 적합합니다.
  • AOF 선택 시: 실시간에 가까운 백업이 필요한 경우입니다. 모든 쓰기 작업을 기록하므로 거의 실시간 백업이 가능합니다.

결론

RDB와 AOF는 각각의 장단점이 뚜렷합니다. 실제로는 두 방식을 함께 사용하는 것이 가장 이상적일 수 있습니다. Redis 4.0 이후부터는 “혼합 지속성” 모드를 지원하여 두 방식의 장점을 모두 활용할 수 있게 되었습니다. 최종적으로, 여러분의 시스템 요구사항, 데이터 특성, 그리고 운영 환경을 고려하여 적절한 방식을 선택하거나 두 방식을 조합하여 사용하는 것이 좋습니다. 지속적인 모니터링과 튜닝을 통해 최적의 설정을 찾아가는 것이 중요합니다.