기적의 4일! Go-성능 선착순 예매 시스템 구현: 레거시 코드에 Go 를 더해 고성능 선착순 예매 시스템을 4일 만에 구축하기 | 인프콘2023

인프런 inflearn·인프콘 2023 2023·2023년·

#aws#redis#go#distributed-systems#load-testing#rds-proxy#traffic-spike#performance-engineering

AI 요약

인프런이 성능 낮은 레거시 강의·결제 흐름을 그대로 두면서 SpringCamp 티켓 트래픽만 격리하기 위해, 단 4일 만에 Go·Fiber·Redis 기반 선착순 번호표 API를 만든 사례다. 가상 대기열 대신 왜 서킷 브레이커형 차단을 택했는지, 어떻게 40초 완판 동안 본 서비스 장애 없이 버텼는지를 부하 테스트 수치와 함께 풀어낸다.

핵심 포인트

실운영 복제 + K6 부하 테스트로 병목을 특정: 강의 상세·장바구니 서버 한 대가 초당 30·10건뿐이라 공유 DB 병목 탓에 50대 이상 늘려도 처리량이 오르지 않아, 코드 전면 개선이 아닌 격리 전략을 선택
가상 대기열 대신 가벼운 번호표 API로 남은 티켓을 확인하고 매진 뒤 상세·장바구니 요청을 앞단에서 차단 — 매진 전 40초만 확장하면 무거운 쓰기 트랜잭션이 급감한다는 판단
Pulumi로 전용 인프라를 10분 만에 복제하고, Redis 원자 증가 연산 + Sorted Set 예약자 명단으로 매진·중복·순번을 교차 검증. c6i.large 3대로 초당 5만 요청을 처리하고 Aurora DNS 캐시 쏠림은 RDS Proxy로 해소

왜 읽나짧은 기한과 레거시 제약 아래 대규모 선착순 트래픽을 격리해야 하는 팀에게, 번호표 API + Redis 원자연산 + 관리형 프록시를 엮는 실전 청사진.

챕터별 상세

010:06 – 3:56

4일 안에 티켓 시스템을 만들어야 했던 이유

SpringCamp 오프라인 티켓을 기존 강의 상세·장바구니·결제 로직으로 판매하기로 했지만 실제 구현과 검증에 쓸 수 있는 시간은 네 날뿐이었다. 프론트엔드·백엔드·DevOps가 병렬로 협업해 운영 환경과 비슷한 테스트를 준비하고 일주일 뒤 판매를 시작해야 했다. 200장이 과거 1분 40초보다 훨씬 빨리 팔릴 것으로 예상되는 상황에서 티켓 트래픽이 강의 수강과 일반 결제까지 장애로 번지지 않게 하는 것이 핵심 목표였다.

실운영 환경을 복제하고 K6 같은 CLI 도구로 부하를 만들어 CPU·메모리와 요청 처리량을 비교하며 병목을 찾는다. 불필요한 필드 조회, 과도한 병렬 쿼리와 거대한 로그인 미들웨어 때문에 강의 상세와 장바구니 서버 한 대는 각각 초당 약 30건과 10건만 처리했다. 자원 증설이나 컨테이너 수평 확장만으로는 공유 데이터베이스 병목이 풀리지 않아 50대 이상을 늘려도 처리량이 거의 오르지 않았고, 네 날 안에 코드 전면 개선이 아닌 격리 전략이 필요해졌다.

가상 대기열은 원본 서버의 처리량에 맞춰 요청을 제한하지만 구축 시간과 복잡성, 모든 사용자를 기다리게 하는 경험 때문에 이번 조건에 맞지 않았다. 대신 서킷 브레이커와 fallback에서 착안해 가벼운 번호표 API가 남은 티켓을 확인하고 매진 뒤 상세·장바구니 요청을 앞단에서 차단하도록 설계한다. 매진 전 40초만 충분히 확장하면 이후 무거운 레거시 트래픽과 쓰기 트랜잭션이 급감하므로 구현은 단순하고 기존 코드 변경도 최소화할 수 있었다.

SpringCamp 경로만 전용 로드밸런서와 복제 서버로 분리하고 Pulumi로 운영과 동일한 인프라를 10분 안에 만들어 정확한 성능 시험과 장애 격리를 확보한다. Go와 Fiber로 만든 API는 데이터베이스 대신 Redis 키의 원자 증가 연산과 Sorted Set 예약자 명단을 사용해 매진 여부, 중복 예약과 최종 순번을 교차 검증한다. 결제 완료 뒤 정원을 넘은 요청은 환불 흐름으로 보내고 나노초 타임스탬프·사용자·순번을 기록해 서버가 실패해도 로그로 순서를 복원할 방어선까지 둔다.

Go 번호표 API는 c6i.large 세 대로 초당 5만 요청을 처리했고, 레거시는 Aurora 읽기 인스턴스와 이벤트 루프 수를 늘리고 로드밸런싱 전략을 조정해 목표 처리량을 확보했다. Aurora의 DNS 캐시가 특정 리더에 연결을 몰아주는 문제는 관리형 RDS Proxy가 커넥션 풀과 분산을 맡게 해 해결했으며 비용·대기 시간과 지원하지 않는 옵션이라는 제약도 함께 평가했다. 실제 판매는 40초 만에 끝났고 약 4만 5천 요청을 장애 없이 처리해 일반 사용자의 강의 이용을 보호했으며, 이후 상시 대기열과 WAF rate limit 같은 개선 방향을 남겼다.