대규모 트래픽을 감당하는 MSA 티켓 예매 아키텍처 설계

📌 시스템 구성 개요

본 문서는 대규모 동시 접속 환경에서도 티켓 예매 서비스(WAS)가 안정적으로 동작하도록 보호하기 위한

모의 티켓팅 시뮬레이션 시스템의 핵심 구성 요소와 역할을 정리한다.

 

---

🎯 핵심 목표

• 1차 목표 : 부스트캠퍼 100~200명을 대상으로 동시 티켓팅 예매를 처리할 수 있는 서비스 만들기
• 2차 목표 : 수십만명 단위 대규모 트래픽을 감당할 수 있는 티켓팅 예매 서비스 만들기
  • 국내 티켓 예매 서비스의 “트래픽 피크(동시접속자 수)” 규모를 보면 인기 공연의 경우에는 수십만 명 단위의 접속이 몰리는 것으로 예상
• WAS가 절대 터지지 않도록 보호
• 한정된 자원 내에서 최대 동시 사용자 수용
• 실제 티켓팅 환경과 유사한 흐름 제공

 

 

구성요소

• frontend : 프론트엔드
• ticket-backend : 티켓 예매 백엔드 서비스
• queue-backend : 대기열 백엔드 서비스
• backend : 일반 API 서버

1. 브라우저 (Client)

본 서비스에 접속한 사용자

• 웹서버(WS)로부터 HTML / CSS / JS 번들을 수신
• 이후 모든 화면은 CSR(Client-Side Rendering) 방식으로 렌더링
• API 요청은 직접 WAS 또는 백엔드 서버로 전송

2. 웹서버 (WS)

SPA + CSR 구조의 정적 리소스 제공 서버

• 최초 진입 시 HTML / CSS / JS 번들 제공
• 정적 리소스 서빙에 집중하여 서버 부하 최소화
• 런타임 SSR은 지양
• 데모 단계에서는 React 사용
• 향후 확장 시 Next.js의 SSG / ISR 도입 가능

3. 대기열 서버 (Queue Server)

티켓 예매 서비스(WAS)로 유입되는 사용자를 제어하는 관문(Gate)

역할

• WAS로 진입 가능한 사용자 수를 정확히 제한
• 사용자에게 활성 토큰(Active Token) 발급
• 대기열 스케줄링 수행

내부 큐 구조(Redis)

• 대기 큐 (Waiting Queue)
  • 아직 예매가 불가능한 사용자
• 활성 큐 (Active Queue)
  • 현재 예매를 진행 중인 사용자
  • WAS가 동시에 처리하는 사용자 수와 대응

활성 큐를 별도로 두는 이유는

• "예매 중인 사용자 수를 정확히 제한"하기 위함이다.

도입 목적

• 순간적인 대량 트래픽으로 인한 WAS 과부하 방지
• 네트워크 요청 유실 및 타임아웃 문제 예방
• 서버 처리 가능 범위를 초과한 요청을 무질서하게 흘려보내지 않기 위함

4. 티켓 예매 서비스 (WAS)

실제 "예매"와 직접적으로 연관된 요청만 처리하는 핵심 서비스

• 활성 토큰의 유효성 검증
• 좌석 선택, 예매자 정보 입력, 결제 API 처리
• 강한 트랜잭션 정합성 요구

WAS는 대기열 서버를 통과한 사용자만 접근 가능하도록 설계됨

5. 일반 백엔드 서버

예매와 직접 관련 없는 기능 처리

• 공연 목록 조회
• 채팅, 알림, 기타 일반 API
• 예매 서비스와 분리하여 장애 전파 최소화

6. Redis Pub/Sub

대기열 서버 ↔ 티켓 예매 서비스(WAS) 간 이벤트 전달 수단

• 예매 완료 시 BOOKING_DONE 이벤트 발행
• 대기열 서버는 이벤트 수신 후:
  • 활성 큐에서 사용자 제거
  • 다음 대기 사용자를 활성 큐로 이동

이를 통해 실제 처리 완료 시점 기준으로

새로운 사용자를 정확히 수용할 수 있음

7. Redis

티켓 예매 서비스(WAS)가 빠른 티켓 예매 처리를 위해 사용하는 인메모리 DB

8. RDB

일반 백엔드 서버에서 사용하는 RDB

 

전체 흐름 요약

