읽기 트래픽이 늘면 가장 먼저 떠올리는 카드가 **읽기 복제(read replica)**입니다. 쓰기는 프라이머리(primary) 한 대가 받고, 조회 쿼리는 여러 대의 레플리카(replica)로 분산해 프라이머리 부하를 덜어 줍니다. 그런데 도입하고 나면 "방금 저장했는데 화면에는 안 보인다"는 버그 제보가 들어오기 시작합니다. 원인은 거의 항상 복제 지연입니다.
복제는 비동기다
프라이머리에 쓴 데이터가 레플리카에 반영되기까지는 시간이 걸립니다. 기본 복제는 비동기라서 프라이머리는 레플리카의 반영을 기다리지 않고 커밋을 끝냅니다.
| 구분 | 동작 | 지연 |
|---|---|---|
| 프라이머리 쓰기 | 즉시 커밋, 응답 | 없음 |
| 레플리카 반영 | 바이너리 로그를 받아 재실행 | 수 ms ~ 수 초 |
부하가 몰리거나 큰 트랜잭션이 돌면 이 지연이 수 초까지 벌어집니다. 그 사이 레플리카로 간 조회는 옛 데이터를 봅니다.
지연 진단
MySQL이라면 레플리카에서 지연 초를 직접 볼 수 있습니다.
SQL
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source: 이 값이 프라이머리보다 몇 초 뒤처졌는지
Seconds_Behind_Source가 0이 아니라 계속 커지면 레플리카가 따라잡지 못하는 상태입니다. 이 값이 NULL이면 복제 자체가 끊긴 것이니 더 급한 문제입니다. PostgreSQL이라면 pg_stat_replication의 replay_lag로 같은 것을 봅니다.
일관성 함정을 푸는 실전 순서
- 쓰기 직후 읽기는 프라이머리로 — 사용자가 방금 만든 데이터를 바로 보여 줘야 하는 화면(주문 완료, 프로필 수정 직후)은 레플리카가 아니라 프라이머리에서 읽습니다. "read-your-writes" 보장이라 부릅니다.
- 세션 기준 라우팅 — 글을 쓴 사용자는 이후 몇 초간 같은 세션의 조회를 프라이머리로 보냅니다. 다른 사용자의 조회는 레플리카로 분산해도 무방합니다.
- 지연 허용 가능한 화면만 레플리카로 — 통계 대시보드, 목록 페이지, 검색처럼 몇 초 늦어도 되는 읽기를 레플리카로 보냅니다.
- 지연 임계값 모니터링 —
Seconds_Behind_Source가 임계값(예:3초)을 넘으면 해당 레플리카를 라우팅에서 잠시 빼고 알림을 받습니다.
핵심은 "모든 읽기를 레플리카로"가 아니라, 데이터 신선도가 중요한 읽기와 아닌 읽기를 구분해 라우팅하는 것입니다.
요점 정리
- 읽기 복제는 비동기라 레플리카는 항상 프라이머리보다 뒤처질 수 있다.
Seconds_Behind_Source(MySQL) /replay_lag(PostgreSQL)로 지연을 모니터링한다.- 쓰기 직후 바로 보여 줘야 하는 조회는 프라이머리에서 읽는다.
- 지연을 허용할 수 있는 화면만 골라 레플리카로 분산한다.
복제 구조를 직접 띄워 지연을 만들어 보고 쿼리 라우팅을 설계하는 실습은 데이터베이스 트랙에서 회원가입 없이 무료로 할 수 있습니다.