백엔드 데이터 인프라 67편 — Redis Replication (Master-Replica)

백엔드 데이터 인프라 시리즈 130편 중 67편이에요. 66편 에서 단일 인스턴스 영속화를 잡았다면, 이번 67편은 그 위에 올라가는 Replication — 여러 인스턴스로 복제본을 두는 메커니즘이에요. 읽기 분산·고가용성 기초·재해 복구의 출발점.

Replication이 어렵게 느껴지는 이유

분산 시스템 첫 발을 떼는 자리라 낯선 개념이 한꺼번에 나와요. 우선 비동기 복제의 의미부터 안 잡혀요. master가 쓰기를 받자마자 클라이언트에 OK를 응답하고, replica 동기화는 그 뒤에 비동기로 일어나는 모델인데, 이게 읽기 일관성에 어떤 영향을 주는지 처음 보면 감이 안 와요.

그 다음은 PSYNC(부분 동기화 명령)·offset·replication ID 개념이 복잡해요. partial resync와 full resync의 분기 조건에 더해 failover 시 replication ID가 바뀌는 메커니즘까지 한꺼번에 들어와요.

마지막으로 Replication만으로는 자동 failover가 안 된다는 점. master가 죽으면 사람이 직접 replica를 promote 해야 해요. 자동 failover가 필요하면 Sentinel(69편)이 별도로 붙어야 해요. "Replication 박았으니 HA(고가용성, High Availability) 되겠지"는 흔한 오해예요.

이 글에서 비동기 모델·PSYNC 동작·자동 promote 한계·읽기 분산 패턴·WAIT 명령까지 한 번에 봐요.

Master-Replica 모델

        +--------+
        | master | ← 클라이언트 쓰기
        +--------+
         /  |  \  (비동기 복제)
        v   v   v
     +----+----+----+
     | r1 | r2 | r3 | ← 클라이언트 읽기
     +----+----+----+

• Master = 쓰기 받는 본진
• Replica = master 의 복제본, 읽기 가능

설정

replica 쪽에서 한 줄:

# 런타임
> REPLICAOF 192.168.1.1 6379

# 영구 (redis.conf)
replicaof 192.168.1.1 6379

기본은 replica가 read-only 예요 (replica-read-only yes).

비동기 복제 — 핵심 모델

여기가 가장 중요한 자리.

흐름

1. 클라이언트 → master: SET key value
2. master 가 메모리 갱신
3. master → 클라이언트: OK            ← 여기서 응답 끝
4. master 가 replica 에 변경 stream
5. replica 가 메모리 갱신

핵심 — master가 응답한 뒤에 replica 동기화가 일어나요. 그 사이에 master가 죽으면 4·5 단계가 일어나지 않으니, 복제 안 된 쓰기가 그대로 손실됩니다.

영향

• 읽기 일관성 — 방금 master에 쓴 값을 replica에서 즉시 읽으면 예전 값이 돌아올 수 있어요 (Eventual Consistency, 결과적 일관성)
• 데이터 손실 위험 — master가 갑작스럽게 죽으면 복제 지연 동안의 쓰기는 사라져요
• 성능 이점 — replica 응답을 안 기다리니 master 응답 시간이 짧아요

동기 모드 — WAIT

특정 요청만 replica 확인까지 기다리게 할 수 있어요:

> SET important:key value
OK
> WAIT 2 1000             # 2개 replica 가 ack 할 때까지 최대 1초 대기
(integer) 2               # 2개가 ack 했음

반환값은 실제로 ack(확인 응답, acknowledgement)한 replica 수예요. 1초 안에 2개가 ack 되지 않으면 그 시점까지 ack 된 수만 돌려줘요.

주의 — WAIT도 진짜 동기 복제를 보장하지는 않아요. master가 WAIT 직후 죽으면 그 쓰기가 ack 한 replica에 도착했더라도, promote 된 replica가 그 값을 쓸 거라는 보장은 별개 문제예요. 강한 일관성은 Redis 만으로 어려워요.

PSYNC — 동기화 메커니즘

Replication ID + Offset

