부하 테스트란 무엇인가

Soyun Park·2025년 3월 20일
0
post-thumbnail

성능 테스트 소개

1. 성능 테스트란

성능테스트는 시스템 구성 요소가 특정 상황에서 어떤 성능을 보이는지 확인하기 위해 수행되는 테스트이다. 제품의 반응 시간, 안정성, 확장성, 리소스 사용량 등을 통해 시스템의 한계와 필요한 리소스를 검증할 수 있다.

성능 테스트는 다음 그림처럼 부하 및 스트레스 테스트 등 모든 것을 포괄하는 상위 개념으로 매우 광범위하다. 성공적인 성능 테스트는 DB, SW, HW, 네트워크 등과 관련될 수 있는 대부분의 성능 문제를 예측해야 한다.

2. 성능 테스트 종류

Load Testing

하루 평균 사용자가 10,000명일 때, 100명 동시 접속 테스트하기!
API 응답속도와 에러율을 분석하자

서버가 정상적인 트래픽에서 얼마나 잘 작동하는지 확인하는 테스트이다. 얼만큼의 트래픽을 처리할 수 있는지, 최대 부하에서도 잘 동작하는지, 응답 시간이 얼마나 걸리는지 등을 확인한다.

응답 시간(Response Time), 초당 처리량(TPS), CPU와 메모리 사용률이 주요 지표로 사용될 수 있다.

Stress Testing

1초당 1000명씩 접속하는 트래픽을 걸어보자
서버가 몇 명까지 견디다가 죽을까?
CPU 사용률이 100%를 찍는 순간이 언제지?

서버가 최대 트래픽을 받을 때, 어디까지 버틸 수 있는지, 과부하가 걸렸을 때 어떻게 대처하는지 확인한다.
예를 들어, 2분 정도에 100개 요청 -> 300개 요청 -> 500개 요청 하는 식으로 천천히 요청 수를 늘리면서 CPU와 메모리 상태를 관찰한다. 또한 요청 수를 0으로 다시 내렸을 때의 리소스 변화도 주목해보자.

Spike Testing

평수에는 10명 접속하는 서버에 갑자기 1,000명이 접속, 10초 후 다시 10명 접속한다면
서버가 급작스러운 트래픽 변화를 감당할 수 있을까?

짧은 시간 동안 트래픽이 폭증할 때, 서버가 버틸 수 있는지 확인하는 테스트이다.
쇼핑몰, 티켓 예매, 이벤트 사이트에서 특히나 중요하다.
CPU와 메모리 급증 여부, 트래픽 급증 후 정상 상태로 돌아오는 속도에 주목하자.

Endurance Testing(Soak Test)

12시간 동안 100명 동시 접속 유지하기
24시간 동안 평균 트래픽 부하를 걸었을 때 성능 저하가 일어날까?

서버가 오랜 시간(시간 단위부터 일 수까지)동안 안정적으로 운영되는지 확인하는 테스트이다. 장기간 동작하면서 발생할 수 있는 메모리 누수, 스레드 누수, 성능 저하 등의 문제를 발견할 수 있다.
메모리 사용량 증가 여부, CPU 과부하 발생 여부, 장시간 실행 후 응답 속도 저하 여부에 대해 분석한다.

Scalability Testing(확장성 테스트)

AWS EC2 Auto Scaling 설정 후, 동시 접숙자 수가 증가했다.
새로운 서버가 자동으로 추가되는지를 확인한다.

서버의 자동확장이 잘 동작하는지 확인하는 테스트이다. 시스템이 처리할 수 있는 최대 부하를 파악하고 용량 증설 및 하드웨어 확장성을 예측한다.
Auto Scaling 반응 속도와 서버 추가 후 응답 속도 개선 여부에 대해 파악한다.

부하 테스트 소개

1. 부하테스트란

부하 테스트란 성능 테스트의 하위 지합으로 임계치 한계에 도달할 때까지 시스템의 부하를 지속적으로 증가시켜 시스템을 테스트 하는 것이다.
부하 테스트에서 모니터링되는 속성에는 최대 성능, 서버 처리량, 다양한 부하 수준(중단 임계 값 미만)에서의 응답 시간, H/W 환경의 적절성, 성능에 영향을 주지 않고 처리할 수 있는 사용자 애플리케이션 수 등이 있다.

