피드로 돌아가기
Treasure Hunting at Scale: Why Our Cache-Aside Cache Cost Us 40% in Tail Latency During Black Friday
Dev.toDev.to
Backend

Write-through 캐시 전환으로 p99 Latency 1.8s에서 210ms로 단축

Treasure Hunting at Scale: Why Our Cache-Aside Cache Cost Us 40% in Tail Latency During Black Friday

Lillian Dube2026년 5월 28일4advanced

Context

동시 접속자 270k 규모의 이벤트 시 Cache-aside 패턴의 TTL 만료로 인한 Cache Miss Storm 발생. Redis 부하보다 PostgreSQL의 Seq Scan 및 Connection Exhaustion으로 인한 DB 병목이 시스템 전체의 502 에러를 유발한 상황.

Technical Solution

  • Kafka 기반의 Event-driven 아키텍처 도입을 통한 Write-through 캐싱 구조 설계
  • CMS에서 생성된 이벤트를 hunt-publisher 서비스가 소비하여 Redis Hash에 전역 설정값을 사전 기록하는 방식 채택
  • 이벤트 기반 Pre-warming Job을 통해 헌트 시작 10분 전 캐시 데이터를 미리 로드하여 Cold Start 방지
  • PostgreSQL의 JSON 컬럼 조회를 최적화하기 위해 hunt_id와 coordinate를 결합한 복합 인덱스 생성으로 Seq Scan 제거
  • Read-through 엔드포인트 도입으로 캐시 부재 시 404 Fallback 처리하여 DB로의 요청 전파를 원천 차단
  • 데이터 일관성 수준을 Eventual Consistency로 낮추어 쓰기 경로의 복잡도를 해결하고 읽기 성능 극대화

1. 트래픽 스파이크가 예상되는 이벤트성 데이터에 Cache-aside 대신 Pre-warming 전략을 검토했는가?

2. 캐시 미스 시 DB로 유입되는 트래픽이 감당 가능한 수준인지, 아니면 Fallback 전략이 필요한가?

3. JSONB 등 비정형 컬럼 조회 시 Explain Plan을 통해 Seq Scan 발생 여부를 확인하고 적절한 인덱스를 적용했는가?

4. 데이터의 실시간 정합성보다 가용성이 중요한 서비스에서 Eventual Consistency 수용 가능 여부를 판단했는가?

원문 읽기