Replication Lag이란 무엇인가
데이터베이스를 안정적으로 운영하려면 보통 하나의 원본(Master/Primary) 서버와 이를 복제한 여러 개의 사본(Replica) 서버를 함께 사용합니다. Master에 데이터가 쓰이면 그 변경 내용이 Replica로 전달되어 동일하게 반영되는데, 이 과정에는 물리적인 시간이 소요됩니다. 이때 Master의 데이터와 Replica의 데이터 사이에 발생하는 시간 차이를 Replication Lag(복제 지연)이라고 부릅니다.
쉽게 비유하면, 라이브 방송과 이를 몇 초 뒤에 송출하는 재방송 채널의 관계와 비슷합니다. 원본 방송(Master)에서는 이미 지나간 장면이지만, 재방송 채널(Replica)에서는 아직 그 장면이 나오지 않은 상태와 같은 것이죠.
왜 발생하고 어떻게 확인하는가
복제 지연은 다음과 같은 이유로 발생합니다.
- 네트워크 지연: Master와 Replica 간 물리적 거리나 대역폭 문제
- 쓰기 부하 증가: Master에 대량의 트랜잭션이 몰릴 때
- Replica의 처리 성능 부족: 복제 로그를 반영하는 속도가 느릴 때
MySQL 기준으로는 SHOW SLAVE STATUS 명령의 Seconds_Behind_Master 값으로 지연 시간을 확인할 수 있습니다. 예를 들어 이 값이 5라면, Replica는 Master보다 5초 늦은 데이터를 보여주고 있다는 의미입니다.
서비스에 미치는 영향과 대응 방법
복제 지연이 문제가 되는 대표적인 상황은 ‘쓰기 직후 읽기’입니다. 사용자가 게시글을 작성(Master에 쓰기)한 직후 목록 페이지를 새로고침(Replica에서 읽기)했을 때, 지연이 발생하면 방금 쓴 글이 보이지 않는 현상이 나타날 수 있습니다. 이는 사용자에게 데이터 유실처럼 오해를 불러일으킬 수 있어 서비스 신뢰도에 영향을 줍니다.
이를 해결하기 위해 실무에서는 다음과 같은 방법을 사용합니다.
- 중요한 읽기는 Master에서 직접 조회하도록 라우팅
- 애플리케이션 레벨에서 일정 시간 동안 캐시된 결과나 낙관적 업데이트 사용
- 모니터링 도구로 지연 시간을 상시 감시하고 임계치 초과 시 알림 설정
결국 Replication Lag은 완전히 없앨 수 있는 문제라기보다는, 서비스 특성에 맞게 얼마나 관리하고 완화할 것인지가 핵심입니다. 데이터 일관성과 시스템 확장성 사이의 트레이드오프를 이해하는 것이 안정적인 서비스 설계의 출발점입니다.