2. 클라우드 환경에서의 부하 테스트 목적

  1. 시스템 확장성을 가졌는지 확인!
  2. 성능을 개선하기 위해 확장해야 하는 시스템이 무엇인지 파악
  3. 부하가 많이 발생할 때 문제 상황 개선
  4. 각 시스템의 병목 지점을 예측하고 진단 및 개선

3. 부하가 많이 발생할 때의 문제 요소

  1. 응답 속도Latency 저하
  2. 시스템 잠금 경합
  3. 부하 발생 시 애플리케이션 또는 서버 에러 발생
  4. 데이터 일관성 문제와 손실

4. 병목 지점을 예측하고 진단 및 개선

throughputlatency는 시스템 성능 지표의 주요 메트릭이며 이 두가지 지표를 활용해 평가한다.

처리량(Throughput)

서버 또는 시스템이 일정 시간 동안 처리할 수 있는 요청(트랜잭션) 수를 의미한다. 쉽게 말해, 우리 서버가 초당 몇개의 요청을 처리할 수 있는지를 말한다.

1. TPS(Transactions Per Second)
초당 몇 개의 트랜잭션을 처리할 수 있는지
최대 TPS가 500이라면, 초당 500개의 트랜잭션 처리가 가능
2. RPS(Requests Per Second)
초당 몇 개의 HTTP 요청을 처리할 수 있는지
API 서버의 RPS가 1000이라면, 초당 1000개의 요청 처리가 가능

지연 시간(Latency)

클라이언트가 요청을 보낸 후, 서버가 응답을 받기까지 걸리는 시간을 의미한다. Latency가 중요한 이유는

  • 응답이 느려지면 사용자가 서비스를 이탈한다.
  • 부하 테스트에서 응답 속도를 측정하는 핵심 지표이다.
  • Latency가 높아지면 Throughput도 감소할 가능성이 커진다.

1. 평균 응답 시간
전체 요청의 평균 응답 시간
2. P95, P99(Percentile Latency, 백분위 지연 시간)
요청 중 95%는 300ms이하, 나머지 5%는 500ms 걸린다면 P95=300ms
3. TTFB(Time to First Byte)
서버가 첫 번째 바이트를 응답하기까지 걸리는 시간
4. RTT(Round Trip Time)
패킷이 오고 가는 데 걸리는 시간

5. 좋은 부하 테스트에 대한 지표

테스트 대상 시스템은 부하가 집중되고 있는 상태

여러 하위 시스템으로 구성된 테스트일 때 각각의 하위 시스템에 개별적으로 부하를 주고 조사헤야 한다. 부하 테스트 중 특정 하드웨어 리소스가 과부하 상태가 되는 것이 좋은 부하 테스트이다.

병목 지점을 확인한 상태

시스템에 많은 요청을 보내는 테스트인 경우 일반 적으로 시스템의 어느 한 부분이 과부하 상태가 되어 이 부분으로부터 전헤의 Throughput을 결정하게 된다. 그러므로 항상 병목 구간이 어디인지를 의식하고 확인해야 한다. 병목 구간을 찾기 쉽게 테스트 방법을 준비하면 보다 효율적으로 테스트 할 수 있다.

부하 테스트 도구

1. 부하 테스트에서 사용하는 3가지 도구

부하 테스트 도구

  • 많은 요청을 줘서 시스템에 부하를 준다.

모니터링 도구

  • 시스템 리소스, 예를 들어 CPU, 메모리, 스토리지와 같은 것의 사용률을 가시화해준다.

프로파일링 도구

  • 미들웨어나 springboot, mysql과 같은 애플리케이션 내부 동작을 분석하고 가시화해주는 도구

2. 부하 테스트 도구 선택 기준

조건 1. 요청을 정확하게 시뮬레이션 한다.
Apache Bench를 사용하면 시나리오 기반 테스트가 불가능하다. 따라서 시나리오가 필요한 부하 테스트는 이러한 도구를 사용할 수 없다.

조건 2. 부하 정도를 조정 가능해야 한다.
클라이언트 동시 접속자 수, 요청 간격, 최대 Throughput 등을 조정하여 공격 강도를 조절해야 한다. 이러한 설정은 대부분의 테스트 도구에서 가능하다.

조건 3. 대상 시스템에 충분한 부하를 발생시켜야 한다.
대상 시스템의 성능 지표에 따라 사용할 수 있는 테스트 도구가 달라진다.

