대규모 트래픽을 감당하는 MSA 티켓 예매 아키텍처 설계하기 ( 1주차 )

대규모 트래픽을 감당하는 MSA 티켓 예매 아키텍처 설계하기 ( 0주차 )

1주차를 읽기 전에 먼저, 0주차에서 기본적인 시스템 설계 아키텍처를 이해하고 본 글을 읽기를 추천 드립니다. 

 

서버 환경 구축

위 설계에서 확인하실 수 있듯이 저희가 기존에 설계한 시스템은 총 4대의 물리적으로 독립된 서버에서 동작하는 시스템입니다. 따라서 이를 구현하기 위해서는 총 4대의 서버가 필요했습니다.

1. 프론트엔드 웹서버 → 런타임 SSR 처리
2. 일반 API 서버(WAS)
3. 티켓 예매 서버(Ticker WAS)
4. 대기열 서버(Queue WAS)

 

이렇게 서버를 물리적으로 분리한 것에는 ‘장애 전파를 최소화하자는 의도’와 ‘수십만의 트래픽을 안정적으로 처리하자는 목적’을 가지고 있었지만, 실제 구현 단계에 들어서면서 몇 가지 현실적인 제약에 직면했습니다.

 

첫째, 팀원 모두가 MSA 환경 운영 경험이 없는 상황에서 여러 대의 서버를 동시에 관리하는 것은 학습 및 운영 부담이 상당했습니다.

둘째, 네이버 부스트캠프에서 제공되는 인프라 크레딧이 총 30만 원이며, 최소 3개월간 배포 상태를 유지해야 한다는 조건이 있었습니다.

대규모 트래픽 테스트 비용과 예비 비용을 고려해 약 5만 원을 제외하면,

실질적으로 월별로 사용할 수 있는 서버 비용은 약 7~8만 원 수준 이었습니다.

 

그러나 NCloud 기준 최소 사양(vCPU 2, Memory 4GB) 서버 한 대의 월 비용만으로도

이미 이 예산에 근접하는 수준이었고, 기존에 설계한 3~4대의 서버를 그대로 운영하는 것은 현실적으로 불가능했습니다.

 

그나마 선택 가능한 대안은

• 계정당 1대 제공되는 Micro-g1 무료 서버
• vCPU 1, Memory 1~2GB 수준의 compact-g1 서버(월 26,000원)

이었습니다.

그러면 compact-g1 server 기준으로는 최대 3대(78,000원) 까지의 서버를 대여할 수 있게 됩니다.

그러나 여기서 가장 걱정이 되는 점은, 저희는 아무래도 ‘수십만명의 대규모 트래픽을 감당할 수 있는 서버’ 를 목표로 하고 있기 때문에, 혹시나 이러한 ‘낮은 서버 스펙을 선택했을 때 요구사항을 만족하는데 걸림돌이 되지 않을까?’ 고민하게 되었습니다.

그리고 이는 다음과 같은 고민으로도 이어졌습니다.

 

“저사양·소수 서버 환경에서

‘수십만 명 트래픽을 감당하는 시스템’이라는 목표가 과연 의미를 가질 수 있을까?”

 

 

 

물론 기술적 최적화를 통해 단일 서버에서 처리량을 어느 정도 끌어올릴 수는 있습니다.

하지만 근본적으로 서버의 처리량은 CPU와 메모리라는 물리적 자원에 강하게 의존하며,

저사양·소수 서버 환경에서 실제 수십만 명의 동시 트래픽을 감당하는 것은 현실적으로 어려울 수 있습니다.

실제로 사실 자원 제한이 없다는 가정하에 무한대의 서버를 대여할 수 있다면, 대규모 트래픽을 처리하는 가장 단순한 방법은 서버의 사양 혹은 대수를 늘리는 것입니다.

