부하 테스트로 운영 조건의 처리 한계 검증하기

운영 트래픽을 가정해 성능 한계를 확인한다

부하 테스트는 목표 운영 조건에서 시스템이 요구된 처리량, 응답 지연, 오류율을 계속 충족하는지 검증하는 성능 시험이다. 애플리케이션만 보는 절차가 아니다. 캐시와 브로커, 데이터베이스, 네트워크, 스토리지까지 포함한 종단 간 경로에서 SLA/SLO 충족 여부와 용량 한계를 확인한다.

마이크로서비스, 클라우드 오토스케일, 데이터베이스 락처럼 구성 요소가 분산된 환경에서는 특정 지점의 처리량만으로 안정성을 판단하기 어렵다. 목표 처리량과 지연 시간, 오류율을 기준으로 검증해야 용량 계획과 비용 최적화의 근거를 만들 수 있다.

워크로드는 유입 방식에 따라 달라진다

Open 모델은 초당 도착률(RPS)을 고정하거나 변화시키며, 요청이 서로 독립적으로 들어오는 상황을 모델링한다. 인터넷 트래픽에 가깝고 큐 대기와 백프레셔 효과를 관찰하기에 적합하다.

Closed 모델은 고정된 동시 사용자 수(VU)와 생각 시간으로 워크로드를 만든다. 단말 시뮬레이션에는 유용하지만, 큐잉이나 붕괴 시점을 보는 데 한계가 있다. 실무에서는 두 모델을 섞어 적용할 수 있다.

품질 기준은 처리량(RPS), 지연 시간(p50/p95/p99), 오류율(HTTP 5xx/타임아웃), CPU·메모리·GC·IO 사용률, 큐 길이, 스레드·커넥션 풀 포화도로 구성한다. 예를 들어 p95 < 200ms, 오류율 < 0.1%, 스로틀링/리트라이율 제한, GC STW < 50ms, DB 대기 시간 < 20%처럼 조직의 SLO에 연결한 품질 게이트를 둘 수 있다.

부하 검증은 요구사항에서 출발해 워크로드 모델링, 데이터 준비, 환경 동등성 확보, 부하 주입, 관측·분석, 튜닝, 재검증으로 반복된다. 이 과정에서는 RED/USE 메트릭, 샘플링·구조화 로그, 분산 추적, 플레임그래프를 함께 보며 A/B 비교와 회귀 탐지를 자동화한다.

⤢✕

시나리오와 환경이 결과의 신뢰도를 좌우한다

트래픽 믹스에는 엔드포인트별 비율, 요청 크기, 페이로드 다양성, 생각 시간, 리트라이, 타임아웃을 반영한다. 캐시 적중률과 데이터 지역성도 워크로드에 포함한다. 프로파일은 램프업·안정 구간·램프다운으로 구성할 수 있으며, 스파이크, 소크(롱런), 계단형 증가도 목적에 맞춰 사용한다. 영업 이벤트와 크론 배치가 겹치는 상황도 고려 대상이다.

테스트 데이터는 시딩하고 고유 ID를 제공하며, 캐시 워밍과 콜드 스타트를 구분한다. 멱등성과 테어다운 절차를 갖춰야 결과를 반복 검증할 수 있다. DB·큐·스토리지 상태를 고립하고, 개인정보와 토큰 같은 보안 데이터에는 마스킹과 시크릿 관리를 적용한다.

환경은 인스턴스 타입, 오토스케일 파라미터, 네트워크, WAF, 레이트리밋을 포함해 Prod와 유사하게 구성한다. 기능 플래그, 캐시, 서드파티 샌드박스의 동등성도 확인한다. 다른 배치나 테스트와의 자원 경쟁을 분리하고, 인바운드 제한과 서드파티 사용 동의·요금도 사전에 점검한다.

분석 시에는 RED(요청율, 오류율, 지연)와 USE(자원 사용/포화/에러)를 같이 관측하고 퍼센타일과 히스테리시스를 고려한다. CPU 바운드, 스레드·커넥션 풀 포화, DB 락·컨텐션, GC·메모리 누수, 디스크·네트워크 IO가 대표적인 병목이다. 샘플링 프로파일과 트레이스로 핫패스를 식별한다.

CI에는 스모크 부하, 회귀 부하, 주간 소크를 연결하고 결과와 기준선을 보관한다. 임계값 위반 시 실패 처리와 알림·티켓 발행을 자동화할 수 있으며, 테스트 샤딩과 클라우드 부하 발생기는 비용과 시간을 줄이는 수단이 된다.

시험 목적에 따라 보는 지표가 달라진다

