[공식 문서 훑어보기] 6. Redis AOF 동작 원리 및 리스크 관리 대안

Redis의 AOF(Append Only File)는 모든 쓰기 명령을 디스크에 로그 형식으로 기록함으로써 서버가 재시작될 때 해당 명령들을 순차적으로 실행하여 데이터를 복구할 수 있게 합니다.

이 방식은 사람이 읽을 수 있는 형태로 저장되며 디버깅과 복구 측면에서 매우 유용합니다.

그러나 모든 쓰기 작업을 로그로 남기기 때문에 시간이 지날수록 AOF 파일의 크기는 계속 증가하게 되고 결국 디스크 용량의 문제를 야기할 수 있으며 무한한 저장 공간이 존재하지 않는 이상 AOF 파일의 크기를 제어하는 메커니즘이 필수입니다.

AOF 파일은 무한히 커질 수 있을까?

Redis는 이를 방지하기 위해 BGREWRITEAOF라는 백그라운드 AOF 재작성 명령어를 제공합니다.

이 명령어는 기존 AOF 파일의 내용을 메모리 상의 현재 Redis 상태를 기반으로 최적화된 새로운 AOF 파일로 재작성함으로써 불필요한 명령 누적을 제거하고 파일 크기를 줄이는 역할을 합니다.

하지만 이 방법 역시 근본적인 저장 한계를 해결하는 수단은 아니며 특정 조건에 따라 수동 또는 자동으로 수행되어야 합니다.

AOF Rewrite 관련 설정

Redis에서는 AOF rewrite가 자동으로 수행되도록 다음과 같은 설정을 제공합니다.

• auto-aof-rewrite-percentage
  •  마지막 rewrite 시점보다 AOF 파일이 N% 이상 커졌을 때 rewrite를 수행합니다.
• auto-aof-rewrite-min-size
  • 현재 AOF 파일 크기가 N 바이트 이상일 때만 rewrite를 고려합니다.

설정 확인 방법 (Docker 환경 기준)

docker exec -it redis redis-cli config get auto-aof-rewrite-percentage
docker exec -it redis redis-cli config get auto-aof-rewrite-min-size

AOF Rewrite의 동작 흐름

재작성이 일어나는 경우 ( 7.0 미만 )

1. Redis에 클라이언트의 쓰기 작업이 발생합니다.
2. 해당 명령은 AOF 버퍼에 기록됩니다.
3. 설정된 rewrite 조건이 충족되면, Redis는 fork()를 통해 자식 프로세스를 생성합니다.
4. 자식 프로세스는 부모의 메모리 상태를 기반으로 최적화된 AOF 임시 파일을 생성합니다.
5. 이 동안 부모는 계속해서 클라이언트 요청을 처리하며, 추가 쓰기 작업은 AOF Rewrite Buffer에 따로 저장합니다.
6. 자식 프로세스가 작업을 완료하면 부모에게 신호를 보냅니다.
7. 부모는 Rewrite Buffer에 있던 내용을 자식이 작성한 AOF 파일에 append합니다.
8. 기존 AOF 파일을 새로 작성된 임시 파일로 교체(rename) 합니다.
9. 자식 프로세스는 종료됩니다.

7.0 이상일 경우 부모는 fork() 후 들어오는 쓰기작업을 AOF Rewrite Buffer에 저장만 하는게 아닌 실제 임시 AOF 파일에 작성하게 되고 자식 프로세스가 작성 완료 시 두가지 파일을 합쳐서 새로운 파일을 만들게 됩니다.

이는 fork() 후 비정상 종료가 될 경우 fork() 후 AOF Rewrite가 완료되기 전까지의 쓰기 작업에 대해 복구가 가능하다 점입니다.

재작성이 일어나지 않는 경우

1. Redis에 클라이언트의 쓰기 작업이 발생합니다.
2. 해당 명령은 AOF 버퍼에 기록됩니다.
3. 일정 주기 또는 조건에 따라 AOF 버퍼의 내용이 기존 AOF 파일에 flush (append) 됩니다.

AOF 파일이 손상되었을 경우

1. Truncate (파일 일부 손상)

디스크 용량 부족이나 Redis 프로세스 크래시로 인해 AOF의 마지막 명령어가 불완전하게 저장될 수 있습니다.

이 경우 Redis는 다음과 같은 메시지를 출력하며 자동 복구를 시도합니다:

# !!! Warning: short read while loading the AOF file !!!
# !!! Truncating the AOF at offset 439 !!!
# AOF loaded anyway because aof-load-truncated is enabled

이 동작은 aof-load-truncated 설정이 yes일 경우 발생하며 Redis는 손상된 마지막 명령을 잘라내고 나머지 데이터를 정상적으로 로드하게 되며 강제 종료를 원할 경우 aof-load-truncated no로 설정하면 됩니다.

2. Corruption (중간 데이터 손상)

파일 중간이 깨진 경우 Redis는 복구하지 않고 실행을 중단합니다.

1. AOF 파일 백업

2. redis-check-aof 도구로 검사 및 수정

 

redis-check-aof --fix filename.aof

3. 필요한 경우 diff -u 명령으로 변경 사항 확인

4. Redis 재시작

 

주의: --fix 옵션을 사용할 경우 손상된 지점부터 이후 모든 명령이 삭제될 수 있어 데이터 손실 가능성이 큽니다.

재작성의 한계 및 대응 방안

앞서 설명한 BGREWRITEAOF는 AOF 파일의 크기를 줄이는 유용한 방법이지만, AOF 파일은 계속해서 다시 생성되고 커질 수 있기 때문에 장기적으로 디스크 용량에 대한 근본적인 해결책은 되지 않습니다.

현재 지식 수준에서 가능한 대응 방안

Redis는 자체적으로 오래된 AOF 파일을 삭제하거나 백업하는 기능을 제공하지 않기 때문에 운영 환경에서는 다음과 같은 방식으로 추가 관리가 필요합니다.

• Cron job을 통한 주기적인 백업 및 AOF 삭제
  • 일정한 AOF 파일 크기 이상일 경우
    1. BGREWRITEAOF를 명시적으로 수행
    2. 재작성된 AOF 파일을 외부 스토리지(S3, NAS 등)에 백업
    3. Redis 인스턴스 재시작 없이 AOF 파일 삭제