로드 테스트 및 스트레스
로드 테스트 및 스트레스
1) 왜 필요한가
목표:- 용량 확인 (주어진 SLO에서 시스템이 견딜 수있는 RPS/경쟁 세션 수).
- 병목 현상을 찾으십시오 (CPU/IO/DB/네트워크/잠금/풀).
- CI/CD에 성능 예산 및 게이트를 설정합니다.
- 릴리스 위험을 줄입니다 (p95/p99 회귀, 피크 오류 성장).
- 용량/비용 계획 (스케일 아웃 및 준비금).
2) perf 테스트의 종류
로드: 정점에 가까운 실제 트래픽; SLO 검증.
스트레스: 한계를 초과하는 성장 → 파괴 동작.
스파이크: 빠른 하중 점프 → 탄성/오토 스케일.
흡수/지구력: 시간/일 → 누출, 조각화, 대기 시간 드리프트.
용량/확장 성: 스케일 아웃에 따라 처리량/대기 시간이 어떻게 변하는 지; 암달/구스타프 슨 법.
연기 퍼프: 각 릴리스에서 짧은 "연기" 실행 (성능 존엄성).
3) 트래픽 생성 모델
고정 된 VU/동시성: 'N' 사용자, 각각 클라이언트에서 → 대기열을 요청합니다. 과부하 숨기기의 위험.
도착 속도: 실제 생활에서와 같이 λ강도 (req/s) 를 가진 응용 프로그램의 흐름. 공개 API에 대해 더 정확합니다.
풀/서비스의 경우, 최소 병렬 처리
작은 법칙: 'L = λ× W'.
처리량 인 경우 'W' 는 평균 서비스 시간입니다.
4) 로드 프로파일 및 시나리오
사용자 여행 믹스: 스크립트 공유 (로그인, 탐색, 예금, 체크 아웃...).
생각 시간: 사용자 일시 정지 (분포: 지수/로그 노멀).
데이터 프로파일: 응답 크기, 페이로드, 매개 변수의 변동성.
상관 관계: 실제 흐름에서와 같이 링크 단계 (쿠키/토큰/ID).
차가운/따뜻한/핫 캐시: 개별 실행.
읽기 대 쓰기: 읽기/기록의 균형, 배상에 대한 demotency.
다중 지역: RTT, POP/ASN 별 배포.
5) 테스트 환경
격리: 스탠드는 토폴로지/설정에서 제품에 가깝지만 제품을 "비트" 하지는 않습니다.
데이터: PII 마스킹, 볼륨, 판매 지수.
로드 생성기: CPU/네트워크에 대해 휴식을 취하지 마십시오 분산 러너, 시간 동기화.
관찰 가능성: 메트릭/트레일/로그, 주변의 합성, CPU/힙 프로파일 내보내기.
6) 측정 및 SLI
처리량: RPS/거래/초
대기 시간: p50/p95/p99, TTFB, 서버 시간 대 네트워크.
오류: 5xx/4xx/domain 오류 공유.
포화: CPU, 부하 avg, GC, 디스크 IOps/대기 시간, 네트워크, 풀 대기.
비즈니스 SLI: 보증금 5 초, 주문 확인 2 초.
SLO에서 임계 값을 가져 오십시오 (예: "99. 실행 중 연소율을 모니터링하십시오.
7) 병목 현상 찾기 (기술)
1. 목표 하중의 60-80% 까지 시스템을 일관되게 예열하십시오.
2. p95/p99 및 오류율이 증가하는 단계 (램프) → 수정
3. p99 스파이크와 일치:- 수영장의 대기열 (DB/HTT),
- WAIT/자물쇠 (DB) 의 성장,
- GC- 일시 정지/힙에서
- 네트워크 재송신/패킷 손실,
- 디스크 대기 시간/캐시 누락.
- 4. 현지화: 쿼리 경로, 프로파일 러 (CPU/alloc/lock-profile) 별 이진 검색.
- 5. "병" → 튜닝 → 실행을 반복합니다.
8) 스트레스를받는 행동
우수한 저하: 한계, 회로 차단기, 역압 대기열, 처리에 허용됩니다.
배신자: 최대 1, demmpotent 만; 지터; 리트레이 예산은 RPS의 10% 입니다.
실패/실패: 중요하지 않은 종속성의 경우 실패 (캐시/스터브) 를 허용하십시오.
캐스케이드 실패: 풀/쿼터 (벌크 헤드) 격리, 빠른 타임 아웃, 기능의 "부드러운" 비활성화 (기능 플래그).
9) 도구 (작업 선택)
k6 (자바스크립트, 오픈/오픈 모델, 빠르며 CI에 편리 함).
JMeter (생태계, UI/CLI, 플러그인이 풍부하지만 더 무겁습니다).
개틀링 (Scala DSL, 고성능).
메뚜기 (파이썬, 스크립팅 유연성).
Vegeta/Hey/wrk (마이크로 벤치 및 빠른 점검).
규칙: PR에서 연기 펜을위한 하나의 "주요" 도구 + 가벼운 CLI.
10) 예 (스 니펫)
10. 1k6 (도착 속도로 열린 모델)
js import http from 'k6/http';
import { sleep } from 'k6';
export const options = {
scenarios: {
open_model: {
executor: 'ramping-arrival-rate',
startRate: 200, timeUnit: '1s',
preAllocatedVUs: 200, maxVUs: 2000,
stages: [
{ target: 500, duration: '5m' }, // до 500 rps
{ target: 800, duration: '5m' }, // стресс
{ target: 0, duration: '1m' }
]
}
},
thresholds: {
http_req_duration: ['p(95)<300', 'p(99)<800'],
http_req_failed: ['rate<0.005'],
},
};
export default function () {
const res = http.get(`${__ENV.BASE_URL}/api/catalog?limit=20`);
sleep(Math.random() 2); // think-time
}10. 2 JMeter (프로필 아이디어)
스레드 그룹 + 스테핑 스레드 и동시성 스레드 (공개).
그림% 1개의 캡션을 편집했습니다.
백엔드 리스너 → InfluxDB/Grafana; 시간/코드 별 주장.
10. 3 메뚜기 (파이썬)
python from locust import HttpUser, task, between class WebUser(HttpUser):
wait_time = between(0.2, 2.0)
@task(5)
def browse(self): self.client.get("/api/catalog?limit=20")
@task(1)
def buy(self): self.client.post("/api/checkout", json={"sku":"A1","qty":1})11) 데이터, 상관 관계, 준비
종자 데이터: 판매와 같이 디렉토리, 사용자, 잔액, 토큰.
PII 마스킹/익명화; 실제 분포 위에 합성을 생성합니다.
상관 관계: 응답 (RegExp/JSONPath) 에서 ID/토큰을 추출하고 후속 단계에서 사용하십시오.
12) 달리는 동안 관찰 가능성
경로를 따라 RED 대시 보드 (속도, 오류, 지속 시간).
Exemplars-메트릭에서 트레이스로 전환 (trace _ id).
오류 로그: 샘플링 + 집계, 중복/dedempotence.
시스템: CPU/GC/heap, 디스크/네트워크, 풀 대기.
DB: 최고 쿼리, 잠금 장치, 색인 스캔, 팽만감.
13) 자동화 및 성능 게이트
CI: 합병시 짧은 실행 (예: 임계 값이있는 k6 2-3 분).
야간/주간: 별도의 매체에서 긴 담그기/스트레스; 보고서 및 동향.
카나리아 릴리스: 프로모션의 "게이트" 로서 SLO (오류율, p95) 분석.
회귀: 기준선 대 현재 빌드; 열화시 경고> X%.
14) 용량 계획 및 비용
처리량 → 대기 시간 곡선: 무릎 점을 정의하십시오-p99가 급격히 성장한 후.
스케일 아웃: 측정 스케일링 효율 (RPS 델타/노드 델타).
비용: "시간당 RPS", 피크 이벤트 예약 + DR 예약.
15) 반 패턴
prod가 아닌 "빈" 환경에서 제어하거나 테스트하지 않고 prod를 치십시오.
고정 VU가 과부하를 감추는 폐쇄 모델.
사고 시간/데이터 부족 → 비현실적인 캐시 적중 또는 그 반대도 마찬가지입니다.
사용자 정의 흐름 대신 하나의 "/ping "스크립트.
관찰 부족: "우리는 RPS와 평균 지연 만 볼 수 있습니다".
통제되지 않은 배상 → 자체 DDoS.
가설/변경을 수정하지 않고 테스트 및 최적화를 혼합합니다.
16) 점검표 (0-30 일)
0-7 일
SLI/SLO를 정의하고 트래픽 프로파일을 대상으로합니다 (믹스, 사고 시간, 데이터).
공구 (k6/JMeter/Locust) 를 선택하고 RED 대시 보드를 올립니다.
스탠드 및 시드 데이터를 준비하고 타사 제한/캡차를 비활성화하십시오.
8-20 일
빌드 시나리오: 오픈 모델 (도착률), 콜드/워밍/핫 캐시.
실행 하중 → 응력 → 스파이크; 무릎 점과 병목 현상을 해결하십시오.
CI (마이크로 런) 의 성능 게이트 구현.
21-30 일
흡수 테스트 4-24 시간: GC 누출/드리프트, 안정화.
문서 제한, 용량 계획, "RPS → p95/oshibki" 그림.
"한계/규모를 늘리는 방법" 및 "저하하는 방법" 런북을 준비하십시오.
17) 성숙도 지표
트래픽의 80% 이상을 차지하는 사실적인 프로필 (믹스, 사고 시간, 데이터) 이 있습니다.
RED 대시 보드 + 추적은 모든 테스트에 연결됩니다.
p95/오류를 회전 할 때 성능 게이트 블록 해제
용량과 무릎 지점은 주요 서비스에 의해 문서화됩니다.
월간 담그기/스트레스 실행 및 진행 보고서.
"스파이크" 에 대한 내성은 오토 스케일 및 캐스케이드 실패의 부재에 의해 확인됩니다.
18) 결론
로드 테스트는 일회성 측정이 아닌 정기적 인 엔지니어링 관행입니다. "실제 사용자를 모델링하고 (오픈 모델) 클라이언트의 경험 (SLI/SLO) 을 반영하는 것을 측정하고 CI/CD에서 관찰 가능성과 게이트를 유지하며 스트레스/스파이크/흡수 실행을 수행하고 무릎 점을 수정하십시오. 그런 다음 피크 이벤트와 검은 백조가 관리 가능한 시나리오로 바뀌고 성능이 플랫폼의 예측 가능하고 측정 가능한 매개 변수로 바뀝니다.