피드로 돌아가기
Dev.toInfrastructure
원문 읽기
Kafka에서 Pulsar+Redis 전환으로 Latency 5s → 50ms 단축
I Made the Wrong Bet on Event Streaming in Our Treasure Hunt Engine
AI 요약
Context
수천 명의 동시 접속자와 초당 수백만 건의 이벤트를 처리하는 Treasure Hunt 엔진 설계 필요성 대두. 초기 Kafka 도입 후 고부하 Batch 처리 시 시스템 Crash 발생 및 5초 이상의 Latency로 인한 사용자 경험 저하 직면.
Technical Solution
- Apache Pulsar 도입을 통한 Event Stream의 기능별 분리를 통한 컴포넌트 간 Decoupling 및 독립적 Scaling 구조 설계
- Redis Caching Layer 구축을 통한 DB 부하 분산 및 Event Stream 데이터 조회 시간 최적화
- Redis TTL 1초 설정을 통한 네트워크 지연 상황에서도 최신 Game State 제공 보장
- Player Update, Game State Change, Chat Message 등 도메인별 스트림 분리로 병목 지점 제거 및 처리 효율 증대
- Low Latency 요구사항 충족을 위해 Kafka의 Batch 중심 처리 구조에서 Pulsar의 실시간 스트리밍 구조로 전환
Impact
- 시스템 Latency: 5s에서 50ms 미만으로 획기적 감소
- 처리 성능: 초당 1,000만 건(10M events/sec)의 이벤트 처리 능력 확보
- 안정성: High-throughput 상황에서의 시스템 Crash 및 Downtime 대폭 감소
Key Takeaway
범용적인 기술의 인지도보다 애플리케이션의 구체적인 Workload 특성(Batch vs Real-time)에 기반한 플랫폼 선택이 아키텍처의 성패를 결정함.
실천 포인트
1. Real-time Latency가 핵심 지표인 경우 Kafka의 Batch 처리 특성이 병목이 되지 않는지 검토할 것
2. State 조회 빈도가 높은 Event-driven 구조에서는 Event Store와 별개로 Redis 같은 Fast-access Cache Layer 설계를 고려할 것
3. 부하 테스트 단계에서 단순 처리량이 아닌 High-throughput 상황의 Latency Tail(P99)과 시스템 안정성을 정밀하게 검증할 것