1. 사용자는 웹서버(WS)에서 정적 리소스를 내려받아 서비스 진입
2. 예매 시도 시 대기열 서버로 요청 이동
3. 대기열 서버에서 순번 대기 → 활성 토큰 발급
4. 활성 토큰을 가진 사용자만 WAS 접근 가능
5. 예매 완료 시 WAS → Redis Pub/Sub → 대기열 서버로 이벤트 전달
6. 대기열 서버가 다음 사용자를 활성화

---

 주요 고민과 의사결정 정리

대규모 티켓팅 시스템에서 가장 중요한 목표는 단순하다.
“아무리 많은 사용자가 동시에 몰려도, 예매 서버(WAS)는 절대 터지지 않게 하는 것”이다.

이 문서는 모의 티켓팅 시뮬레이션 시스템을 설계하면서 마주한 핵심 아키텍처 고민 지점들과, 각 선택에 이르게 된 판단 과정을 정리한 글이다.

---

1. 대기열을 WAS 내부에 둘 것인가, 전용 서버로 분리할 것인가

가장 먼저 고민한 것은 대기열의 위치였다.
대기열 로직을 티켓 예매 서비스(WAS) 내부에 포함시키는 방식은 구현이 간단하고 구조도 단순하다.
하지만 이 방식에는 치명적인 문제가 있다.

대기열과 예매 로직이 CPU / 메모리 자원을 공유하게 된다는 점이다.
순간적으로 예매 요청이 폭증하는 상황에서는, 정작 트래픽을 제어해야 할 대기열 로직 자체가 과부하로 제대로 동작하지 않을 가능성이 생긴다.

대기열의 본질적인 역할은 트래픽을 제어하는 관문(Gate) 이다.
그 관문이 보호해야 할 대상(WAS)의 부하에 영향을 받는 구조는 역할적으로도 맞지 않다고 판단했다.

결론적으로 대기열은

• 항상 살아 있어야 하고
• 예매 트래픽의 영향을 받지 않아야 하는 제어 계층이므로

=> 티켓 예매 서비스(WAS)와 물리적으로 분리된 전용 서버로 두는 구조를 선택했다.

---

2. 대기열 Queue(Redis)의 위치: WAS 진입 전 vs 진입 후

다음 고민은 대기열 큐를 WAS 앞에 둘 것인가, 아니면 진입 후에 둘 것인가였다.

일반적으로 대기열의 목적은 명확하다.
동시에 WAS로 진입하는 요청 수를 제한하는 것이다.

이 관점에서 보면 대기열을 WAS 진입 직전에 두는 것이 가장 자연스러운 패턴이다.

하지만 이 구조를 그대로 적용했을 때 문제가 하나 드러났다.
WAS 앞단에 대기열을 두면, 티켓 예매와 무관한 일반 기능들까지 모두 대기열에 걸린다는 점이다.

 

예를 들어

• 메인 페이지의 채팅
• 최근 공연 목록 조회
• 단순 정보 조회 API

이런 기능들까지 예매 트래픽이 몰리는 순간 함께 막히게 되면,
사용자 입장에서는 “서비스 전체가 멈춘 것처럼” 보이게 된다.

이 문제를 다시 들여다보니, 원인은 대기열의 위치가 아니라
트래픽 특성이 완전히 다른 기능들을 하나의 서버에서 처리하고 있다는 점이었다.

 

그래서 결론은 다음과 같았다.

• 대기열은 WAS 진입 직전에 둔다
• 대신, 일반 기능을 처리하는 API 서버와 트래픽이 폭증하는 티켓 예매 전용 WAS를 물리적으로 분리한다

이렇게 함으로써
예매 트래픽이 몰려도 일반 기능은 영향을 받지 않도록 구조를 정리했다.

---

3. 티켓 예매 서비스(WAS): 단일 서버 vs 다중 서버

다음은 WAS를 몇 대로 운영할 것인가에 대한 고민이었다.
직관적으로는 “서버를 여러 대로 늘리면 더 많은 요청을 처리할 수 있지 않을까?”라는 생각이 들 수 있다.

하지만 티켓 예매의 병목 지점을 분석해보면 이야기가 달라진다.

 

티켓 예매는 본질적으로

• 좌석 단위 락
• 강한 트랜잭션 정합성
• DB 쓰기 충돌

이 핵심이다.
즉, 병목은 WAS가 아니라 DB의 락과 트랜잭션 처리 구간에 있다.

 

WAS를 여러 대로 늘려도

