[실습] 내가 구성한 인프라는 1초당 몇 개의 요청을 견뎌낼 수 있을까?

JSCODE 박재성

2025-12-06

✅ 부하 테스트 할 인프라 구성

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

1. 프로덕션 환경과 비슷하게 구성하기 위해 더미 데이터 넣기
DB는 데이터가 얼마나 들어있느냐에 따라 성능 차이가 많이 난다. 따라서 정확한 부하 테스트를 하기 위해서는 프로덕션 환경의 DB에 들어있는 데이터와 비슷하게 구성하는 것이 좋다. 기존 프로덕션 환경에 100만개의 게시글 데이터가 들어있다고 가정하자.

-- 높은 재귀(반복) 횟수를 허용하도록 설정
-- (아래에서 생성할 더미 데이터의 개수와 맞춰서 작성하면 된다.)
SET SESSION cte_max_recursion_depth = 1000000;

-- 더미 데이터 삽입 쿼리
INSERT INTO boards (content, title, created_at)
WITH RECURSIVE cte (n) AS
(
  SELECT 1
  UNION ALL
  SELECT n + 1 FROM cte WHERE n < 1000000 -- 생성하고 싶은 더미 데이터의 개수
)
SELECT
    CONCAT('Content', LPAD(n, 7, '0')), -- 'Content' 다음에 7자리 숫자로 구성된 이름 생성
    CONCAT('Title', LPAD(n, 7, '0')), -- 'Title' 다음에 7자리 숫자로 구성된 이름 생성
    TIMESTAMP(DATE_SUB(NOW(), INTERVAL FLOOR(RAND() * 3650) DAY) + INTERVAL FLOOR(RAND() * 86400) SECOND) AS created_at -- 최근 10년 내의 임의의 날짜와 시간 생성
FROM cte;

-- 잘 생성됐는 지 확인
SELECT COUNT(*) FROM boards;

 

2. 부하를 주기 위해 k6 스크립트 작성

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



 

실제 프로덕션 환경에서 발생하는 트래픽과 최대한 비슷하게 부하를 만들어서 테스트 해야한다. 실제 서비스에서 100명의 사용자 중 95명이 게시글 조회(GET /boards)를 하고, 5명이 게시글 작성(POST /boards)을 한다고 가정하자. 실제 프로덕션 환경과 유사하게 트래픽을 만들어낼 수 있게 k6 코드를 작성해보자.

script.js

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

export const options = {
  // 부하를 생성하는 단계(stages)를 설정
  stages: [
    // 10분에 걸쳐 vus(virtual users, 가상 유저수)가 50에 도달하도록 설정
    { duration: '10m', target: 50 }
  ],
};

export default function () {
  let random = Math.random();
  // 100명 중 5명의 비율로 게시글을 작성
  if (random < 0.05) {
    const data = { title: '제목', content: '내용' };
    http.post('http://{ELB 주소}/boards', JSON.stringify(data), {
      headers: { 'Content-Type': 'application/json' },
    });
    
  // 100명 중 95명의 비율로 게시글을 조회
  } else {
    http.get('http://{ELB 주소}/boards');
  }
  
  // 1초 휴식
  sleep(1);
}

 

2. 부하 테스트 시작하기

$ K6_WEB_DASHBOARD=true k6 run script.js

 

4. k6의 웹 대시보드 열기
http://{k6가 실행되고 있는 EC2 IP 주소}:5665으로 접속하기



 

✅ 부하테스트 결과 해석

1. VUs가 늘어나도 HTTP Request Rate가 더 이상 증가하지 않는 구간을 찾는다.
더 이상 증가하지 않는 HTTP Request Rate가 현재 시스템의 최대 Throughput이다. 초당 3개 정도의 요청을 처리하고 있다. 즉, 현재 시스템은 1초당 3개의 요청을 처리할 수 있다는 뜻이다. 이걸 보고 ‘현재 시스템의 최대 Throughput은 3 TPS’라고 표현한다.



 

2. HTTP Request Duration이 비이상적으로 높은 건 아닌지 체크한다.
요청 당 응답 시간이(Latency)이 최대 TPS를 넘은 이후로부터 점점 응답 시간이 길어지는 걸 확인할 수 있다. 하지만 최대 TPS에 도달하기 전에는 1초 미만의 Latency인 걸로 봐서 크게 문제가 없는 걸로 판단된다.



참고) VUs가 높아짐에 따라 서버가 처리할 수 있는 요청량이 밀려서 대기하는 시간이 늘어나기 때문에, HTTP Request Rate(= Throughput)는 늘어나지 않는데 Request Duration(Latency)는 늘어나는 현상을 확인할 수 있다.
 

3. HTTP Request Failed가 있는 건 아닌지 체크한다.
만약 실패한 요청이 있다면 요청이 왜 실패했는 지 분석해야 한다.