[Redis] Redis의 백업과 HA를 위한 전략 (RDB, AOF, Replication, Sentinel, Sharding, Cluster)

🏝0. 서론

팀 프로젝트에서 Redis를 사용하다가, 신기한 현상을 발견했다.

우리 프로젝트에서는 도커를 통해 레디스 서버를 돌리고 있었고, JWT Refresh Token을 레디스 서버에 저장하고 있었는데 도커를 중지하고 며칠 뒤에 다시 실행을 해본 결과 아직 해당 토큰들이 남아있는 현상을 발견했다.

"엥? Redis는 InMemory DB로 종료되면 메모리가 모두 휘발되어 데이터가 없는게 맞지 않나?"

이러한 생각을 가지게 되었고, Redis의 백업에 관련된 내용을 공부하자 해당 실마리를 풀어낼 수 있었다.

🤔 1. Redis의 백업 방식

1-1. RDB(Redis DataBase 방식)

여기서 RDB는 관계형 데이터베이스가 아니라, Redis의 자체적인 백업 방식인 Redis Database 방식을 의미한다.

Redis를 사용하면서 일정 주기마다 Redis가 가지고 있는 데이터를 그대로 스냅샷 형태로 저장해 .rdb 확장자를 가진 파일로 만들어 내는 방식이 바로 RDB이다. 해당 백업은 Redis 서버를 fork를 떠서 진행된다.

기본적인 설정으로 Redis를 사용하면 RDB 방식이 세팅되어있기 때문에, 위에서 레디스를 종료해도 토큰이 그대로 남아있던 현상은 재시작한 후 RDB 파일을 불러왔기 때문에 그대로 남아있다고 볼 수 있다.

기본적으로 스냅샷 형태로 저장하기 때문에 작은 파일 사이즈로 백업 파일 관리가 용이하고, 원격지 백업이나 버전 관리가 쉽다.

또한 해당 백업이 되는 과정은 Redis 서버를 fork를 떠서 자식 서버에서 백업을 하게 되므로 본 프로세스에는 성능적 영향이 없다.

또 데이터 스냅샷을 그대로 복구하면 되기 때문에 빠른 복구가 가능하다.

단점이라고 하면, 이러한 RDB 방식에 대한 이해가 있다면 쉽게 유추할 수 있다.

스냅샷을 저장하는 '시점'이 분명히 존재하기 때문에 그 사이에 데이터 변경 사항은 유실될 수 있다.

예를 들어 스냅샷을 1분마다 저장하는 상황에서 스냅샷이 저장되기 1초 전에 서버가 중단된다면 59초간의 데이터 손실은 막을 수 없다.

또한 본 프로세스에 성능에 영향을 끼치지는 않지만, fork를 사용하는 시간 및 CPU와 메모리 자원을 소모한다는 것도 단점이라고 볼 수 있다.

따라서 데이터 무결성이나 정합성에 대한 요구가 크지 않은 경우에 사용하면 좋다. 사실 Redis를 캐시 서버로 사용하고 적절한 캐싱 로직을 구성했다면 데이터 무결성이나 정합성에 대한 요구가 크지 않은 경우가 많이 발생한다. 이러한 점에는 간단한 RDB 방식을 사용해도 괜찮아 보인다. 무결성과 정합성을 강력하게 지켜야 한다면 차라리 Redis 보다는 RDB를 고려하게 될 것이니 말이다.

이러한 RDB 방식에 대해 커스텀을 하고 싶다면, redis.conf 파일을 수정하면 된다.

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

Redis configuration

Overview of redis.conf, the Redis configuration file

redis.io

위의 링크에서 버전에 맞는 redis.conf 파일을 다운로드 받아 수정해서 사용하면 된다.

1-2. AOF(Append Only File 방식)

RDB 방식은 해당 시점에 존재하는 데이터를 스냅샷 방식으로 저장하고, 다시 복구하는 방식이다.

반면 AOF는 스냅샷 방식이 아닌, 모든 쓰기 요청에 대한 로그를 저장하는 방식이다.

클라이언트가 레디스 서버에 데이터를 쓴다면, 해당 명령 하나하나를 모두 기록해서 AOF 파일에 저장하는 방식이다.

스냅샷 방식과 다르게 재시작을 한다면, 여태껏 기록된 명령의 히스토리를 모두 재실행해 이전 데이터를 만들어내는 방식이다.

이러한 방식을 사용하면 모든 변경사항이 기록되므로 RDB 방식에 비해 더욱 더 안정성을 얻을 수 있다는 것이 장점이다.

