부하 테스트 결과 ·병목 분석 보고서 - 100-hours-a-week/KTB4-7th-Cloud GitHub Wiki
이 문서는 한 번의 테스트 묶음에서 기준 실행, 병목 분석, 개선, 동일 조건 재시험을 연결해 기록하기 위한 양식입니다. 양식을 복사해 실행별 새 Wiki 페이지를 만듭니다. 숫자와 증거를 확인하기 전에는 통과·개선 완료라고 적지 않습니다.
사용 방법
- SLI·SLO 설계와 목표 선정 근거를 확인합니다. 이 문서의 범위·목표와 다른 시험이면 차이를 먼저 기록합니다.
- 개선 전 기준 실행을 기록합니다. 실패한 실행도 삭제하거나 좋은 회차로 덮지 않습니다.
- 로그와 자원 지표를 대조해 병목 후보와 근거를 정리하고, 수정 내용과 가설을 팀에 공유합니다.
- 변경 후에는 같은 데이터·스크립트·요청 혼합·목표 부하·시간·측정 위치로 재시험합니다. 변경한 서버 자원 등 실험 변수와 예상 외 차이는 모두 표시합니다.
- 전후 수치와 한계를 비교하고, 연결된 결정 로그에 실제 선택 이유와 상태를 남깁니다.
현재 문서에 적힌 계획
2026-09-30 문서상 매출 분석 Q1·Q2 계획은 Smoke 1 RPS 2분, 필수 Load 5 RPS 10분입니다. 5 RPS 결과가 안정적이고 다른 사용자·환경에 영향을 주지 않을 때만 10 RPS 30분을 선택적으로 추가합니다. Q1과 Q2는 분리해 기록합니다. Stress·Spike·Soak는 이번 발표의 필수 범위가 아닙니다.
이 값은 시험 계획입니다. 실제 실행 여부와 결과는 아래 보고서에 실행 ID, 실행 시각, 증거를 붙여 기록합니다. 오늘의 솔루션 조회와 업로드 상태 조회는 경로·응답 계약을 확인하기 전까지 주 부하에 섞지 않습니다.
전후 비교에서 고정·기록할 조건
| 항목 |
개선 전 |
개선 후 |
비교 규칙 |
| 대상 환경·URL·리전 |
|
|
같은 환경·경로인지 기록 |
| 앱·이미지 버전, 설정 |
|
|
개선 대상 변경을 제외한 차이를 공개 |
| Backend·RDS 사양·수량 |
|
|
증설 자체가 실험 변수면 명시 |
| 데이터셋·매장 수·기간·응답 크기 |
|
|
같은 데이터 스냅샷 사용 |
| API별 시나리오·요청 혼합 |
|
|
Q1·Q2 각각 같은 비중; 추가 API는 별도 비교 |
| 테스트 스크립트·k6 버전 |
|
|
동일 버전·동일 threshold |
| 목표/실제 RPS와 지속 시간 |
|
|
단계와 판정 구간을 똑같이 맞춤 |
| 워밍업·실행 위치·발생기 자원 |
|
|
발생기 병목 여부도 확인 |
| timeout·재시도·세션 |
|
|
인증 세션 재사용, 재시도 규칙 고정 |
| 캐시 상태·백그라운드 작업 |
|
|
상태를 맞추고 차이가 있으면 영향 설명 |
| 측정 위치 |
|
|
k6 클라이언트와 Nginx 결과를 분리 |
| 실행 회차 |
|
|
가능하면 전후 각 3회; 적은 회차는 이유와 변동 표시 |
성능 개선 대상 이외의 조건이 달라져 공정한 짝비교가 되지 않으면 결과를 억지로 직접 비교하지 않습니다. 해당 차이를 적고, 필요한 경우 조건을 맞춰 다시 실행합니다.
실행 보고서 복사 양식
실행 개요
| 항목 |
값 |
| 실행 ID |
LT-YYYYMMDD-NN |
| 상태 |
계획 / 실행 중 / 유효 결과 / 무효·재실행 필요 |
| 실행 날짜·시간대 |
|
| 목적·대상 문제 |
|
| 환경·리전 |
|
| 커밋 SHA / 이미지 digest |
|
| 담당자 / 함께 검토한 사람 |
|
| 관련 결정 ID / 이슈·PR |
|
| 결과 증거 링크 |
로그, k6 summary, 대시보드, 메트릭 캡처 등 |
세션 토큰, 쿠키, 고객·점주 식별정보, 운영 비밀값은 보고서나 캡처에 포함하지 않습니다.
실행 조건과 시나리오
| 항목 |
값 |
| 데이터셋 식별자·범위 |
|
| 요청 혼합과 API 계약 버전 |
|
| 테스트 도구·버전·실행 위치 |
|
| 목표 RPS 단계·각 유지 시간 |
|
| 워밍업·timeout·재시도·캐시 상태 |
|
| 서버·DB·연결 풀·부하 생성기 사양 |
|
| 백그라운드 작업·외부 의존성 상태 |
|
| API / 시나리오 |
요청 조건 |
목표 비중 |
실행 여부·제외 사유 |
| Q1 매출 분석 당월 조회 |
THIS_MONTH |
|
|
| Q2 매출 분석 지정 기간 조회 |
CUSTOM, 고정 시작·종료일 |
|
|
| 오늘의 솔루션 조회 |
실제 제공 경로·계약 확인 후 |
|
|
| 업로드 상태 조회 |
준비된 uploadId의 GET만 |
|
|
서로 다른 API와 조건은 하나의 평균으로 합치지 않습니다. Q1·Q2 정상 결과의 데이터 정확성과 매장 접근 격리를 함께 확인합니다.
개선 전 기준 결과
| API·부하 단계 |
실행 회차 |
실제 RPS |
요청 수 N |
정상 완료 G / 비율 |
500ms 이내 정상 비율 |
1초 이내 정상 비율 |
p95 / p99 |
|
|
|
|
|
|
|
|
- k6 클라이언트 측 지연과 Nginx 처리 지연을 별도 표 또는 링크로 제시합니다.
- 실패·timeout·연결 실패·dropped iterations, 잘못된 결과와 예상 밖 상태를 API별로 적습니다.
- CPU, 메모리, CPU 크레딧, JVM·GC, 스레드/연결 풀, RDS CPU·연결·지연·잠금 등 확인한 지표와 미수집 지표를 구분합니다.
- 결과는 이 환경과 이 실행 조건에만 적용합니다. 부하 테스트 통과를 14일 운영 SLO 달성으로 바꾸어 말하지 않습니다.
병목 분석과 팀 공유
| 관찰한 느린 구간·오류 |
증거와 발생 시각 |
영향 API·부하 단계 |
병목 가설 |
확인·반박한 증거 |
|
|
|
|
|
요청 발생기 → 네트워크/Nginx → Spring Boot 처리·스레드·DB 풀 → RDS 쿼리·연결 등 구간을 따라 원인을 좁힙니다. 높은 지표가 동시에 보였다는 이유만으로 원인으로 단정하지 말고, 시간 관계나 별도 확인 결과를 적습니다.
- 발견된 병목과 판단 근거:
- 아직 확인되지 않은 부분:
- 팀에 공유한 날짜·참석자·피드백:
- 수정하기로 한 항목과 담당자:
- 수정하지 않기로 한 항목과 이유:
적용한 개선
| 항목 |
기록 |
| 변경 ID / PR / 커밋 |
|
| 수정한 코드·설정·자원 |
|
| 바꾼 이유와 병목 증거 |
|
| 기대한 효과 |
|
| 함께 바뀐 조건 |
|
| 롤백·안전 기준 |
|
개선 후 동일 조건 결과
| API·부하 단계 |
실행 회차 |
실제 RPS |
요청 수 N |
정상 완료 G / 비율 |
500ms 이내 정상 비율 |
1초 이내 정상 비율 |
p95 / p99 |
|
|
|
|
|
|
|
|
전후 비교와 결론
| API·부하 |
비교 지표 |
개선 전 |
개선 후 |
차이 |
조건 동일 여부·해석 |
|
정상 완료율 |
|
|
%p |
|
|
500ms 이내 정상 비율 |
|
|
%p |
|
|
1초 이내 정상 비율 |
|
|
%p |
|
|
p95 / p99 |
|
|
|
|
|
오류·대기·자원 지표 |
|
|
|
|
- 결론: 개선 확인 / 개선 미확인 / 악화 / 비교 불가·재시험 필요
- 판정 이유:
- 해결된 문제와 아직 남은 병목:
- 합격 기준 통과 여부: API·평가 구간별로 판정
- 운영 SLO와의 관계: 운영 배포 후 별도 관측이 필요한 부분
- 후속 조치·담당자·기한:
- 연결된 결정 로그와 다음 재검토 조건:
| 날짜 |
변경 사항 |
근거·검토자 |
| YYYY-MM-DD |
실행 결과 기록 |
|
관련 문서