그래서 결국 이러한 시도가 단순히 서버를 늘리는 것에서 그치지 않고 이를 기술적으로 의미있는 도전으로 만들기 위해서 다음과 같이 목표를 재정의하게 되었습니다.

 

 

1. 주어진 비용과 서버 제약(사양·대수)을 고정한 상태에서, 그 안에서 최대한의 처리량을 달성하는 것을 목표로 한다.
2. 절대적인 사용자 수가 아니라, 서버 1대당 감당 가능한 처리량(단위 처리량)에 집중한다.
3. 만약 compact-g1 server 한대를 기준으로 최대 1만명의 사용자까지만 받을 수 있었다면, 이를 10대로 Auto-Scaling 했을 때는 최대 10만명의 사용자를 받을 수 있다고도 볼 수 있습니다. 비록 실제 10만명 유저의 트래픽을 테스트해보지는 못했어도, 비용(돈)만 충분하다면 수십명까지 감당할 수 있는 시스템이라는 것을 강조하는 방법입니다.

 

 

두가지 현실적인 대안

 

따라서 저희는 현실적인 자원의 한계를 고려해서 본 설계 구조를 반영하기 위한 두가지 방법을 제시하고, 고민하게 되었습니다.

1. 사양이 좋은 단일 서버 한대에 도커 컨테이너로 MSA 구조를 논리적으로 분리
   • 장점
     • 서버 여러대를 관리할 필요가 없다.
   • 단점
     • 도커로는 CPU / 메모리 / 네트워크 물리 자원 경합 을 해결하지 못함
       • cgroup 을 통해 이론적으로 자원을 제한할 수 있다는 의견이 나왔지만 이는 논리적 분리이지 물리적 보호가 아니므로, 커널 스케줄러, GC 순간 burst 등으로 완벽하게 격리하는 것은 어렵다고 판단.
     • 대기열 서버 + 티켓 예매 WAS를 같은 물리 서버에 올리면, 대기열 트래픽 증가 시 CPU·메모리 자원 경합(Resource Contention)이 발생하여 티켓 예매 요청이 정상적으로 처리되지 못할 위험이 있다.
2. 3대의 서버를 운용 : 각각 프론트엔드 웹서버, 일반+티켓 예매 서버, 대기열 서버 로 나눈다.
   • 장점
     • 최소한의 스케일링 단위는 유지하면서 장애 전파를 최소화할 수 있다.
   • 단점
     • 서버 3대를 동시에 운용해야 한다.

 

3대의 서버를 운용하기

 

우선 서버를 3대밖에 활용하지 못하기 때문에, 두개의 서버는 한데 묶어서 배포하는 결정을 해야했습니다.

특히나 3대의 서버를 운용하는 경우에 기존 서버 4대 중 어떤 조합은 합쳐도 괜찮을지에 대해서도 고민을 해보았습니다.

 

 

1. Web Server + 일반 Backend 

 

처음에는 일반 Backend 서버에 트래픽이 몰리거나 장애가 발생하더라도, 프론트엔드에서는 항상 안정적으로 에러 메시지 화면을 제공하기 위해 Web Server 와 일반 Backend 를 물리적으로 분리하는 선택을 했습니다. 그런데, 일반적으로 Web Server 와 일반 Backend 가 감당해야하는 사용자 수는 거의 비슷합니다.

이로 인해 실제 트래픽 피크 상황에서는 Web Server 와 일반 Backend 가 감당해야 하는 부하 수준이 크게 다르지 않다고 판단했습니다.

따라서 일반 Backend 가 트래픽 문제로 장애가 발생할 정도의 상황이라면, 동일한 인프라 환경에서는 Web Server 역시 함께 문제가 발생할 가능성이 높고, 이 경우 물리적으로 서버를 분리하더라도 병목 지점을 분리하는 효과는 제한적이라고 보았습니다.

이러한 이유로 Web Server 와 일반 Backend 는 하나의 서버로 통합해도 전체 시스템 안정성 측면에서 큰 손해는 없다고 판단했습니다.

 

 

