피드로 돌아가기
Dev.toBackend
원문 읽기
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
AI 요약
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 수용 가능 여부를 판단했는가?