귀하의 응용 프로그램은 10명의 사용자와 완벽하게 작동합니다. 만개로 판매일에는 어떻게 되나요? 부하 테스트와 스트레스 테스트는 이에 답하는 두 가지 다른 방법을 설명하며, 이를 혼합하면 테스트가 수행한다고 생각하는 것을 증명하지 못하는 테스트로 이어집니다.

이 가이드에서는 각 테스트가 표시하는 내용, 관련 테스트 유형 및 결과를 읽는 방법에 대해 설명합니다. Python 3.13에서 시뮬레이션된 숫자를 사용하여 아래의 작은 백분위수 계산을 실행했습니다. k6 스크립트는 우리가 실행하지 않은 예시적인 예이며, 사용자 수와 대상은 고안되었으므로 자신의 것으로 교체하십시오. 과도한 트래픽은 공격처럼 보일 수 있으며 실제 중단을 초래할 수 있으므로 소유하고 있거나 테스트 권한이 있는 시스템에 대해서만 이러한 테스트를 실행하십시오.

짧은 대답

부하 테스트는 다음과 같이 묻습니다. 예상되는 트래픽을 처리하고 이를 수행하는 동안 목표를 달성할 수 있습니까? 스트레스 테스트에서는 실패하기 전에 얼마나 걸릴 수 있는지, 어떻게 실패하는지, 얼마나 빨리 회복할 수 있는지 묻습니다.

다리를 생각해 보세요. 부하 테스트는 예상되는 수의 트럭을 운전하고 그것이 괜찮은지 확인합니다. 스트레스 테스트는 한계를 학습하고 경고를 먼저 제공하는지 여부를 알아보기 위해 계속해서 가중치를 추가합니다. 다행스럽게도 소프트웨어는 브릿지보다 깨는 비용이 더 저렴합니다.

부하 테스트와 스트레스 테스트를 나란히 비교

부하 테스트란 무엇입니까?

부하 테스트는 예상되는 실제 트래픽을 시뮬레이션하고 시스템 작동 방식을 측정합니다. 예를 들어 “동시 사용자가 500명인 경우 결제 요청의 95%가 800ms 이내에 완료되고 오류는 1% 미만입니다.”와 같은 테스트 대상이 필요합니다.

k6 스크립트처럼 보이는 방법은 다음과 같습니다. k6 테스트는 JavaScript로 작성되었으며 thresholds 대상을 합격 또는 실패 결과로 바꿉니다.

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

