스트레스 테스트로 시스템 한계와 복구 능력 검증하기
스트레스 테스트의 부하·장애 주입 방식과 보호 메커니즘 검증, 관측 지표, k6 기반 시나리오를 정리한다.
2026-08-14 · 최초 발행 2025-12-22
한계를 넘겼을 때 드러나는 시스템의 모습
스트레스 테스트는 정상 운영 범위를 넘어서는 요청량, 동시성, 자원 고갈, 의존성 실패를 의도적으로 만들어 시스템의 붕괴 지점과 복구 행태를 관찰하는 성능·안정성 시험이다. 클라우드 네이티브와 마이크로서비스 환경에서는 회복 탄력성(resilience) 및 운영 안전장치가 실제로 작동하는지 미리 확인하는 수단이 된다.
부하 테스트가 SLO 범위 안에서의 용량을 확인한다면, 내구 테스트는 장시간 누적 영향을 본다. 스파이크 테스트는 급격한 변동 대응력을 검증한다. 스트레스 테스트가 겨냥하는 대상은 의도적으로 한계를 넘긴 뒤의 실패 모드와 복구 과정이다.
이 시험에서는 한계 용량과 병목을 찾고, 자동 확장·백프레셔·회로 차단기 같은 보호 메커니즘을 확인하며, 데이터와 트랜잭션의 일관성이 어느 수준까지 보존되는지도 평가한다.
현실적인 부하와 장애를 함께 설계한다
부하 프로파일에는 램프업, 버스트, 스파이크, 롱테일처럼 실제 트래픽에서 나타나는 패턴을 담는다. 캐시가 웜 상태인지 콜드 상태인지, 데이터 스큐가 있는지, 핫키 접근이 집중되는지도 반영 대상이다.
장애와 자원 제약도 별도로 주입한다. CPU·메모리·디스크 I/O·FD 한도·스레드 풀의 제한 또는 고갈, 네트워크 지연·패킷 손실·단절, 의존 서비스의 타임아웃과 오류가 여기에 포함된다.
이때 확인할 보호 장치는 레이트 리미터, 큐와 백프레셔, 큐잉 지연 허용 한도, 우아한 성능 저하(degradation) 정책, 회로 차단기다. 오토스케일링 정책과 냉각 시간, 커넥션 풀 한계, 재시도와 백오프가 폭주를 만들지 않는지도 함께 점검한다.
판정에는 RED(요청율·오류율·지연), USE(사용률·포화·에러), p95/p99, 큐 길이, GC/스톨, 스레드·락 경합을 활용한다. 실패 임계값, 데이터 손상 여부, RTO/RPO, 자동 복구 성공률, 에러 버짓 소비율이 합격 여부를 결정한다.
안전장치까지 포함한 실행 흐름
시작 전에는 서비스 SLO와 에러 버짓을 정의하고, 최대 허용 오류율과 지연 임계값을 정한다. 현재 자원, 스케일링 한계, DB·캐시·외부 API SLA를 명시해 용량 가설을 세운다. 폭주를 막는 세이프가드, 읽기 전용 모드, 피처 토글 롤백 경로도 준비한다.
시나리오는 동시 사용자 또는 ARR(Arrival Rate), 페이로드 크기, 읽기·쓰기 비율, 핫패스 중심 경로를 기준으로 구성한다. 의존 API의 타임아웃과 오류율 증대, 네트워크 지터와 손실, ulimit·cgroups 자원 한도를 조절하고, 캐시 콜드·웜 상태, 인덱스 유무, 파티션 스큐, 장기 트랜잭션과 락 경합도 포함한다.
실행은 워밍업에서 시작해 부하를 올리고, 한계 초과 상태를 유지한 뒤 장애를 주입한다. 이후 완화·복구와 쿨다운을 거친다. 애플리케이션·인프라 메트릭, 분산 트레이싱, 로그·샘플링 프로파일, DB·캐시 대기 이벤트를 수집하며, 오류율이나 타임아웃이 임계를 넘으면 자동 중지하고 데이터 무결성을 검증한다.
분석 단계에서는 CPU 프로파일, GC/스톨, 락·컨텐션, 큐 포화, DB 인덱스·플랜, N+1 쿼리에서 병목을 찾는다. 알고리즘, 캐싱, 배치 크기, 재시도·백오프, 커넥션 풀·스레드 풀을 조정하고, 임계 자원을 확대하거나 차단·격하 정책을 강화할 수 있다. 재시험은 같은 조건에서 한 번에 하나의 변경만 적용하고 기준선을 갱신하는 방식으로 진행한다.
보호 전략이 만드는 운영상 차이
| 전략/기법 | 성능(지연/처리량) | 확장성(스케일링) | 일관성(데이터/트랜잭션) | 안정성(장애 격리) | 운영 편의(자동화/가시성) |
|---|---|---|---|---|---|
| 레이트 리미팅·토큰버킷 | 지연 완만 증가, 폭주 억제 | 수평 확장 전 완충 | 쓰기 드롭 시 멱등성 필요 | 장애 전파 차단 | 정책·대시보드로 운영 용이 |
| 백프레셔·큐잉 | 단기 지연↑, 처리량 안정 | 버스트 흡수, 워커 확장 용이 | 재시도·순서 보장 설계 필요 | 다운스트림 보호 | 큐 모니터링 필수 |
| 회로 차단기·폴백 | 타임아웃 단축, 폴백 성능 의존 | 비정상 인스턴스 격리 | 폴백 데이터 정확도 저하 가능 | 연쇄 장애 방지 | 임계치 튜닝 필요 |
| 캐시·읽기 분리 | 읽기 지연↓, 처리량↑ | 리드 레플리카로 확장 | 최종 일관성 고려 | 원본 보호 | 캐시 적중률 관측 필요 |
| 오토스케일링 정책 | 부하에 비례한 처리량 | 빠른 수평 확장 | 상태 동기화 지연 고려 | 과부하 지속 시 효과 제한 | 지표·쿨다운 튜닝 필요 |
서비스별로 검증할 실패 조건
전자상거래 대규모 행사에서는 스파이크 부하와 재고 경합을 시험한다. 사전 토큰 발급, 가상 대기열, 원자적 재고 차감 패턴이 의도대로 동작하는지 확인한다.
결제나 핵심 API는 외부 게이트웨이의 지연과 오류율 상승을 주입해 회로 차단기와 멱등 키를 검증한다. 예약·보류 상태로 이어지는 폴백 경로와 보상 트랜잭션의 사후 정합성도 확인 대상이다.
데이터베이스 계층에서는 커넥션 풀 포화, 인덱스 부족, 슬로우 쿼리 플랜 변동을 검출한다. 읽기 분리, CQRS, 배치 크기 조정으로 압력을 분산할 수 있는지도 살핀다.
k6로 구성하는 스트레스 시나리오
전제조건은 k6 v0.49+ 설치와 대상 서비스가 사전 스테이징 환경에서 실행 중인 상태다.
// filename: stress.js
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
scenarios: {
stress: {
executor: 'ramping-arrival-rate',
startRate: 100, // req/s
timeUnit: '1s',
preAllocatedVUs: 200,
maxVUs: 2000,
stages: [
{ duration: '2m', target: 500 }, // 램프업
{ duration: '3m', target: 1500 }, // 정상 용량 초과
{ duration: '2m', target: 3000 }, // 극한 부하
{ duration: '2m', target: 0 }, // 쿨다운
],
},
},
thresholds: {
http_req_failed: ['rate<0.02'], // 에러율 < 2%
http_req_duration: ['p(99)<800'], // p99 < 800ms
},
};
export default function () {
const res = http.get(`${__ENV.TARGET}/api/hot-path`);
check(res, {
'status is 2xx': (r) => r.status >= 200 && r.status < 300,
});
sleep(0.1);
}실행 예:
TARGET=https://staging.example.com k6 run stress.js- 관측 권장: 애플리케이션 메트릭(p95/p99, 오류율), 큐 길이, 오토스케일 이벤트, DB 대기 이벤트, GC/CPU 프로파일.
테스트 결과를 운영 기준으로 연결하기
연쇄 장애, 폭주 재시도, 큐 포화를 일찍 발견하면 중대 사고 발생률이 30% 이상 감소한 사례가 보고됐다. 시험 결과로 한계 처리량(X req/s), 안전 운전 구간(SLO 내), 오토스케일 수렴 시간(분 단위)을 정량화할 수 있다.
임계치, 스케일 정책, 재시도·타임아웃 파라미터를 조정하고 에러 버짓 기반 릴리스 게이팅 체계를 강화하는 데도 활용된다. 스테이징에서 자동화된 시험을 반복하고, 변경이 생길 때마다 회귀 스트레스 테스트를 수행해야 실패 모드와 자동 복구 능력을 지속적으로 확인할 수 있다.