성능 개전 전 부하테스트 리포트
성능 개선 전 10명의 사용자가 30분간 지속적으로 요청을 보내는 환경에서 TPS가 1.2, MTT가 8000ms로 매우 비정상적인 매트릭을 보여주었다. 개발 단계에서는 데이터량이 많지 않았기 때문에 성능에 문제가 있다는것을 파악할 수 없었지만 데이터가 많아지면서 아래와 같은 비정상적인 매트릭을 측정할 수 있었다.
성능 개선 후 부하테스트 리포트
상품 검색 기능에 대한 성능 개선을 완료하고 다시 한 번 부하테스트를 진행했다. 테스트를 진행한 서버의 스펙은 모두 t3.medium으로 동일하며 2vCPU와 4GiB 메모리를 가지는 EC2 환경에서 진행했다. 테스트는 30분 동안 N명의 사용자가 계속해서 요청을 보내는 환경으로 진행했고 사용자수를 10명, 100명, 1000명으로 늘리며 진행했다.
✅ 1차 테스트
1차 테스트에서는 만족할만한 결과를 얻을 수 있었다. 10명의 사용자가 30분간 요청을 보내는 환경에서 TPS가 284.5로 측정되었고 MTT는 32.93ms로 성능 개전 전의 비정상적인 매트릭에 비해 실제 서비스를 운영할 수 있을만큼의 매트릭을 측정할 수 있었다. TPS나 MTT가 한번 씩 튀는 현상은 많은 이유가 있는데 그 중 GC의 동작으로 인해 쓰레드가 멈춰 발생하는것이 가장 대표적이라고 한다. 메모리와 CPU 사용률 또한 준수하게 관측되었다.
✅ 2차 테스트
해당 서비스가 어느정도의 트래픽을 견딜 수 있는지 측정하고 싶었기 때문에 유저수를 늘려가며 단계적으로 테스트를 진행했고 2차 테스트에서는 100명의 사용자가 30분간 요청을 보내는 시나리오로 테스트를 진행했다. MTT는 258.71ms로 1차 테스트의 결과인 32.93ms에 비해 8배 가량 늘었지만 TPS의 경우 1차 테스트의 결과인 284.5에 비해 381.2로 초당 더 많은 트랜젝션을 처리하는 것을 볼 수 있었다. 이는 애플리케이션 내부적으로 처리할 수 있는 리소스에 대해 여유공간이 있고, 스프링 애플리케이션은 기본적으로 멀티 스레드 환경에서 동작하기 때문에 요청이 많아짐에 따라 쓰레드풀의 크기에 맞춰 병렬처리를 진행하기 때문에 TPS가 오히려 상승할 수 있다고 한다.
✅ 3차 테스트
3차 테스트는 1,000명의 사용자가 30분간 요청을 보내는 시나리오로 테스트를 진행했다. 테스트 결과 TPS가 485, MTT가 2,597.28ms로 TPS는 준수했지만 MTT에서 많은 부하가 발생해 서비스가 불가능한 수준의 매트릭을 관측할 수 있었다. 따라서, 서비스 제공 시간이 2초를 넘어가면 안된다는 자체 기준하에 해당 서비스는 최대 800명 정도의 동시 요청을 안정적으로 처리할 수 있다는 결론을 내릴 수 있었다.
