어느 한 서버개발자....

우리 서버 짱짱임 500명? 1000명? 다 버틸 수 있음!! (EC2 t2.micro)
.
.
.

엄... 그만 알아보자

들어가며

성능 테스트라는 말을 들으면 뭔가 마음 한편에서 강한 울림과 함께 막막함이 같이 몰려오곤 하죠 솔찍히 말하면

"어디서부터 시작해야 할지, 어떻게 해야 할지 모르겠습니다."
++ 한번도 안해봤다고!!!

그래서 간단하게 성능테스트 도구 소개와 방법을 알려드리도록 하겠습니다.

테스트, 그게 뭐길래?

테스트란 서비스에서 문제를 찾아내는 사전 탐사 작전입니다.
미리 잡아야 실제 상황에서 빵! 하고 터지지 않으니까요.

예를 들면?

단위 테스트: "이 메소드 제대로 돌아가?"

통합 테스트: "여러 메소드랑 외부 시스템까지 엮으면 뭐가 꼬이는 거 없겠지?"

성능 테스트: "와우, 사람들이 몰려오면 우리 서비스 감당할 수 있을까?"

그럼, 트래픽?

트래픽은 1초 동안 서버로 요청이 들어오는 수를 말합니다.
"1초에 몇 건?"을 기준으로 흔히 RPS(Requests Per Second)라는 단위를 씁니다.

트래픽이 많다는 건 뭘까?

"1000RPS면 많아?"라고 물으면... 그때그때 달라요.

내 서비스가 평소 받는 최대 트래픽이 기준이 됩니다.

👉 내 서비스가 평소 50RPS만 받아도 200RPS는 많아진 거죠!

'문제'란 뭘까?

서비스의 목표는 사용자를 만족시키는 것.
그렇다면 사용자가 짜증나게 만드는 건 전부 문제입니다.

예시 1: 서비스가 느리다

"아니, 결제 버튼 눌렀는데 아직도 로딩 중이야? 😡"
사용자: “그냥 다른 데서 산다.”

예시 2: 서버 터짐

"에러 500? 내 돈은 어디 갔냐고!! 🤬"
사용자: “다시는 여기 안 와.”

예시 3: 알 수 없는 버그

"앗, 로그인 버튼 눌렀더니 홈으로 튕김? 이게 뭐야? 🤯"
사용자: “이 서비스 왜 이래?”

등이 될 수가 있죠

정리하자면

성능 테스트란?

"1초당 요청이 가장 많은 상황을 기준으로 서비스의 성능과 가용성 문제를 찾아내는 것"
입니다.

한 마디로, "위험요소를 사전에 찾아내는 서비스의 안전장치!" 이죠

성능 테스트 툴

성능 테스트를 진행하는 도구는 JMeter, nGrinder, K6, Postman 등 많은 도구가 있습니다.

처음알았는데 어느순간 Postman에서도 테스트를 할 수 있더라고요 (2024.09년 업뎃 이후)

제가 이전에 쓰던 K6와 Postman 두가지를 소개하겠습니다.

K6

K6는 자바스크립트로 성능 테스트 코드를 작성해야합니다 또한 Grafana 와 InnoDB 연동으로 테스트 시각화가 간편하죠

(도커 컴포즈 띄우기만 하면 끝~)

다운로드 방법은 이 글 참조 바랍니다.

먼저 테스트 스크립트를 작성해야겠죠?

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

export const options = {
  stages: [
    { duration: '10s', target: 10 }, // 10초 동안 가상 사용자를 10명으로 증가
    { duration: '20s', target: 10 }, // 10명의 가상 사용자 유지
    { duration: '10s', target: 0 },  // 가상 사용자 수를 0으로 감소
  ],
};

export default function () {
  const url = 'https://your-api-endpoint.com/api/test';
  const payload = JSON.stringify({ key: 'value' });

  const params = {
    headers: {
      'Content-Type': 'application/json',
    },
  };

  const res = http.post(url, payload, params);

  // 응답 코드 확인
  check(res, {
    'is status 200': (r) => r.status === 200,
  });

  // 짧은 대기
  sleep(1);
}

요런 스크립트는 지피티 시키면 잘 도와줘요

대충 본인 서버 API 형식에 맞도록 스크립트를 작성해줘야 합니다.
그리고 실행을 하면 CLI 를 통해 결과를 볼 수 있고 Grafana 대쉬보드 구성을 해뒀다면

이런 결과도 볼 수 있습니다.

