RPS (초당 요청 수)를 점진적으로 늘려가며 진행하는 부하 테스트로 얻을 수 있는 주요 인사이트는 아래와 같다.
| 구분 | 설명 | 얻을 수 있는 정보 |
|---|---|---|
| 1. 처리량(Throughput) 한계 | RPS를 올렸을 때 처리 건수가 비례해서 늘어나는지 확인 | 선형 증가 → 여유 있음증가 둔화 → 시스템 한계 도달 신호 |
| 2. 응답시간 변화 | p90, p95, max 응답시간이 어떻게 변하는지 추적 | 지연이 급격히 증가하는 지점 = 성능 임계점 |
| 3. 에러율(Fail Rate) | HTTP 4xx, 5xx, 타임아웃 발생 여부 | 에러 발생 시점 → 스레드풀 부족, DB 연결 고갈 등 원인 추적 |
| 4. 안정성(Consistency) | 같은 부하에서 응답시간 편차가 얼마나 큰지 | 불안정한 응답 패턴 → 특정 자원 경합 발생 가능성 |
| 5. 병목 자원 식별 | CPU, 메모리, 네트워크, DB, 캐시 등 | 모니터링 연계 시 어느 레이어가 먼저 포화되는지 확인 |
우선, 보통의 서비스에서 당연히 회원가입 관련 트래픽보다 로그인 트래픽이 훨씬 많다.
[회원가입] 의 경우 런칭 직전, 대규모 마케팅&이벤트로 신규 유저 급증이 예상될 때 많은 트래픽이 들어오게 된다.
DB INSERT 작업이 많아, 중복 검사나 이메일/SMS 인증 로직이 있으면 부하가 커진다.
[로그인] 의 경우 회원가입보다 요청 빈도가 훨씬 높고, 대부분의 실서비스 운영 단계에서 가장 핵심적인 부하 포인트이다. 로그인 실패율 증가는 곧, 서비스 전반의 장애로 직결되기 때문이다.
따라서 둘을 동시에 테스트할 경우 로그인을 메인 시나리오로, 회원가입은 비율을 낮춰서 두 시나리오를 구성해보았다. 각 시나리오는 병렬로 실행되며, 여러 명의 사용자가 각 회원가입과 로그인 요청을 동시에 시도하는 상황을 가정했다.
실행 명령어