프로젝트를 배포, 운영해보면서 내 프로젝트에 어디서 병목 현상이 발생하는지, 트래픽은 어느 정도까지 감당할 수 있는지 확인이 필요한 경우를 공부한 과정입니다.
테스트하는 프로젝트는 sns 사이드 프로젝트로, 간단히 포스팅을 쓰고, 댓글 및 좋아요가 가능한 기본적인 커뮤니티입니다.
테스트는 다음과 같이 시나리오를 설정하고, 진행했습니다.
테스트 시나리오 구성 근거
실제로 클라우드에 배포하는 건 돈 때문에ㅜㅜ 제 컴퓨터 스펙의 서버를 기준으로 잡고 일단 테스트 기준을 세웠습니다.
1. 서버 스펙
제 컴퓨터 스펙은 다음과 같습니다.
cpu : AMD Ryzen 5 3500X 6-Core Processor 3.59 GHz (6코어 입니다.)
메모리 : 16GB
disk : sdd 500GB
2. api request 의 크기
주로 테스트하게 되는 api의 경우, postingList가 됩니다. 사용자가 화면 스크롤 시 출력하는 페이징이 적용된 posting 들을 조회하는 api입니다.
포스팅의 경우 이미지 5장, 텍스트 1000자 정도로 현재는 제한되어 있다고 가정합니다.
테스트 시나리오 개요
사이드 프로젝트에서는 사실 실제로 트래픽을 받기 어려운 상황이니, 사용자로부터 트래픽이 들어온다고 가정하고 시나리오를 구성해 진행했습니다.
1. 평시 트래픽 테스트
일반적으로 트래픽이 서버에 들어오는 시나리오
- 조건 :
동시 접속자 500명, 1시간 지속적으로 동일한 트래픽 부하
- 기준 :
오류 1% 이하, 평균 응답시간 200ms 이하. (이 정도 응답시간이면 사용자가 불편을 느끼지 않을 정도의 시간이라 생각)
2. 순간 트래픽 테스트
순간적으로 트래픽이 증가하는 시나리오 (이벤트로 인해 , 또는 인기있는 사람의 포스팅 등장 시)
- 조건 :
순간적으로 접속자 1000으로 증가, 5분 동안 테스트
(읽기, 또는 댓글, 좋아요 등 이 많이 발생할 것으로 예상되기에, 해당 시나리오는 다른 api들도 같이 테스트 진행 필요)
- 기준 :
오류 1%보다 높아도 됨 (평시보다 높아도 어느 정도는 허용) 5%는 넘으면 사용자가 심각하게 불편함을 겪을 테니, 그것보단 아래여야 함. 응답 시간은 2~3초 정도까진 허용하도록.
3. 최대 부하 테스트
점진적으로 사용자가 증가해 한계치가 어느 정도인지 확인하는 시나리오
- 조건 :
접속자 300명에서 점진적으로 사용자 수 증가.
- 기준 :
서버가 응답하지 않을 때까지 진행.
Jmeter 세팅
jmeter를 시나리오 대로 세팅하는 과정입니다.
가장 먼저 보이는 Thread group 설정을 통해 사용자 수나 요청 빈도 등을 설정했습니다.
- Number of Threads : user 수 (thread) 라고 생각하면 됩니다.
- Ramp-up period : Number of Threads가 다 실행되는데 걸리는 시간을 설정합니다. 위 사진을 예시로 들면, 500개 스레드가 다 실행되는 데 300초 가 걸리도록 되어 있는 것입니다.
- Loop count : user가 해당 요청을 실행하는 횟수입니다.
이렇게 thread group 을 생성했으면 이 그룹 하위에 부하를 주기 위해 어떤 api를 사용할지, 부하 테스트 결과로 어떤 지표를 볼 지 추가할 수 있습니다.
thread group 우클릭 -> add에서 sampler 를 통해 여러 request를 , listener를 통해 결과 지표를 추가했습니다.
제가 추가한 request와 listener는 다음과 같습니다.
위 2개 항목이 제가 부하를 가하고자 하는 api, 하위 6개 항목이 지표가 되겠습니다.
하위 6개 항목의 경우, api 요청이 실패율이 얼마인지, 시간에 따라 응답시간이나 tps가 어떻게 변화했는지 등을 주요 테스트 대상으로 보고 선정한 지표들입니다.
하위 6개 항목들을 다음과 같이 요약할 수 있습니다.
- view result tree : 각 request에 대해 요청과 응답을 디테일하게 볼 수 있음
- summary report : 요청한 api 종류별로 테스트 후 통계를 보여줌. 빠르고 전반적으로 파악 가능하도록
- aggregate report : 요청한 api 종류별로 통계를 집계, 디테일한 결과를 확인가능.
- transaction per second : tps 로, 초당 처리 건수를 의미한다. 실시간으로 tps가 어떻게 변화했는지 그래프로 볼 수 있다.
- response times over time : 시간에 따른 요청에 대한 응답 시간 그래프.
- active threads over time : jmeter로 활성화된 스레드들이 시간에 따라 어떻게 변화했는지 그래프로 볼 수 있다. 의도한 대로 스레드가 증감했는지 보기 위한 것.
이렇게 세팅도 해봤으니, 실제로 로컬 서버에 부하를 가해보았습니다.
부하 테스트
테스트는 피크 시간대 부하 시나리오를 기반으로 진행했습니다.
1. Response Times Over Time
먼저 response times over time, 시간에 따른 응답시간 변화 입니다. 초반에는 2~3초의 응답시간을 유지하다 최대 12초까지 도달합니다. 즉 저 시간대에는 request 결과는 12초 후에 사용자에게 도달했을 것 이라는 거겠죠. 사용자 입장에선 매우 불편하겠네요.
물론 테스트 환경이기에 시간은 오래걸리는게 맞지만, 조금 더 성능 향상에 대해 고민해봐야할 것 같습니다.
2. Aggregate report
다음은 aggregate report 입니다. samples (생성된 요청 수) 만큼 진행했고, 뒤에 average, median, ... 등은 단위를 ms를 사용합니다. 직관적으로 해석해서 보면 average 의 경우 평균적으로 걸린 응답시간이 되겠습니다. 90% line의 경우 퍼센타일 로,
평균 7초가 넘게 걸렸네요;; 참 오래 걸립니다.
3. Active Threads Over Time
active threads over time 지표로 활성화된 스레드들이 어떻게 되었는지 보면, 점진적으로 증가한 스레드들이 요청을 마치고 시간이 지나면서 동작을 멈추는 것을 이렇게 보여줍니다.
회고
실무 환경에서는 이런 부하테스트 하기가 참 제한적이었습니다. 아무래도 특수한 환경이기도 하고, 회사 특성상 저희가 함부로 이런 건 진행하기가 어려워 이런 점이 참 아쉬웠습니다. 그래서 집에서 해본 프로젝트에 직접 스스로 상황을 가정해 테스트를 해보게 되었습니다.
테스트를 해보며 궁금한 점들이 더 생기게 되었습니다.
- 실제 부하 테스트 시 환경은 어떻게 세팅하는가? jmeter를 다른 서버에 세팅해서 트래픽을 보낼까??
- 테스트 시나리오를 세울 때 근거들은 상황에 따라, 사업 특성에 따라 다양할 것 같은데, 내가 모르는 근거가 있을까?
'Project > 개인 프로젝트' 카테고리의 다른 글
| spring boot 사이드 프로젝트 : 채팅기능을 위한 stomp 적용 (0) | 2024.02.20 |
|---|