[공식 문서 훑어보기] 2. Redis 기초 관리 - Replication

Replication

1. Replication Backlog는 Memory 사용량에 비례하여 설정하세요.

Replication Backlog는 Primary 인스턴스에서 변경된 데이터를 Replica 인스턴스가 동기화할 수 있도록 돕는 버퍼입니다.

이 버퍼에는 실제 데이터가 아닌 Primary에서 발생한 명령어 스트림이 저장됩니다.

 

Replica가 일시적으로 Primary와 연결이 끊어졌다가 다시 연결되더라도 Backlog에 저장된 명령어를 활용하여 빠르게 최신 상태로 증분 동기화를 수행할 수 있습니다.

 

만약 필요한 명령어가 Backlog에서 사라진 경우 Replica는 전체 데이터베이스를 다시 복제하는 Full Resynchronization을 수행해야 하는데 이는 네트워크 및 시스템 부하를 증가시키므로 Backlog 크기를 적절하게 설정하는 것이 중요합니다.

▶▶ 명령어가 사라진다는 말은 Backlog 크기가 충분하지 않다는 말이다.

1-1. Replication Backlog 크기와 메모리 사용량

Redis 공식 문서에서는 "Replication Backlog 크기를 Redis가 사용하는 메모리 양에 비례하여 설정해야 한다"고 안내하고 있습니다.

 

Redis의 메모리 사용량이 많아질수록 처리해야 할 데이터 변경 사항도 많아지므로 이를 효과적으로 복제하기 위해 충분한 버퍼 공간이 필요합니다.

Backlog 크기를 충분히 확보하면 Replica와 Primary 간의 동기화가 더 원활하게 이루어질 수 있습니다.

1-2. Backlog 설정하는 방법

Redis는 기본적으로 적절한 크기의 Backlog를 자동으로 설정하지만 특별한 상황에서는 수동 설정이 필요할 수 있습니다.

▶▶ Backlog 크기가 maxmemory에 비해 훨씬 작은 이유는 명령어 스트림만 저장되기 때문입니다.

 

1. Redis-cli에서 backlog size 확인하는 방법

CONFIG GET repl-backlog-size

2. Redis-cli에서 backlog size 세팅하는 방법 ( 휘발성 )

CONFIG SET repl-backlog-size 1048576

3. redis.conf에서 backlog 설정하는 방법 ( 재사용 )

repl-backlog-size 10mb

2. 복제는 어떻게 하는걸까?

Redis에서 Primary서버에서 데이터가 변경되면 그 데이터는 Replica 서버로 복제되어 여러 서버에서 동일한 데이터를 유지하게 됩니다.

이렇게 하면 하나의 서버가 다운되더라도 다른 서버에서 데이터를 사용할 수 있어 고가용성을 보장합니다.

2-1. 복제 방식

Redis에서 복제는 메모리 단위로 이루어지며 backlog를 통해 복제가 이루어집니다.

여기서 중요한 점은 디스크를 사용하느냐 마느냐에 따라 복제 방식이 다르다는 것입니다.

• 디스크를 사용하는 복제 방식
  • Redis는 데이터를 디스크에 저장하여 영속성을 유지합니다.
  • 데이터를 디스크에 저장함으로써 장애가 발생했을 때 복구가 가능합니다.
  • RDB 스냅샷을 생성하여 데이터를 저장하며, 이 때 I/O 작업이 발생합니다.
• 디스크를 사용하지 않는 방식 (Default)
  • 디스크를 사용하지 않으면 메모리에서만 복제가 이루어집니다.
  • 이 방식은 속도가 매우 빠르지만 장애 발생 시 데이터를 복구할 수 없습니다.
  • 디스크를 사용하지 않는 복제 방식은 실시간성을 극대화하고 빠른 응답성을 제공하는 장점이 있습니다.

주의 할 점으로는 디스크를 사용하는 방식이면서 영속성 설정이 비활성화된 경우라도 복제 시 RDB 스냅샷이 실행됩니다.

이 경우 Redis는 데이터를 디스크에 저장하지 않지만 복제 과정에서 디스크를 참조하는 I/O 작업이 발생할 수 있습니다.

 

1. 영속성 유지 확인 방법

save 명령어를 사용하여 영속성 설정을 확인할 수 있습니다.

설정이 비어 있거나 빈 문자열을 반환하면 영속성 유지가 비활성화된 상태입니다.

CONFIG GET save

2. 디스크 사용 방식 확인 방법

이 명령어를 사용하여 디스크리스 복제 여부를 확인할 수 있습니다.

yes인 경우 디스크를 사용하지 않는 복제 방식이 활성화된 상태입니다.

CONFIG GET repl-diskless-sync

2-2. 왜 Redis는 기본값으로 디스크를 사용하지 않는 방식을 선택했을까?

개인적인 생각으로는 Redis는 기본적으로 빠른 실시간 응답을 중요시하는 시스템이기 때문에 디스크를 사용하는 방식이 RDB 스냅샷을 찍고 이를 기반으로 I/O 작업을 처리하는 과정에서 속도 면에서 불리할 수 있다고 생각합니다.

디스크를 사용하지 않는 경우 복제는 메모리 내에서만 이루어지므로 실시간성을 최대한 보장할 수 있습니다.

그래서 Redis는 기본적으로 디스크를 사용하지 않는 복제 방식을 채택한 것이라고 추측됩니다.

디스크를 사용하게 되면 복제는 backlog를 통해 메모리에서 복제되고 그 후 RDB 스냅샷을 통해 I/O 작업이 진행되는데 이 과정에서 지연이 발생할 수 있어 실시간 성능이 떨어질 가능성이 있다고 생각합니다.

3. Primary 서버 영속성 미설정 시 위험할 수 있습니다.

Primary 서버가 데이터를 복제하는데 중요한 역할을 합니다.

Primary 서버의 데이터는 Replica 서버에 복사되며 복제본들은 Primary 서버와 동일한 데이터를 유지하려고 합니다.

 

여기서 중요한 점은 Primary 서버의 영속성 설정(persistence) 입니다.

Redis에서는 데이터를 디스크에 저장 (영속성) 할 수 있는데 만약 Primary 서버의 영속성이 비활성화되거나 설정이 잘못되면 마스터 서버가 재시작할 때 데이터가 초기화될 수 있습니다.

3-1. Primary 서버 재시작 시 데이터가 비어있다면?

만약 Primary 서버가 재시작되면서 빈 데이터로 시작하게 된다면 그 복제본들도 빈 상태로 초기화됩니다.

 

쉽게 말해보면 Redis에서 Replication은 Primary 서버의 데이터를 Replica 서버가 똑같이 따라가는 구조입니다.

그런데 만약 Master 서버가 재시작 했을때 디스크에 데이터(=RDB, AOF 등)가 저장되어 있지 않았다면, Master 서버가 부팅 후 비어 있는 상태가 되어버립니다.

Redis의 Replication은 "Master와 똑같이 맞추는 것"이 목적이기 때문에 Replica 서버들도 "어? Master가 비었네?" 하고, 자기 데이터도 다 지워버립니다.