개요
Redis는 In-memory 데이터 저장소이므로 서버를 재시작하면 모든 데이터를 유실합니다. 또한 복제 기능을 사용해도 잘못된 코드나, 사람의 실수가 발생하면 복제본도 똑같이 데이터가 삭제됩니다. 또한 복원을 할 수 없습니다. 따라서, Redis를 캐시 이외에도 용도로 사용한다면 적절한 데이터 백업이 필요합니다.
Redis Persistence 종류
Persistence란 SSD같은 저장소에 데이터를 저장하는 것입니다. Redis는 영속성을 위해 여러가지 옵션을 제공합니다. 대표적으로 RDB, AOF 2가지 방식이 있습니다.
RDB(Redis Database)
RDB 영속화는 일정한 가격으로 특정 시점 스냅샷을 수행합니다.
RDB 장점
1. RDB는 단일 파일이며, 특정 시점의 메모리에 있는 데이터 전체를 바이너리파일에 저장합니다. 특히 백업에 효과적입니다. RDB 파일을 매 시간마다 저장할 수 있고, 스냅샷을 매일 저장할 수도 있습니다. 덕분에, 장애 시, 다양한 데이터 버전들을 손쉽게 복구 할 수 있습니다.
2. RDB는 Redis 부모가 영속화를 위해 단지 자식을 fork()하면되기 때문에 간편합니다. 부모 프로세스는 결코 디스크 I/O를 하지 않습니다. RDB는 AOF에 비해서, 큰 데이터를 빠르게 재시작합니다. (BGSAVE)
RDB 단점
1. RDB는 Redis가 멈추는 경우 데이터 손실을 최소화해야 할 때 성능이 좋지 않습니다. 예를 들어, 최소 5분 및 100회 쓰기 후에 저장을 한다고 가정합니다. 그러나, 일반적으로 5분 이상마다 RDB 스냅샷을 생성하므로 갑자기 Redis가 작동을 중지하는 경우 최신 데이터 손실이 발생합니다.
2. RDB는 가끔 자식 프로세스를 이용해 디스크에 영속화하는 fork()가 필요합니다. fork()는 데이터가 너무 크면, 작업 시간이 길어질 수 있고, 수백만초 혹은 심지어 1초 이상 동안 클라이언트가 Redis 기능을 사용하지 못하는 상황이 발생할 수 있습니다. (SAVE)
3. AOF도 물론 fork()를 하지만, 자주 하지 않으며, 내구성에 영향을 미치지 않는 선에서 로그 다시쓰기를 어떻게 하느냐에 따라 RDB보다 훨씬 좋은 성능을 냅니다.
AOF(Append Only File)
AOF 영속화는 서버로 수신한 모든 쓰기 동작을 기록합니다,
AOF 파일은 default로 appendonly.aof 파일에 기록됩니다. 입력/수정/삭제 명령이 실행될때마다 기록되며, 이 정보는 서버 재시작, 원래의 데이터로 재구성을 할 때 실행됩니다. Redis는 로그 기록 규모가 너무 커지면, 백그라운드에서 로그 다시쓰기를 할 수 있습니다.
AOF 장점
1. AOF는 내구성이 훨씬 좋습니다: 여러 fsync 정책을 수립할 수 있습니다, fsync 비활성화, 매초 fsync(default), 매 쿼리 fsync 등이 있습니다. fsync는 백그라운드 쓰레드에서 수행되고, 약 1초 가량의 쓰기 정보만 유실합니다.
2. AOF 로그는 추가전용(append-only)이기 때문에, 검색이 없고, 장애 시에도 문제가 없습니다. 어떠한 이유로 로그가 반쯤 작성된 명령어로 끝나더라도, 손쉽게 복구할 수 있습니다.
3. AOF는 모든 수행 동작에 대한 로그를 이용해 파싱하기 쉬운 형태로 보관합니다.(text) 따라서 손쉽게 AOF 파일을 사용할 수 있습니다. 만약 실수로 FLUSHALL 명령어를 입력해 flush가 발생해도, 즉시 레디스 서버를 shutdown하고, appendonly.aof 파일에서 FLUSHALL 명령을 제거 한 후 레디스를 다시 시작하면 데이터 손실없이 DB를 살릴 수 있습니다.
AOF 단점
1. AOF 파일들은 같은 데이터 기준으로 RDB보다 훨씬 용량이 큽니다.
2. AOF는 fsync 정책에 따라 RDB보다 성능이 느릴 수 있습니다. fsync 정책의 성능이 뛰어나지만, 그럼에도 RDB보다 여전히 쓰기 부하가 있습니다.
RDB와 AOF 중, 어느 방식을 사용 해야 할까요?
AOF를 기본으로 하고, RDB를 Option으로 합니다. 왜냐하면 AOF는 복구 시, 최대한 최근의 데이터까지 복구 할 수 있기 때문입니다. AOF 시간 설정은 매초 fsync로 하고, AOF Rewrite를 사용합니다. AOF를 사용해도 성능에 거의 영향을 미치지 않습니다.
만약에 데이터가 장애가 나도 몇 분의 데이터 유실도 괜찮다면, RDB가 좋습니다. AOF 하나만 쓸 수도 있지만, 빠른 재시작을 위해 데이터베이스 백업으로 RDB 스냅샷을 저장하여 바로 복구하는 방식을 추가로 사욯아기를 추천합니다.
RDB(SNAPSHOT) 방식 사용법
이 방식은 Redis가 디스크에 dump.rdb라는 바이너리 파일로 데이터의 스냅샷을 저장합니다. 데이터에 최소 M번의 변화가 있다면, N초마다 데이터를 저장하도록 설정할 수 있습니다. SAVE 혹은 BGSAVE 명령어를 직접 입력해서 RDB를 생성 할 수도 있습니다.
예를 들어, 다음 설정으로 60초동안 1000개 이상의 key가 변경된 경우 데이터를 덤프할 수 있습니다.
save 60 1000
redis.conf의 파라미터는 save 입니다. RDB를 저장하지 않으려면 redis.conf 에서 SAVE를 모두 주석 처리하면 됩니다.
1. SAVE로 RDB 파일 생성
메인 프로세스가 일하므로 끝날때까지 클라이언트의 요청을 처리 할 수 없습니다.
1. Redis 부모 프로세스가 fork로 자식 프로세스를 만듭니다.
2. 자식 프로세스는 임의의 RDB 파일에 데이터 쓰기를 시작합니다
3. 새로운 RDB 파일에 쓰기작업이 끝나면, 이전 파일에서 새로운 파일로 전환합니다.(copy-on-write)
2. BGSAVE로 RDB 파일 생성
자식 프로세스가 생성되고 백그라운드에서 일하므로 클라이언트의 요청을 처리하는데 문제가 없습니다.
1. 메인 프로세스가 데이터를 새 RDB temp 파일에 씁니다.
2. 쓰기가 끝나면 기존 파일을 지우고, 새 파일로 교체합니다.
AOF 방식 사용법
RDB 스냅샷은 장애 대응에 뛰어나지 않습니다. Redis를 실행중인 컴퓨터가 멈춘다면, 파워가 나간다면, 인스턴스를 kill -9로 종료한다면, Redis에 쓰인 최근의 데이터는 손실됩니다. 몇몇 어플리케이션에서 문제가 되지 않겠지만, 내구성이 필요한 경우들이 있으며, 이 경우 스냅샷은 별로 좋지 않은 선택입니다
이 때, append-only-file이 대안책이며, Redis에 완벽한 내구성을 제공합니다 1.1 버전부터 사용이 가능하며, 다음 명령어로 AOF 설정을 활성화 할 수 있습니다
appendonly yes
AOF 활성화로, Redis가 데이터를 변경하는 명령어를 수신할때마다, AOF에 해당 내용을 추가합니다. Redis를 재시작할 때, 상태를 회복하기 위해서 AOF를 다시 수행합니다. appendonly no 인 경우 RDB 파일을 읽어 들입니다.
참고
[NHN FORWARD 2021] Redis 야무지게 사용하기
'문제 해결, 기술 비교 > 개인프로젝트(북클럽)' 카테고리의 다른 글
| 페이징에서 JPA N +1 문제 해결하기 (0) | 2022.09.28 |
|---|---|
| Mysql Replication 구성하기 (3) | 2022.06.29 |
| Message Queues vs Pub/Sub (0) | 2022.06.26 |
| RabbitMQ와 Kafka 비교하기 (1) | 2022.06.25 |
| In-memory Redis vs Memcached 비교하기 (0) | 2022.06.21 |