다만, 프론트엔드 빌드 결과를 CDN 같은 곳에 배포해서 트래픽에 유동적으로 대응할 수 있게끔 할 수 있다면, 확실히 어떤 상황에서도 정적 빌드 결과(HTML&CSS&JS) 를 제공할 수 있다는 점에서

사용자가 웹사이트에 아예 접속하지 못하는 상황은 벌어지지 않을 것이라고 기대됩니다. ( 최소한 에러 페이지는 보여줄 수 있음 )

 

 

정적 리소스 서버와 API 서버의 부하 규모와 패턴은 다른데, 왜 비슷하다고 단정하지?

물론, 정적 리소스 서버와 API 서버의 부하 패턴과 규모는 다를 수 있습니다.

• 일반적으로 프론트엔드 웹서버는 정적 리소스를 서빙하는 역할을 맡습니다.
• 만일 SSR 은 최소화하는 방향으로 개발한다면, SPA + CSR 구조에서는 정적 리소스 요청이 초기 로딩에 집중되고, 이후 트래픽의 대부분은 API 요청 형태로 일반 Backend 에 집중됩니다.
• 정적 리소스 요청을 처리하는 것은 단순히 파일을 읽고 전달만 하면 되는 상대적으로 가벼운 작업이며, CDN / 브라우저 캐시로 부하를 감소할 수 있기에 결국 트래픽 피크의 실질적인 원인은 API 요청에서 발생합니다.
• API 서버에서는 인증/인가 및 비즈니스 로직을 처리하면서 상대적으로 큰 CPU 와 메모리 자원을 소모하게 되고, DB I/O (DB, Redis) 등으로 압도적으로 비용이 높습니다.
• 따라서 동시에 같은 수의 유저가 접속했을 때, 백엔드 API서버만 부하가 걸려서 터지고, 상대적으로 처리하는 요청이 가벼운 프론트 웹서버는 터지지 않는 상황이 발생할 수도 있습니다.
• 이 경우에는 병목 지점을 분리해서 항상 HTML 을 보여줄 수 있도록 설계하는게 의미 있는 선택이라고 볼 수도 있습니다.

그러나, 저희가 저사양 서버 (vCPU 1, 1~2GB RAM)를 사용하고 있다는 관점에서는 아무리 정적 서버가 가볍다고 해도 네트워크 / 이벤트 루프 / 메모리 압박 은 같이 받을테니 API 서버만 터지고 프론트는 멀쩡한 이상적인 그림이 잘 그려지지 않았습니다.

왜냐하면, 예를 들어 프론트엔드 정적 웹서버는 일반적으로 수만 ~ 수십만 rps (Requests Per Second), 일반 API 는 1천 ~ 수천 rps 요청을 처리할 수 있다고 가정하면,

정적 리소스	50,000+ rps
SSR	200~500 rps
일반 API	1,000~2,000 rps
티켓팅 API	50~200 rps

대략적으로 계산했을 때, 메인 페이지에서 각 사용자가 5초에 1번 요청을 보낸다면, API 서버는 최대 400명의 사용자를 받을 수 있고, 반면, 정적 리소스 서버는 50,000명의 사용자를 받을 수 있습니다.

결국 이러한 구조가 병목 지점 분리로 실효성을 발휘하는 것은 400~50,000명 사이 구간의 사용자 요청이 들어왔을 때이고, 5만명 이상의 트래픽이 몰릴 경우에는 두 서버가 모두 터져서 병목 지점을 분리한 것이 크게 의미가 없을 수 있다는 결론에 이릅니다.

 

2. 티켓 예매 WAS + 일반 Backend (초기)

 

두번째는 WAS 와 일반 Backend 를 합치는 방법입니다.

사실 이 둘의 배포단위를 분리하도록 설계한 이유도 앞선 이유와 비슷합니다.

