성능 테스트의 중요성과 목적 그리고 효과

📌 글 작성

성장에 관심이 많은 F-Lab 백앤드 멘토 Elkein
스타트업 여럿과 NHN, 넷마블, 크래프톤 등을 거쳤으며
게임 산업, 클라우드 플랫폼 개발, 웹 개발 등을 두루 경험한 19년 차 엔지니어

개요

우리의 기대와 별개로 대다수의 서비스는 폭발적인 트래픽 증가를 겪는 경우가 드물다. 서비스 트래픽이 폭발할 때, 예정된 광고나 이벤트 등을 통한 유입이 이루어진다면 다행이겠지만 의외로 많은 서비스는 예상하지 못한 타이밍에 예상하지 못한 상황에 트래픽이 폭발한다. 굳이 트래픽 폭발이 아니더라도 서비스의 트래픽이 성장세에 있을 때 이 서비스에 얼마만큼의 자원 할당이 필요한지 알고 있는가? 그저 자원 소모율이 높아질 때마다 서버를 한대씩 추가하면 되는 걸까?

그렇게 할 수도 있겠지만, 어디까지나 임기응변에 가깝다. 또한 서버 비용은 무료가 아니기에 비용적 비효율을 감당해야 하기도 하다. 가장 큰 문제는 자원 소모의 효율과 쓰루풋은 항상 비례하진 않는다는 점이다.

성능 테스트 툴 소개

jmeter

• Apache JMeter - Apache JMeter™
• Apache JMeter란 무엇인가? (+ 사용 방법 with 성능 및 부하 테스트) (tistory.com)

ngrinder

• nGrinder (naver.github.io)
• nGrinder 성능테스트 사용법 및 테스트 예제 (tistory.com)

grafana k6

• Load testing for engineering teams | Grafana k6
• Spring Boot로 K6 & Grafana를 활용한 부하테스트 해보기 (velog.io)

성능 테스트 툴 추천

이외에도 Gatling이나, AB (Apache HTTP server benchmarking tool), Artillery.io | Cloud-scale Load Testing 등 다양한 방법이 많지만 위에 별도로 추천한 3개의 툴 중 grafana k6를 추천한다. 좋은 사용성과 자바 스크립트 기반의 스크립팅을 통한 테스트 환경 구축, HTTP, WebSocket, gRPC 등 다양한 프로토콜 지원, 플러그인을 통한 확장 등 다양한 장점이 있어 추천한다.

프로파일러

자 성능 테스트 툴은 frontend의 API 호출과 그 결과를 검증한다. 우리의 목적은 성능 테스트 툴을 통해서 서버의 성능을 검증하기 위함이다. 이를 확인하기 위해선 어떤 툴을 써야 하는가?

• VisualVM: Home
• scouter-project/scouter: Scouter is an open source APM (Application Performance Management) tool. (github.com)

주요 모니터링 도구의 장단점 비교

VisualVM의 장점

1. 다양한 플러그인
   • VisualVM은 풍부한 플러그인 생태계를 가지고 있어 다양한 기능과 확장성을 제공한다.
   • 이를 통해 특정 애플리케이션 또는 환경에 맞게 도구를 커스터마이징할 수 있다.
2. GUI 인터페이스
   • VisualVM은 사용하기 쉽고 직관적인 그래픽 사용자 인터페이스(GUI)를 제공하여 프로파일링 데이터를 시각적으로 표현하고 분석할 수 있다.
3. 다양한 분석 도구
   • VisualVM은 CPU 사용량, 메모리 사용량, 스레드 분석, 가비지 컬렉션 등 다양한 분석 도구를 제공하여 애플리케이션의 성능 문제를 식별하고 해결하는 데 도움을 준다.

VisualVM의 단점

1. 원격 모니터링 제한
   • VisualVM은 원격 서버의 애플리케이션을 모니터링할 수 있지만, 애플리케이션을 프로파일링하기 위해 원격 서버에 별도의 에이전트를 설치해야 한다.
   • 이는 일부 환경에서 추가 구성이 필요할 수 있다.
2. 큰 규모의 애플리케이션에 제한적
   • VisualVM은 큰 규모의 애플리케이션에 대한 성능 모니터링 및 분석에 제한이 있을 수 있다.
   • VisualVM이 수집하고 분석할 수 있는 데이터의 양과 프로파일링 작업의 오버헤드와 관련이 있다.

Scouter의 장점

1. 분산 시스템 지원
   • Scouter는 분산 시스템에서의 모니터링을 강력하게 지원한다.
   • 여러 대의 서버에 설치된 Scouter 에이전트는 중앙 집중식 서버로부터 모니터링 및 분석 데이터를 수집하고 보고한다.
2. 실시간 모니터링
   • Scouter는 실시간으로 애플리케이션의 상태를 모니터링할 수 있다.
   • 이를 통해 실시간으로 성능 이슈를 감지하고 조치할 수 있다.
3. 다양한 지표 제공
   • Scouter는 CPU 사용량, 메모리 사용량, 데이터베이스 성능, 네트워크 지연 시간 등 다양한 지표를 수집하고 제공한다.

Scouter의 단점

1. 플러그인 생태계 제한
   • VisualVM에 비해 Scouter의 플러그인 생태계는 상대적으로 제한적이다.
   • 추가적인 기능 확장이 필요한 경우 개발자가 직접 구현해야 할 수도 있다.
2. GUI 인터페이스 한정
   • Scouter는 주로 웹 기반의 GUI 인터페이스를 제공한다.
   • 이는 사용자에게 친숙한 환경이지만, 일부 개발자들은 클라이언트 애플리케이션을 선호할 수 있다.

봐야할 지표

