부하테스트 툴 정하기

김재연·2025년 2월 16일

Jmeter K6 부하테스트

부하테스트를 하게된 계기

저희 회사의 서비스는 B2B입니다.

그렇다보니, B2C에 비해서 성능보다는 저희 회사가 전달하는 가치인 데이터가 정확히 원하는 바대로 전달되는 것이 정말 중요했습니다.

핑계처럼 들릴 수 있겠지만, 그렇기에 현재까지는 부하테스트를 많이 해보지 않았고, 그에 대한 중요성도 많이 인지를 못했던 것 같습니다. (저희 서비스에서)

허나 이번에 꽤나 큰 사이즈의 API 개발을 맡고 진행하게 되었고, 개발을 마무리하고 나니, 아무리 성능이 후순위더라도, 최적화하지 않으면 불편함을 느낄 수준으로 지연시간이 길었습니다.

그래서 해당 API의 최적화에 들어가게 되었고, 그 과정 중에, 실제로 테스트해보지 않는다면 어떤 방식이 더 효과적일지 추론이 어려운 문제에 봉착하게 되었습니다.

이를 판단하기 위해 부하테스트를 진행하게 되었습니다.

발생했던 문제 (꼭 보실 필요 없습니다.)
- 단건 조회로 DB에서 여러 번 데이터를 가져오는 경우와 (Query 여러번)
- 완전히 데이터를 거의 싹 다 불러온 다음에 로직으로 필터링 (Query 한번인데, 쓸데없는 데이터를 가져옴)
  물론 둘의 확연한 차이가 보일정도로 데이터가 엄청 많다거나, 조회 횟수가 엄청 많은 API가 아님

Jmeter vs K6

부하테스트에서 Well-Known 한 툴인 Jmeter, K6 둘 중에 하나를 고민했다.

여기서 가장 먼저 접하게 된 포스트는 다음과 같다.

링크: https://qalified.com/blog/k6-load-testing/

뭔가 편파적인 것 같긴한데

K6의 장점과 Jmeter와 비교 포인트는 다음과 같다고 한다.

K6의 장점

개발자 친화적이다.

JavaScript를 쓰기 때문에, 빨리 배울 수 있고, 유지보수도 뭔가 새로운 언어를 배우지 않고 할 수 있다고 한다.

CI/CD 통합

내가 알아듣기로는 K6 서버를 올려놓고 CI/CD 해서 지속적으로 하나의 애플리케이션처럼 관리하기가 수월하다는 의미로 보인다

모던하다.
오픈소스다.
Go로 설계되어서 처리가 뛰어나다.
Javascript 파일을 실행하기에, Java Heap Memory와 같이 고정적으로 할당해야 할 메모리가 필요가 없다.
사용자 커스텀 시나리오를 적용가능하다. (Lifecycle)

export function setup() {  
// 2. setup code  
}  
  
export default function scenario(data) {  
// 3. Virtual User Scenario code  
}  
  
export function teardown(data) {  
// 4. teardown code  
}

다음과 같이 마치 인수테스트처럼 가능하다. 나한테는 이게 엄청난 장점으로 다가온다.

K6를 선택할 때, 고려사항

또한 고려사항도 있는데

러닝커브가 있다.

당연히 자바스크립트를 모르는 경우, 러닝커브가 존재한다.

Protocol에 제한이 존재한다.

HTTP/1.1, HTTP/2, Websocket을 지원한다고 한다. 우리 회사의 환경에서는 전혀 상관이 없는 문제인 것 같다.

No GUI다

GUI가 존재하지 않는다. 다 CLI다.

어짜피 우리는 CLI를 정말 많이 경험한다. GUI가 좋다하지만, 가끔 나는 CLI가 더 편한 경우가 많다. 심지어 성능테스트 결과 같은 경우는 Grafana를 연동해 시각화 할 수 있다. (With Influx DB)

서로 비교할 부분

사용성 영역

아무래도 CLI로만 해야 한다는 것이, 누군가에게는 엄청난 큰 단점으로 다가올 수 있다. 하지만, 부하테스트는 일단 백엔드에서 주도적으로 할 것 같기 떄문에 따로 걸림돌이 되지는 않는 것 같다.

퍼포먼스 영역

K6 > Jmeter 라고 한다. 아무래도 위에서 언급했던 장점도 한 몫 하는 것 같다.

CI/CD 영역

아무래도 콘솔로 하는 부분이 K6가 더 잘되어있고, 이런 저런 부분으로 인해서 CI/CD 에 더 유리하다고 생각이 된다.

그래서 결국 무엇을?

결과적으로 나는 K6를 선택했다.

내가 정말 마음에 들었던 부분은 다음과 같다.

Custom Scenario

현재 회사에서 테스트 코드를 정말 많이 짜고 있다. 프로젝트를 시작한지 얼마 되지 않았음에도 불구하고 테스트 개수가 1500개를 넘어가고 있으니 말이다.

하지만, 이렇게 테스트가 많다면 하나의 단점이 작용하게 된다.

빠른 검증이 불가능하게 된다.

그렇기 때문에, 우리는 Mockito와 단위테스트를 통해 테스트 속도를 확실하게 향상시켰고, 이를 통해 모든 테스트를 돌리는데 10초 정도밖에 걸리지 않는 결과를 얻어낼 수 있었다.

하지만, 여기서 인수테스트를 진행하지 않는다는 찝찝함이 남아있었는데, 이거를 K6로 진행한다면? 정말 좋을 것 같았다.

그래서, 추후 가능하다면, 우리 서비스에서도 K6를 통해서 유저 시나리오를 작성하고, 이를 기반으로 성능테스틀 해보고 싶다.

출처 : https://medium.com/weolbu/%EC%9B%94%EA%B8%89%EC%9F%81%EC%9D%B4%EB%B6%80%EC%9E%90%EB%93%A4%EC%9D%98-%EB%B6%80%ED%95%98%ED%85%8C%EC%8A%A4%ED%8A%B8%EB%A5%BC-%EC%9C%84%ED%95%9C-k6-%EB%8F%84%EC%9E%85%EA%B8%B0-d7c82e7fe65f

초반에 말했던 B2B 서비스라서 성능은 후순위다라는 말을 떨쳐내고, 성능도 이를 기반으로 더 향상 시켜보고싶다.

결국 내가 하고 싶은 것

그래서 결국 내가 하고 싶은 것은 이거다.

회사에 부하테스트 시스템을 구축해보고싶다.

앞에서 말했던 Custom Scenario, CI/CD에 강력이라는 장점을 살려 부하테스트 서버를 만들고, 이를 API 개발 프로세스에 집어넣어, 더욱이 회사의 서비스를 탄탄하게 만들고 싶다. (Visualize는 Grafana로 하고, Slow Query 알림 같은 것들도 도입하고 etc...)