각 Redis 인스턴스는 현재 데이터셋 버전을 두 가지 값으로 표현해요:

• Replication ID — 임의의 pseudo-random 문자열로 데이터셋의 역사를 표시
• Offset — 복제 stream의 바이트 카운터

Replication ID + Offset = 데이터셋의 정확한 버전

PSYNC 흐름

replica → master: PSYNC <old_replid> <old_offset>
master 가 판단:
  - 같은 replication ID + master 의 backlog 에 그 offset 이후 데이터 있음
    → Partial Resync (놓친 데이터만 전송)
  - replication ID 다름 또는 backlog 부족
    → Full Resync (RDB 스냅샷 + 이후 stream)

Partial Resync — 빠른 복구

connection이 잠시 끊겼다가 복구되면 마지막으로 본 offset 이후 데이터만 받아요. 매우 빨라요.

조건:

• replica의 old replication ID가 master의 현재 또는 secondary ID와 일치
• master의 replication backlog(메모리 buffer)에 offset 이후 데이터가 충분

설정은 repl-backlog-size 1mb가 기본. 큰 환경에서는 수십~수백 MB 권장.

Full Resync — 비싼 작업

backlog가 부족하거나 첫 연결이면 master가 RDB 스냅샷을 만들고 → 네트워크로 전송 → replica가 로드 → 이후 stream을 받아요. 큰 데이터셋에서는 수십 초~수 분 걸려요.

Diskless Replication

# redis.conf
repl-diskless-sync yes
repl-diskless-sync-delay 5

기본은 RDB를 디스크에 쓰고 네트워크로 전송. Diskless는 디스크를 거치지 않고 곧장 네트워크로 보내요. 디스크가 느리고 네트워크가 빠른 환경에 유리.

repl-diskless-sync-delay 5는 5초를 대기해서 여러 replica가 한 번에 sync 받게 해줘요 (네트워크 한 번에 broadcast).

Failover — 수동 Promote

Replication만으로는 자동 failover가 안 돼요. master가 죽으면 수동으로:

# replica 에서
> REPLICAOF NO ONE
OK                       # 이 replica 가 새 master 됨

# 다른 replica 들에게 새 master 가르치기
> REPLICAOF <new_master_ip> <new_master_port>

Failover 후 Replication ID

여기 시험 함정이 하나 있어요 — promote 된 replica는 새 replication ID를 생성하면서 동시에 예전 master의 ID를 secondary로 유지해요. 그래서 다른 replica들이 partial resync로 새 master에 붙을 수 있어요 (full resync 회피).

자동 failover가 필요하면 → Sentinel(69편) 또는 Cluster(68편).

읽기 분산 패턴

단순 분산

            +--------+
write → ----| master |
            +--------+
              /    \
        read v      v read
          +------+----+
          | r1   | r2 |
          +------+----+

클라이언트가 write는 master, read는 replica로 라우팅해요. Spring Data Redis의 replication-aware 클라이언트를 쓰거나, 클라이언트 코드에서 직접 라우팅 로직을 짜요.

일관성 trade-off

비동기 복제니 방금 쓴 값을 즉시 replica에서 읽지 못해요. 두 가지 대응이 있어요:

1. 쓰기 직후는 master에서 읽기 — 사용자가 자기 글을 본인이 보는 경우에만, 일정 시간만
2. eventual consistency 허용 — 통계·랭킹·검색처럼 약간 늦어도 괜찮은 도메인

Read Replica 의 또 다른 활용

• Backup 전용 — replica 하나를 RDB 백업만 전담시켜서 master 부담을 뺌
• 분석 쿼리 — 무거운 KEYS·SCAN 같은 명령을 replica 에서만
• 장애 격리 — replica 에 무거운 작업 폭주해도 master 영향 X

한계·실무 함정

1. 복제 지연 (Replication Lag)

master와 replica 사이의 비동기 지연. 보통 수 ms~수십 ms, 부하 큰 환경에서는 수 초까지 가요.

모니터링:

> INFO replication
# Replication
role:master
connected_slaves:2
slave0:ip=...,offset=12345,lag=0
slave1:ip=...,offset=12345,lag=2     # 2초 lag