1. CPU 사용량
   • 서버의 CPU 사용량은 서버가 현재 처리 중인 작업의 양을 나타내며, 과도한 CPU 사용량은 서버의 성능 저하나 부하를 야기할 수 있다.
2. 메모리 사용량
   • 서버의 메모리 사용량은 현재 서버에서 사용되고 있는 메모리의 양을 나타낸다.
   • 메모리 사용량이 높으면 서버의 성능에 영향을 줄 수 있으므로 주의해야 한다.
3. 네트워크 트래픽
   • 웹 서버의 네트워크 트래픽은 서버로 들어오는 요청과 서버에서 나가는 응답의 양을 나타낸다.
   • 트래픽이 많은 경우 서버 부하와 성능 저하를 초래할 수 있으므로 추적하고 관리해야 한다.
4. 스레드 상태
   • 서버의 스레드 상태를 모니터링하여 현재 활성 스레드 수, 대기 중인 스레드 수 등을 확인할 수 있다.
   • 스레드 풀이 너무 작거나 너무 크면 서버의 성능에 영향을 줄 수 있으므로 적절한 조정이 필요하다.
5. 디스크 사용량
   • 서버의 디스크 사용량은 서버에 저장된 데이터 및 로그 파일의 양을 나타낸다.
   • 디스크 사용량이 너무 높으면 서버 성능에 영향을 줄 수 있으므로 디스크 상태를 확인하고 필요한 경우 정리해야 한다.
6. 요청 처리 시간
   • 서버에서 처리되는 요청의 평균 처리 시간이나 각 요청의 처리 시간을 확인하여 서버의 응답성을 평가할 수 있다.
   • 처리 시간이 긴 요청을 식별하여 성능 개선을 위해 분석할 수 있다.
7. 데이터베이스 상태
   • 웹 애플리케이션이 데이터베이스를 사용하는 경우, 데이터베이스의 연결 상태, 실행 중인 쿼리 수, 쿼리 응답 시간 등을 모니터링하여 데이터베이스의 성능과 가용성을 확인할 수 있다.

주의 사항

1. 같은 머신에서 테스트를 하면 지표가 오염된다.
   • 별도의 머신을 구비해서 테스트를 하는 것을 권장한다.
   • Docker나 VM을 이용할 경우에도 호스트 머신의 자원을 나눠 쓰는 것이기에 영향을 주기 좋다.
   • 실제 서비스가 호스트 머신의 자원을 공유하는 Docker나 VM 형태로 이뤄진다 하더라도, 성능 테스트 지표는 별개의 머신에서 추출하는 것이 좋다.
   • 그래야 온전히 해당 서비스에서 사용되는 지표를 확보할 수 있어서 이를 바탕으로 판단과 대처 방안을 마련하기 좋다.
2. 지표를 분석할 때, 내가 작성한 어플리케이션이 어떠한 자원을 많이 사용하는 것이 정상인지 비정상인지 이해해야 한다.
   • 예를 들어 톰캣 기반의 스프링 부트 서버라면, 스레드 갯수가 많고, 스레드 컨텍스트 스위칭이 많으며, 대기 중인 스레드가 많은 것이 정상적이다.
   • 하지만 넌 블러킹 기반의 서버라면, 이러한 상황 자체가 비효율을 내고 있는 설정일 수 있다. 이 경우 액티브 스레드 개수를 줄이고 컨텍스트 스위칭 비용을 줄인다면 성능 개선을 할 수 있다는 판단으로 이어져야 한다.
   • 즉 지표를 분석하는 능력과 연관 관계에 대한 판단, 그리고 대처에 대한 이해도를 높여야 한다.
3. 지표를 통해 서비스의 베이스 라인을 만들어야 한다.
   • 어떠한 값 이내일 때 정상적인 상황인지, 어떠한 값을 넘어서면 비정상으로 감지해야 하는지 알기 위한 용도로 사용해야 한다.
   • 또한 응답 시간 등의 지연이 발생하기 시작했을 때의 차이점들도 비교하면 좋다. 예를 들어 최근에 추가한 코드가 트랜잭션에 대한 대기가 늘어났거나, 혹은 블러킹 함수 호출 코드가 추가됐거나 같은 실수 혹은 기술적 선택의 사이드 이펙트 때문인지 혹은 트래픽이 전반적으로 많아졌거나 같은 일반적인 상황인지를 판별해 내기 위해서도 수치화된 지표를 활용해야 한다.

마치며

성능 테스트를 통해서 실제 사용자가 몰렸을 때의 트래픽과 유사한 트래픽을 재현해낼 수 있다. 만약 실제 master 데이터 베이스를 백업해올 수 있고, 사용자의 주요 액션에 대해서 통계나 이벤트를 레코딩 해두었다면 이를 재생하는 방식으로도 성능 테스트를 재현 해낼 수 있다. 이를 바탕으로 미리 예상되는 트래픽이 감당 되는지, 자원 할당은 얼마나 해야 하는지, 또는 악의적 공격에 대한 대처 혹은 안정적인 서비스 제공을 위한 보완재를 마련할 수 있는지 등을 판단할 근거를 마련할 수 있다.

또한 성능 테스트는 컴퓨터 과학과 아주 많은 부분에 접점이 있는데, 컴퓨터 과학에 대한 이해가 부족하다면 친해질 계기, 이미 잘 안다면 활용하고 시너지를 내서 좀 더 원인과 해결책을 잘 마련할 수 있는 성장 계기가 될 수 있다.

부디 성능 테스트를 통해서 열심히 만든 프로덕트의 안정성 확보를 하면 좋겠고, 토이 프로젝트라면 실제 사용자 트래픽을 미리 예측하고, 시뮬레이션 하는 용도로 활용하길 바란다.