k6 부하테스트 실습

송범·2025년 3월 15일

✅ 부하테스트란?
-> 시스템이 어느 정도의 부하(=트래픽, 요청)를 견딜 수 있는 지 테스트하는 것이다.

✅ 부하 테스트를 왜 할까?

-> 백엔드 서버를 구현하고 나서 배포를 한다. 그런데 프로덕션 환경에 서비스를 배포 하기 전에 문득 이런 생각이 들 수 있다.

"혹시 요청이 몰려서 서버가 터지면 어떡하지?"
"내 서버는 어느 정도 사용자 요청을 견딜 수 있는 거지?"

이런 불안감을 없애기 위해서 서비스를 배포하기 전에 백엔드 서버가 어느 정도의 요청을 견딜 수 있는지 부하테스트를 해봐야 한다. 그래야 어느 정도의 트래픽을 감당할 수 있는 지 미리 파악할 수 있다. 이걸 파악할 수 있다는 건 트래픽이 늘어나서 서버가 터질 때쯤 빠르게 대처할 수 있다는 게 장점이다. 즉, 서버가 터져서 죽는 걸 미리 감지하고 대처를 할 수 있다는 뜻이다.

✅ 가장 좋은 사양의 서버를 쓰면 되지 않을까요?

-> 당연히 오버 스펙으로 고사양의 컴퓨터를 서버로 사용하면 수 많은 트래픽을 처리할 수 있을 것이다. 하지만 여기서 문제가 되는 것은 비용이다. 비용을 절약하기 위해 부하테스트를 통해 딱 필요한 만큼의 컴퓨터 사양을 선택하는 게 중요하다.

✅ 처리량(Throughput)이란?

부하 테스트에서 서비스가 1초당 처리할 수 있는 트래픽 양을 보고 Throughput이라고 부른다. 단위는 TPS(Transaction Per Secondes, 1초당 처리한 트랜잭션의 수, 1초당 처리한 요청의 수)를 많이 활용한다. 만약 내가 만든 서비스가 1초에 최대 100개의 API 요청을 처리할 수 있다면, 이 서비스의 Throughput은 100 TPS라고 얘기한다.

현업에서는 '처리량'이라고 잘 얘기하지 않고 'Throughput(쓰루풋)'이라고 많이 얘기하는 편이다
TPS(Transaction Per Seconds) ≠ RPS(Request Per Second)
→ 이 두 가지 단위를 같다고 생각해도 무방하다.

✅ 지연 시간(Latency)이란?

부하 테스트에서의 Latency는 요청에 대한 응답 시간을 의미한다. 만약 내가 만든 서비스에 부하 테스트를 했을 때 평균 응답 시간이 2.5초일 경우, 평균 Latency가 2.5초라고 얘기한다. 조금 더 쉽게 해석하면 하나의 API에 요청을 보냈을 때 응답받기까지의 시간이 2.5초 정도 걸린다는 뜻이다

현업에서는 '지연 시간'이라고 잘 얘기하지 않고 'Latency(레이턴시)'이라고 많이 얘기하는 편이다.

✅ k6란?

부하 테스트(Load Testing) 도구에는 다양한 종류가 있습니다. 대표적으로 nGrinder, JMeter, Apache Bench(ab), Locust 등이 있으며, 그중에서도 메모리를 적게 사용하면서 비교적 많은 요청을 보낼 수 있는 부하 테스트 도구가 k6입니다.

k6의 특징

고성능 & 경량(메모리 절약)

Go 언어 기반으로 작성되어 성능이 뛰어나고 메모리 사용량이 적음
다른 부하 테스트 툴에 비해 더 많은 동시 요청을 보낼 수 있음

코드 기반 스크립트 작성 (JavaScript)

성능 테스트를 JavaScript 코드로 작성 가능
유지보수 및 커스터마이징이 쉬움
CI/CD 파이프라인에 쉽게 통합 가능

HTTP 기반 성능 테스트 최적화

REST API, gRPC, WebSocket, GraphQL 지원
다양한 인증 방식(JWT, OAuth) 적용 가능

실시간 결과 확인 & 다양한 출력 포맷 제공

터미널에서 실시간 부하 테스트 결과 확인 가능
Prometheus, InfluxDB와 연동하여 메트릭 분석 가능

✅ 주의점

부하 테스트 환경 독립적으로 분리