처음에는 일반 Backend(WAS)와 티켓 예매 WAS를 분리해 배포하도록 설계했습니다.

그 이유는 일반 WAS는 채팅, 공연 조회 등 비교적 가벼운 요청을 지속적으로 처리하는 반면,

티켓 예매 WAS는 예매 시작 시점에 다수의 사용자가 동시에 요청을 보내며

순간적인 트래픽 피크가 발생하기 쉽고 이것이 일반 기능 사용에 영향을 줄 수 있겠다고 판단했기 때문입니다.

예를 들어 인터파크에서 대형 콘서트 티켓팅이 진행되더라도,

해당 공연의 예매 트래픽으로 인해 공연 목록 조회나 채팅과 같은 일반 서비스 기능까지 함께 장애가 발생하는 상황은 지양하고자 했습니다.

하지만 다시 구조를 검토하면서, 오히려 일반 WAS 가 티켓 예매 WAS 보다도 더 많은 실시간 요청을 감당하고 있어야 할수도 있겠다는 사실을 깨닫게 되었습니다.

왜냐하면 티켓 예매 WAS 에서 순간적으로 예매하기 버튼을 누른 요청 수는 현재 웹사이트에 접속하고 있는 사용자 수를 넘어갈 수 없기 때문입니다.

 

 

---

 10만명 트래픽을 감당하기 위해서는 어느정도의 서버 사양이 필요할까?

 

만약 현재 웹사이트 접속자 수가 10만명이라고 가정해보겠습니다.

 

 

1. 첫번째 시나리오 : 10만명이 동시에 웹사이트에 접속해서 이후에는 5초에 1번 채팅 요청을 보내는 상황

메인페이지에 5개의 API 를 호출된다고 치면,

일반 WAS 는 최초 접속 시점에는 순간적으로 최대 초당 50만개의 요청을 처리할 수 있어야 하고,

100,000 * 5 = 500,000 rps 

이후에는 초당 2만개의 요청을 지속적으로 처리할 수 있어야 합니다.

RPS = 100,000 / 5 = 20,000 rps

반면 티켓 WAS 는 10만개의 요청을 순간적으로 처리할 수 있으면 됩니다.

 

 

2. 두번째 시나리오 : 10만명의 인원이 점진적으로 웹사이트에 접속한 상황

그러나 이는 대규모 인원이 한번에 동시 접속하는 건 실제 상황과 약간 차이가 있기 때문에, 점진적으로 접속하는 상황 또한 가정해보겠습니다.

이 경우에는 예매가 오픈하기 5분 전에 10만명의 접속이 고르게 분포한다고 가정합니다.

이 경우 일반 WAS는 초당 평균적으로 1666 개의 요청을 처리해줄 수 있어야 합니다.

 RPS = 100,000 * 5 / 5 * 60  = 1666 rps

즉, 일반 WAS 는 수십만명을 감당하기 위해서는 최소 1666rps 부터 순간적으로는 500,000 rps까지 지속적으로 높은 수준의 처리량을 요구한다는 사실을 알 수 있습니다.

 

 

vCPU 1, Memory 1~2GB 수준의 compact-g1 에서는 요청을 최대 몇명까지 감당할 수 있을까?

 

1. 일반 API 서버

예를 들어 일반 API 서버가 초당 2,000 rps를 처리할 수 있고,

사용자 1명이 최초 접속했을 때는 5회의 API 요청, 이후에는 지속적으로 0.2 회 API 요청이 발생한다고 가정하면,

• 첫번째 시나리오에서는 순간적으로 최대 약 400명의 사용자까지 감당할 수 있습니다. ( worst case )
• 400 * 5 = 2,000 rps
• 두번째 시나리오에서는 같은 스펙의 서버에 대해서도 5분간 트래픽이 분산해서 들어오므로 저스펙으로도 대규모 인원을 처리할 수 있습니다.
• ⇒ 트래픽이 나눠서 들어온다면 2,000 rps 서버로 초당 400명씩 꾸준히 받아서 5분동안 최대 120,000명의 사용자를 감당할 수 있습니다.

