피드로 돌아가기
Dev.toDatabase
원문 읽기
Materialized View 기반 설계로 p99 6.8ms 달성 및 렌더링 성공률 99.8% 기록
The Treasure Hunt Engine Blew Up My Inbox at 3 AM
AI 요약
Context
PostgreSQL 기반 read-through 서비스의 Bitmap Index Scan 부하로 인한 503 에러 발생. 고사양 인스턴스 도입 및 Redis 캐시 계층 추가에도 불구하고, 데이터 불균형에 따른 Shard Bottleneck과 JVM GC Pause로 인해 Front-end 렌더링 타임아웃 문제 지속.
Technical Solution
- 무제한 캐시 확장 방식 대신 Bounded Staleness 모델을 적용한 Stream-time Materialized View 구조로 전환
- Debezium CDC 스트림을 통한 Content System 데이터 동기화 및 PostgreSQL 내 hunt_tile_mv 뷰 생성
- Kubernetes CronJob과 Redis Redlock을 활용한 5분 주기 concurrent refresh 자동화 체계 구축
- Index-only Scan을 유도하는 (hunt_id, x, y) 인덱스 설계를 통해 Query Planner 부하 제거
- Kafka 기반의 이벤트 발행 구조를 유지하되 뷰 갱신은 버전 비교 방식으로 단순화하여 일관성 모델 최적화
- Redis 클러스터 제거를 통한 인프라 복잡도 감소 및 JVM 메모리 풋프린트 최소화
실천 포인트
1. 고부하 쿼리 시 CPU/Disk 지표 외에 Query Planner의 Planning Time 및 Index Scan 방식을 분석했는가?
2. 캐시 도입 전, 데이터의 갱신 주기와 허용 가능한 Staleness 범위를 정의했는가?
3. Sharding 도입 시 데이터 분포의 편향성(Hotspot)을 고려한 Key 설계가 이루어졌는가?
4. L1/L2 캐시 추가가 JVM Heap 압박 및 GC Pause로 인해 오히려 Availability를 해치지 않는가?