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

🔍 문제 분석

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

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

🛠️ 해결 방안

수평 확장

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

대기열 서버 도입

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

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

🔧 설계 변경

변경된 아키텍처 개요

• 변경된 아키텍처

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

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

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

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

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

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

🚀 성능 테스트

테스트 계획 수립

• 시나리오: 동시 접속자가 3000/5000명일 때 티켓 구매 권한 획득, 티켓 구매 프리뷰, 티켓 구매 요청 세 단계 api를 요청하여 상태 코드가 200인지 확인
  • 각 단계에서 실패 시, 다음 단계를 진행하지 않음
• 지표: 메인 서버의 cpu 부하량, 대기열 서버 처리량

결과 분석