이번 포스팅은 얼마전 진행했던 부하테스트에 관한 이야기를 하고자 합니다.
들어가기에 앞서 실제 부하 테스트 경험이 전무한 상태로 진행하여 놓치거나 실수한 부분이 굉장히 많았습니다.
테스트 환경
- CentOS 7
- Apache
- Apache Tomcat
테스트 Tool & Utility
- Apache JMeter : 부하 발생기
- BlazeMeter (Chrome Extenstion) - JMeter Thread Group 시나리오 간편 녹화 기능
- Elasticsearch, Logstash, Kibana - Apache access log 실시간 모니터링 용도
- Prometheus, Grafana - 시스템 리소스 사용량 모니터링 용도
- Node Exporter, JMX Exporter, MySQL Exporter, Apache Exporter
목표
- CPU/Memory 사용률 80% 미만
- 응답속도 3초 미만
부하테스트 1차
초기에 계획한 부하 발생 프로세스
상세 시나리오
- 내용 설명
위 이미지는 Thread Group에서 동시 접속자 설정에 대한 내용을 시각화 한것입니다.
최대 1000명의 동시 접속자를 Limit으로 지정하고 1분 간격으로 접속자를 50명 씩 늘리고 1000명이 도달하였을때 3분의 시간동안 서서히 빠지도록 설정을 했습니다.
부하테스트 결과
결론부터 말하자면 부하가 제대로 발생되지 않았습니다.
위 이미지는 Apache access log를 Elasticsearch에 들이부어 각 요청에 대한 Bar chart를 그린것입니다.
차트에서 이상한 점은 우선 API 요청, Header 요청, Main Page 요청에 대한 그래프의 양상이 비슷한 모양을 나타내어야 한다.
또한 동시 접속자가 점점 증가하는듯한 우상향 형태의 차트가 아닙니다.
문제의 원인
원인의 추측으로는 부하 발생 측 네트워크 대역폭, 부하 발생 PC Spec 이 낮음, 부하 받는 측 네트워크 대역폭 등을 두고 원인을 파악해보았는데 아마 부하 발생기 (사무실 Desktop PC)의 Spec 문제인것 같습니다.
부하 발생 시 CPU 사용량이 주기적으로 100%에 도달하고 메모리 사용률도 높은것이 원인이 되어 부하 발생 자체가 제대로 이루어지지 않았던것 같습니다.
1차 부하테스트 결론
없음.
애초에 부하가 제대로 가해지지 않아 무의미한 부하 테스트가 되었습니다.
부하테스트 2차
개선한 부하 발생 프로세스
우선 기존에 비교하여 Spec 이 비교적 뛰어난 Remote 서버를 활용하여 부하를 발생시키도록 구성했습니다.
해당 구성 중 기존과 구조가 다름으로 인하여 셋팅 중 발생한 문제가 있었습니다.
- JMeter Client와 JMeter Server간의 통신이 RMI 기반으로 이루어지는데 Google Cloud VM Instance에서 Public/Internal IP 관련한 통신 문제로 인해 부하 신호가 제대로 전달되지 않아 Google Cloud에 L2TP VPN Server를 구성하여 가상으로 네트워크를 묶어 부하 신호를 주도록 처리했습니다.
2차 부하테스트 진행 시나리오
이번 부하테스트는 Step 1, Step 2로 나뉘어 했습니다.
부하 발생 서버 용도로 셋팅한 두개의 JMeter Remote Agent를 이용하여 동시 사용자 수를 100명부터 최대 500명까지 100명 단위로 증가하도록 부하를 발생시켰습니다.
Step 1에서 이전에 부하가 제대로 발생되지 않은 점을 고려하여 포커스를 부하가 제대로 발생되는지에 대한 테스트를 진행 했고 결과적으로 부하가 잘 발생되었습니다.
Step 2에서는 Step 1의 결과를 바탕으로 WEB, WAS, Database 의 Thread, Process, Connection 등의 성능 수치 설정을 튜닝한 후 진행했습니다.
2차 부하테스트 결과
- Elasticsearch - Apache access log 차트
- Google Cloud VM - CPU 사용률
- Google Cloud VM - Network 전송 트래픽
- WEB, WAS 설정 튜닝
- Apache의 경우 mpm 관련 설정인 StartServers, MinSpareThreads, MaxSpareThreads, ThreadsPerChild, MaxRequestWorkers, ServerLimit, MaxConnectionsPerChild, ThreadLimit 등의 설정을 조정.
- Tomcat도 마찬가지로 maxThreads, max/minSpareThreads 수치를 조정.
2차 부하테스트 결론
Step 1 : 부하는 이전과 다르게 정상적으로 발생되었지만 서버의 설정 문제 및 서버의 처리 한계로 인하여 특정 수치에 도달한 후 처리량이 증가하지 않는 모습을 확인했다.
Step 2 : 시나리오에서 설정한 동시 접속자 최대 수가 증가함에 따라 서버 설정 튜닝 후 정상적으로 요청 처리량이 우상향 형태의 모습을 보이는것을 확인했다.
이번 부하 테스트를 경험으로 다음에 부하 테스트를 하게 된다면 더욱더 성공적으로 마무리 할 수 있길 ..
댓글