피드로 돌아가기
Dev.toInfrastructure
원문 읽기
P99 지연시간 1.8s에서 ➔ 72ms 달성 및 1만 동시 접속자 확장 설계
The Gamedev Server That Broke at 300 Concurrent Hunters and How We Fixed It
AI 요약
Context
LuaJIT 기반의 Coroutine 구조와 Redis/Postgres의 동기적 쓰기 구조로 인한 병목 발생. 300명의 동시 접속자 상황에서 Redis 연결 풀 부족과 Postgres Autovacuum으로 인한 쓰기 지연이 연쇄적으로 작용하며 P99 Latency가 1.8s까지 급증하는 한계 노출.
Technical Solution
- Coroutine 기반의 상태 유지 모델을 Stateless한 short-lived process인 hunt_worker 구조로 전환하여 Context Switching 비용 제거
- Envoy Proxy의 Consistent Hashing을 통한 세션 라우팅과 Idempotency 보장 설계로 분산 환경 내 상태 관리 최적화
- Redis EVALSHA 및 Postgres 직접 쓰기 방식을 Kafka REST Proxy 기반의 Event-driven 구조로 변경하여 Write Latency 분리
- Kafka Aggregator 서비스를 통한 15분 단위의 Materialized View 생성으로 Eventual Consistency 모델 도입
- KEDA와 Envoy 메트릭을 연동한 HPA 설정으로 트래픽 변화에 따른 Pod 단위의 자동 스케일링 체계 구축
- Docker multi-stage build와 musl libc 최적화를 통한 Worker 프로세스의 빠른 기동 시간(8ms) 확보
Impact
- P99 Latency: 1.8s ➔ 72ms로 대폭 감소
- 처리 용량: 300명에서 10,000명 동시 접속자로 확장 가능성 증명
- Redis Latency: EVALSHA 수행 시간 3ms 이하로 안정화
- 쓰기 성능: Kafka 도입을 통해 P99 Write Latency 12ms 달성
실천 포인트
- 고빈도 쓰기가 발생하는 시스템에서 DB 직접 쓰기보다 Event Store를 통한 비동기 업데이트 검토 - 프로세스 간 Context Switching 비용이 임계치에 도달했을 때, Stateless Worker 모델로의 전환 고려 - 인프라 스케일링 시 CPU/Memory 지표 외에 Envoy RPS와 같은 실제 비즈니스 트래픽 메트릭 기반 HPA 적용 - 대규모 트래픽 분산 시 Consistent Hashing을 통해 Pod 간 데이터 이동 최소화 및 캐시 효율 극대화