Redis Replication 구축

Redis는 Remote Dictionary Server의 약자로서, "Key - Value" 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 데이터베이스 관리 시스템이다. 인 메모리 데이터 구조를 가진 저장소이다.

즉, 휘발성을 가진 데이터베이스 이므로 MySQL과 같은 RDBMS와 다르게 데이터베이스를 종료시키면 메모리에 있는 데이터는 다 사라지게 된다.

 

그래서 Redis를 사용할 때에는 HA(고가용성)에 대한 의문을 항상 가져야 하는데 Redis는 이런 부분을 다양한 기능을 통해 지원을 하고 있다.

 

Redis Replication

Redis가 복제를 통해 고가용성 및 장애 조치를 지원하는 방법

 

 

복제본

Redis Replication은 사용 및 구성이 간편한 리더의 Follower (복제)가 있다. 복제된 Redis 인스턴스는 마스터 인스턴스의 정확한 복사본이 될 수 있다. 마스터 측에서 발생하는 쓰기, 키 만료 또는 제거에 대한 영향을 복제하기 위해 복제본에 명령 스트림을 전송하여 복제본을 업데이트된 상태로 유지한다.

 

서버 이중화

이중화 개념으로 데이터를 거의 실시간(비동기 방식)으로 다른 레디스 노드에 복사하는 방식이다. 서비스를 제공하던 마스터 노드가 다운되더라도, 복제 노드에서 서비스를 계속해서 진행할 수 있다.

 

Redis를 단일 노드로 운영하면 생기는 문제점

1. 단일로 운영되던 Redis 노드가 어떤 이슈로 인해 다운될 경우 서비스 전체에 영향이 간다.
2. Redis를 다시 구동하기 위해 AOF 파일을 읽을때도, 만약 파일이 크다면 읽는 시간이 오래 소요된다.

 

Redis AOF 백업

• AOF(Append Only File) 방식으로 명령이 실행될 때마다 해당 명령이 파일에 기록됨.
• 데이터 손실이 거의 없음!

 

Replication 복제 특징

1. 비동기 복제
2. 마스터는 여러 Replication을 가질 수 있음.
3. 복제의 복제서버를 가질 수 있음
4. 하지만, FailOver는 되지 않음.

 

 

Master 노드를 stop 시킨 후 복제 노드의 로그

 

Master 노드를 Start 한 후 복제 노드의 로그

 

Redis Cli 접속 후 Key 값 확인

 

Replication 구성시 마스터 서버에서 백업을 받아야만 하는 이유

• 마스터 서버가 백업을 받지 않는 경우 마스터와 복제 서버에서 데이터를 모두 유실할 수 있는 가능성이 있다.
• Redis는 default 설정으로 AOF 백업 기능을 제공한다.

 

Why??

마스터 서버에서 AOF나 RDB 파일 없이 복제서버만 구성 후 운영 중인 상태일 때를 가정하자.

1. 마스터 서버가 다운된다. (AOF, RDB 파일 없음)
2. FailOver가 발생하기 전 마스터 서버가 빠르게 구동. AOF나 RDB 파일이 없기 때문에 데이터가 없는 상태로 구동
3. 마스터 서버에서 복제 서버로 동기화가 일어남
4. 복제 서버는 데이터가 사라지게 된다.
5. 복제 서버에서 AOF 백업을 받는다고 하지만, rewrite 기능으로 AOF 파일에서도 데이터가 사라지게 됨.

 

---

 

Docker 환경에서 Redis Replication 구현하기

• Redis Master : 6379
  • REDIS_REPLICATION_MODE 옵션을 MASTER로 설정

 

• Redis Slave-1 : 6380
  •  REDIS_REPLICATION_MODE=slave
  • REDIS_MASTER_HOST=redis

 

• Redis Slave-2 : 6381
  • REDIS_REPLICATION_MODE=slave
  • REDIS_MASTER_HOST=redis

 

• Redis docker-compose 파일
  • docker-compose가 제대로 동작하지 않는 문제점 수정⇒ container이름이 제대로 올라가지 않아 의존을 할 수 없는 문제
    ⇒ container_name을 명시하여주어야 제대로 동작
  • 레플리카를 등록했을 때, 세 개의 서버가 연결되지 않고 서로 master 서버로 띄워지는 문제점을 발견

 

version: '3'

services:
    redis:
        image: 'bitnami/redis:latest'
        container_name: redis-master
        environment:
          - REDIS_REPLICATION_MODE=master
          - ALLOW_EMPTY_PASSWORD=yes
        networks:
          - redis-network
        ports:
          - 6379:6379
    redis_slave-1:
        image: 'bitnami/redis:latest'
        container_name: redis-slaves-1
        environment:
          - REDIS_REPLICATION_MODE=slave
          - REDIS_MASTER_HOST=redis
          - ALLOW_EMPTY_PASSWORD=yes
        ports:
          - 6479:6379
        depends_on:
          - redis
        networks:
          - redis-network
    redis_slave-2:
        image: 'bitnami/redis:latest'
        container_name: redis-slaves-2
        environment:
          - REDIS_REPLICATION_MODE=slave
          - REDIS_MASTER_HOST=redis
          - ALLOW_EMPTY_PASSWORD=yes
        ports:
          - 6579:6379
        depends_on:
          - redis
        networks:
          - redis-network
networks:
    redis-network:
        external: true

 

 

Redis Replication 의 한계

Master 서버 1개와 Slave 서버(복제 서버) 2개로 Replication을 구축하여 배포한다고 하였을 때 Master 서버가 다운된다하더라도 Slave 서버에서 Read는 가능할 것이다. 하지만 Slave은 readOnly이기 때문에 write(쓰기) 기능이 수행 되지 않는 사이드 이펙트가 발생할 수 있다. Redis Replication은 FailOver 기능을 제공하지 않기 때문이다.

 

물론 이런 Redis 장애가 잦은 상황은 아닐 것이지만 서버, 인프라는 365일 정상적으로 장애없는 서비스를 운영해야 하기 때문에 이런 장애를 미리 대응할 수 있는 시스템을 구축해야 한다.

 

 

Redis Sentinel

위에서 설명한 FailOver 기능을 제공하기 위해, Redis는 Sentinel이라는 기능을 제공한다. 간단히 말하자면 관리자가 모니터링하고 수동으로 Master 서버를 다시 올려야 하는 과정을 Sentinel이 대신 맡아서 실시간으로 모니터링하고, 자동으로 FailOver 하는 기능을 제공한다.

 

다음 포스팅엔 Redis Sentinel에 대해 이야기 해보도록 하자!!