• 결국 동일한 DB를 바라보게 되고
• 락 경합은 더 심해질 가능성이 높다

이 상황에서 WAS 수평 확장은
실질적인 처리량 증가를 얻기 힘들다.

 

그래서 의도적으로 티켓 예매 서비스(WAS)는 단일 서버로 유지했다.

 

---

❓ Auto Scaling + Load Balancer를 붙이면 정말 의미 없을까?

이 질문도 자연스럽게 따라왔다.

결론부터 말하면, 완전히 의미 없지는 않다.

다만 DB 구조를 바꾸지 않는 한은,

• 동시 처리량 증가 폭은 제한적이고
• 병목은 여전히 DB 락 구간에 남는다

즉,

• DB 샤딩
• 좌석 단위 분할
• 예매 모델 자체의 재설계

같은 변화 없이 WAS만 증설하는 것은
“체감 성능 개선”으로 이어지기 어렵다고 판단했다.

---

4. 대기열 서버: 1대 vs 여러 대

또 하나의 질문은 이것이었다.

WAS에 한계가 있어서 대기열이 필요한데,
대기열 서버도 한계가 있다면
또 다른 대기열이 필요한 것 아닌가?

이 질문 자체는 논리적으로 타당하다.
하지만 현 단계에서 대기열 서버가 병목이 될 만큼의 트래픽은 아니라고 판단했다.

초기부터 대기열 서버를 분산시키면

• 시스템 복잡도만 증가하고
• 디버깅, 설명, 운영 비용이 급격히 커진다

그래서 선택한 전략은

초기에는 대기열 서버 1대 + 관측 기반 확장

즉,

• 터지지 않을 것이라는 낙관적 기대하에 설계하되
• 실제 병목이 관측되면 그때 확장하는 것이다.

---

5. 대기열 Queue 기술 선택: Redis

대기열 구현을 위한 기술로는 여러 선택지가 있었지만,
최종적으로 Redis를 선택했다.

이유는 명확하다.

• In-memory 기반 → 매우 빠른 접근 속도
• Sorted Set / Stream 등 → 대기열 구현에 적합한 자료구조
• TTL 지원 → 오래된 대기 데이터 자동 정리 가능

구체적으로는:

• Stream으로 순차 처리와 Consumer Group 기반 병렬 처리
• Pipeline으로 네트워크 왕복 최소화
• TTL로 메모리 관리

를 염두에 두고 있다.

물론 Redis의 한계도 명확하다.

• 메모리 기반 → 용량 제한
• 단일 스레드 → CPU 병목 가능

이 부분은:

• 데이터 최소화
• 필요 시 Redis Cluster / 샤딩
• 장기적으로 Kafka 병행 가능성

으로 대응할 계획이다.

---

6. 대기열 서버 ↔ 티켓 WAS 통신 방식

두 서버 간 통신 방식으로는

• HTTP
• WebSocket
• SSE
• 메시지 큐

를 검토했다.

 

필요한 것은

• 요청-응답이 아닌
• 단방향 이벤트
• 빠른 전달

이었다.

 

HTTP는 구조적으로 맞지 않았고,
WebSocket은 서버 간 통신에 비해 연결 비용이 과했다.

 

결론적으로

=> 메시지 큐가 가장 적합하다고 판단했다.

---

7. 메시지 큐 선택: Redis Pub/Sub

메시지 큐 중에서도 최종 선택은 Redis Pub/Sub이다.

BOOKING_DONE 이벤트의 특성을 보면

• 실시간성이 매우 중요하고
• 약간의 메시지 유실은 허용 가능하며
• 재처리는 필요 없다

이 특성에 가장 잘 맞는 것이 Redis Pub/Sub이었다.

• 지연 거의 없음
• 구조 단순
• 운영 부담 낮음

즉,
신뢰성보다 실시간성을 우선한 선택이다.

RabbitMQ, Kafka 등의 비교는
설계 설명 흐름상 부록으로 분리하는 것이 더 적절하다고 판단했다.

---

8. 클라이언트 대기 상태 확인 방식

마지막으로 클라이언트가 대기 상태를 확인하는 방식이다.

• WebSocket은 연결 유지 비용이 크고
• SSE는 서버 단방향 이벤트만 가능해 대기 순번 계산에 애매하다

결국 선택은 Polling

단순하지만,

• 가장 많은 사용자를
• 가장 안정적으로 수용할 수 있는 방식이라고 판단했다.

---