AOF 파일은 이름값 답게 Append Only 파일이므로 명령 수행에 대한 내용을 삽입하기만 하므로 백업파일에 대한 손상 위험이 굉장히 적다.

또한 실제 수행된 명령어가 저장되어있어 사람이 직관적으로 이해할 수 있고 해당 내용을 일부 수정해서 데이터를 살리는 방식도 가능하다.

스냅샷 방식이라면 이러한 히스토리를 알지도 못할 뿐더러, 저장 간격 탓에 지키지 못한 정합성을 원래대로 돌릴 생각도 하기 어렵다.

단점으로는 RDB는 순간의 데이터 결과를 스냅샷으로 저장하는 것과 달리 모든 히스토리를 기록하므로 파일 사이즈가 커지고, 해당 히스토리를 모두 재실행 과정을 거치기 때문에 백업 및 복구 속도가 느린 편이다.

AOF 백업 방식을 사용하고 싶다면, redis.conf 파일에서

appendonly yes

코드를 입력하면 된다. 템플릿 파일에서는 주석 처리가 되어있으므로 해제하면 된다.

생성된 AOF 파일명 역시 redis.conf 파일에서

appendfilename appendonly.aof

해당 부분을 수정하면 된다.

appendfsync everysec

마지막으로는 fsync에 대한 정책 설정이 가능한데 fsync() 호출은 OS에게 데이터를 디스크에 쓰도록 하는 것이다.

파일에 데이터를 쓴다고 해서 바로 디스크에 저장되는 것이 아니라 OS를 통해 일정 시간 버퍼링이 존재하는데(완전한 실시간이 아님), 이러한 파일 쓰기에 강제 호출을 통해 간격 조정이 가능하다.

always를 주면 새로운 커맨드 하나가 AOF가 추가되면 fsync가 즉시 호출되는 방식으로 디스크에 확실히 기록되게한다. 따라서 가장 안전하지만 가장 느린 방식으로 볼 수 있다. 너무 느려서 Redis의 장점이 퇴색되기도 한다고 한다.

예제에 나온 everysec은 1초마다 fsync를 수행하며, 성능은 RDB 수준에 근접하다. 중간수준의 타협이라 많이 사용하는 옵션이라고 한다.

no 방식은 OS에 순전히 fsync 호출을 맞기는 방식이며, 가장 빠르지만 덜 안전한 방법이라고 볼 수 있다. 언제 저장이 될 지 불확실하다.

AOF 방식이 발전하면서 AOF 방식과 RDB 방식이 혼합된 형태가 나오기 시작했는데 그 개념에 대해 알아보자.

Log rewriting은 AOF에서 모든 히스토리를 저장해 히스토리의 크기가 지나치게 커지는 것을 방지하기 위한 개념으로, 최종 상태를 만들기 위한 최소한의 로그만 남기기 위해 일부를 새로 쓰는 방식이다.

예를 들어 SET 명령어를 통해 같은 키에 대해 값 수정을 100회 진행했다고 하더라도 최종 상태는 1개 이므로 SET 1개로 대체 할 수 있다.

이러한 방식으로 히스토리가 지나치게 커지는 것을 방지한다.

또 Multipart AOF의 개념이 Redis 7부터 나오게 된다.

AOF 단일 파일로 구성된 과거와 달리 Base file, Incremental file, Manifest file 세 가지의 고유한 역할을 가진 파일으로 분할되게 된다.

Base File은 RDB 파일로, 마지막 Rewrite 시의 스냅샷을 저장해 모든 히스토리의 재시작을 방지해 백업 시 속도를 향상시킨다.

Incremental File은 마지막으로 Base File이 생성된 이후의 히스토리가 쌓이게 되는 AOF 파일이다.

Manifest File은 이러한 파일들을 관리하기 위한 메타 데이터를 저장하고 있다.

즉 Multipart AOF 개념은 RDB + AOF 방식의 융합이라고 볼 수 있다.

🤔 2. 백업만으로는 장애 대비에 부족해..!

2-1. Replication과 Sentinel

RDB의 사례에서 보았듯이 백업이 실패할 가능성이 존재하고, 복구를 하는데 시간이 소요된다.

이 사이에 발생할 수 있는 장애가 충분히 있을 수 있으므로 백업만으로는 장애 대비에 부족하다.

RDB(관계형 데이터베이스)와 비슷하게 Redis도 복제를 통해 가용성을 확보하고 빠른 장애조치가 가능하다.

