대규모 트래픽 좌석 예매 시스템 설계_대기열, Redis

올리브영/무신사/지그재그 등 쇼핑을 즐겨하는 나인데

늘 시간 쿠폰만 받으려고 하면 그게 그렇게 어렵더라.

올리브영의 경우 12시면 11:59:45분부터 쿠폰 페이지를 누르면 대기 몇번 + 예상 시간이 생기고

지그재그의 경우는 페이지는 바로 들어가지면 결제하기 누르는 순간부터 대기가 생겨서 그런지 거기서부터 로딩이 있다가 결국 내가 받는 메세지는 "이미 품절 된 상품입니다"

ㅎㅎ

 

이런 대기열, 대규모 트래픽 서비스가 궁금했다.

마침 프론트 친구들과 함께한 포폴겸 토이 프로젝트를 만들기로 했는데 여기에 대규모 트래픽 예매 서비스를 넣어보기로 했다.

사용하고 싶었던 거 다 공부하면서 써보자!! 

 

티켓팅 서비스처럼 찰나의 순간에 수만 명의 사용자가 몰리는 시스템을 설계할 때 가장 큰 고민은

"어떻게 하면 중복 결제를 막으면서도 사용자에게 짜증 나지 않는 경험을 줄 것인가?"

 

오늘 고민하고 정리한 핵심 설계 전략을 잊지 않게 작성한다!

 

 

---

 

1. 전체 프로세스 설계: 2단계 권한 분리

- 대기를 위한 만료시간과 좌석 선점에 대한 시간이 필요한데 이 부분에 대해서는 

현재 날짜를 누르면 팝업으로 예매하기 → 좌석선택  → 결제하기 이렇게 흐름이 간다.

단계	핵심 트리거	관리 대상	만료 시간(예시)	만료 시 결과
좌석 선택	대기열 통과 시	페이지 이용 권한	10분	대기열로 재이동
결제 진행	'결제하기' 클릭	좌석 임시 선점	5분	좌석 점유 해제

 

2. 동시성 제어: Redis를 활용한 "임시 선점(Lock)"

처음 실시간 좌석 공유고 websocket을 써보고 싶어서 이걸 써야지 했었는데 하단의 차이로 폴링과 reids를 이용하기로 했다.

WebSocket: 서버와 클라이언트가 연결(Connection)을 계속 유지해야 합니다. 10만 명이 접속하면 서버는 10만 개의 연결 통로를 계속 열어두어야 하므로 서버 메모리(RAM)와 부하가 엄청납니다. Short Polling: 3~5초마다 API를 쏘지만, 응답을 주면 즉시 연결이 끊깁니다. 트래픽 문제 해결법: 이때 API가 DB를 조회하면 서버가 터지지만, **Redis에 저장된 가벼운 데이터(JSON 스냅샷)**만 읽어서 바로 던져주면 서버 부하를 최소화할 수 있습니다. 현실적인 타협안: 트래픽이 아주 몰리는 오픈 직후에는 Polling 주기를 10초로 늘리거나, 아예 클라이언트가 "좌석 새로고침" 버튼을 누를 때만 조회하게 만들기도 합니다.

 

 

3. 그렇다면 왜 Redis를 쓰는가?

가장 큰 차이는 속도와 휘발성(TTL)이다.

DB (MySQL 등): 디스크에 저장하므로 안전하지만 느립니다. "결제 중"인 상태를 DB에 저장하면, 수많은 사용자가 "결제 취소"를 하거나 "이탈"했을 때 일일이 DB의 상태를 다시 Available로 바꾸는 Update 쿼리를 날려야 합니다. 이는 DB에 큰 부하를 줍니다. Redis: 메모리(RAM)에 저장해서 DB보다 수십 배 빠릅니다. * 핵심 기능 (TTL): "이 좌석은 5분 동안만 사용자 A가 점유한다"라고 설정하면, 5분이 지나면 Redis가 알아서 데이터를 지워버립니다. * 따라서 사용자 A가 결제하다가 그냥 브라우저를 닫고 도망가도, 서버가 별도의 작업을 안 해도 5분 뒤에 좌석이 자동으로 풀립니다.

 

 

[실제 흐름]

1. 사용자 A가 좌석 1번 선택 후 결제 클릭
   • 서버는 먼저 Redis에 "seat:1"이라는 키가 있는지 확인
   • 없다면 Redis에 "seat:1" : "occupying" 이라고 저장하고 유효시간 5분을 Lock
2. 사용자 B가 좌석 1번 선택 후 결제 클릭
   • 서버가 Redis를 보니 이미 "seat:1" 키가 쥰재
   • 서버는 DB까지 가보지도 않고 바로 B에게 "이미 선점된 좌석입니다"라고 응답함으로써 DB 부하 방지
3. 사용자 A가 결제 완료
   • 그제서야 DB에 1번 좌석을 "예약 완료" 변경
   • Redis에 있던 임시 키 "seat:1"은 삭제