300명 동시 접속자에게 망가진 게임 개발 서버, 그리고 우리가 해결한 방법

(dev.to)

동시 접속자 300명에서 1만 명으로 급증하는 트래픽을 처리하기 위해 기존의 코루틴 기반 엔진을 상태가 없는(stateless) 단기 실행 워커와 Kafka 기반의 비동기 이벤트 처리 구조로 재설계하여 지연 시간을 1.8초에서 72ms로 획기적으로 단축한 기술적 여정을 다룹니다.

이 글의 핵심 포인트

1동시 접속자 300명에서 10,000명으로 확장 시 P99 지연 시간을 1.8s에서 72ms로 개선
2지속적인 코루틴 방식에서 짧게 실행되고 종료되는 stateless 'hunt_worker' 구조로 전환
3Envoy 프록시의 일관된 해싱(Consistent Hashing)을 통한 세션 라우팅 최적화
4Kafka REST Proxy를 활용한 비동기 이벤트 기록으로 DB 쓰기 병목 제거 및 최종 일관성 채택
5KEDA를 이용한 자동 스케일링(Scale-to-zero) 구현으로 인프라 비용 효율성 극대화

이 글에 대한 공공지능 분석

왜 중요한가?

단순한 인프라 업그레이드가 아닌, 애플리케이션 아키텍처의 근본적인 패러다임 전환(Stateful $\rightarrow$ Stateless)이 대규모 트래픽 대응의 핵심임을 보여주는 사례입니다.

어떤 배경과 맥락이 있나?

고성능 게임 서버나 실시간 트래픽 처리가 필요한 서비스에서는 데이터베이스 부하와 컨텍스트 스위칭 비용이 시스템 전체의 가용성을 결정짓는 주요 요인으로 작용합니다.

업계에 어떤 영향을 주나?

서버리스(Serverless)와 유사한 워커 모델과 이벤트 기반 아키텍처(EDA)의 결합이 어떻게 비용 효율적인 스케일링을 가능하게 하는지 기술적으로 증명합니다.

한국 시장에 어떤 시사점이 있나?

급격한 사용자 성장을 경험하는 한국의 게임 및 커머스 스타트업들에게, DB 최적화보다 중요한 것은 데이터 처리의 경계를 재설정하는 설계 능력임을 시사합니다.

이 글에 대한 큐레이터 의견

많은 개발자가 트래픽 급증 시 가장 먼저 DB 사양을 높이거나 캐시를 추가하는 등 '레이어별 최적화'에 매몰되곤 합니다. 하지만 이 사례는 병목의 근본 원인이 데이터베이스가 아닌, 애플리케이션 엔진의 상태 관리 방식(Stateful Coroutines)에 있었음을 날카롭게 지적합니다. 이는 기술 부채를 해결할 때 현상(Latency)이 아닌 구조(Architecture)를 보아야 한다는 중요한 교훈을 줍니다.

창업자 관점에서는, 서비스 초기 단계에서 구축한 편리한 구조가 성장의 발목을 잡는 '성장의 저주'를 어떻게 기술적으로 돌파할 수 있는지 보여주는 훌륭한 벤치마크입니다. 특히 인프라 비용을 최적화하면서도 성능을 유지하기 위해 '최종 일관성(Eventual Consistency)'을 전략적으로 수용한 점은, 빠른 실행력과 비용 효율성이 생명인 스타트업에게 매우 실용적인 인사이트를 제공합니다.

원문 보기 →