export const options = {
  stages: [
    { duration: "5m", target: 500 },   // ramp up
    { duration: "20m", target: 500 },  // hold at expected peak
    { duration: "2m", target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ["p(95)<800"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/products");
  sleep(1);   // think time, as real users pause
}

sleep이 중요합니다. 생각할 시간이 없으면 각 가상 사용자는 지속적으로 서버를 공격하여 동일한 수의 실제 사용자보다 훨씬 더 많은 트래픽을 생성합니다.

스트레스 테스트란 무엇입니까?

스트레스 테스트는 의도적으로 예상 수준을 뛰어 넘습니다. 당신은 통과하려고하지 않습니다. 다음과 같은 질문에 대한 답변을 원합니다.

• 어느 수준부터 성능이 저하되기 시작합니까?
• 데이터베이스, 애플리케이션 서버 또는 제3자 호출 중 어떤 구성 요소가 먼저 실패합니까?
• 명확한 오류로 인해 정상적으로 실패합니까, 아니면 충돌하여 데이터가 손실됩니까?
• 트래픽이 떨어지면 자동으로 복구됩니까?

export const options = {
  stages: [
    { duration: "5m", target: 500 },    // expected peak
    { duration: "5m", target: 1000 },   // beyond it
    { duration: "5m", target: 2000 },   // further
    { duration: "5m", target: 4000 },   // likely to break
    { duration: "10m", target: 0 },     // recovery: does it come back?
  ],
};

마지막 회복 단계는 종종 잊혀지며, 이는 가장 가치 있는 단계일 수도 있습니다. 오류를 잘 처리하지만 수동으로 다시 시작하지 않으면 복구되지 않는 시스템은 여전히 ​​누군가가 한밤중에 문제를 해결해야 하는 중단을 의미합니다. 이상적으로는 과부하가 심한 경우 시스템은 제어된 방식으로 작업을 중단하고 시간 초과 대신 명확한 503개 응답을 반환해야 합니다.

스파이크, 담그기 및 기타 유형

부하 및 스트레스 테스트는 더 광범위한 성능 테스트 제품군에 속합니다.

Soak 테스트는 짧은 테스트에서는 결코 볼 수 없는 문제를 포착합니다. 작은 메모리 누수는 20분 동안은 무해해 보일 수 있으며, 이틀 후에야 서비스가 중단될 수 있습니다. 스파이크 테스트는 트래픽이 점진적으로 증가하지 않는 반짝 세일과 같은 이벤트에 적합합니다.

중요한 측정항목

평균이 오해를 불러일으키는 이유

평균은 실제 사람들이 불평하는 느린 요청을 숨깁니다. 이를 보여주기 위해 95개는 빠르고(80~200ms) 5개는 매우 느렸으며(2.5~4초) 100개의 시뮬레이션된 응답 시간을 생성한 후 공통 통계를 계산했습니다.

import math, random, statistics

random.seed(3)
times = [random.randint(80, 200) for _ in range(95)] \
      + [random.randint(2500, 4000) for _ in range(5)]

def pct(values, p):
    values = sorted(values)
    return values[math.ceil(p / 100 * len(values)) - 1]

print("avg", round(statistics.mean(times)), "p50", pct(times, 50),
      "p95", pct(times, 95), "p99", pct(times, 99), "max", max(times))

# avg 302 p50 150 p95 199 p99 3740 max 3896

그 숫자들을 자세히 보세요. 평균 302ms는 아무도 설명하지 않습니다. 일반적인 요청은 약 150ms가 소요되는 반면, 느린 요청은 3초 이상 걸렸습니다. p95도 199ms에서는 건강해 보이고 p99에서만 문제가 드러납니다. p95와 같은 수치는 요청의 95%가 이 정도 빠르거나 더 빨랐다는 것을 의미합니다.

그리고 요청의 1%도 드문 일이 아닙니다. 페이지에서 50개의 요청을 수행하는 경우 느린 p99는 페이지 조회수의 상당 부분에 영향을 미칩니다. 자신에게 중요한 백분위수에 대한 목표를 설정하고 여러 가지를 함께 살펴보세요.

도구

이들 중 하나는 부하 테스트와 스트레스 테스트를 모두 실행할 수 있습니다. 기능 목록을 쫓기보다는 팀의 기술에 맞는 것을 선택하세요. 파이프라인에서 이를 사용하려면 CI/CD란 무엇입니까를 참조하세요.

테스트 계획 방법

1. 목표를 설정하세요. 실제 분석을 사용하여 최대 트래픽을 찾고 목표를 정의하세요.
2. 여정을 선택하세요. 찾아보기, 검색, 결제 등 현실적인 사용자 행동을 현실적인 비율로 모델링합니다. 홈페이지만 방문하는 것은 거의 증명되지 않습니다.
3. 현실적인 환경을 사용하십시오. 작은 스테이징 서버는 생산을 예측할 수 없습니다. 차이점을 참고하세요.
4. 데이터를 준비합니다. 100개 행에서 빠른 쿼리가 1,000만 행을 크롤링할 수 있으므로 현실적인 볼륨을 사용합니다.
5. 사람들에게 경고합니다. 운영 팀과 제3자에게 알리고 실수로 결제 서비스 제공업체에 대한 로드 테스트를 하지 마십시오. 적절한 경우 외부 서비스를 모의합니다.
6. 작게 시작하세요. 먼저 작은 연기 테스트를 실행하여 스크립트가 작동하는지 확인하세요.
7. 모든 것을 모니터링하세요.서버 측정항목이 없으면 다음과 같이 표시됩니다.그속도가 느려졌지만 그렇지는 않았습니다왜.
8. 반복합니다. 각 수정 후에 다시 실행하고 비교할 기준을 유지합니다.

결과 읽기

데이터베이스는 일반적인 병목 현상이므로 쿼리가 문제인 경우 SQL 쿼리 최적화 가이드를 읽어보세요. 테이블의 마지막 행은 중요한 함정입니다. 로드를 생성하는 머신의 상태도 항상 확인하세요.

일반적인 실수

• 요청으로 사용자를 혼란스럽게 합니다. 대상이 동시 사용자를 의미하는지 아니면 초당 요청을 의미하는지 명확하게 확인하세요.
• 생각 시간을 생략합니다. 이는 트래픽을 부풀리고 오해의 소지가 있는 결과를 제공합니다.
• 테스트가 너무 늦었습니다. 출시 일주일 전에는 아키텍처 문제를 해결할 시간이 없습니다.
• 단일 엔드포인트를 사용합니다. 실제 트래픽에는 읽기, 쓰기, 검색이 혼합되어 있습니다.
• 캐싱은 모든 것을 숨깁니다. 동일한 반복 요청은 캐시만 테스트할 수 있으므로 데이터를 다양하게 변경하세요.
• 한 번 테스트합니다. 릴리스마다 성능이 변경되므로 정기적으로 테스트를 실행하세요.

마무리

로드 테스트를 실행하여 예상한 트래픽을 처리할 수 있는지 확인하고, 스트레스 테스트를 실행하여 처리할 수 없는 경우 어떤 일이 발생하는지 알아보세요. 작게 시작하세요. 가장 중요한 사용자 여정을 선택하고, 하나의 명확한 목표를 설정하고, 모니터링을 활성화한 상태에서 스테이징에 대해 간단한 테스트를 실행하세요. 첫 번째 실행은 일반적으로 무언가를 가르쳐주고 거기서부터 구축할 수 있습니다.

자주 묻는 질문

계속 학습하세요