상품 상세 페이지 트래픽이 늘면서 DB CPU가 80%를 넘기 시작했어요. 읽기 부하를 빼야 하는데, 복제본을 붙일지 캐시를 둘지 정해야 하는 상황입니다.
언제: 읽기가 무거운데 쿼리 종류가 다양하고, 데이터가 거의 최신이어야 할 때. 코드는 읽기 커넥션 라우팅만 바꾸면 돼서 사고 날 곳이 적어요.
비용: 복제 지연 때문에 방금 쓴 데이터가 안 보일 수 있고, DB 인스턴스 비용이 한 대 더 듭니다. 무거운 쿼리 자체는 복제본에서도 똑같이 느려요.
언제: 소수의 인기 데이터에 읽기가 몰리고, 몇 초 정도 오래된 데이터를 보여줘도 괜찮을 때. 같은 걸 반복해서 읽는 패턴이면 DB 부하를 수십 배 줄일 수 있어요.
비용: 무효화 로직이 버그의 온상이 되고, 캐시가 비거나 죽으면 트래픽이 한 번에 DB로 쏟아집니다(스탬피드). 운영할 시스템이 하나 더 늘어나요.
기본은 읽기 복제본부터 갑니다. 코드 변경이 거의 없고 데이터도 거의 최신이라 운영 사고가 덜 나거든요. 다만 모니터링에서 상위 10개 쿼리가 전체 읽기의 80% 이상을 차지하고 몇 초의 staleness가 허용된다고 확인되면, 그때 그 핫한 경로에만 캐시를 얹습니다.
- 복제본을 붙였는데도 읽기 p99가 500ms 위에 머무름 — 쿼리 자체가 무겁다는 신호
- pg_stat_statements에서 상위 10개 쿼리가 전체 읽기의 80% 이상 — 같은 데이터를 반복 조회 중
- 피크 시간대 복제 지연이 5초를 넘어 '방금 쓴 게 안 보여요' 문의가 들어오기 시작
- 복제본을 2대, 3대로 늘려도 비용만 선형으로 증가하고 p99는 그대로
🔧pg_stat_statementsGrafana (p99, replication lag 대시보드)RedisAWS RDS read replicaslow query log
“I start with a read replica because it's simpler to run; I add a cache only when hot keys dominate reads.”
checking microphone…