1. 티켓 예매 WAS

반면 티켓 예매 WAS는 순간적으로 처리해야하는 트래픽이 몰릴 수 있다는 특성을 지닙니다.

예매 요청은 사용자 수를 초과해 발생할 수는 없으며,

락이나 트랜잭션 처리로 인해 요청 1건당 비용은 상대적으로 조금 더 높습니다.

순간적으로 많은 요청을 안정성 있게 처리하는 것과 큰 규모의 요청을 지속적으로 안정성 있게 처리하는 것은 분명 다른 문제입니다.

 

따라서, 이것도 마찬가지로 서버가 현재 접속한 유저에 대한 일반 서비스에 대한 API 요청은 처리할 수 있는데,

그 이상의 예매 요청이 순간적으로 몰려서 이걸 처리할 수 없을 때에만 병목지점을 분리하는 것이 의미가 있다는 결론이 나옵니다.

일반 API 서버가 초당 2,000 rps를 처리할 수 있고, 사용자 1명당 초당 평균 5회의 API 요청이 발생한다고 가정하면 동시에 약 400명의 사용자를 안정적으로 처리할 수 있습니다. 반면 티켓 예매 API는 요청 1건당 처리 비용이 높아 초당 50~200 rps 수준의 처리량만을 기대할 수 있습니다.

 

따라서 400명 이상이 접속한 상태에서는 일반 API 만으로 서버 자원이 다 소진되고,

200명 이상일 경우에도 순간적으로 예매 트래픽이 몰리면 ( 일반 200 + 티켓예매 200 ) 최대 처리 가능량을 넘어서서 정상적으로 처리되지 못할 위험이 있습니다.

 

즉, 예상되는 사용자 수가 200명 미만이라면 일반 WAS와 티켓 예매 WAS를 하나의 서버로 통합해도 동시 트래픽을 감당할 수 있어서 큰 문제가 없고, 200명 ~ 400명 사이일 때에는 서버를 통합하면 한번에 최대 200명까지만 사이트 접속 → 티켓 예매를 동시에 처리할 수 있었는데, 최대 400명까지는 웹사이트 접속해서 일반 기능은 사용 가능하도록 개선이 가능합니다.

즉, 예상되는 사용자 수가 200명 이상인 경우에는, 티켓 예매 기능을 분리 배포하여

‘티켓 예매’ 기능을 위한 CPU 와 메모리 자원을 따로 할당해두어서 사이트에 접속했는데 예매 요청은 제대로 처리되지 못하는 상황은 어느정도 막을 수 있다는 데에 의의가 있습니다.

 

 

결론

 

 

1. 저희는 Websever 는 CDN 같은데에 올려서 독립적으로 스케일링 될 수 있도록 해서 최소한의 페이지 제공은 가능한 구조를 만들고,
2. 나머지 Backend + 일반 API 를 그냥 서버 한대에 배포하기로 결정했습니다.
   • 서버를 나눠도, 각 서버가 병목에 걸리는 시점이 거의 비슷해서 전체 시스템이 버틸 수 있는 최대 사용자 수는 거의 늘지 않고
   • 서버를 나눠서400명이 웹사이트에 접속 가능하게끔 하더라도 실제적으로는 200명만 예매가 가능하기 때문에, 추가 200명의 단순 웹사이트 접속 만을 위해서 서버를 분리할 필요가 있을까? 고민을 했을 때, 그렇게 큰 이익은 아니라고 판단했기 때문입니다.

     서버 통합	~200명	~200명
     서버 분리	~400명	~200명

   • 아마 이 부분은 실제 서비스 되는 환경이라면 실제 사용자 데이터를 바탕으로 평균 접속자 수를 감안하여 더 상황에 적합한 결정을 할 수 있을 것입니다.