간단하게 설명하자면

첫줄부터 가상 유저 수, 초당 요청수, 초당 오류수, (위 사진에서 스크립트에 check 함수 사용안해서 데이터가 없지만) 초당 check 수

두번째 줄은 순서대로 평균, 최고, 중위, 최저, 90%는 이 안에 들어왔다, 95%는 이 안에 들어왔다.

로 알아주심 되겠습니다.

Postman

포스트맨에서 새로 생긴 기능인 API Test 기능입니다.
다양한 테스트를 지원하고 포스트맨으로 간편하게 테스트를 할 수 있습니다.

무료 플랜에서 최대 25회의 성능 테스트 실행을 매월 무료로 제공합니다! 더 많은 사용량을 위해 유료 플랜으로 업그레이드할 수 있습니다. 다양한 플랜에 대한 자세한 내용은 여기를 참조하세요 .

라고 포스트맨에서 안내하고 있어요 (관련글)

그럼 포스트맨으로도 테스트를 진행해볼까요?

저같은 경우엔 포스트맨의 폴더를 만들어 API 들을 저장하고 관리하는데요 폴더 상세보기를 클릭하면

Run folder 가 보이실겁니다. 그거 클릭하면 테스트 할 수 있는 화면으로 전환됩니다

이렇게 폴더 하위에 포함된 API를 테스트 할 수 있으며 어떤식으로 동작하냐면

기존 포스트맨에 정의해둔 요청을 바탕으로 테스트도 진행됩니다.

간편하게 테스트를 해볼 수 있죠

부하 테스트 외에도 실행예약, CLI 요청 자동화 등등이 가능합니다.

저희는 부하테스트를 진행해볼게요.

Performance 부분으로 넘어가서 테스트 환경을 설정할 수 있습니다.

Load profile은 다양한 부하 패턴을 설정할 수 있는데요

각 부하 테스트의 주요 활용 사례로는
스파이크 : 이벤트성 트래픽(광고 캠페인, DDoS 공격)에 대한 서버의 내구성 평가.
피크 : 대규모 접속이 예상되는 특정 시간대(예: 쇼핑몰의 세일 이벤트)에서 서버의 처리 성능 확인.
램프업 : 신규 사용자 증가 시 서버가 부하를 처리하는 속도와 안정성 평가.
픽스드 : 지속적인 사용(예: 정기적인 업무 시간)에서 서버의 성능과 안정성 평가.

로 본인이 적용하고 싶은 패턴을 선택한 뒤

Virtual users 가상유저 인원을 선택 한 후 Test duration 몇분동안 지속할껀지 작성 후 아래 Run 버튼을 통해 테스트를 진행해볼 수 있습니다.

저는 10분으로 설정하고 돌렸다가 1분이 지난 뒤 멈췄습니다.
(저희 머신은 Oracle V1 VM.Standard.A1.Flex 3c 18g 를 사용중입니다.)

아래 보시면 총 844번의 요청 초당 13.87개의 요청을 날렸고 평균적으로 427ms 최저는 361 최고는 1518ms 가 걸린걸 확인할 수 있습니다. 이렇게 요청값을 파악하고 느린 이유가 뭔지, 개선할 수 있는 방법이 뭔지 고민해볼 수 있죠.

여러가지 문제를 도출하고 실제 지표를 활용해 의사결정을 할 수 있는 단계로 오신겁니다.

인프라적 관점으로 API 성능을 개선시킨 사례

지표가 있으니 캐싱이라던가, 쿼리 최적화 등을 통해 성능을 개선하면 수치화를 할 수 있겠죠??

글을 마치며

현재는 요청이 똑같은 Body 값으로 요청을 하는데 이 값을 포스트맨에 데이터셋을 올릴 수 있는 방법이 있다고 하더라고요 이를 통해 더욱 다양한 API 테스트가 가능할 것이라 생각합니다.

기존 K6를 애용하던 저도 이젠 간단한 테스트는 포스트맨으로 해야겠다는 생각이 들었고 이렇게 점점 다양한 테스트 툴이 생기다보면 언젠간 AI가 자동으로 부하테스트도 해주는 날이 오지 않을까요??

긴 글 읽어주셔서 감사합니다.

여담으로
아직 포스트맨 테스트가 정식 출시가 아닌거 같은게 테스트 클릭하면 이렇게 겁나 많은 창이 열리더라고요.. ㅎㅋㅋㅋ 순간 식겁;;