IT 서비스가 보편화 됨에 따라 서비스에서 감당해야할 유저의 수가 기하급수적으로 증가했다. 일반 사용자의 수 뿐만 아니라 특정 시간에 이벤트를 진행한다고 한다면 동시에 접근하는 유저의 수는 매우 크다. 이렇게 실제 운영하는 서비스에서는 대용량 트래픽을 접하는 경우가 매우 빈번하지만, 개인이 진행하는 사이드 프로젝트에서는 이런 경험을 접해보기 어렵다. 따라서 이러한 트래픽을 간접적으로 체험해보기 위해 부하 테스트를 진행하였다.
먼저 데이터를 생성하기 전에 정확히 어떤 API 를 테스트 할 것인지 정해야 한다. 가장 메인인 ‘내 주변 러닝크루 목록 조회’ 의 경우 사용자가 처음에 접하는 API 이기 때문에 요청의 수도 많고, 데이터의 수가 가장 많이 쌓일 것이라 예상되어 부하 테스트 API 로 선정하였다.
부하 테스트를 도와주는 툴들은 많지만 무료이며 많은 사람들이 사용하는 JMeter 와 nGrinder 중에서 고민하였다.
nGrinder 가 더 괜찮은 UI 와 세부적인 설정을 제공하지만 그만큼 테스트 하는 환경에 대한 투자가 필요하다. nGrinder 의 장점을 최대한 살리기 위해서는 nGrinder 를 실행시키는 서버와 Agent 로 사용할 서버들을 구축해야 한다. 사이드 프로젝트를 진행하는 환경에서 그만큼 다양한 서버를 구축하기에는 어렵다. 또한 일반적으로 서비스를 사용한다면 하나의 기능만 사용하는 것이 아닌, 접속 플로우가 있기 때문에 시나리오 테스트를 제공하는 JMeter 를 선택하였다.
부하 테스트를 진행할 때 어떤 결과를 보고 성능이 좋다, 나쁘다를 구분할 수 있을까?
대표적인 성능 지표로는 TPS 가 있다. TPS 는 Transaction Per Seconds 로 1초동안 처리된 트랜잭션의 수를 나타낸다. 말 그대로 1초동안 서버에서 처리되던 요청의 기준이라고 생각하면 된다. TPS 가 높으면 높을수록 처리되는 요청의 수가 많다. 그렇다고 TPS 가 높다고 좋은 것도 아니다. TPS 가 높을수록 서버에서의 처리량이 많다는 뜻이고, 서버의 자원을 많이 쓸수록 사용자의 응답 시간은 늦어진다. 따라서 TPS 와 함께 응답 시간을 의미하는 Latency 도 고려 대상이다.
두벅스 - 욜로가 서버 구조도
욜로가 서버의 구조도는 다음과 같다. AWS 에서 제공하는 Route 53 과 Load Balancer 를 거쳐 API 서버에 도달하며 기능에 따라 DB 나 S3 에 접근한다. 개발자가 개입할 수 없는 부분은 제외하고, 이번 부하 테스트에서 확인할 기능이 거쳐가는 플로우는 EC2 - MySQL 이다. EC2 에서는 Spring Boot 프로젝트가 동작하고 있다.
이번 부하 테스트의 목표는 ‘Spring Boot 의 내장 Tomcat 에 대한 최적의 설정 찾기’ 이다. Tomcat 의 Thread, Connection 등의 설정을 변경하여 수많은 사용자들의 요청에 대비할 예정이다. 부하 테스트를 마치고 Spring Application, MySQL 등에도 성능 개선을 이어나갈 계획이다.
그러면 Tomcat 의 ‘어떤’ 설정값을 변경하는 것이 좋을까? 서비스에 안전하게 접속할 수 있는 동접자의 수를 늘리려는 것이 목적이니 웹서버가 사용자의 연결을 진행할 때 영향이 있는 값을 변경해봐야 한다.