CHAPTER 07 레플리케이션 [PART 02 실전]

I. 레플리케이션 기능

1. 개요

• Redis는 기본적으로 단일 노드로 동작하지만, 가용성 확보와 읽기 부하 분산을 위해 레플리케이션 기능을 제공함
• 마스터-레플리카 모델로 구성되며, 마스터 노드에서 발생한 데이터 변경을 여러 레플리카 노드에 비동기적으로 복제함

(1) 주요 목적

1. 읽기 부하 분산 (Read Scaling)
   • 여러 레플리카를 통해 읽기 요청 분산 처리 가능
   • 특히 읽기 작업 비중이 큰 시스템에서 효과적
2. 고가용성 확보 (High Availability)
   • 마스터 노드 장애 시, 레플리카를 새로운 마스터로 승격 가능(페일오버)
   • Redis Sentinel 또는 클러스터를 통해 자동화 가능
3. 데이터 중복성 확보 (Redundancy)
   • 마스터의 데이터를 실시간 복제함으로써 백업 역할도 수행

(2) 레플리케이션의 특징

1. 비동기 복제
   • 마스터가 변경 사항을 비동기로 레플리카에 전파
   • 마스터에 쓰기 직후 레플리카에는 아직 반영되지 않았을 수 있음 (일관성 유의)
2. 읽기 전용 레플리카
   • 기본적으로 레플리카는 읽기 전용
   • replica-read-only no 설정 시 쓰기 가능하나 일관성 깨질 수 있어 위험
3. 클라이언트 연결 시 유의사항
   • 마스터와 레플리카의 주소를 분리하여 설정
   • AWS ElastiCache 등은 마스터용(primary)과 레플리카용(reader) 엔드포인트 제공
4. 마이그레이션 활용 가능
   • 새로운 Redis 서버로 이관 시, 기존 마스터를 레플리카로 연결 → 데이터 복제 완료 후 독립 → 다운타임 최소화 가능
5. 주의사항
   • 재동기화 또는 레플리카 재시작 시 데이터 삭제 가능
   • 마스터에 영속성이 설정되어 있지 않으면 위험
   • CONFIG DEBUG 등 일부 명령어는 조심해서 사용

---

II. 레플리케이션을 시작할 때의 메커니즘

1. 전체 동기화 (Full Synchronization)

• 레플리카가 마스터에 처음 연결하거나, 부분 동기화가 불가능한 경우에 발생
• 마스터는 FULLRESYNC 응답 후 RDB 스냅샷을 생성하고 레플리카에 전송
• 동기화 중 마스터는 계속 쓰기 작업을 처리하며, 변경 명령어를 replication buffer에 저장
• 레플리카는 RDB 파일을 수신하고 로딩한 뒤, buffer에 누적된 명령을 수신해 반영
• 이 과정을 통해 마스터와 레플리카 간 완전한 데이터 일치 상태가 됨

Redis에서 전체 동기화는 레플리카가 마스터의 전체 데이터를 RDB로 받아 초기화하는 과정이며, 다음과 같은 절차와 상황에서 발생함

- 전체 동기화 절차

• 레플리카가 마스터에 레플리케이션 요청
• 마스터가 BGSAVE 명령으로 포크하여 RDB 파일 생성
• 레플리카는 기존 RDB 제거 후 새로운 RDB 수신 및 로딩
• 생성 도중의 쓰기 명령은 클라이언트 출력 버퍼에 저장됨
• RDB 로딩이 끝나면 클라이언트 출력 버퍼의 명령도 전송
• 이후 실시간으로 동기화 지속됨

- 여러 레플리카가 있는 경우

• 첫 번째 레플리카가 붙었을 때 BGSAVE가 시작되고, 이 시점 이후 레플리카는 동일한 RDB를 공유
• 두 번째 레플리카가 BGSAVE 종료 전에 연결되면 같은 RDB를 공유함
• BGSAVE 완료 이후에 연결된 레플리카는 새롭게 전체 동기화를 시작함

- 클라이언트 출력 버퍼 초과 시

• 레플리카는 client-output-buffer-limit 초과 시 연결이 끊어짐
• 이후 연결 시 backlog로 부분 동기화가 되지 않으면 전체 동기화 발생
• 기본값은 256MB hard, 64MB soft, 60초 지속 시 강제 종료

- TTL(만료 키) 처리 방식

• 레플리카는 자체적으로 TTL을 만료시키지 않음
• 마스터가 키를 만료시키면 DEL 명령으로 동기화됨
• RDB에는 만료된 키가 포함되지 않으므로 레플리카의 키 수가 더 적을 수 있음

- diskless replication에서의 레플리카 동작

• repl-diskless-sync yes 설정 시 마스터는 RDB를 디스크에 저장하지 않고 소켓으로 전송
• 이때 5초 대기 후 여러 레플리카에게 동시에 전송 (repl-diskless-sync-delay)
• 이후에 붙는 레플리카는 새롭게 BGSAVE를 수행함

- 기타 고려 사항

