피드로 돌아가기
That 0.8 second P99 Latency Cliff in Production Wasnt Supposed to Happen
Dev.toDev.to
Infrastructure

Redis 제거 및 mmap 도입으로 P99 Latency 700ms에서 220ms로 단축

That 0.8 second P99 Latency Cliff in Production Wasnt Supposed to Happen

mary moloyi2026년 5월 27일5advanced

Context

초당 150k req/s의 고트래픽 환경에서 Redis 기반 설정 관리 시스템인 Veltrix의 gRPC 호출과 Lua Pub-Sub 기반 캐시 플러시로 인한 Thundering Herd 현상 발생. 캐시 미스와 네트워크 타임아웃이 연쇄 작용하여 P99 Latency가 700ms까지 치솟는 성능 절벽 경험.

Technical Solution

  • Control Plane과 Data Plane을 분리한 ConfigEdge 아키텍처 설계
  • Git-backed store(Flux CD + CRD)를 통한 설정의 권위적 관리 및 15초 이내 클러스터 전파
  • gRPC 호출을 대체하는 Node-local File-system Watcher 기반의 ConfigRelay 사이드카 도입
  • WASM 런타임을 이용한 5초 주기 비동기 설정 갱신으로 게임 루프 블로킹 제거
  • 설정 데이터를 Memory-mapped file로 노출하여 50ns 수준의 초고속 메모리 접근 구조 구현
  • Redis 및 Lua 스크립트를 Critical Path에서 완전히 제거하여 단일 장애점 해결

1. 설정 변경 전파 시 전체 캐시를 플러시하는 Lua 스크립트나 Pub-Sub 구조의 확장성 검토

2. 고빈도 요청 경로에서 외부 API/DB 호출이 필수적인지 확인하고 Local Cache 또는 Sidecar 기반 복제 구조 고려

3. Cache Stampede 방지를 위해 TTL 기반 갱신보다 Push 기반의 Local File Sync 방식 검토

원문 읽기