461. 복제 (Replication) - 마스터-슬레이브 아키텍처

⚠️ 이 문서는 데이터베이스 한 대가 죽으면 서비스 전체가 멈추고 데이터가 영구 유실되는 최악의 재앙을 막기 위해, **원본 데이터베이스를 똑같이 복사한 '쌍둥이 서버(복제본)'를 여러 대 만들어두어 데이터의 안전성과 읽기 속도를 동시에 끌어올리는 기술인 '복제'**를 다룹니다.

핵심 인사이트 (3줄 요약)

본질: 마스터(Master) DB에 데이터가 쓰이면, 슬레이브(Slave) DB들이 그 데이터를 졸졸 따라 쓰며 똑같은 복제본을 유지하는 아키텍처다. (최근에는 윤리적 이유로 Primary-Replica, Leader-Follower 용어로 대체됨)

읽기 분산 (Scale-out): 조회(SELECT) 쿼리는 슬레이브 3대에게 분산시키고, 쓰기(INSERT) 쿼리는 마스터 1대만 처리하게 하여 DB 서버의 부하를 획기적으로 줄여준다.

동기화 방식: 마스터가 슬레이브의 성공 응답을 끝까지 기다리는 동기(Sync) 방식과, 일단 마스터만 쓰고 대충 끝내버리는 비동기(Async) 방식 사이의 트레이드오프가 존재한다.

Ⅰ. 개요: 붕어빵 공장의 역할 분담 (Context & Necessity)

웹 서비스에서 데이터베이스 작업의 80%는 읽기(SELECT)고, 20%만 쓰기(INSERT/UPDATE)다. 서버 한 대로 이걸 다 처리하면, 사람들이 검색창을 새로고침 할 때마다 버벅거리게 된다.

그래서 아키텍트는 꼼수를 쓴다.

"쓰기 전용 서버(마스터)를 딱 1대만 두고, 읽기 전용 서버(슬레이브)를 3대 두자."
"사용자가 회원가입을 하면 마스터에 저장하고, 마스터는 그 내용을 즉시 슬레이브 3대에게 복사해 줘!"
"그리고 사용자가 자기 프로필을 조회하면, 무조건 슬레이브 1, 2, 3번 중 하나에 연결해 줘!"

이렇게 하면 읽기 트래픽을 무한대로 분산시킬 수 있으며, 마스터 서버가 벼락을 맞아 죽더라도 슬레이브 중 하나를 승격시켜 즉시 마스터로 쓸 수 있어 완벽한 고가용성(HA)이 보장된다.

📢 섹션 요약 비유: 마스터-슬레이브 복제는 **'유명 셰프와 3명의 수강생'**과 같습니다. 셰프(마스터)가 새로운 요리(데이터)를 개발하면, 3명의 수강생(슬레이브)이 그 레시피를 똑같이 베껴 적습니다. 손님들(읽기 쿼리)이 레시피를 물어보면 셰프를 귀찮게 할 필요 없이 3명의 수강생 중 아무에게나 물어보면 됩니다.

Ⅱ. 데이터 동기화의 딜레마: 동기 vs 비동기 ★

마스터가 데이터를 슬레이브로 복사할 때, 언제 "성공(Commit)!"이라고 외칠 것인가?

1. 동기 복제 (Synchronous Replication)

원리: 마스터에 데이터를 쓰고 $\rightarrow$ 슬레이브들에게 쏜다 $\rightarrow$ 모든 슬레이브가 "저장 완료!"라고 대답할 때까지 기다렸다가 $\rightarrow$ 클라이언트에게 성공이라고 응답한다.
장점: 마스터가 죽어도 데이터 유실이 0%다. (가장 안전함)
단점: 슬레이브 1대가 인터넷이 끊겨서 응답이 늦어지면, 마스터도 계속 기다려야 하므로 전체 시스템 속도가 엄청나게 느려진다.

2. 비동기 복제 (Asynchronous Replication)