• repl-backlog-ttl 시간이 지나거나 비워지면 전체 동기화 발생
• 마스터의 복제 ID가 변경되거나 재시작되면 전체 동기화 유도됨
• replica-serve-stale-data no 설정 시 전체 동기화 중에는 클라이언트 요청 거부 가능

2. 부분 동기화 (Partial Synchronization)

• PSYNC 명령어를 이용하여 수행됨
• 레플리카가 이전 복제 ID와 오프셋 정보를 보유하고 있고, 마스터가 repl-backlog 버퍼를 보유 중일 때 동작
• backlog에 남아 있는 변경 명령만 전송하여 빠르게 동기화 가능
• 네트워크 단절 등으로 잠시 끊긴 경우 유용

3. repl-backlog 역할

• 마스터는 변경 데이터를 일정량 메모리에 보존 (repl-backlog)
• 레플리카가 재접속할 경우 이 데이터를 기준으로 부분 동기화를 시도
• backlog 크기를 초과하거나 오래되면 데이터가 사라져 전체 동기화가 다시 발생함

4. 동기화 실패 시 동작

• 레플리카가 보유한 오프셋이 backlog에 없거나, 복제 ID가 다르면 전체 동기화 수행
• 전체 동기화는 부하가 크므로 가능하면 부분 동기화를 유지하는 것이 성능상 유리함

---

III. 레플리케이션 동작 중 메커니즘

1. 연결 상태 유지 및 확인

• 마스터와 레플리카는 PING/PONG 메시지를 주고받으며 지속적으로 연결 상태를 확인
• 레플리카는 ping 명령을 주기적으로 마스터에 전송하고, 응답을 받지 못하면 연결이 끊겼다고 판단함
• 마스터는 repl-timeout 설정값 이내에 레플리카로부터 응답이 없으면 해당 레플리카를 끊긴 것으로 판단

2. 데이터 동기화 지속

• 정상 상태에서는 마스터는 변경된 명령어를 실시간으로 레플리카에 전파함
• 레플리카는 해당 명령을 받아 마스터와 동일한 데이터를 유지함
• 데이터는 명령어 단위로 전달되며, 수신 후 바로 적용

3. 네트워크 불안정 시 처리

• 일시적 연결 단절이 발생해도, repl-backlog 범위 내이면 부분 동기화로 복구 가능
• backlog 범위를 초과한 경우, 다시 전체 동기화 수행

4. 중요 파라미터

• repl-disable-tcp-nodelay: TCP Nagle 알고리즘 사용 여부
• repl-ping-slave-period: 레플리카가 마스터에 ping 보내는 간격 (초 단위)
• repl-timeout: ping 응답 대기 시간. 이 시간 초과 시 연결 끊김 처리

레플리카가 단순히 데이터를 복제만 하는 게 아니라, 마스터와의 연결 상태를 지속 감시하며, 중간에 끊겨도 복구 가능한 구조임.

---

IV. 페일오버

1. 개요

• 마스터 Redis 서버에 장애가 발생했을 때, 레플리카를 새로운 마스터로 승격시키는 과정
• 수동 또는 자동으로 수행할 수 있음

2. 수동 페일오버

• Redis 서버에 접속해 replicaof no one 명령어를 실행하면 레플리카가 마스터로 승격됨
• 이후 기존 마스터가 복구되면, 새 마스터를 기준으로 다시 복제 설정 필요

3. 자동 페일오버: Redis Sentinel

• Sentinel은 Redis의 고가용성(HA) 구성 도구
• 마스터와 레플리카의 상태를 모니터링하며, 마스터 장애 시 자동으로 레플리카를 마스터로 승격
• 클라이언트에게 새로운 마스터 정보를 자동으로 전달할 수 있도록 지원

4. Sentinel 동작 방식

• 최소 3개의 Sentinel 프로세스를 운용할 것을 권장
• Sentinel 간 Quorum(정족수) 투표로 마스터 장애를 감지
• 장애가 확정되면 가장 적절한 레플리카를 마스터로 승격시키고, 다른 레플리카들은 이 새 마스터를 따르도록 구성 변경

---

V. 레플리케이션 도입 방법

1. 설정 방법

• Redis 설정 파일 또는 CLI에서 replicaof <master-host> <master-port> 명령 사용
• 연결 이후 자동으로 RDB 및 AOF 복제 수행

2. systemd로 실행하는 경우

• systemd 서비스 유닛 파일에 ExecStart 명령어로 Redis 실행 시 --replicaof 옵션 전달 가능
• 예:
• ExecStart=/usr/bin/redis-server /etc/redis/redis.conf --replicaof 192.168.0.10 6379

3. Redis Sentinel 활용 시

• Sentinel 구성 파일 (sentinel.conf)에 마스터 정보와 Quorum 설정 등 지정
• Sentinel 프로세스를 별도로 실행하며, Redis 서버들과는 별개로 유지

4. 주의사항

• 보호모드(protected-mode)는 비활성화 필요
• 마스터/레플리카 간 시간 동기(NTP) 권장
• AOF 및 RDB 설정은 마스터에만 필수, 레플리카에는 선택 적용 가능

---