즉, 읽기가 가능한 Master Redis 서버와 동일한 내용을 가진 Replica Redis 서버를 가질 수 있고, Master 서버가 죽었을 경우 Replica 중 하나를 Master로 전환해 즉시 서비스를 정상화 시킬 수도 있다.

또한 Replica는 Read-only 노드이기 때문에 트래픽 분산의 역할도 할 수 있다. (읽는 연산은 Replica로, 쓰기 연산은 Master로)

Master 노드는 RDB나 AOF를 이용한 백업 기능 활성화가 필수적이다. (재시작 후에 비어있는 데이터 상태가 복제되는 경우 방지)

단순히 Master 노드가 죽었을 때 Replica를 Master로 수동으로 승격시킬 수도 있지만, Redis는 고가용성을 위해 Sentinel이라는 장치를 마련했다.

Master-Replica 구조에서 Master가 다운 시 Replica를 자동으로 Master로 승격시키는 Auto-Failover를 수행하는 것이 센티넬의 역할이다.

센티넬 노드는 3개 이상으로 구성하는데, 그 이유는 서버가 다운됐다는 결정을 내리기 위한 '과반수'라는 개념을 갖기 위해서는 3명이 최소 노드이기 때문이다. (Quorum : 정족수)

만약 찰나의 네트워크 단절이 발생했다고 가정하고, 곧바로 복구되었다고 가정하자. 단 하나의 센티넬만 서버가 다운되었다고 판단하고 두 센티넬은 서버가 정상적이다라는 판단을 내리면, Master 서버가 정상적으로 작동되었다고 판단하는 것이다. 즉 서비스에 지장이 가지 않는 오류로 인해 Master 노드를 다운이라 판단하고 Replica 서버를 승격시키는 오버헤드를 발생시키는 일을 줄일 수 있다.

센티넬 1대가 Master 노드가 다운되었다고 판단하는 것을 SDOWN(Subjective Down)

정족수가 충족되어 Master 노드가 다운되었다고 판단하는 것을 ODOWN(Objective Down)이라고 한다.

이러한 3개 이상의 센티넬 노드들은 서로 연결되어있고, 연결된 Redis Master와 Replica를 모니터링한다.

Client는 Master와 Replica 노드에 접근하는 것이 아니라, 이 센티넬 노드들을 통해 Redis에 접근할 수 있다.

따라서 SpringBoot + Redis Replica with Sentinel의 구조라면, 센티넬 노드들의 IP-Port를 기입해 연결해야 한다는 의미이다.

센티넬이 적절한 Master-Replica 노드의 적절한 주소를 자동으로 알려주기 때문이다.

아래는 Docker Compose 파일을 통해 Redis Replication + Sentinel을 구성한 예제이다.

version: "3"
services: 
  my-redis-a:
    hostname: redis-master
    container_name: redis-master
    image: "bitnami/redis"
    environment:
      - REDIS_REPLICATION_MODE=master
      - ALLOW_EMPTY_PASSWORD=yes
    ports:
      - 5000:6379 
  my-redis-b:
    hostname: redis-replicas-1
    container_name: redis-replicas-1
    image: "bitnami/redis"
    environment:
      - REDIS_REPLICATION_MODE=slave
      - REDIS_MASTER_HOST=redis-master
      - ALLOW_EMPTY_PASSWORD=yes
    ports:
      - 5001:6379
    depends_on:
      - my-redis-a

  redis-sentinel-1:
    container_name: sentinel1
    image: 'bitnami/redis-sentinel:latest'
    environment:
      - REDIS_SENTINEL_DOWN_AFTER_MILLISECONDS=3000
      - REDIS_MASTER_HOST=redis-master
      - REDIS_MASTER_PORT_NUMBER=6379
      - REDIS_MASTER_SET=mymaster
      - REDIS_SENTINEL_QUORUM=2
    ports:
      - 26379:26379
    depends_on:
      - my-redis-a
      - my-redis-b
  redis-sentinel-2:
    container_name: sentinel2
    image: 'bitnami/redis-sentinel:latest'
    environment:
      - REDIS_SENTINEL_DOWN_AFTER_MILLISECONDS=3000
      - REDIS_MASTER_HOST=redis-master
      - REDIS_MASTER_PORT_NUMBER=6379
      - REDIS_MASTER_SET=mymaster
      - REDIS_SENTINEL_QUORUM=2
    ports:
      - 26380:26379
    depends_on:
      - my-redis-a
      - my-redis-b
  redis-sentinel-3:
    container_name: sentinel3
    image: 'bitnami/redis-sentinel:latest'
    environment:
      - REDIS_SENTINEL_DOWN_AFTER_MILLISECONDS=3000
      - REDIS_MASTER_HOST=redis-master
      - REDIS_MASTER_PORT_NUMBER=6379
      - REDIS_MASTER_SET=mymaster
      - REDIS_SENTINEL_QUORUM=2
    ports:
      - 26381:26379
    depends_on:
      - my-redis-a
      - my-redis-b

