[ 성능 테스트 ! ]
이전에 사용해본 부하테스트 툴인 'Locust'
이번에 새로운 프로젝트를 진행하면서, API테스트와 부하테스트를 한번에 해주는 툴을 만들기로 했다! (쿠버네티스 + 프로메테우스 + 그라파나 조합인데 공부하면서 3주안에 만들 수 있으련지...) 그러려면 기존의 툴에 대한 이해는 필수이다! 따라서 전에 사용해본 locust에 이어, 아직도 성능테스트 툴로 많이 사용하고 있는 JMeter에 대한 간단한 내용을 기록으로 남긴다.
[ 성능 테스트 종류 ]
- 부하 테스트(Load Test)
- 목표 성능 도달 여부를 측정하기 위함(realse할때 사용) -> 방법은 여러가지가 있지만 부하를 서서히 높이는 방법을 주로 사용!
- 예를 들어 출결사이트의 경우, 최소 동시접속 80명(출결인원)까지는 가능해야 함
- 스파이크 테스트(Spike Test)
- 일시에 부하가 몰릴때 시스템이 버틸 수 있는지 체크(갑자기 사용자가 급증했을 때 서버가 견디지 못하는 경우를 많이 봤다!)
- 수강신청 시스템처럼 일시에 부하가 몰릴것을 가정했을때, 이때 부하 가정 시나리오를 수강신청 모델을 사용한다.
- 일시에 부하가 몰릴때 시스템이 버틸 수 있는지 체크(갑자기 사용자가 급증했을 때 서버가 견디지 못하는 경우를 많이 봤다!)
- 신뢰성 테스트(Stress Test)
- 한계 부하가 걸린 상태에서 시스템의 모든 기능들이 어느 정도 운용되는지 테스트 하는 것이며 이 결과는 SW품질 특성 중 '신뢰성'을 나타내는 지표로 활용됨
- 미션 크리티컬한 시스템(예를 들어 운송수단, 산업 등등)에서는 필수적으로 받아야 하는 시스템이다.
- 안정성 테스트(Stability Test)
- 장시간 테스트(짧게는 한두시간, 길게는 1~2일)를 하면서 서버의 성능을 테스트한다.
[ 무엇을 측정해야 하는가 ! ]
주로 알려진 성능 테스트의 목적은 1. 목표 성능 도달 여부 확인, 2. 한계 성능 측정 , 3. 부하 스트레스 하에서 기능 안정성 확인 이다. 이를 위해서 Jmeter를 통해 측정하는 항목 중 대표적인 키워드는 아래와 같다.
- 트랜젝션(Transaction) : Request + Response 가 하나의 트랜젝션을 이룬다. ( 사용자 수 <= 트랜젝션 수 )
- 화면 조작을 통한 Request발생 ~ Response를 받기까지의 동작을 의미
- TPS(Transaction Per Sec)
- 1초에 처리할 수 있는 트랜젝션 수를 의미하며 성능 테스트의 중요한 지표
- 응답시간(Response Time) : 사용자가 요청을 보낸 시점부터 결과가 보여지기까지 시간
- Request~최종화면 표시까지 걸리는 시간이며 영향을 주는 변수들이 많아 지표로서는 좋지 않으나, 사용자들이 직접 체감하는 지표이므로 같이 측정을 해 준다.
- 그 외에 추가적으로 알아두면 좋은 용어들은 다음과 같다.
[ 관련 도구 ]
1. LoadRunner ( 성능테스트 왕좌, 기업 단위 )
2. Locust (개발자 단위)
3. nGrinder ( 국내 오픈소스 )
4. JMeter ( 아파치 재단에서 LoadRunner를 따라잡이 위해 만든 오픈소스 )
[ JMeter 의 장단점 ]
그렇다면 JMeter 의 장단점은 무엇이 있을까? 제작중인 프로젝트에서 Jmeter의 단점을 보완할 수 있으면 좋겠다 하여 한번 알아봤다.
장점은 ?
- 분산환경 지원
- 스크립트 레코딩
- DB, HTTP 등 각종 프로토콜 제공
단점은 ? -> 프로젝트를 진행하면서 보완할 수 있다면 보완해보려고 한다!
- 분산환경 설치가 쉽지 않음
- 프록시 서버 기반 스크립트 레코딩이 불편하다.
[ 일단 설치를 한번 해보자 ]
조사는 이쯤 해 두고 Jmeter를 사용해보기로 했다. MacOS는 brew로 간편하게 설치가 가능하다! 실행은? 그냥 jmeter만 치면 된다!
# 설치
brew install jmeter
# 실행
jmeter
이어서 설치해야 하는 항목은 플러그인 들이다. JMeter에서는 굉장히 다양한 플러그인을 제공하고 있다. 나는 그중에서 가장 대표적으로 쓰이는 세개의 플러그인(3 Basic Graphs, Custom Thread Groups, jpgc-standard set)을 설치했다.
설...치...중...
[ 실험 내용 ]
1. 먼저 TestPlan에서 Thread Group을 만들어 준 뒤, 아래 4개의 thread를 추가해 준다.
- ThreadGroup(우클릭) -> Add -> Sampler -> Http Request을 눌러준다.
- ThreadGroup(우클릭) -> Add -> Listener -> View Results Tree
- ThreadGroup(우클릭) -> Add -> Listener -> Summary Report
- ThreadGroup(우클릭) -> Add -> Listener -> Transaction Per Second 를 추가 시켜준다.
2. 이제 여기서 Thread-Group을 만져준다. 중앙에 보이는 세 값은 다음과 같다.
- Number of Threads(users)
Threads의 개수를 정한다. 물론 엄밀히 따졌을 때 스레드의 개수가 유저의 활동을 전부 포함할 수는 없겠지만 근사하게는 값을 도출시킬 수 있다. 스레드 수가 많을수록 서버는 많은 부하를 받을 것이다. - Ramp-up Period(in seconds)
한번의 실행을 몇초 동안 완료 시킬것인지에 대한 설정값을 의미한다. - Loop Count
반복하고자 하는 횟수이다., Infinite를 누르면 무제한으로 실행하게 된다.
※ brew로 jmeter를 실행시키다가 test-plan이 저장되지 않는 문제를 발견했다.
( 같은 문제가 발생하시는 분들은 darcular가 아닌 다른 테마를 선택하시면 해결됩니다. )
3. 파라미터를 설정하고 Test-plan을 저장하고 실행하면 다음과 같이 테스트 결과값을 얻어낼 수 있다. 지금은 로컬에 간단한 spring프로젝트를 실행시키고 돌려본 상태인데, 생각보다 transaction-failure가 꽤 발생하고 있다. 일단 locust와 크게 다르지 않은(같은 부하테스트 툴이니까!) 느낌을 가져가면서, jmeter 엔진을 spring-boot 쪽으로 가져오기 위한 테스트를 해 볼 예정이다. 면접 시즌이라 바빠서 시간을 많이 투자하지는 못하겠지만, 재밌는 프로젝트가 될 것 같다^^.