트래픽이 적은 상황이라 모니터링 시스템으로 서버의 실시간 지표를 확인하는 의미가 크게 없었음
만약 사용자가 늘어 트래픽이 증가하게 된다면 “서버가 안정적으로 트래픽을 처리할 수 있는지”, “어느 수준에서 성능 저하가 발생하는지”가 궁금해짐
1-3. 테스트 진행 방법
Apache의 JMeter를 통해 테스트하고자 하는 API에 짧은 시간동안 많은 요청을 발생시켜 서버의 처리 능력 측정
1-3-1. Apache JMeter 란 ?
Apache JMeter
오픈 소스 기반의 부하 테스트 도구
주요 특징
GUI 기반으로 테스트 플랜 작성 가능
CLI 모드로 테스트 자동화 가능
다양한 Listener(리포트)를 통한 시각적인 결과 확인
커스터마이징 용이하며 다양한 플러그인 제공
경량 테스트 도구로 별도 서버 설치 없이 로컬에서 실행 가능
2. JMeter 활용 부하 테스트
2-1. JMeter 설치
터미널에 아래 명령어 입력
brew search jmeter
brew install jmeter
2-2. JMeter 실행 (GUI)
GUI로 실행할 것 (사용자 설정이 있다면 설치 위치가 다를 수 있음)
# GUI 실행
open /usr/local/opt/jmeter/libexec/bin/jmeter
# CLI 실행
jmeter
2-3. 테스트 플랜 구성 및 테스트 진행
2-3-1. Thread Group 추가
Test Plan 우클릭 > Add > Threads(Users) > Thread Group
Thread Properties 설정
Number of Threads (users) : 동시에 실행될 가상 사용자(스레드) 수 ex) 10,000으로 설정 ⇒ 10,000 명의 사용자가 동시에 서버에 요청 보내는 상황 시뮬레이션 함
Ramp-up period (seconds) : 모든 스레드를 몇 초 동안 순차적으로 실행할 지 (0 설정 : 모든 스레드가 동시에 시작함) ex) 10초로 설정 ⇒ 10,000개의 스레드가 10초 동안 순차적으로 실행됨 / 값이 작을수록 부하가 급격하게 증가
Loop Count : 각 스레드가 요청을 몇 번 반복할 지 ex) 5로 설정 ⇒ 각 스레드가 요청을 5번 반복함
2-3-2. HTTP Request 추가
Thread Group 우클릭 > Add > Sampler > Http Request
HTTP Request 작성
Server Name or IP : 테스트할 서버 주소
Port Number : 포트번호
HTTP Request : HTTP Method와 테스트할 API의 URI
Timeout 설정 (선택)
Advanced 탭 > Timeout
Connect (Connect Timeout) : 클라이언트 (JMeter)가 서버에 TCP 연결을 맺을 때까지 기다리는 최대 시간 (ms 단위) ⇒ 설정 시간을 초과하면 “Connection Timeout” 에러 발생함
Response (Response Timeout) : 서버에 요청을 보내고 응답을 모두 받을 때까지 기다리는 최대 시간 (ms 단위) ⇒ 서버 연결은 되어 있지만, 응답까지 시간이 오래걸리면 “Response Timeout” 에러 발생함
2-3-3. View Results Tree + Aggregate Graph 추가
View Results Tree 추가
Thread Group 우클릭 > Add > Listener > View Results Tree
⇒ 개별 요청에 대한 상세 결과 (성공 여부, 응답 시간, 응답 내용, 오류 메시지 등)를 확인 가능
Aggregate Graph 추가
Thread Group 우클릭 > Add > Listener > Aggregate Graph
⇒ 전체 테스트 결과를 집계하여 그래프 형태로 시각화, 테스트 종료 후 주요 성능 지표 확인에 활용 가능
✏️ Aggregate Graph 주요 항목
- Samples : 총 요청 수 (스레드 수 * loop 수 등) - Average : 요청 1건 당 평균 응답 시간 (ms) - Min : 요청 중 가장 빠른 응답 시간 - Max : 요청 중 가장 느린 응답 시간 - Throughput : 초당 처리 요청 수 (Requests per Second, RPS) ⇒ 서버 처리 성능을 나타내는 중요한 지표임 Error % : 오류 발생 비율 ⇒ 높다면 서버 또는 테스트 설정에 문제가 있을 가능성이 높음 - Received KB/sec : 초당 수신한 데이터 양 - Sent KB/sec : 초당 전송한 데이터 양
2-3-4. Plugin 설치 (선택)
우측 상단 Plugins Manager 클릭
Available Plugins 탭 > 3 Basic Graphs > Apply Changes and Restart JMeter
⇒ Response Times Over Time, Transactions per Second, Active Threads Over Time의 3개 그래프를 확인 가능
3. Grafana 연동한 모니터링 결과 분석
3-1. 테스트 시 관찰할 메트릭 선정
CPU 사용률
Memory 사용률
Request 처리 속도 (Throughput)
에러율 (Error %)
응답 시간 (Latency / Response Time)
⇒ 서비스 성능과 안정성 확인에 핵심적인 지표라고 생각해서 선정함
3-2. 테스트 진행 + Grafana 대시보드 관찰
3-2-1. 테스트 진행
JMeter에서 설정한 부하 시나리오 실행 (현 상황 : Thread 1,000 / Ramp-up 1초 / Loop 3회)
Aggregate Graph 통해 기본 응답 시간 및 에러율 확인
3-2-2. Grafana 관찰 항목 분석
CPU 사용률
System CPU Usage (전체 시스템 CPU 사용률) : 약 13.7% 사용
Process CPU Usage (Spring Boot 프로세스 자체가 사용한 CPU 사용률) : 약 12.7% 사용
⇒ CPU 사용률이 100%에 가까울 수록 병목 가능성 높음 현재는 13% 수준이므로 CPU에는 여유가 있음을 확인 가능
Memory 사용률
Heap Used (JVM 힙 영역 사용률) : 43.0% ⇒ 일반적으로 Heap 사용률이 70~80% 이상에서 GC가 자주 발생하면서 성능에 영향을 줄 가능성이 커짐 현재는 43%이므로 안정적임
Non-Heap Used (JVM 힙 외 영역 (Metaspace, Code Cache 등) 사용률) : 11.3% ⇒ 현재 11.3% 수준이므로 여유로움
Throughput
Requests per second (RPS, 서버가 초당 처리하는 요청 수) : 3.82 ⇒ 서버 리소스 (CPU, Memory) 등에는 여유가 있지만 처리 수는 낮음 (요청량이 작아서 그런 것 같긴 함, 스레드 수를 늘려서 확인 필요)
에러율 (Error %)
4xx (클라이언트 에러) : 0 ops/s ⇒ 클라이언트 오류 발생 x
2xx (성공) : 54.7 ops/s ⇒ 초 당 약 54.7 건의 정상 응답 (성공) 발생 테스트 설정이 정상적이고, 서버가 요청을 안정적으로 처리하고 있음을 확인 가능
응답 시간 (Latency / Response Time)
Average (평균 응답 대기 시간) : 2.29 ms ⇒ 평균적으로 거의 즉시 응답하는 모습을 확인 가능
Maximum (가장 긴 응답 대기 시간) : 11.8ms ⇒ 최악의 경우에도 11.8ms 내에 응답을 하므로 괜찮은 결과라고 판단 가능 (일반적으로 평균 latency가 수십ms라면 사용자 체감 성능에 문제 없다고 평가됨)
