티켓핑은 대규모 트래픽 상황에도 안정적으로 사용자들이 예매할 수 있도록 하는 공연 예매 서비스입니다.
인기 공연의 티켓팅 시에 순간 트래픽으로 인한 서버 과부하 상황을 방지하기 위해 예매 인원을 제한하는
대기열 시스템을 구축하였습니다.
-
MSA: 특정 서비스에 대한 부하가 증가할 때 해당 서비스만 독립적으로 스케일 아웃할 수 있는 MSA 적용
-
느슨한 결합: 메시지 큐를 활용한 비동기 처리로 각 서비스 간의 의존성 최소화
-
고가용성: 서버 장애 시에도 서비스가 지속적으로 운영될 수 있도록 고가용성 보장
-
동시성 처리: 대규모 트래픽과 분산 환경에서도 안정적이고 신뢰성 있는 서비스를 제공하기 위한 동시성 처리
-
모니터링: 서버의 과부하 상황 시 즉각적으로 대응할 수 있도록 알림을 보내는 모니터링 시스템 구축
-
공통 모듈: 코드 중복을 최소화하고 일관성을 유지하기 위해 공통 모듈 사용
| 카테고리 | 기술/도구 |
|---|---|
| Backend |   |
| Database |   |
| Messaging |  |
| Monitoring |     |
| Infra |  |
| Test |  |
| Channel |  |
| 인스턴스 | 스펙 |
|---|---|
| Server | t2.2xlarge (8 vCPU, 32 GB memory) |
| Test | t2.medium (2 vCPU, 4 GB memory) |
| Monitoring | t2.medium (2 vCPU, 4 GB memory) |
| Redis OSS | cache.r7g.large (13.07 GB memory) |
10,000명의 동시 대기열 진입 이후 15분간 3초 주기의 Polling을 통해 대기열 상태 조회를 실시하였습니다.
동일 환경에서 테스트한 결과 WebFlux가 MVC에 비해 약 10% 정도 짧은 응답 시간을 갖고,
CPU 사용량과 Load Average가 상대적으로 낮은 것을 확인할 수 있었습니다.
이미 Lua Script를 통한 성능 최적화가 이루어진 상태에서도 WebFlux가 MVC에 비해 더 적은 리소스를 사용하여도
대량의 트래픽을 빠르게 처리함을 확인할 수 있었습니다.
Redis 데이터의 동시성 문제를 해결할 수 있는 Lua Script를 이용한 원자적 처리와, 분산락을 이용한 처리 두 가지 방법을 고민하였습니다.
| 장점 | 단점 | |
|---|---|---|
| Lua Script | - 네트워크 호출을 최소화할 수 있음 - 락 해제 오류에 대한 위험성 없음 |
- Redis 기본 함수를 알아야 함 - Spring 실행 시 디버깅이 어려움 |
| 분산락 | - Spring 코드로 디버깅이 편리 - Redis 함수를 알지 못해도 쉽게 구현 가능 |
- 분산락을 얻기 위한 네트워크 호출이 늘어남 - 분산락이 해제되지 않을 가능성이 존재 |
좌석 선점은 빠른 속도가 중요하다고 생각해 로컬 컴퓨터에서 1,000명의 동시 좌석 선점 속도를 비교해보았습니다.
(CPU: AMD Ryzen 7 5700G, RAM: 32GB)
동일 환경에서 테스트한 결과 Lua Script에서 응답 속도가 2배 빠르고, 처리량도 더 높은 것을 확인할 수 있었습니다.
두 방식의 장단점과 실제 성능 결과를 바탕으로 속도도 빠르고 더 안정성도 높은 Lua Script를 활용해 좌석 선점을 구현하였습니다.
