4차: 대기열 시스템 기반 가용성 확보

🔍 문제 분석

• 티켓팅 서비스는 단시간, 높은 트래픽 처리
• 티켓팅 중 메인 서버가 다운된 후 복구될 때, 대기 중이던 사용자들이 한꺼번에 재접속을 시도하면 메인 서버가 다시 다운될 수 있음
• 모든 요청을 메인 서버가 혼자 처리하므로, 티켓팅이 아닌 서비스도 티켓팅 트래픽의 영향을 받음
• T3.small 1대 기반 동시 접속자 5000명에서 모니터링을 하지 못할 정도로 CPU 과부하가 일어남

가용성을 위한 아키텍처 개선이 필요하다고 판단

🛠️ 해결 방안

수평 확장

• 메인 서버를 스케일 아웃해 트래픽 처리량을 늘리는 방법
• 티켓팅이 아닌 다른 서비스의 트래픽도 함께 처리 가능
• 예측하지 못한 고부하 발생 시 모든 서버가 순차적으로 다운될 가능성 있음

대기열 서버 도입

• 티켓팅 시에만 사용되어 티켓팅의 높은 트래픽을 버퍼링하여 기존 메인 서버에 안정화된 트래픽 제공 가능
• 예측하지 못한 고부하 발생 시에도 대기열 서버만 다운되어 메인 서버로 장애 전파되지 않음
• 근본적인 처리량이 증가하지는 않아 사용자 경험이 떨어질 수 있음

한정된 자원으로 안정성을 갖추기 위해 대기열 서버 도입

🔧 설계 변경

변경된 아키텍처 다이어그램

• 기존 아키텍처: 웹서버, mysql, 모니터링 서버
• 변경 아키텍처: 웹서버, mysql, 모니터링 서버, 대기열 서버, 레디스

새로 추가된 컴포넌트 및 기능

• 큐 서버: 대기열 서버로 사용자 요청을 버퍼링하는 서버

  • 사용자 대기 번호를 발급
  • polling 요청을 통해 티켓을 구매할 수 있는 대기 번호 시점까지 트래픽 관리

• redis: 티켓 구매를 위해 필요한 정보(재고 수량, 티켓 판매 시각)를 저장하고, 대기열에 참여한 사용자를 관리하는 DB

  • DB 부하 분산, 빠른 데이터 접근, 다양한 자료 구조를 지원하여 사용 결정함
  • 티켓 구매 시 검증해야 하는 기본 정보들인 재고 수량, 티켓 판매 시각을 저장함
  • 대기열에 참여한 사용자를 set으로 관리

🚀 성능 테스트

테스트 계획 수립

• 동시 접속자 수: 3000명, 5000명
• 시나리오: 동시 접속자들이 다음 순서대로 api 요청
  • 1. 티켓 구매 권한 획득
  • 2. 티켓 구매 미리보기 조회
  • 3. 티켓 구매
  • 참고) 현재 api 요청 실패 시 다음 api를 요청하지 않음
• 검증: 상태 코드가 200인지 여부, 티켓 구매 성공한 요청 수와 mysql, redis의 티켓 구매 수 일치 여부
• 핵심 지표: 메인 서버의 cpu 부하량

결과 분석

기존 아키텍처:

• 동시 접속자 5000명 시, CPU 사용률이 지속적으로 100%임을 확인.

개선된 아키텍처:

• 동시 접속자 5000명 시, 결제 처리에서 CPU 사용률이 50% 이하로 안정적인 모습을 확인.

결론

기존 아키텍처는 높은 부하에서 CPU 과부하가 발생하며, 안정적인 처리에 한계가 있음을 파악.
개선된 아키텍처는 대기열 서버와 Redis 도입으로 메인 서버의 CPU 부하를 줄이며, 기존과 같은 동시 접속자 수에서도 안정적인 성능을 유지함을 확인.