피드로 돌아가기
Dev.toBackend
원문 읽기
Redis TCP 병목 제거 및 Rust In-Process 캐시 도입으로 처리량 11배 개선
Why We Stopped Using Redis (And Built a Sub-Microsecond Cache in Rust Instead)
AI 요약
Context
96개 Concurrent Worker 환경에서 Redis의 TCP Round-trip으로 인한 연결 직렬화 발생. 이로 인해 Throughput이 1.51M에서 136K ops/sec로 급감하는 11배 성능 저하 경험.
Technical Solution
- Network Hop 제거를 위해 Redis를 대체하는 In-process Rust 캐시 Cachee 도입
- Lock 경합 최소화를 위한 DashMap 기반의 고성능 Lookup 구조 설계
- 메모리 효율성을 위해 Count-Min Sketch 기반의 Admission 정책 적용
- 512 KiB 상수로 제한된 메모리 내 LFU Eviction 알고리즘 구현
- Shared State가 필요한 Leaderboard 기능만 Redis Sorted Sets로 분리 운영
- Rate Limiting 및 ZKP Proof Caching 등 Hot Path 로직의 로컬 캐시 이전
Impact
- Lookup 지연시간 50 microseconds(Redis RTT)에서 0.085 microseconds로 단축
- 단일 Graviton4 인스턴스 기준 1,667,875 authenticated operations per second 달성
- Network Serialization 병목 제거를 통한 44x 속도 향상
Key Takeaway
초고빈도 조회가 발생하는 단일 인스턴스 환경에서는 외부 캐시의 Network Overhead가 시스템 전체의 병목이 됨. 데이터 일관성보다 지연시간이 핵심인 Hot Path의 경우 In-process 캐시 전환을 통한 Zero TCP Contention 설계 필요.
실천 포인트
- 초당 수백만 건의 Lookup 발생 시 Redis RTT 비용 산정 - 분산 공유 상태가 불필요한 데이터의 In-process 캐시 전환 검토 - 고정 메모리 사용을 위한 Count-Min Sketch 등 확률적 자료구조 적용 고려 - 서비스 특성에 따라 Shared State(Redis)와 Local Cache의 하이브리드 구성 설계