피드로 돌아가기
Dev.toBackend
원문 읽기
L1/L2 분산 캐시 및 Kafka 도입으로 p99 Latency 1.8s에서 152ms로 단축
The One Cache That Broke Our Treasure Hunt Engine
AI 요약
Context
단일 Redis Shard에 Write-heavy한 위치 정보와 Leaderboard 데이터를 혼재하여 사용한 구조적 결함 발생. Redis maxmemory 도달에 따른 Key Eviction으로 Cache Hit Rate가 47%까지 급락하며 Postgres 부하 및 p99 Latency가 1.8s까지 치솟은 상황.
Technical Solution
- Pod 메모리를 활용한 L1 Local LRU 캐시(500MB, 5s TTL) 도입을 통한 네트워크 트래픽 및 스파이크 제어
- Working Set의 2배 규모(24GB/shard)로 확장된 전용 Redis Cluster L2 계층 구축 및 noevict 정책 적용
- Kafka 기반 Append-only Log를 통한 비동기 쓰기 구조(WAL) 설계로 Geo-indexer의 최종 일관성 보장
- Redis Cluster 스냅샷을 활용한 L1 캐시 Pre-warming으로 Pod 재시작 시 발생하는 Cold-start 지연 시간 해결
- 서로 다른 Access Pattern을 가진 Location 데이터와 Ranking 데이터를 물리적 클러스터로 분리하여 리소스 간섭 제거
실천 포인트
1. 서로 다른 TTL과 갱신 주기를 가진 데이터가 동일 캐시 노드에 배치되었는지 확인
2. Cache Eviction 발생 시 DB Fallback으로 인한 연쇄적 장애(Cascading Failure) 가능성 검토
3. Write-heavy 경로에 L1(Local) - L2(Remote) 계층 구조 및 WAL 적용 고려
4. Working Set 대비 최소
1.5~2배의 메모리 헤드룸 확보 여부 점검