아래는 SpringBoot 프로젝트에서의 application.yml 파일이다.

spring:
	redis:
    	sentinel:
        	master: mymaster
            nodes: 127.0.0.1:26379, 127.0.0.1:26380, 127.0.0.1:26381

기존의 Redis 연결에서 해당 파트만 변경한다면, 문제 없이 사용이 가능하다.

2-2. Redis Cluster

Redis Cluster는 여러 노드에 자동적인 데이터 분산을 처리해주며, Sentinel과 비슷하게 일부 노드의 실패나 통신 단절에도 계속 작동하는 고가용성을 제공하며, 고성능과 선형 확장성을 제공한다.

즉 샤딩의 역할을 한다고 보면 이해하기 쉬울 것이다.

Redis Cluster의 특징은 위와 같이 Full-mesh 구조로 통신하게 된다. 즉 모든 노드가 자신을 제외한 나머지 노드와 전부 연결되어 통신된다는 뜻이다. 이러한 구조로 데이터의 전송이 이뤄지면 다음과 같은 궁금증이 생길 수 있다.

"자신을 제외한 나머지 모든 노드에 각자의 데이터를 전송한다면 지나치게 많은 통신량이 요구되는 것 아닌가?"

이러한 문제를 해결하기 위해 Redis Cluster는 Gossip Protocol이라는 프로토콜을 사용한다. Gossip이라는 이름답게 소문이 퍼지는 현상처럼 통신의 개수를 줄이더라도 모두 통신이 되게끔 만드는 프로토콜이다.

Gossip Protocol에 대한 자세한 내용은 아래의 글에서 얻을 수 있었다.

http://highscalability.com/blog/2023/7/16/gossip-protocol-explained.html

Gossip Protocol Explained - High Scalability -

You can subscribe to the system design newsletter to excel in system design interviews and soft...

highscalability.com

Redis Cluster는 Cluster Bus라는 별도의 포트를 사용해서 서로 통신하게 된다.

또한 '샤딩'이 적용되므로 키에 따라 다른 Master-Replica Redis 서버에 값이 저장되게되는데, 이러한 키에 따른 레디스 서버 선택은 Hash Slot이라는 방식에 의해 결정된다.

Sentinel과 다른 점으로는, Sentinel 역시 HA를 위한 도구이기는 하나, 오직 한 쌍의 Master-Replica 모델을 가지고 운용하기 때문에 한계가 존재한다. 레디스 클러스터를 사용하면 샤딩을 적용하기 때문에 더욱 더 높은 수준의 고가용성을 이룰 수 있다.

또한 레디스 클러스터를 사용하면 서로 Full-Mesh 구조로 통신하며 서로의 Heart Beat를 체크하기 때문에 별도의 모니터링 서비스(Sentinel)이 필요 없게 된다.

Sentinel에서 클라이언트가 모든 센티넬 노드에 접속을 했던 것처럼, Redis Cluster 역시 클라이언트는 모든 Cluster 노드에 접속해 사용하는 방식으로 이뤄진다.

Redis Cluster를 사용하면 약간의 제한 사항이 존재하는데, 그것은 바로 DB0만 사용하다는 것과, MultiKey Operation이 불가하다는 점이다. 이러한 제한사항에 크게 벗어나지 않고, 고가용성을 챙기고 싶다면 Redis Cluster를 선택하는 것은 좋은 방향으로 보인다.

반면에 규모가 그다지 크지 않거나 MultiKey Operation이 필요한 경우에는 Redis Cluster보다는 Sentinel을 사용하는 것이 좋다.

위에서 키에 따라 어떤 클러스터 노드에 들어가는 지 결정하는 방법은 바로 Hash Slot을 이용한 방법이라고 언급했다.

일반적으로 샤딩은 단순 해시를 통해 해당 노드를 추적하게 되는데, 이 방법은 굉장히 좋고 간단하다.

예를 들어 key 값이 'fruit'라고 하면, 해시함수를 통해 key 값의 해시값을 구하고, 샤딩된 총 노드의 개수만큼 모듈러 연산을 통해 어느 노드에 저장될 지 결정하면 되기 떄문이다!

굉장히 직관적이고 강력하고 좋은 방법이지만, 단점이 부각되는 상황은 클러스터가 추가되었을 경우이다.

