Load testing(부하 테스트)란?
부하 테스트는 Application, API 또는 Web 등 시스템에 시뮬레이션된 워크로드를 적용하여 시스템 성능의 성능을 확인하는 소프트웨어 테스트의 한 종류이다.
부하 테스트를 수행하며 시스템 속도 저하, 충돌이나 트래픽 증가에 의한 오류에 대비
부하테스트의 목표
- 정상 사용량과 최대 사용량에 어떻게 반응하는지 (유저 수, 트랜잭션, 데이터 양 등)
- 테스트 결과를 Metric과 시각화하고 상호 연관시켜 시스템 성능에 대한 전체적인 개요 파악
부하 테스트의 vs 성능 테스트(performance test)
부하 테스트와 성능 테스트는 서로 연관되어 있지만 서로 다른 유형의 테스트입니다.
앞서 설명한 대로 부하 테스트는 사용자 활동을 시뮬레이션하여 시스템이 트래픽 또는 부하 증가를 얼마나 잘 처리할 수 있는지 확인합니다.
성능 테스트는 애플리케이션의 전반적인 성능을 측정하는 포괄적인 용어입니다. 여기에는 속도, 확장성, 안정성 및 리소스 사용률에 대한 테스트가 포함되어 개선이 필요한 영역을 파악할 수 있습니다. 성능 테스트에는 부하 테스트뿐만 아니라 브라우저 성능 테스트 및 종합 모니터링과 같은 다른 유형의 테스트도 포함됩니다.
- Smoke test: 적은 부하로 시스템 기능 검증
- Average load test: 트래픽에 타입에 따라 시스템 기능이 어떻게 변하는지 확인
- Stress test: 트래픽이 peak를 찍으면 어떻게 되는지 확인
- Spike test: 갑작스러운 트래픽 증가에 어떻게 기능이 작동하는지 확인
- Breakpoint test: 시스템의 용량 한계를 파악하기 위해 부하를 서서히 증가
- Soak test: 장기간에 걸쳐 시스템의 안정성과 성능을 평가할 수 있습니다.
아래는 트래픽의 양과 테스트 시간에 따른 타입별 비교
현재 테스트에서는 개발한 Application test보다 리소스 사용량과 시스템 안정성 테스트가 목적이기 때문에
Stress, Spike, Breakpoint test를 진행
Test Spec
EKS node : c5.large(2core 4Gi) x 3
Prometheus-sever : (500m 512Mi)
Stress testing
Stress test는 average-load test와 유사하지만 가장 큰 차이점은 더 높은 부하를 주는 것입니다.
일부 테스트 대화에서는 stress test를 rush-hour, surge, 또는 scale tests라고 부르기도 합니다.
Test Code
stress.js
테스트 케이스 별로 stages의 파라미터만 변경
import http from 'k6/http';
import { check, sleep } from 'k6';
export let options = {
stages: [
{ duration: '2m', target: 300 }, // 1분 동안 사용자 수를 300까지 점진적으로 증가
{ duration: '3m', target: 300 }, // 다음 3분 동안 사용자 수를 300으로 유지
{ duration: '2m', target: 0 }, // 마지막 1분 동안 사용자 수를 0으로 줄임
],
};
// prometheus-sever endpoint와 검색 query 작성
const PROMETHEUS_ENDPOINT = 'prometheus-server-svc/api/v1/query';
const PROMETHEUS_QUERY = 'sum by (instance, job) (rate(kubelet_http_requests_total[1h]))'; // 예시 쿼리, 연산이 많이 필요한?
export default function () {
const params = {
headers: {
'Content-Type': 'application/x-www-form-urlencoded',
},
};
const body = `query=${encodeURIComponent(PROMETHEUS_QUERY)}`;
const res = http.post(PROMETHEUS_ENDPOINT, body, params);
check(res, {
'is status 200': (r) => r.status === 200,
'is result not empty': (r) => JSON.parse(r.body).data.result.length > 0,
});
console.log(JSON.stringify(res.body));
sleep(1); // 각 VU 사이의 딜레이, 초 단위
}Test 1
2분간 User 300으로 증가하고 3분 유지 후 2분동안 0명으로 감소
Test 진행과정의 Metric
Test
결과 유저가 300명으로 증가할때
- CPU 사용량과 Network 사용량이 증가 이후 유저가 300명으로 유지되면서 점차 감소
- Memory는 Test가 종료된 이후에도 몇 분 뒤에 사용률이 감소
분석
- CPU는 쿼리의 요청에 영향을 많이 받는 것으로 보임, Request 요청이 쿼리 조회
- Memory는 테스트가 진행된 후에도 사용 지속되는 걸로 보아 메모리 부족으로 대기열 발생한것으로 보임.
Test2
- 2분간 User 1000으로 증가하고 3분 유지 후 2분동안 0명으로 감소
Test 결과
- User 증가를 버티지 못하고 prometheus-server 4번 down (Restart 0-> 4)
- 92%의 트래픽만 통과
Test3
- 2분간 User 700으로 증가하고 3분 유지 후 2분동안 0명으로 감소
Test 결과
- 유저가 상승할땐 버티다가 700유저가 유지될때 down 4번 발생 (Restart 4-> 8 복구시간 30초 정도 소요)
- Query가 total을 출력하는 것이라 테스트가 진행될 수록 트래픽 대비 부하가 증가하는 것으로 보임
- 94% 성공
Spike Testing
Spike testing은 갑작스러운 대규모 트래픽에 시스템이 견디는지 테스트
예시로 티켓팅이나 프로세스 마감일 등에 유사한 이벤트가 발생
Spike Test는 매우 짧은 시간에 매우 높은 트래픽이 증가하기 때문에 예열시간(문서에선 ramp-up이라고 표현)이 존재하지 않거나 매우 짧음 유저 감소 시간(ramp-down)도 마찬가지
Test Code
실행 로직은 stress와 동일
spike.js
export let options = {
stages: [
{ duration: '1m', target: 1000 },
{ duration: '1m', target: 0 },
],
}; Test 1
- 1분간 User 1000으로 증가하고 1분동안 0명으로 감소
Test 결과
- 유저가 1000으로 상승한 후에 1차례 down 발생 (Restart 8->9)
- CPU 사용량 max시에도 500이 되지않는 걸로보아 CPU보단 Memory가 주 원인
- Stress Test와 비교했을때 장기간 지속적인 트래픽이 더 부담을 주는 것으로 보임
Test 2
- 1분간 User 2000으로 증가하고 1분동안 0명으로 감소
Test 결과
- User 2000도달 후에 down 1회 발생
- 마찬가지로 CPU는 limit까지 사용되지 않음
- Memory Spike는 트래픽 발생과 약간의 시간 차이가 있는 것으로 보임
Breakpoint testing
Breakpoint testing은 시스템의 한계를 파악하기 위해 주로 사용
Metric tool을 test하기에 가장 적합한 test라고 생각됨
테스트에서 실패가 일어날때까지 증가하다 Down이 발생하면 바로 중지
Grafana에서도 breakpoint test의 이름은 아직 정의되지 않았다고 함 이와 같은 테스트를 Capacity, point load, limit testing 등으로 부르기도 한다.
Breakpoint testing은 시스템 Resource 측정에 사용되며 테스트 목적에 가장 부합
이후의 테스트는 Breakpoint testing으로 진행할 예정
Test Code
실행 로직은 stress와 동일
breakpoint는 ramp-up이나 ramp-down, 유지의 개념없이 유저수 우상향하며 테스트
Resource 한계지점을 찾기 적합
중간에 pod down시 중지하기 때문에 duration과 taget을 매우 높게 설정
breakpoint.js
export const options = {
// Key configurations for breakpoint in this section
executor: 'ramping-arrival-rate', //Assure load increase if the system slows
stages: [
{ duration: '2h', target: 20000 }, // just slowly ramp-up to a HUGE load
],
};Test 1
Test 결과
- 유저수 650에 down 발생
- cpu는 최대 450까지 사용
- Network는 앞선 두 테스트보다 부하가 증가
Test2
동일 조건에서 한번더 Test
Test 결과
- 1차 시도와 동일한 지점에서 실패 발생
- Query duration이 상승하며 CPU 500m 사용됨
Test3
- Prometheus 리소스를 1Core, 1Gi memory로 진행
Test 결과
- 기존 500m 512Mi와 같은 곳에서 down -> vus:650
- 아래는 1.5core, 1536Mi로 진행하였지만 동일한 부분에서 down
Test4
- Statefulset으로 500m 512Mi pod replicas 3개로 구성
Test 결과
- vus=1500에서 server-0 down
- 30초 뒤에 vus=1600에서 server-1 down
- 12초 뒤에 server-2 down
- 3개의 pod라 1개가 down되어도 나머지 2개가 유지되고 있어 트래픽 누수가 상대적으로 적음
- 하지만 부하가 나머지 2개에 집중되며 같은 트래픽일때 down 시간이 점점 짧아짐
총 정리
- Cpu, Memory등의 리소스를 책정하기엔 breakpoint test가 테스트하기 좋지만 Metric tool은 장시간 많은 트래픽을 받는 서비스이기 때문에 Stress Test도 함께 진행하는 것이 좋아 보인다.
- 이번 테스트에서는 Stress Test의 duration이 너무 짧아 Spike와 유사한 구조가 되어서 좀 더 시간을 길게 가지고 재시도 예정
- Prometheus는 500m 512Mi로 설치 시 단일 파드의 트래픽 한계
- 1~3분 3~4만
- 3~5분 6~7만
- Prometheus는 Resource를 Scale up하는 것보다 Scale out 하는것이 안정성 면이나 성능면에서 유리하다.
- 같은 1.5Core, 1536Mi 리소스에서 트래픽 한계점
- 단일 pod : 트래픽 7만, vus=약 650
- replicas=3 : 트래픽 44만 vus=약 1700
- 같은 1.5Core, 1536Mi 리소스에서 트래픽 한계점
- 진행한 테스트는 Pormetheus에 Query를 요청하는 것이므로 실제 리소스보다 더 많은 부하를 줄 수 있다고 생각하며 Grafana Dash Borad를 생각하며 진행한 test 였지만 테스트 목적이 Prometheus를 down 시키는 것이다보니 더 많은 요청이 진행되었음
- 다음 테스트로는 application을 endpoint로 진행하거나 다른 Metric tool로 진행 예정 (thanos, Mimir 등)