lag이 크면 네트워크·디스크·CPU를 점검해야 해요.

2. backlog 부족 → 잦은 full resync

repl-backlog-size가 작으면 짧은 connection 끊김에도 full resync가 트리거돼요. 큰 데이터셋에서는 매번 수십 초씩 멈춰요. 데이터셋 크기 × 10초 정도의 쓰기 분량으로 backlog를 잡아두세요.

3. fork 중 메모리 폭증

Full resync 시 master가 BGSAVE(백그라운드 스냅샷 저장)를 돌리면서 fork → COW(Copy-On-Write, 쓸 때만 복사)로 메모리가 2배까지 갈 수 있어요. 66편 persistence에서 본 함정 그대로예요.

4. Replica 가 master 보다 느림

replica의 명령 처리 속도가 부족하면 점점 뒤처져요. 같은 하드웨어 spec을 권장.

5. 자동 failover 없음

위에서 강조한 그대로. Replication 만으로는 HA X. Sentinel 또는 Cluster.

시험 직전 한 번 더 — Redis Replication 함정 압축 노트

• Master-Replica 비동기 복제 모델
• 설정 = replica 쪽에서 REPLICAOF master_ip port
• 기본 = replica read-only (replica-read-only yes)
• 비동기 복제 = master 응답 후 replica 동기화
• 영향 = eventual consistency + 복제 안 된 쓰기 손실 위험
• WAIT 명령 = 특정 요청만 replica ack 까지 대기
• WAIT 도 진짜 동기 복제 보장 X (강한 일관성은 Redis 만으로 어려움)
• PSYNC = replica 가 보내는 동기화 명령
• 동기화 식별 = Replication ID + Offset
• Partial Resync = old ID 일치 + backlog 충분 → 놓친 데이터만
• Full Resync = ID 다름 또는 backlog 부족 → RDB 스냅샷 + stream
• repl-backlog-size = partial 가능한 buffer 크기 (기본 1mb, 운영 환경 큰 값 권장)
• Diskless Replication = RDB 디스크 거치지 않고 네트워크 직송
• repl-diskless-sync-delay = 여러 replica 한 번에 sync (broadcast 효율)
• Failover 수동 = REPLICAOF NO ONE 으로 promote
• Promote 시 = 새 replication ID + 예전 ID secondary 유지 → 다른 replica partial resync 가능
• 자동 failover 필요 = Sentinel (69편) 또는 Cluster (68편)
• 읽기 분산 = write 는 master, read 는 replica
• 일관성 trade-off = 쓰기 직후 master 또는 eventual consistency 허용
• Read Replica 활용 = backup 전용 / 분석 쿼리 / 장애 격리
• 복제 지연 모니터링 = INFO replication 의 lag
• 부하 큰 환경 = 수 초 lag 가능
• backlog 부족 → 잦은 full resync → 운영 사고
• full resync = master fork → 메모리 2배 위험
• replica 가 master 보다 느리면 → 점점 뒤처짐 → 같은 spec 권장
• Replication 만으로는 HA X — Sentinel/Cluster 필요

공식 문서: Redis Replication 에서 PSYNC·diskless·자세한 메커니즘을 확인할 수 있어요.

시리즈 다른 편 (앞뒤 글 모음)

이전 글:

• 62편 — Redis 패턴 9가지 한눈에 매핑
• 63편 — Distributed Lock + Redlock 알고리즘
• 64편 — Twitter Clone 패턴 + Fanout 전략
• 65편 — Secondary Indexing 패턴 (RDB 인덱스 모방)
• 66편 — Redis Persistence (RDB · AOF · Hybrid)

다음 글:

• 68편 — Redis Cluster (Sharding · 16384 슬롯 · Hash Tag)
• 69편 — Redis Sentinel (자동 Failover · Quorum)
• 70편 — Redis ACL (사용자·권한 관리)
• 71편 — Redis TLS (전송 암호화 · mTLS)
• 72편 — Redis 메모리 최적화 (Encoding · Hash 압축 · Fragmentation)