개요
Redis 백업 방식은 크게 RDB(Redis Database)를 사용하는 방법과 AOF(Append Only File)를 사용하는 방법으로 나뉩니다.
Redis 장애 복구 방법으로 Redis Sentinel의 auto-failover 기능이 쓰이며 이때 Redis replication이 필요하므로 위에 언급된 두 백업 방식과 함께 Redis 복제 및 Sentinel에 대해 간단히 정리해 보겠습니다.
* 대규모 시스템에서는 Redis Cluster가 쓰이는데 이는 별도로 정리하겠습니다.
https://jaimemin.tistory.com/2329
[Redis] Redis 클러스터 개념 정리
개요 앞서 작성한 Redis 백업 및 장애 복구 방법 게시글에서 언급했다시피 대용량 트래픽이 예상되는 서비스에서는 주로 Redis Sentinel 대신 Redis Cluster를 구성해서 운영을 합니다. [Redis] Redis 백업 및
jaimemin.tistory.com
RDB를 사용하는 백업 방식
redis는 특정 시점을 snapshot으로 데이터를 RDB에 저장을 하며 재기동 시 RDB 파일이 있을 경우 파일을 읽어 백업을 진행합니다.
RDB는 별도 설정 파일이 없더라도 디폴트 값으로 활성화되어 있으며 위치는 root 디렉토리 내 bin/sh 디렉토리 내 존재하며 파일명은 dump.rdb입니다.
RDB를 사용하는 백업 방식에는 아래와 같은 장단점이 존재합니다.
장점
- 백업 파일 용량이 AOF 방식 대비 작기 때문에 관리가 용이하기 때문에 버전 관리 및 타 사이트 백업에 용이
- fork 함수를 이용해 백업하기 때문에 서비스 중인 프로세스에 성능 영향 안 끼침
- fork() 함수는 호출한 프로세스를 복사하는 기능
- 데이터 자체를 스냅샷하기 때문에 AOF 방식 대비 빠른 복구 가능
단점
- 스냅샷을 저장하는 시점 사이의 데이터 변경사항이 유실될 가능성 존재
- TPS가 높은 서비스일 경우 1초에 한번씩 스냅샷을 저장하더라도 변경사항이 유실될 가능성 높음
- 저장 시점 사이의 데이터 유실이 없더라도 마지막 백업 시 에러 발생 할 경우 데이터 유실 가능성도 있음
- fork 함수를 이용하기 때문에 메인 프로세스에 성능 영향은 안 끼치지만 시간이 오래 걸릴 수 있고 CPU 및 메모리와 같은 자원을 많이 소모
위와 같이 RDB 백업 방식은 백업에 용이하지만 데이터 유실 가능성이 있기 때문에 데이터 무결성 및 적합성에 대한 요구가 크지 않을 경우 채택되는 방식입니다.
AOF를 사용하는 백업 방식
AOF 백업 방식은 모든 쓰기 요청에 대한 로그를 저장하며 재시작 시 AOF에 기록된 모든 동작을 재수행해서 데이터를 복구하는 방식입니다.
AOF 사용의 경우 별도 설정이 없을 경우 디폴트 값이 no이기 때문에 redis.conf 설정 파일 내 appendonly 설정을 no에서 yes로 변경해야 하며 aof 파일명을 appendfilename 설정을 통해 변경 가능합니다.
AOF를 사용할 경우 redis.conf 내 fsync 정책 설정이 매우 중요한데 이는 appendfsync 설정 값을 통해 변경이 가능합니다.
가능한 fsync 정책은 아래와 같이 세 가지가 있으며 통상적으로 everysec을 사용합니다.
- always: 새로운 커맨드가 추가될 때마다 수행하는 방식으로 가장 안전하지만 데이터를 디스크에 저장하는 비싼 명령어로 redis의 장점을 취할 수 없을 정도로 느린 방식
- everysec: 1초마다 수행하며 성능은 RDB 수준에 근접
- no: OS에 맡기는 방식으로 가장 빠르지만 커널마다 수행 시간이 상이하기 때문에 안전하지 않은 방식
위에서 언급한 redis.conf 설정 파일 템플릿은 https://redis.io/docs/management/config/에서 받을 수 있으며 각자 버전에 맞는 템플릿을 다운로드하면 됩니다.
저 같은 경우 7.0.9 버전을 사용하므로 7.0 버전 템플릿을 다운로드하였습니다.
Redis configuration
Overview of redis.conf, the Redis configuration file
redis.io
AOF를 사용하는 백업 방식에는 아래와 같은 장단점이 존재합니다.
장점
- 모든 변경 사항이 로그로 기록되므로 RDB 방식 대비 데이터 유실 가능성이 낮기 때문에 안정적
- AOF 파일은 append-only 방식이므로 백업 파일이 손상될 위험이 적음
- 밑에 첨부한 AOF 파일 내용의 예시에서 볼 수 있다시피 실제 수행된 명령어가 저장되어 있기 때문에 가독성이 높고 분석하기 용이
단점
- 모든 변경 사항이 로그로 기록되기 때문에 RDB 방식 대비 파일 사이즈가 큼
- RDB 방식 대비 백업 및 복구 속도가 느림
- 백업 성능은 fsync 정책을 수정함에 따라 튜닝 가능
앞서 설명한 RDB의 데이터만 저장한다면 AOF의 경우 아래 이미지와 같이 쓰기와 관련된 모든 요청에 대한 로그를 저장합니다.
반면 dump.rdb에 저장된 내용은 파악하기 어렵습니다.
AOF 관련 추가 개념
- Log rewriting: 파일 크기를 줄이기 위해 최종 상태를 만들기 위해 최소한의 로그만 남기도록 재작성하는 방식
- 1개의 key 값을 N번 수정했다면 마지막 수정 내용만 남겨도 백업하는데 무방
- Multi Part AOF: Redis 7.0부터 AOF가 단일 파일에 저장되지 않고 아래와 같이 여러 개가 사용됨
- base file: 마지막 rewrite 시의 스냅샷 저장
- incremental file: 마지막으로 base file이 생성된 이후의 변경사항이 쌓임
- manifest file: 파일들을 관리하기 위한 메타 데이터 저장
Redis Sentinel을 활용한 Redis 장애 조치
Redis Sentinel 설명에 앞서 꼭 필요한 개념인 Redis replication에 대해 간단히 언급하겠습니다.
Redis replication
Redis 장애를 대비할 때 앞서 언급한 두 백업 방식만으로는 부족하기 때문에 Redis 복제를 통해 가용성을 확보하고 빠른 장애조치를 진행하는 방식을 사용합니다.
Master 노드가 내려갔을 경우 Replica 노드 중 하나를 Master로 전환해 즉시 서비스 정상화가 가능하도록 대비하며 이때 Replica는 read-only 노드입니다. (참고로 Replica의 Replica 노드가 존재할 수도 있습니다.)
위와 같은 특성 때문에 Replica 노드는 장애 대비뿐만 아니라 클라이언트로부터 읽기 요청이 들어왔을 때 트래픽 분산 목적으로 Replica 노드로 요청을 분산시키는 기능도 수행합니다.
* Redis replication 적용 시 주의
Master 노드에는 RDB나 AOF를 이용한 백업 기능을 반드시 활성화해야 합니다.
왜냐하면 마스터 노드가 내려갔다가 올라왔을 때 백업 기능이 없어 데이터가 유실될 경우 멀쩡히 올라와있던 replica 노드들도 마스터 노드의 유실된 데이터 상태를 복제하기 때문에 데이터가 유실될 수 있습니다.
Redis Sentinel
Redis Sentinel은 Redis에서 고가용성을 제공하기 위한 장치로 master-replica 구조에서 마스터 노드가 내려갔을 경우 replica 노드를 마스터 노드로 승격시키는 auto-failover 기능을 수행하는 것이 특징입니다.
Sentinel의 기능은 아래와 같이 네 가지가 있습니다.
- 모니터링
- 알림
- 자동 장애 복구
- 환경 설정 제공
Redis Sentinel의 실제 구성도는 위와 같으며 Sentinel의 노드가 3개 이상인 이유는 Quorum이라는 설정값 때문입니다.
Quorum은 다수결의 원칙을 생각하면 이해하기 쉬운데 일부 sentinel이 마스터 노드가 장애라고 오판단하더라도 quorum 값 이상의 sentinel들이 마스터 노드가 정상으로 판단할 경우 auto-failover 기능을 수행하지 않습니다.
이 때문에 quorum 값은 보통 [Sentinel 노드 수 / 2]의 올림 값이며 Sentinel 노드 수는 보통 홀수입니다.
추가적으로 설명하자면 Sentinel이 마스터 노드가 다운되었다고 판단하는 방식은 아래와 같이 두 가지가 있습니다.
- SDOWN: Sentinel 1대가 마스터 노드가 내려갔다고 판단 (Subjective)
- ODOWN: quorum 값 이상의 Sentinel들이 마스터 노드가 내려갔다고 판단 (Objective)
이처럼 Sentinel들은 Redis 마스터 노드와 레플리카 노드들을 모니터링하고 있으며 클라이언트는 Sentinel을 통해 master 노드의 주소를 얻어내야 하기 때문에 Redis에 접근할 때 반드시 Sentinel을 통해 레디스를 접근합니다.
* 다만, Sentinel의 경우 multi key 오퍼레이션이 필요하거나 비교적 단순하고 소규모의 시스템에서 고가용성이 필요할 때 채택이 되고 TPS가 높은 대규모 프로젝트의 경우에는 주로 sentinel 대신 redis cluster를 구성해서 장애 대응을 진행합니다.
참고
백엔드 개발자를 위한 한 번에 끝내는 대용량 데이터 & 트래픽 처리 초격자 패키지 Online - 고성능 서비스를 위한 Redis 활용 및 아키텍처
'Redis' 카테고리의 다른 글
| [Redis] Redis Streams (0) | 2023.11.22 |
|---|---|
| [Redis] Redis 성능 튜닝 (1) | 2023.11.21 |
| [Redis] Redis 클러스터 개념 정리 (0) | 2023.11.20 |