조건 4. 부하 테스트 도구, 설치, 장소 및 가동 장소를 선택할 수 있어야 한다.
부하 테스트 도구에 따라 기동할 수 있는 서버에 제약이 있을 수 있기 때문에 부하 테스트 서버를 설치하는 장소 제약이 있을 수 있다.
SaaS 서비스로 원격에 설치된 서버에서 부하를 주는 도구도 있지만 원격에서 부하를 주는 혀애는 대상 시스템에만 부하를 주기에는 어려워서 효율적인 부하 테스트를 하기엔 맞지 않다.

3. Apache JMeter 소개

설치 방법

$ brew search jmeter  // Home brew를 사용

실행

$ jmeter

장점 및 특징

  • 다양한 프로토콜 지원
    • 다양한 프로토콜 지원, 풍부한 사용자 인터페이스, 다양한 테스트 요소, 보고서 및 결과 분석 가능을 가지고 있다.
  • 확장성
    • 실시간 모니터링과 스케일링은 JMeter의 GUI 모드에서는 제한이 있으나, CLI 모드와 플러그인을 통해 일부 스케일링 기능을 확장할 수 있다.
  • 분산 테스트
    • 실제와 비슷하게 분산 부하 테스트 가능하다.
  • 강력한 GUI
    • 사용자 친화적인 GUI로 테스트 계획을 쉽게 작성할 수 있다.
  • 스크립트 지원
    • GUI, CLI(XML로 작성, java로 실행) 모두 지원하여 복잡한 테스트 시나리오를 작성할 수 있다.

단점

  • 고사양 요구
    • 스레드 기반 방식을 사용하여 많은 사용자를 동시에 처리할 때마다 각각의 사용자에 대해 별도의 스레드를 생성해야 하므로, 대규모 테스트 시 상당히 많은 리소스를 소모한다.
    • 고부하 테스트를 위해서는 매우 높은 성능의 서버나 여러 서버를 병렬로 활용해야 한다.
  • 복잡한 설정
    • XML과 Java를 기반으로 하는 스크립트 작성을 해야 한다.
  • 모니터링 한계
    • 전체 시스템의 Throughput, 전체 Latency 등만 모니터링 가능하며, 개별 하위 시스템의 Latency나 리소스 프로파일링이 어렵다.
    • 시스템 내부의 상세한 성능 병목 구간을 분석할 수 없어서, 추가적인 프로파일링 도구의 도움이 필수적이다.

4. k6 소개

설치 방법

$ brew install k6  // Home brew를 사용

테스트 스크립트 작성(예시)

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

export let options = {
  vus: 10,       // 가상 사용자 수
  duration: '30s', // 테스트 지속 시간
};

export default function () {
  http.get('https://test.k6.io');
  sleep(1); // 요청 간 1초 대기
}

실행

$ k6 run test.js

장점 및 특징

  • 경량화
    • Go언어 기반으로 설계되어 JMeter와 같은 스레드 기반 도구에 비해 리소스 소모가 매우 적다.
    • 낮은 리소스로도 높은 부하 테스트가 가능하다.
  • 확장성
    • Cloud를 활용한 분산 테스트(k6 Cloud 서비스)를 통해 확장성이 뛰어나며, 매우 큰 규모의 테스트 수행이 가능하다.
    • Grafana와 같은 모니터링 도구와 쉽게 통합할 수 있다.
  • DevOps 친화적
    • 커맨드라인(CLI) 중심 설계로 Jenkins, GitLab CI, GitHub Actions 등 다양한 CI/CD 환경과 쉽게 통합 가능하다.
  • CLI 도구
    • 별도의 GUI 없이 CLI에서 간단히 실행 가능하며, 결과 요약 및 시각화 도구로 빠르게 분석 가능하다.
    • JSON 형식의 결과 출력을 지원하여 데이터 처리 및 분석의 유연성이 뛰어나다.

단점

  • 제한된 프로토콜 지원
    • 기본적으로 HTTP/HTTPS 프로토콜 중심으로 설계됐다.
    • 다른 프로토콜(FTP, SMTP, JDBC 등) 테스트에는 한계가 있다 (JMeter 대비 프로토콜 지원 다양성이 부족하다.)
  • 러닝 커브
    • JavaScript 언어에 익숙하지 않은 사용자는 진입 장벽을 느낄 수 있다.

0개의 댓글