부하 테스트 툴(k6)은 테스트하고자 하는 시스템(백엔드, DB 등)과 반드시 독립적으로 분리해서 구성해야 한다. 왜냐하면 부하 테스트 툴 자체도 트래픽을 만들어내면서 컴퓨팅 리소스(CPU, 메모리 등)를 사용하기 때문이다.

부하 테스트 툴을 개인 컴퓨터에 설치하지 않기

✅ k6를 활용해 부하 테스트 진행하기

백엔드 서버에 부하를 주기 위해 k6 스크립트 작성

구성한 시스템이 1초당 몇 개의 요청을 견딜 수 있는지 알아보려면, 점진적으로 트래픽을 늘려가게끔 부하 테스트를 셋팅해야 한다.

script.js 파일 작성

ubuntu@ip-172-31-38-253:~$ vi script.js

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
        stages: [
                { duration: '10m', target: 6000 }
        ],
};      

export default function () {
        http.get('http://13.209.70.67:6060/api/notice/list');
        sleep(1);
}

script.js 파일이 저장되었는지 확인해줍니다.

ubuntu@ip-172-31-38-253:~$ cat script.js

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
	stages: [
		{ duration: '10m', target: 6000 }
	],
};

export default function () {
	http.get('http://13.209.70.67:6060/api/notice/list');
	sleep(1);
}

K6_WEB_DASHBOARD=true k6 run script.js

VU (virtual users)

1초당 약 159개의 요청을 처리하고 있다.

Request Duration p(95) = 24.6s

요청 응답 시간이 24.6초임을 의미합니다. 즉, 전체 요청 중 95%는 24.6초 이내에 응답을 받았지만, 나머지 5%는 이보다 더 긴 시간이 걸렸을 수 있습니다.

✅ 병목 지점(Bottleneck Point)

병목 지점(Bottleneck Point)

부하 테스트의 전체 흐름

✅ 1. 부하 테스트 필요성 인식

"서비스를 오픈하려고 하는데 사용자들이 몰려서 서버가 터지면 어떡하지?"
"내 서버는 어느 정도 사용자 요청을 견딜 수 있는 거지?"
"개발자님, 이번에 치킨 이벤트를 하려는데 사용작 1만명 정도가 들어와도 서버가 괜찮을까요?"

✅ 2. 부하 테스트 목표 설정하기

부하 테스트 목표는 주로 Throughput과 Latency를 활용해 설정한다

[예시]

목표 Throughput : 2000TPS
→ 서비스 예상 접속자 수, 예상 요청 수 등을 활용해 TPS 목표를 설정합니다.
평균 Latency : 800ms
→ 서비스 특성에 맞게 Latency를 설정합니다.

✅ 3. 현재 시스템이 어느 정도 트래픽까지 견딜 수 있는지 부하 테스트 진행

부하 테스트 툴(k6)을 활용해서 시스템에 부하를 줍니다. 부하의 정도를 올려가면서 어느 정도 부하까지 견딜 수 있는 지를 측정합니다. 즉, 시스템의 최대 Throughput을 측정합니다.

✅ 4. 병목 지점 파악 후 성능 개선하기

목표로 설정한 Throughput, Latency를 달성하기 위해, 기존 시스템의 성능을 개선해야 할 수도 있다. 성능 개선을 하려면 가장 먼저 병목 지점을 파악해서 개선해야 합니다.

부하 테스트 시 주의점

✅ 적절한 부하 테스트 시간

1분 간격으로 기록되는 모니터링 도구를 가지고 정확하게 성능을 측정하려면 최소 5분간의 부하테스트는 진행해야 한다. 그래야 일관된 결과값을 얻을 수 있다.

✅ 프로덕션 환경과 비슷한 데이터 셋팅

데이터베이스는 데이터가 어떻게 저장되어 있는 지와 얼마나 많은 양이 저장되어 있는 지에 따라서 성능 차이가 많이 난다. 따라서 실제 프로덕션 환경과 비슷하게 데이터를 구성해두고 부하 테스트를 진행해야 보다 정확한 결과값을 얻을 수 있다.
프로덕션 환경의 데이터들이 포함된 DB 복제본을 떠서 그 DB로 부하 테스트를 진행하기도 합니다.

✅ 프로덕션과 분리된 환경에서 테스트하기

프로덕션 환경에서 부하 테스트를 하면 안 된다. 왜냐하면 부하 테스트를 함으로써 실제 서비스의 악영향을 끼칠 수 있기 때문에 새로운 환경을 생성하고 테스트를 진행하기를 추천한다.