유형	성능(처리량/지연)	확장성(스케일링)	일관성(재현성)	안정성(장시간)	운영 편의
부하 테스트	높음: 목표 운영 범위 검증	중간: 임계 전까지	높음: 시나리오 고정	중간: 안정 구간 중심	높음: CI 연계 용이
스트레스 테스트	중간: 붕괴점 탐색 중심	높음: 한계/오토스케일	중간: 외란 가중	중간: 단기 피크	중간: 위험 관리 필요
스파이크 테스트	중간: 버스트 응답	중간: 급격 증가 대응	중간: 케이스별 변동	낮음: 단기	높음: 간단 구성
소크 테스트	중간: 열화 관찰	낮음: 스케일 변화 제한	높음: 장시간 평균	높음: 누수/드리프트 탐지	낮음: 장시간 비용
용량 테스트	높음: 최대 처리량 산정	높음: 병렬 확장 곡선	중간: 변화 요인 존재	중간: 임계 근접	중간: 리소스 요구 큼

서비스 경계별로 부하 조건을 설계한다

전자상거래 이벤트에서는 목록 조회 60%, 상세 25%, 결제 10%, 기타 5%로 시나리오를 구성하고 RPS 3배 스파이크 뒤 30분 소크를 수행할 수 있다. 목표는 p95 < 250ms, 오류율 < 0.2%, 결제 트랜잭션 성공률 99.8%이며, 캐시와 결제 게이트웨이의 레이트리밋을 사전에 합의한다.

금융 API에서는 토큰 발급, 잔액 조회, 이체 요청을 연결한 체인을 Open 모델로 1k→5k RPS까지 계단 증가시킨다. 인증 서버와 코어뱅킹의 커넥션 풀 포화 지점, DB 락 대기 시간을 측정하고 회로 차단기 임계를 재설정한다.

큐 컨슈머 환경은 메시지 생산 속도를 높이며 컨슈머 오토스케일 정책을 조정하고, 가시성 타임아웃과 재처리율을 관측한다. 처리 지연과 DLQ 비율 < 0.1%, 평균 체류 시간 SLA 준수가 목표가 된다.

데이터베이스에서는 동일 레코드 업데이트 경합과 인덱스 미스·시퀀스 경합을 재현한다. Read Committed와 Repeatable Read별 대기 그래프, 데드락 빈도, 재시도 정책의 효과를 측정한다.

k6로 Open 모델을 실행하는 예시

k6 v0.46+가 설치되어 있고 테스트 대상 엔드포인트에 접근할 수 있으며 샘플 데이터가 준비되어야 한다. BASE_URL, TOKEN 환경변수를 설정한 뒤 다음 예시를 실행한다.

// k6 v0.46+
// 파일: load-test.js
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  scenarios: {
    steady: {
      executor: 'constant-arrival-rate',
      rate: 200,             // 초당 요청 도착률
      timeUnit: '1s',
      duration: '10m',
      preAllocatedVUs: 50,
      maxVUs: 200,
    },
    spike: {
      executor: 'ramping-arrival-rate',
      startRate: 0,
      timeUnit: '1s',
      stages: [
        { target: 100, duration: '2m' },
        { target: 600, duration: '1m' },
        { target: 200, duration: '2m' },
      ],
      preAllocatedVUs: 50,
      maxVUs: 400,
      startTime: '10m',
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.001'],      // 오류율 < 0.1%
    http_req_duration: ['p(95)<200'],     // p95 < 200ms
  },
};

const BASE = __ENV.BASE_URL || 'https://api.example.com';
const TOKEN = __ENV.TOKEN || '';

export default function () {
  const q = Math.random().toString(36).slice(2, 10); // 캐시 회피용 파라미터
  const res = http.get(`${BASE}/v1/items?size=10&q=${q}`, {
    headers: { Authorization: `Bearer ${TOKEN}` },
    timeout: '3s',
  });
  check(res, {
    'status==200': (r) => r.status === 200,
    'payload<=200KB': (r) => Number(r.headers['Content-Length'] || 0) < 200 * 1024,
  });
}

• BASE_URL=https://api.example.com TOKEN=xxx k6 run -e BASE_URL -e TOKEN load-test.js
• K6_WEB_DASHBOARD=true k6 run load-test.js

용량 기준선과 릴리즈 판단에 남기는 결과

용량 기준선으로 최대 안정 처리량을 기록할 수 있다. 예를 들어 2,400 RPS에서 p95 180ms, 오류율 0.05%를 달성하고, 임계 전 CPU 70%와 DB 대기 12%를 확인한다. 인스턴스 타입과 수를 조정해 월 인프라 비용을 10~25% 절감하고, 캐시 정책을 개선해 DB 쿼리를 30% 줄일 수 있다. 회귀 탐지 리드타임은 시간→분으로 단축되며 장애율과 MTTR 감소로 이어진다.

이벤트와 캠페인에서 예측 불확실성을 줄이고 서드파티 한도를 미리 합의할 수 있다. SLO 기반 의사결정과 관측 가능한 시스템 문화가 자리 잡으며, 개발·운영·보안·비즈니스는 지연, 오류율, 처리량이라는 공통 언어로 협업하게 된다.

작은 스모크 부하에서 시작해 소크와 스트레스 시험으로 범위를 넓히고, DB 락, 풀 포화, 서드파티 한도를 조기에 드러내야 한다. 튜닝과 재검증을 반복해 축적한 용량 기준선은 릴리즈와 운영 판단의 기반이 된다.