DB 의 데이터 여러 노드에 복사. 노드 fail 에도 데이터 살아남고, 읽기를 여러 노드에 분산. 단순해 보이지만 sync vs async, leader vs multi-leader, replication lag 처리, read-your-writes 일관성 — 모든 선택이 trade-off. 이 가이드는 그 trade-off 의 메커니즘을 정리한다.
왜 replication 인가
이유 3 가지:
1. 가용성 (HA) — 1 노드 fail 시 다른 노드가 서비스
2. 읽기 확장 — read 가 N 배 처리 가능 (read replica)
3. 지리 분산 — user 근처 데이터센터 → latency ↓
비용:
- 일관성 vs 가용성 trade-off (CAP)
- replication lag — primary 와 replica 의 시간 차
- 복잡도 — failover · split-brain · monitoringSync vs Async — 같은 단어 다른 보장
Synchronous replication
Client → Primary write → Primary "기다림"
↓
Replica 들에 복사
↓
모든 (또는 N개) replica 의 ack
↓
Client 에 OK 반환
장점:
- 데이터 손실 0 (commit 시점에 모든 곳에 박힘)
단점:
- 가장 느린 replica 의 latency = client latency
- 한 replica 가 hang 하면 write 전체 stall
- 보통 적용 X — 또는 quorum 만 sync (N/2+1)Asynchronous replication (대부분의 DB default)
Client → Primary write → Primary 가 자기 disk 에 박고 즉시 OK
↓ (백그라운드)
Replica 들에 복사 (지연 가능)
장점:
- write latency 낮음 (replica 의 영향 0)
단점:
- replica lag — 1-100ms (또는 더 큼) — 그 시간 안에 primary 죽으면 데이터 손실
- read replica 의 stale read
trade-off 명시:
- MySQL: semi-sync (1 replica ack 까지 wait) 옵션
- PostgreSQL: synchronous_commit = on/off/remote_apply
- Cassandra: ANY (X), ONE, QUORUM, ALL (sync 정도 선택)Topology — 누가 누구에게 복사
Leader-Follower (가장 흔함)
Leader (write)
↓ ↓ ↓
Follower Follower Follower (read)
장점: 단순, 명확한 일관성 모델
단점: leader fail 시 failover 필요 (downtime ~ failover 시간)
사용: MySQL, PostgreSQL, MongoDB primary, Redis masterMulti-Leader (multi-master)
Leader-A (US) ←→ Leader-B (EU) ←→ Leader-C (APAC)
↓ ↓ ↓
Follower Follower Follower
장점: 지리 분산, 각 지역 가까운 leader 로 write
단점: write 충돌 (서로 다른 leader 에 같은 key 동시 update) — 해결 알고리즘 복잡
사용: CouchDB, Bucardo, multi-region 일부 설정Leaderless (Dynamo-style)
모든 노드가 동등.
Client → 직접 N 노드에 write (또는 coordinator 거쳐)
W = write quorum, R = read quorum, N = replica 수
quorum 조건: W + R > N → 일관성 보장
예: N=3, W=2, R=2 → 한 노드 stale 이어도 다른 노드와 비교로 정확한 값 read
장점: leader 없음 → SPOF X, 매우 가용 (Dynamo 의 "always writable")
단점: 충돌 해결 logic 필요 (last-write-wins / version vector / CRDT)
사용: Cassandra, Riak, DynamoDB (내부)Replication Lag — 보이지 않는 함정
시나리오:
user → Primary 에 "프로필 사진 업로드" → OK
user → 새로고침 → 읽기 부하 분산으로 Replica 에 요청
Replica 는 아직 그 사진 못 받음 (lag 50ms)
→ "사진 없음" 표시 ← 사용자 혼란
이게 read-your-writes 일관성 위반.
해결 패턴:
1. write 직후 잠시 동안 primary read (sticky session)
2. write 직후의 read 만 primary 로 라우팅 (logical clock)
3. replica 에서 timestamp 추적 — 자기 시점보다 오래된 데이터면 primary 에 fallback
4. 그 사용자 ID 의 caching layer 강제 invalidate일관성 모델 — 무엇을 보장하나
| 모델 | 보장 | 대표 시스템 |
|---|---|---|
| Strong / Linearizable | 한 시점에 모두 같은 값 (atomic) | Spanner, etcd, ZooKeeper |
| Sequential | 모든 process 가 같은 순서로 봄 | 일부 NewSQL |
| Read-your-writes | 내 write 는 내 read 가 본다 | app layer 추가 시 가능 |
| Monotonic reads | 한 사용자가 점점 새 값만 봄 (시간 거꾸로 X) | sticky session |
| Eventual | 결국 모두 수렴 (시간 보장 X) | DNS, Cassandra default, S3 |
Failover — leader 죽었을 때
자동 failover 단계:
1. failure detection — heartbeat 끊김 (보통 10-30s timeout)
2. new leader 선출 — consensus (Raft 등) 또는 manual
3. data 일관성 검증 — 새 leader 의 log 가 충분 (안 그러면 data loss)
4. routing 갱신 — client 가 새 leader 로
함정:
- false positive — 살아있는 leader 가 잠시 hang → failover → split-brain
- 비대칭 failure — leader 가 follower 는 보는데 client 만 못 보는 경우
- data loss — async replication 의 commit 안 된 write 손실흔한 함정
- "async replication 으로 충분" — production 에서 0 데이터 손실이 필요하면 semi-sync (최소 1 replica ack) 필수.
- read replica 에서 transactional read — lag 때문에 일관성 깨짐. read replica 는 analytics / 캐싱 보조 용.
- multi-leader 의 write 충돌 무시 — last-write-wins 는 데이터 손실. CRDT 또는 application-level merge 가 정석.
- replica 가 너무 많음 — leader 의 outbound network 폭증. cascading replication (replica → replica) 검토.
- cross-region replication 의 cost — 일부 cloud 은 GB 당 과금. 큰 write 워크로드는 monthly 비용 폭발.
마무리
Replication 은 단순 복사 아니다 — 일관성·가용성·latency 의 동시 게임. sync 도 async 도 정답 X — 무엇이 손실 가능한지·무엇이 lag 해도 OK 인지에 따라 선택.
Eventual consistency 는 마케팅이 권할 정도로 매력적이지만 대부분 application 은 read-your-writes 가 필요. 그래서 "eventual 하다고 그냥 두면 사용자가 본 데이터가 사라지는" 사례가 흔함. app layer 에서 명시적 보강 필수.