⚡ Jmeter
📌 Jmeter란?
🔷 1998년에 처음 출시된 오픈 소스 소프트웨어
- 웹 애플리케이션을 비롯한 다양한 서비스의 성능을 측정하고 분석하기 위해 설계
- 웹 애플리케이션의 성능 테스트, 스트레스 테스트, 그리고 부하 테스트를 수행하는 데 사용
👉 사용자가 실제로 시스템을 사용하는 것처럼 HTTP, HTTPS 같은 프로토콜을 이용해 서버에 요청을 보내고, 이에 대한 응답을 분석함으로써 애플리케이션의 처리 능력을 평가한다.
👉 GUI 모드와 CLI 모드 모두 지원하여, 테스트 케이스를 쉽게 작성하고 관리할 수 있다.
❗ GUI 모드로 작성 시에 화면이 멈추거나 테스트 중 다운되는 등 오류 사례가 많이 발견되고 있다. 필자는 그러지 않았는데 아마 과도한 트래픽을 넣은 것이 아니라서 그런듯하다. 빡센 부하테스트를 하게 된다면 CLI 모드로 할 것을 추천한다.
🔷 Jmeter 핵심 기능
1. 다양한 프로토콜 지원
- HTTP, HTTPS, FTP 등 다양한 프로토콜을 통한 요청 시뮬레이션
2. 스레드 그룹
- 가상 사용자를 생성하여 동시에 서버에 요청을 보내는 스레드 그룹을 구성할 수 있다.
3. 리스너
- 테스트 결과를 그래프, 테이블, 트리 등 다양한 형태로 시각화한다.
4. 컨트롤러
- 조건부 로직 실행, 루프 등을 통해 테스트 흐름을 제어한다.
5. 스크립팅
JSR223지원을 통해Groovy,JavaScript등으로 사용자 정의 스크립트를 작성할 수 있다.
📌 Why Jmeter?
1. 성능 병목 발견
- 서비스의 다양한 부분에서 성능 병목 현상을 식별할 수 있었으며, 이를 해결함으로써 전반적인 응답 시간을 개선했다.
2. 스케일링 계획
- 시스템이 사용자의 요청을 얼마나 잘 처리할 수 있는지 평가하여, 인프라의 스케일링 계획을 수립하는 데 도움을 받았다.
3. 부하 테스트
- 가상 사용자를 생성하여 실제 사용량보다 많은 요청을 서버에 보내보고, 최대 사용량을 예측할 수 있었다.
- 프로젝트에 Redis를 적용시켜야 하는 결정적인 근거가 되어주었다.
4. 오픈 소스 및 무료
- 다른 비슷한 도구인
LoadRunner같은 경우는 유료인데 Jmeter는 무료로 제공한다.
5. 사용 용이성
- 사용자 친화적인 GUI를 제공하여 테스트 케이스를 쉽게 생성, 편집, 실행할 수 있었다.
6. 커뮤니티 및 문서 지원
- 강력한 오픈 소스 커뮤니티를 바탕으로 자료를 통해 쉽게 학습할 수 있으며, 문제 발생 시 커뮤니티에서 도움을 받을 수 있었다.
📌 Jmeter로 부하 테스트하기
1. Jmeter를 다운로드 받는다.
- 공식 사이트(다운로드) 링크
JAVA기반이기 때문에JAVA가 반드시 존재해야한다.- 필자는 직접 압축 파일을 다운받았다.
🖥 다운 받은 모습
bin폴더로 이동해 jmeter를 실행한다.
💡 Request나 Response Data에 한글이 있으면 깨진다.
실행 파일 아래쪽의jmeter.properties에서 주석처리된 default encoding을 찾아 UTF-8 주석을 해제하면 해결된다.
버전에 따라 다른 것으로 설정되어 있을 수도 있는데, 이때는 기존의 default encoding을 지우거나 주석처리하고 아래의 구문을 추가한다.
2. 다양한 리스너를 제공받기 위해 플러그인 매니저를 설치한다.
- 플러그인 매니저 다운로드 링크
- 다운받은 플러그인 매니저는
.jar형식으로 들어오는데, 이를lib/ext위치에 넣는다.
- 잘 추가되었다면 Jmeter GUI > Options 하단에
Plugin Manager가 추가되었을 것이다.
💡 Options의 언어 선택을 보면 놀랍게도 한국어가 있다. 필요하다면 설정을 한국어로 바꾸자. 이 글에서는 영어를 기준으로 진행한다.
3. 새로운 리스너를 추가한다.
- Plugin Manager > Available Plugins > 3 basic graphs를 찾아서 체크 >
Apply changes and restart jmeter클릭
💡 필자는 TPS Graph(추후에 설명)을 위해 받았는데, 유용하다 생각되는 리스너가 있다면 더 추가해도 무방하다.
❗ plugin을 설치하면 jmeter가 재시작되기 때문에 하던 작업이 있다면 미리 저장해두어야 한다.
4. 테스트의 스레드 그룹을 생성한다.
- Test Plan > Add > Threads(Users) > Thread Group
-
Number of Threads (users): 스레드수(유저 수) -
Ramp-up period (seconds): 지정된 유저가 모두 로딩될 시간 -
Loop Count: 반복 횟수 -
여기선 각 사용자가 30번의 루프를 돌면서 500명 사용자에 의해 총 15000회의 요청이 이루어질 것이다.
5. 스레드 그룹 내에서 Sampler 생성
- 프로젝트 Backend api 테스트를 위해서는 HTTP 요청을 해야한다.
- Thread Group > add > Sampler > HTTP Request
- 프로토콜(디폴트가 http), 서버 IP, 포트를 입력한다.
- Request 방식과 나머지 경로를 입력하고 매개 변수가 필요하다면 설정해둔다.
💡 Post 요청 시에는 HTTP Header 설정 및 Body Data 설정이 추가로 필요하다.
6. 스레드 그룹 내에서 Listener 생성
- jmeter에서 리스너는 테스트 플랜, 스레드 그룹 등 단위별 생성이 가능하다.
- 유용한 3가지만 생성하여 사용해본다.
1) View Results Tree
- 각 요청마다 Request와 Response를 확인할 수 있다.
2) Summary Report
라벨: 각 테스트 시나리오의 이름표본 수: 총 실행된 요청의 수. 모든 요청에 대해 15000이라는 숫자가 나타나는데, 이는 각 사용자가 30번의 루프를 돌았기 때문에 500명 사용자에 의해 총 15000회의 요청이 이루어진 것을 의미한다.평균: 요청이 처리되는 데 걸린 평균 시간(밀리초)중앙값: 모든 요청의 응답 시간을 중간값으로 나타낸다. 이는 평균보다 이상치의 영향을 덜 받는 지표.최소/최대: 테스트 중 응답 시간의 최소값과 최대값(밀리초)오류 %: 요청이 실패한 비율. 모든 요청이 성공했다면 0%가 된다.처리량: 초당 처리된 요청 수. 이 지표는 서버의 처리량을 나타낸다.수신 KB/초: 초당 서버로부터 수신된 데이터의 양(KB)전송 KB/초: 초당 클라이언트로부터 전송된 데이터의 양(KB)
3) TPS(Transactions per Second) Graph
TPS수치를 그래프로 볼 수 있다.
💡 TPS
서버가 초당 처리할 수 있는 요청의 개수, 높을 수록 초당 처리할 수 있는 요청의 수가 많다고 할 수 있다.
7. 사용해보자!
🖥 상권 Infra 그래프 api 100명이 30번 루프(3000번 호출)
- 요청처리까지 평균적으로 0.6초 정도 걸린다.
- 처리량은 평균적으로 1초에 157kb를 기록중이다.
- TPS 자체가 적은 편이라 그런지 그래프가 상당히 들쭉날쭉해보인다.
8. Redis를 붙인다면 어떻게 달라질까?
- 요청 처리 시간의 평균이 0.03초로 약 20배의 성능 개선을 보인다.
- 처리량은 1초 당 평균 2458kb로 약 15.6배의 성능 개선을 보인다.
- 전체적인 TPS도 상당히 많이 늘어났고, 세 api가 함께 안정적인 그래프를 그린다.
이를 통해 Redis 적용 시 유의미한 성능 개선을 얻을 수 있음을 알 수 있다.
마치며...
JMeter는 현재 프로젝트처럼 빅데이터 분석을 통한 상권 분석 및 추천 서비스와 같은 데이터 중심의 애플리케이션 개발에 있어 필수적인 도구이다.
성능을 정기적으로 측정하고 최적화함으로써,사용자에게 더 나은 서비스를 제공하는 것을 목표로 한다. JMeter를 통해 우리는 기술적 한계를 넘어서고, 사용자 기대를 초과하는 서비스를 제공할 수 있는 기반을 마련할 수 있다.
한 가지 개선할 점이라면, 이번에는 단순히 Redis 적용의 근거를 밝히기 위해 로컬에서 사용하였는데, 이를 CI/CD 파이프라인 안에 테스트로 통합한다면, 지속적으로 품질 유지를 보장할 수 있을 것이다. 이를 고려해보아야겠다.
