RoundWait 1만 명 부하 테스트 — 서버리스 스택의 한계를 직접 확인하다

배경

RoundWait는 대규모 행사 현장에서 부스 예약과 대기열을 실시간으로 관리하는 시스템이다. Firebase 기반 서버리스 스택으로 재구축한 뒤, 실제 행사 투입 전에 1만 명 규모의 부하 테스트가 필요했다.

테스트 대상 행사: 마비노기 Fantasy Party 2026 (예상 참가자 1만 명+)

테스트 설계

핵심 SLO

• 예약 성공률 ≥ 99%
• 예약 처리 p95 ≤ 2초
• 알림톡 오발송 0건

환경 구성

실제 마비노기 행사 이벤트를 테스트 환경에 그대로 복제했다. 실데이터는 건드리지 않고, 참가자 1만 명 + 부스 5개 구성.

이 테스트 환경은 Cloud Run + PostgreSQL 기반 스테이징 복제본이며, 실제 운영 스택(AWS ECS + MySQL)과는 별도로 구성했다.

부하 생성기는 Cloud Run Job으로 구성했다. 로컬 머신으로 1만 건의 Firebase 인증을 시뮬레이션하면 Google Identity Toolkit의 API 쿼터에 금방 걸린다. 인-리전(asia-northeast3) Cloud Run Job을 쓰면 Firebase 프로젝트와 같은 리전에서 실행되어 쿼터 조건이 다르게 적용된다.

테스트 도구는 k6. RAMP_SEC 파라미터를 두어서 1만 명의 로그인이 시간에 걸쳐 퍼지도록 했다. 한꺼번에 몰리면 Identity Toolkit 쿼터를 먼저 소진한다.

결과

예약 성공률:    99.94%  (10,000건 중 실패 6건)
예약 처리 속도: 평균 0.26초
오토스케일:     정상 작동
DB 연결:        한도 내 안정
알림 오발송:    0건

→ 예약 성공률·알림 정확도 목표 달성.

전체 측정에서 약 3% 실패율이 보였지만, 분석해보니 98%는 Cloud Run Job이 1만 건의 가짜 로그인을 한꺼번에 발급하다가 Identity Toolkit 쿼터에 걸린 것이었다. 실제 예약 처리 실패율만 보면 0.06%.

주요 기술적 발견

DB 연결 관리

Cloud Run 인스턴스가 오토스케일로 늘어날 때 PostgreSQL 연결 풀이 급증한다. maxInstances 캡과 인스턴스당 풀 크기를 조정해서 연결 한도 내에서 안정적으로 유지되도록 했다.

트랜잭션 모드

부하 집중 시 예약 중복이 발생하지 않도록 raw-pg 트랜잭션 모드를 테스트했다. 동시성 제어가 실제로 작동하는지 검증하는 과정이었다.

비용 구조

1만 명 테스트 1회 비용: 약 1만 원 미만.

서버리스 스택의 특성상 행사 전날 용량을 높이고, 행사가 끝나면 내린다. 평상시 비용은 거의 0에 가깝다. 대규모 행사를 자주 하지 않는 운영 환경에서 서버리스가 맞는 이유다.

남은 과제

꼬리 지연(tail latency)이 있다. 99%는 빠른데 극히 일부 사용자가 느린 응답을 받는다. 예약 오픈 시간을 시간대별로 분산하면 완화할 수 있다.

Firebase RTDB Fanout 테스트(100명 p95 715ms, 500명에서 꼬리 지연 확인)에서 드러난 것처럼, 동시 소켓 수가 늘어날수록 fanout 지연이 길어진다. 현재는 참가자 수에 비해 실시간 구독 클라이언트 수가 제한적이라 실제 운영에서는 문제가 없지만, 스케일이 더 커지면 RTDB Fanout 경로 최적화가 필요할 수 있다.

배운 것

부하 테스트는 숫자를 뽑는 것보다 어디서 병목이 생기는지 이해하는 게 더 중요하다. 이번에도 겉보기 실패율 3%의 대부분이 테스트 도구 자체의 한계였고, 실제 서비스 경로는 0.06% 실패율로 정상이었다.

숫자를 그대로 믿지 말고, 원인을 파고드는 게 맞다.