복제

복제의 모든 어려움은 결국 하나로 귀결돼 — 변경된 데이터를 어떻게 처리하느냐. 데이터가 안 바뀌면 복사는 쉽잖아. 문제는 바뀔 때야.

가장 흔한 방식은 리더 기반 복제야. 리더 하나가 모든 쓰기를 받고, 복제 로그로 팔로워들에게 전파하는 거지. 단순하고 잘 동작하는데, 진짜 까다로운 건 리더 장애 조치(failover) 야. 팔로워를 새 리더로 승격시키고, 클라이언트와 다른 팔로워를 재설정해야 하는데 — 비동기 복제면 새 리더가 옛 리더의 쓰기를 다 안 받았을 수 있고, 스플릿 브레인이면 두 노드가 동시에 리더라고 주장하고, DB 외부 시스템과 프라이머리 키가 꼬이면 개인 데이터가 잘못된 사용자에게 노출될 수도 있어. GitHub에서 실제로 일어난 사고야. 이런 문제들 때문에 일부 운영 팀은 자동 장애 조치를 안 쓰고 수동으로 하기도 해.

비동기 복제에서는 복제 지연이 불가피하고, 이게 미묘한 문제를 만들어. 내가 뭔가 썼는데 바로 읽으니 안 보이는 거(자기 쓰기 읽기 문제), 팔로워마다 지연이 달라서 시간이 거꾸로 간 것처럼 보이는 거(단조 읽기 문제), 인과적으로 연결된 쓰기의 순서가 뒤바뀌어서 답이 질문보다 먼저 보이는 거(일관된 순서 읽기 문제). 최종적 일관성이라고 하지만, 그 "결국"이 언제인지는 아무도 몰라.

다중 리더는 리더를 여러 개 둬서 쓰기 성능과 가용성을 높이지만, 대가는 쓰기 충돌이야. 두 리더에서 같은 데이터를 동시에 다르게 고치면 나중에 복제할 때 충돌이 터지거든. 최종 쓰기 승리(LWW) 는 간단하지만 데이터 유실이 있고, 병합은 복잡하고, 결국 완벽한 해법은 없어. 리더 없는 복제(다이나모 스타일)는 더 극단적이야. 모든 노드가 직접 쓰기를 받고, 정족수(w + r > n) 로 일관성을 확보하는데, 현실에서는 느슨한 정족수, 동시 쓰기, 부분 성공 같은 엣지 케이스가 너무 많아서 강한 일관성은 포기해야 해.

세 가지 접근법 모두 다른 트레이드오프를 가지고, 어떤 것도 충돌 없는 완벽한 복제를 제공하지 못해. 복제는 쉽게 끝나지 않는 문제야.

---

정리

5장 읽고 기억할 거:

1. 복제의 핵심 어려움은 변경 데이터 처리다. 단일 리더, 다중 리더, 리더 없는 — 각각 다른 트레이드오프를 가진다
2. 복제 지연은 불가피하고, 보장 수준을 명확히 해야 한다. 자기 쓰기 읽기, 단조 읽기, 일관된 순서 읽기 — 필요한 보장을 식별하고 구현해야 한다
3. 다중 리더와 리더 없는 복제는 강력하지만 충돌 해결이 핵심 과제다. 동시 쓰기를 어떻게 감지하고 해결할 것인가가 성패를 가른다