예를 들어 Hash 값이 2라고 가정하고, 클러스터 변경 전 총 노드 수가 2개, 변경 이후는 3개라고 가정하자.

변경전에는 2 % 2 = 0 으로 0번 노드에 저장되지만, 변경 후에는 2 % 3 = 2로 2번 노드에 저장되게 된다.

단순 해시에서는 클러스터의 수의 변경에 의해 모든 매핑이 새로 계산되어야만 하는 소요가 생길 수 밖에 없다. 이것은 치명적인 단점이다.

Hash Slot을 통한 데이터 분산은 약간 다르다.

위의 그림을 보면, Redis Cluter가 총 3개의 Master 노드를 가지고 있다. Redis Cluster Hash Slot은 0~16383의 슬롯을 미리 구성해놓고, 해당 슬롯의 각 범위를 Cluster가 각각 나눠 가지게 되는 구조로 구성한다.

Hash 알고리즘은 CRC16을 사용하며, 키값을 해당 연산을 통해 해시 값을 얻어낸 이후, 모듈러 연산을 통해 Hash Slot의 값을 얻어낸다.

해당 HashSlot에 매핑된 클러스터를 찾아가는 방식으로 구성되어있다.

이렇게 되면, 클러스터가 추가되고 삭제되면 영향이 가는 Hash Slot에 대해서만 데이터의 재구성이 이뤄지면 된다.

모든 데이터에 영향이 가는 기존 방식과는 약간 다른 점이다.

만약 해시슬롯에 매핑되지 않은 다른 클러스터에 요청이 가면 Redis는 어떻게 처리할까?

Redis Cluster는 다음과 같은 MOVED 에러를 내보낸다.

MOVED [Hash Slot Num] [IP:Port]의 형식으로, 해당 노드가 담당하지 않는다는 의미의 에러를 내보내고, 해당 해시슬롯을 담당하는 올바른 클러스터 서버의 IP와 포트번호를 알려주게 된다.

"그럼 Redis를 사용하는 클라이언트 입장에서는 클러스터에 요청을 던지고 MOVED 에러에 대한 후처리까지 고려해야 하는 수고로움이 더 있지 않느냐?"

라는 질문을 할 수 있는데, Spring 환경에서는 이러한 점을 신경쓰지 않도록 알아서 처리하게 된다.

내부적으로 라이브러리에서 key-node를 맵을 캐싱해서 이러한 오류가 덜 발생하게끔 만들고, 발생하더라도 신경 쓰지 않아도 되게끔(Redirect 기능) 편리하게 구성되어있다.

이러한 Redis Cluster를 통해서 Single Redis를 사용하는 것 만큼의 퍼포먼스를 낼 수 있다.

다만, Redis Cluster가 데이터 일관성이 항상 지켜지느냐?라고 한다면 그것은 아니다.

항상 분산시스템에서는 성능은 데이터 일관성과 trade-off 관계이기 떄문이다.

Redis Cluster는 Master-Replica 간 데이터 복제가 비동기 방식으로 이뤄진다. 아래의 그림을 보면 좀 더 이해하기 쉬워진다.

사용자가 Master 서버에 쓰기 요청을 보내면 Master에서 Replica로의 복제를 하는 과정과, 해당 내용을 쓰기 완료했다는 Ack 신호 리턴이 동시에 이뤄진다. 만약 아래와 같은 시나리오가 이뤄진다면 복제는 실패하게 되어 데이터 일관성이 떨어지게 된다.

1) 쓰기 요청 마스터 노드에 전달

2) Replica로 복제 요청과 Ack 신호를 동시에 전달

3) 복제 요청이 이뤄지기 전 master 노드의 다운 발생

4) 데이터 유실

Redis Cluster는 Sentinel과 비슷하게 Auto Failover 기능을 지원한다. 특정 Master 노드가 다운되더라도 과반수 이상의 Master 노드가 살아있으며 다운된 노드의 Replica가 살아있다면 Failover 처리를 하고 Replica를 Master로 승격시키는 작업을 자동으로 수행한다.

만약 Replica가 Master로 승격된 이후에 해당 Master 노드의 통신이 재개되거나 재시작을 한다면, 이미 Replica가 Master로 승격되었으므로 해당 노드는 Replica로써 동작하게 된다.

또한 Master가 통신 불능이라는 판단은 과반수의 master 노드와 통신하지 못한 경우 스스로 error state로 빠지게 되며 write 요청을 받지 않는다.

저작자표시 비영리 동일조건 (새창열림)