Read Replica 일관성 운영 플레이북
Read replica는 primary 부담을 줄여주지만, 동시에 사용자 입장에서 가장 답답한 버그를 만듭니다. 방금 저장한 데이터가 바로 보이지 않는 문제입니다.
진짜 문제는 기대치 불일치다
복제 지연 자체가 항상 장애는 아닙니다. 하지만 시스템이 최신 데이터를 보여줄 것처럼 행동하면서 다음 읽기를 stale replica로 보내면 그 순간 제품 장애가 됩니다.
어떤 흐름이 최신성을 요구하는지 먼저 정의하자
모든 쿼리가 primary 일관성을 요구하지는 않습니다. 보통 다음처럼 나눌 수 있습니다.
- 반드시 read-your-write가 필요한 흐름: 결제, 프로필 수정, 권한 변경
- eventual consistency가 허용되는 흐름: 대시보드, 통계, 피드
- 약간의 지연이 괜찮은 내부 백그라운드 읽기
이렇게 해야 일관성이 우연한 결과가 아니라 명시적인 아키텍처 선택이 됩니다.
실전에서 잘 먹히는 패턴
- 짧은 세션 윈도우 동안 sticky read 적용
- 중요 후속 조회는 primary로 강제 라우팅
- 요청 컨텍스트에 freshness 요구사항 전달
- replica lag 메트릭을 애플리케이션 라우팅과 연결
이 방법들은 stale 결과를 UI 문구로 변명하는 것보다 훨씬 낫습니다.
부수 효과도 같이 봐야 한다
Replica lag는 다음도 깨뜨립니다.
- 캐시 무효화 기대치
- 페이지네이션 안정성
- 검색 인덱싱 최신성
- 운영자가 primary와 replica를 비교하며 디버깅할 때의 혼선
즉 일관성 계획은 데이터팀만의 문제가 아니라 API, 프론트엔드, 운영팀이 함께 공유해야 하는 설계 문제입니다.
무엇을 모니터링할 것인가
- 시간대별 replica lag
- stale read 관련 사용자 불만
- replica에서 primary로의 fallback 빈도
- 쓰기 직후 읽기가 따라붙는 사용자 여정
읽기 확장은 누구나 이야기하지만, 그 과정에서 사용자 신뢰를 지키는 것이 진짜 엔지니어링입니다.
Continue Reading
다음으로 읽기 좋은 글
쿼리 플랜 회귀를 막는 데이터베이스 가드
인덱스 변경, 통계 갱신, 배포 이후 쿼리 실행 계획이 나빠지는 문제를 사전에 감지하는 방법을 정리합니다.
🗄️ DatabaseIdempotent Backfill 체크포인트 설계
백필은 한 번에 끝나지 않는 경우가 많습니다. 중단과 재시작을 견디는 체크포인트 설계가 데이터 작업의 안정성을 좌우합니다.
🚀 DevOpsKubernetes 심화 — HPA, Resource 관리, Pod Scheduling
Kubernetes 운영을 설정 모음이 아니라 자원 배치와 장애 복원력의 관점에서 정리합니다. requests/limits, HPA, affinity, taint, PDB, probe를 언제 어떻게 써야 하는지 실무적으로 설명합니다.
📈 최신 동향2026 쿠버네티스 플랫폼 트렌드: v1.35 이후 운영팀이 보는 포인트
2026년 4월 21일 기준 Kubernetes는 1.35, 1.34, 1.33을 유지보수합니다. 지금 중요한 것은 기능 개수보다, 운영팀이 어떤 비용 구조를 줄이고 있는가입니다.
다음 탐색