원리: 마스터에 데이터를 쓰자마자 클라이언트에게 "성공!"이라고 응답해버린다. 그리고 슬레이브들에게는 "이거 복사해 놔~"라고 던지고 끝낸다(답장 안 기다림).
장점: 대기 시간이 없으므로 마스터의 쓰기 속도가 미친 듯이 빠르다. (대부분의 서비스 기본값)
단점: 마스터가 방금 쓰고 성공 응답을 줬는데, 아직 슬레이브에게 복사되기 0.1초 전에 마스터가 죽어버리면? 그 데이터는 영원히 유실된다.

Ⅲ. 실무 주의점: 복제 지연 (Replication Lag)

비동기 방식을 쓸 때 주니어 개발자들이 가장 많이 겪는 '귀신 곡할 노릇'이다.

상황: "내 정보 수정" 페이지에서 전화번호를 바꾼 뒤, "확인" 버튼을 눌렀다.
마스터 서버에 새 번호가 잘 들어갔다.
화면이 즉시 "내 프로필 페이지(조회)"로 넘어갔다. (슬레이브 서버를 찌름)
문제: 슬레이브에 아직 새 번호가 복사되기 전(보통 0.1~0.5초 지연됨)에 내 프로필을 조회해 버린 것이다.
결과: "어? 번호가 안 바뀌었는데? 버그인가?"

해결책: "방금 내가 쓴 데이터는 무조건 마스터 서버에서 조회하게 한다(Read-your-writes 일관성)" 같은 라우팅 로직을 애플리케이션 단에 추가해야 한다.

┌──────────────────────────────────────────────────────────────┐
│           마스터-슬레이브(Master-Slave) 복제 아키텍처 시각화           │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│        [ 👨‍💻 웹 서버 (Application) ]                           │
│        │ (쓰기 요청: INSERT)      │ (읽기 요청: SELECT)       │
│        ▼                        ▼                         │
│ [ 👑 마스터 (Master) ] ────▶ (로드밸런서 - 번갈아 가며 조회)       │
│        │                                                     │
│        │ (복제: Binlog / Redo Log 전송)                        │
│        │                                                     │
│        ├────────────────────┬────────────────────┐           │
│        ▼                    ▼                    ▼           │
│ [ 👥 슬레이브 1 ]      [ 👥 슬레이브 2 ]      [ 👥 슬레이브 3 ]      │
│                                                              │
│ ★ 특징: 쓰기 성능은 1대 분량이지만, 읽기 성능은 3대 분량으로 뻥튀기된다! │
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"완벽한 일관성과 압도적인 성능은 동시에 가질 수 없다." 복제(Replication)는 클라우드 네이티브와 분산 시스템을 지탱하는 가장 기초적이고 위대한 기술이다. 단순히 백업을 넘어, 전 세계에서 쏟아지는 트래픽을 감당하기 위해 읽기 부하를 분산시키는 유일한 탈출구다. 하지만 0.1초의 '복제 지연(Replication Lag)'이라는 물리적 한계를 인정해야만 하며, 이를 극복하기 위해 반동기(Semi-Sync) 복제나 멀티 마스터(Multi-Master), 혹은 AWS Aurora(390번 문서) 같은 하드웨어 융합 기술들이 끊임없이 발전하고 있다.

📌 관련 개념 맵

관련 특성: 고가용성 (High Availability, HA), 분할 투명성 (459번 문서)
동기화 원리: 이중화 (Active-Standby, Active-Active)
보안/윤리 용어 변경: Master-Slave $\rightarrow$ Primary-Replica, Leader-Follower
데이터 포맷: Binlog (MySQL - 복제할 때 던져주는 로그 파일)

👶 어린이를 위한 3줄 비유 설명

마스터 서버는 수업 시간에 칠판에 글씨를 쓰는 '선생님'이에요. (쓰기 담당)
슬레이브 서버들은 선생님이 쓴 글씨를 자기 공책에 똑같이 받아 적는 '학생들'이에요.
반 친구들이 "아까 선생님이 뭐라고 쓰셨어?"라고 물어볼 때, 선생님을 귀찮게 하지 않고 공책 필기를 다 한 학생들한테 물어보는 게 훨씬 빠르겠죠? 이게 바로 복제 아키텍처랍니다!