피드로 돌아가기
Dev.toBackend
원문 읽기
Dragonfly 도입을 통한 P95 레이턴시 4.5배 개선 및 Heap OOM 해결
The Treasure Hunt Engine That Broke Before the Traffic Did
AI 요약
Context
인당 4MB의 in-memory state를 처리하는 블록체인 시뮬레이터 구조로 인해 단일 Node 프로세스에서 290GB의 Heap 요구량이 발생하는 병목 현상 발생. Vertical Scaling 시도 시 Node.js의 single-threaded GC 특성으로 인한 Event Loop 포화 및 OOM 리스크 상존.
Technical Solution
- Redis 7.0의 1Gbps 네트워크 대역폭 한계와 Lua script의 multi-slot 처리 불가 문제를 해결하기 위해 Dragonfly 1.0 채택
- Key space를 64개 Shard로 분할하고 Envoy를 통한 gRPC stream 연결로 TCP 오버헤드 제거 및 Stateless 구조 구현
- 4MB State를 단일 Shard에 배치하여 atomic rarity calculation을 2ms 미만의 단일 Lua call로 처리하도록 설계
- blocking SET 연산을 32개 command pipeline으로 교체하고 Shard당 in-flight request를 1k로 제한하여 트래픽 제어
- Node.js worker_threads 도입을 통해 CPU 집약적인 시뮬레이션 로직을 Event Loop에서 격리하여 I/O 스톨 방지
실천 포인트
1. CPU 집약적 작업이 Event Loop를 점유하는지 확인하고 worker_threads나 별도 서비스로 분리할 것
2. Redis Cluster의 Lua script 제약 사항(Cross-slot operation 불가)을 사전에 검토할 것
3. 대규모 state 전송 시 TCP 대신 gRPC stream이나 Pipeline 최적화를 통해 네트워크 대역폭 병목을 해결할 것