Redis 데이터를 disk에 쓰는 방법(영속성)

https://redis.io/docs/management/persistence/

Redis는 데이터를 영구적인 저장소(예: SSD)에 기록하는 여러 가지 영속성 옵션을 제공한다.
RDB(Redis Database), AOF(Append Only File), RDB와 AOF의 결합 등이 있다.
각각의 장단점과 사용 시 고려해야 할 사항들에 대해 이해하고 적절하게 구성하여야 한다.

RDB

RDB는 압축된 데이터 세트의 스냅샷을 저장한다.
Redis의 스냅샷 기능은 데이터 세트의 상태를 디스크에 주기적으로 저장하는데, 이 파일을 Redis 데이터를 백업하거나, 시스템 재시작 시 데이터를 복구하는 데 사용된다. 기본적으로 Redis는 dump.rdb라는 binary 파일에 데이터 세트가 저장된다.

사용자가 스냅샷에 대한 트리거를 설정 할 수 있다.

save 60 1000
# 1000개의 key가 변경된 경우 60초마나 덤프

또는 사용자가 수동으로 SAVE 또는 BGSAVE 명령을 호출하여 스냅샷을 생성할 수도 있다.

Redis가 데이터 세트를 디스크에 덤프할 때, 먼저 Redis는 자식 프로세스를 생성한다. (fork). 이 프로세스에서 임시적으로 RDB 파일을 생성한 뒤, 성공적으로 덤프가 완료되면 기존 파일을 덮어씌우는 식으로 작동한다.

장점

• 백업에 아주 유용하다.
  일정한 간격으로 스냅샷을 생성하면, 해당 시점의 데이터 세트로 복원하면 되기 때문.

• 단일 파일로서 다른 위치로 전송하기 용이하다. (로컬 백업, Aws S3)

• Redis 성능 최적화에 도움이 된다. 디스크 I/O 작업을 redis 프로세스가 수행할 필요가 없기 때문.

• 대규모 데이터 세트에서 AOF에 비해 재시작이 빠르다

• Replica 환경에서 부분동기화가 가능하다.

단점

• RDB스냅샷 주기 사이에 장애가 발생하면 데이터가 유실 될 수 있다.

• 데이터 세트가 큰 경우, fork()시 시간이 많이 소요되며 클라이언트 서비스에 영향을 줄 수 있다.

AOF

위 RDB 방식에서는 dump주기 사기에 Redis에 문제가 발생하면 데이터가 유실될 수 있다.
내구성을 높이며 저장하는 방식인 AOF를 고려해볼 수 있다.

AOF를 아래 구성 파일에서 설정하여 활성화 할 수 있다.

#redis.conf
appendonly yes

활성화가 된 이후, Client로 부터 쓰기 명령을 수신할 때 마다 AOF에 해당 명령이 추가된다. Redis가 재시작 하는 경우, AOF에 쓰여진 명령들이 실행되며 복원된다.

Redis 7부터는 멀티 파트 AOF 메커니즘을 사용하는데, 단일의 base AOF 파일과 여러개의 incremental AOF 파일로 분리되어 작동한다. base에서는 데이터 초기 스냅샷을 저장하고, incremental파일에서는 base 이후 쓰기 작업에 대한 명령들을 저장하게 된다.

Log rewriting

Redis에 데이터가 증가하면 비효율적인 AOF가 작성될 수 있다. 예를들어 동일한 key에 대해 INCR을 100,000번 수행한 경우, 쓰기 작업이 모두 추가되지만 실제 필요한 데이터는 하나이다.
효율적인 AOF 저장 공간 사용을 위해 쌓인 로그들에 대해 재작성(rewriting) 작업이 필요하게 된다.

rewrite는 기존 AOF파일에 계속 로그가 추가되는 동안, 현재 데이터 세트를 만드는 데 필요한 최소한의 작업 집합으로 완전히 새로운 파일을 생성하고 해당 파일이 준비되면 기존 AOF가 아닌 새 AOF파일로 전환하여 로그가 쌓이게 된다.

BGREWRITEAOF 명령을 통해 클라이언트 서비스를 중단하지 않고 백그라운드에서 AOF rewirte 작업을 수행 할 수 있다. 메모리에 존재하는 데이터 세트를 재구성하는 데 필요한 최단 명령 시퀀스를 작성한다고 한다.

fsync

AOF는 어떤 주기로 얼마나 로그를 fsync(disk에 flush)하는지에 따라 내구성(durable)에 영향을 미친다.
어느 시점에 fsync에 대한 구성을 지정할 수 있는데, 아래와 같은 3가지 옵션이 존재한다.

• appendfsync always
  새로운 명령이 AOF에 추가될 때마다 fsync한다. 느리지만 안전하다.
• appendfsync everysec
  매초마다 fsync. 충분히 빠르지만, 재해가 발생하면 1초의 데이터가 손실될 수 있다.
• appendfsync no
fsync 설정을 따로 하지 않고 운영 체제에 따라간다. Linux에서는 30초마다 데이터를 flush한다고 한다.

장점

• 내구성(durable)에 유리하다. 모든 쿼리마다 fsync를 통해 지정한 정책에 따라 높은 성능의 쓰기 작업이 진행되기 때문에 장애 발생시 손실의 정도가 매우 적다.

• AOF 파일은 자동으로 안전하게 재작성될 수 있다.

• AOF내 모든 로그가 이해하기 쉽고 파싱할 수 있는 형식으로 기록된다.

단점

• AOF 파일은 동일한 데이터에 대해 RDB 파일보다 일반적으로 크다.

• fsync 정책에 따라 RDB보다 느릴 수 있다.

• Redis 7.0 이전 버전에서는 AOF 재작성에 많은 메모리를 사용할 수 있다.

• 재작성 중에 도착하는 모든 쓰기 명령은 두 번 디스크에 기록되게 된다.