대기열 시스템 성능 비교
저희는 대기열 시스템 설계를 바탕으로 Java 자료 구조를 이용한 대기열, Redis를 이용한 대기열을 구현하였습니다. 이번 게시글에는 두 가지 대기열의 성능 비교 분석을 위한 테스트 환경, 부하 테스트 결과에 대해 소개드리겠습니다.
부하 테스트 도구로는 Locust를 이용했습니다.
처음에는 EC2 t3.small 인스턴스 하나만 테스트 인스턴스로 이용하려고 했으나 가상 사용자가 500이 넘어가는 순간 예외가 발생하거나 가상 사용자 수가 멋대로 감소, 증가하는 문제가 있었습니다. 저희는 대량의 트래픽을 테스트 하기 위해 많은 가상 사용자가 필요했기 때문에 Locust는 master-worker 분산 환경으로 구성할 필요가 있었습니다.
Locust를 실행시키기 위해서는 Python 가상 환경 설정, locust 스크립트 업로드, 의존성 추가 등 환경 세팅에 많은 시간이 필요했습니다. 따라서 AWS가 제공하는 서비스를 적극 활용하여 효율적인 테스트 환경을 구성했습니다.
- 기존 EC2 인스턴스로부터 Locust worker 용 AMI 이미지를 생성했습니다.
- AMI 이미지를 이용해 자동으로 Locust worker로 실행시키기 위한 시작 템플릿을 생성했습니다.
- 오토스케일링 그룹을 이용하여 테스트가 필요할 때 일괄적으로 인스턴스를 생성했습니다.
- 부하 테스트가 진행 중이 아닐 때는 오토스케일링 그룹을 삭제하여 비용을 절약했습니다.
테스트 시나리오는 다음과 같습니다.
- 사용자의 티켓팅 페이지 접속(티켓팅 API 호출)
- 대기열 페이지 리다이렉트(남은 순서 조회 API 호출, 1초 주기 폴링)
사용자 로그인의 경우 Locust에 JWT 의존성을 추가하여 자체적으로 토큰을 생성하였습니다. 또한, 클라이언트의 대기열 페이지 구현과는 별도로 대기열 시스템의 원활한 성능 측정을 위해 사용자가 남은 순서 조회 API를 1초 주기로 폴링하는 것으로 시나리오를 구성하였습니다.
본 시나리오를 이용하여 테스트 시간 5분, 가상 사용자 1,000명, 2,5000명, 5,000명으로 설정, 자바 대기열과 레디스 대기열 각각 부하 테스트를 진행하였습니다.
다음 그래프는 각 테스트 결과를 요약하여 정리한 것입니다.
성능 상 우위를 보이는 것은 자바 대기열입니다. RPS는 자바 대기열이 레디스 대기열에 비해 근소하게 우위에 있습니다. 그러나 응답 시간에서는 자바 대기열이 레디스 대기열에 비해 2배 정도 빠른 것을 확인할 수 있었습니다.
가상 사용자 1,000명, 2,500명, 5,000명 중 가장 안정적인 것은 2,500명인 상황이었습니다. 2,500명일 때 95%의 요청 응답 시간이 600ms 안에 완료되는 것을 확인할 수 있었습니다.
추가로 레디스의 강점을 살리기 위해 서버 인스턴스를 2대로 스케일 아웃해서 부하 테스트를 다시 한 번 진행해봤습니다.
기존 가상 사용자 5,000명 조건일 때는 대부분의 요청 응답 시간이 1초 이상 소요되었습니다. 그러나 스케일 아웃 후에는 레디스 대기열 쪽이 RPS와 응답 시간 확연히 차이 나는 것을 확인할 수 있었습니다.
마지막으로 기존 1초 주기로 남은 순서 조회 API를 폴링하는 것에서 리액트 클라이언트의 구현에 맞추어 5초 주기로 폴링하는 것으로 변경하여 부하 테스트를 진행하였습니다. 기존 가상 사용자 2,500명, 1초 주기 폴링 조건에서 대부분의 요청을 600ms 내로 처리했으므로 가상 사용자 10,000명, 5초 주기 폴링 조건에서도 대부분의 요청을 1초 이내에 처리할 수 있을 것으로 예측했습니다.
다음은 레디스 대기열의 RPS, 응답 시간 결과 지표입니다.
최종적으로 저희의 대기열 시스템은 사용자가 10,000명, 5초 주기 폴링 조건에서도 안정적으로 동작한다는 사실을 검증하였습니다.
그런데 서로 다른 조건에서 실행한 부하 테스트들의 응답 시간 그래프에서 공통적으로 스파이크가 발생하는 것을 관찰할 수 있었습니다.
저희는 '어째서 응답 시간 스파이크가 발생하지?'라는 의문을 품었습니다. 다음 편에서는 이 의문을 해결하고, 응답 시간 스파이크를 줄인 과정에 대해 이야기해보겠습니다.