[V1] 부하 테스트 시나리오 설계 및 구현 - 100-hours-a-week/KTB4-11th-Cloud GitHub Wiki
- V1 핵심 기능 - 리포트 조회 API
- 이건 사용자 요청 흐름대로 진행할 예정이고
- 현재 V1구조 최대한 살려서 진행할 예정
- V1에서 구현된 기능이자 V2의 핵심 기능 - 투자매매 API
- V2 구조대로 진행하기에는 아직 개발된 FE 코드가 없고, 추후에 개발된 예정이니 그때 제대로 운영환경 모방해서 하는것이 더 효과적일 것으로 생각이 들어, docker-compose 에 포함된 FE, NginX 모두 사용하지 않고, BE, DB만 V1 환경과 유사하게 진행 -> 즉 AI가 백엔드 API를 통해 처리되는 주문 기능만 부하테스트 진행한 셈이다.
- 저번에 정하였던 사용자 흐름 시나리오 기반으로 API 시나리오 짜서 진행할 예정
- V1구조 대로 진행 [ only API 호출을 통한 BE <-> DB의 부하만 주입하고 측정 ]
Infra환경 세팅
- VPC 새로 생성
- 이 안에서 현재 배포 환경과 유사하게 구성하여 진행할 예정
- 마찬가지로 terraform 분리하지만 git branch와 디렉토리도 분리하여 관리
1. V1 핵심 기능 - 리포트 조회 API
- 모니터링(메트릭, 로그 수집) 세팅
- 코드는 ECR은 전에 만들어 놓은거 공유해서 거기에 가장 최근 태그값가져와서 쓰고, 현재 docker-compose에 그 값은 고정으로 넣는 작업
- 리포트 조회 처리 흐름 봐야하니까 미리 리포트 mock 데이터 넣어놓고
- SLO 기반 목표치 정하기
- 시나리오 정하기
- 테스트 진행
SLO - 리포트 조회 API
23명이 peak이기에 1건이 실패해도 성공률은 95%가 된다. 이때 SLO는 MAU 23기준 실패 0건으로 잡고 이를 실행 합격 기준으로 둬야하고, 3초 이내 정상 응답 비율도 별도로 기록하는 것이 명확하다.
리포트 상세 조회 부하테스트 계획
대상: 게시 완료된 AI 리포트 상세 조회 API
GET /api/v1/accounts/{accountId}/orders/{orderId}/ai-report
로그인이나 리포트 생성은 부하에 포함하지 않고, 테스트용 계정으로 상세 조회만 확인한다.
측정 지표
- 정상 조회율: 전체 요청 중 HTTP 200, 요청한 주문 ID와 응답 주문 ID 일치, 완료 상태, 유효한 리포트 본문까지 확인한 비율
- 운영 SLO 목표: 30일 기준 100%
- 부하테스트 실행 합격 기준: 실패 0건
- 빠른 정상 조회율: 전체 요청 중 유효한 응답을 3초 안에 받은 비율
- 기존 초안의 99% 목표는 검토값으로 두고, 응답시간 p95·p99와 함께 기록한다.
트래픽과 시나리오
주 1회 발행된 리포트를 MAU 23명이 한 번씩 조회한다고 보면 주간 평균은 약 0.000038 RPS다. 공부 흐름에서 주 3회 조회하는 경우는 한 번에 여는 리포트 수를 K라 할 때 0.000114 × K RPS다. K는 코드만으로 알 수 없어, 1회 조회를 기술 기준선으로 삼는다.
Peak의 23명은 한 번에 들어오는 23건의 요청이지, 23 RPS를 계속 보내는 테스트는 아니다. 순서는 Smoke부터 시작해 결과를 확인한 뒤 다음 시나리오로 진행한다.
| 시나리오 | 부하 방식 | 요청 수·속도 |
|---|---|---|
| Smoke | 사용자 1명이 1회 조회 | 1건 |
| Baseline | 사용자 1명이 30초 간격으로 조회 | 10건, 약 5분 |
| Peak | 사용자 23명이 거의 동시에 1회씩 조회 | 총 23건, 순간 집중 |
| spread10 | 사용자 23명이 10초 동안 나눠서 1회씩 조회 | 총 23건, 약 2.4건/초. 같은 방식으로 2회 |
| spread60 | 사용자 23명이 60초 동안 나눠서 1회씩 조회 | 총 23건, 약 0.4건/초 |
| Repeat | 사용자 23명이 30초 간격으로 20회씩 반복 조회 | 총 460건, 10분간. 매 30초마다 23건이 몰리는 형태 |
측정 방법
k6 결과에서 실패 건수, 3초 이내 정상 응답률, p95·p99, 실제 요청률을 기록한다. 같은 시간 범위의 CloudWatch에서 앱 EC2와 k6 EC2의 CPU·메모리 및 로그도 함께 확인한다. 부하 발생기인 k6 EC2가 포화된 실행은 서버 판정에 사용하지 않는다.
리포트 상세 조회 부하테스트 결과
실행일: 2026-10-02 (KST)
대상: GET /api/v1/accounts/{accountId}/orders/{orderId}/ai-report
목적: 예상 조회 시나리오에서 응답 성공률과 응답시간 확인
결과 보고
유효한 인증정보로 실행한 본시험은 **563/563건 성공(100%)**했다. 모든 응답이 shorten_text와 9개 thoughts 필드를 포함했고, 3초 안에 완료됐다. 가장 많은 표본을 제공한 Repeat는 460/460 성공, p95 141.42ms, p99 217.33ms였다.
| 시나리오 | 부하 | 요청 수 | 성공률 | 응답 p95 |
|---|---|---|---|---|
| Smoke | 1 VU, 1회 | 1 | 100% | 795.67ms |
| Baseline | 1 VU, 30초 간격 10회 | 10 | 100% | 24.68ms |
| Peak | 23 VU, 동시에 1회씩 | 23 | 100% | 267.64ms |
| spread10 1차 | 23 VU, 약 10초에 분산 | 23 | 100% | 22.21ms |
| spread10 2차 | 23 VU, 약 10초에 분산 | 23 | 100% | 18.85ms |
| spread60 | 23 VU, 약 60초에 분산 | 23 | 100% | 17.69ms |
| Repeat | 23 VU, 30초 간격 20회씩, 약 10분 | 460 | 100% | 141.42ms |
Repeat의 p99는 217.33ms였다. 전체 유효 요청에서 HTTP 실패와 잘못된 리포트 응답은 없었다.
참고 자원 지표
- 사용자 제공 CloudWatch 그래프에서 App EC2 Host CPU는 약 **5–8%**로 안정적으로 보인다.
- 첨부 화면에는 RAM 그래프가 없어 수치를 확인할 수 없다. 로컬 k6 결과에도 RAM 측정값은 포함돼 있지 않다.
- 이 부하에서 CPU가 낮았다는 것은 예상 조회 부하가 CPU 포화를 만들지 않았다는 관측이다. 최대 처리량이나 서버 한계점을 시험한 결과는 아니다.
판정과 범위
- 시험한 부하 시나리오의 응답 성공률 목표 100%를 만족했다.
- 측정된 요청은 모두 3초 안에 완료돼 3초 이내 응답 목표도 만족했다.
- 이 결과는 해당 시나리오와 시험 시간 구간에서의 SLI 결과다. 30일 전체 SLO 달성이나 최대 용량을 증명하지는 않는다.
- Peak는 23건의 단발 동시 요청이고, Repeat는 평균 약 0.77건/초로 30초마다 23건씩 몰리는 부하다. 지속적인 고RPS 용량 시험은 아니다.
별도 사전 오류
토큰 재발급 전 Smoke 1건은 HTTP 401 인증 오류였다. 토큰을 바로잡은 뒤의 Smoke는 1/1 성공했다. 본시험 집계 563건에는 인증 설정 오류가 난 사전 요청을 넣지 않았다.
원본 k6 JSON·로그·시간 메타데이터는 같은 폴더에 보관돼 있다. 시간 메타데이터가 있는 Peak, spread10, spread60, Repeat의 본시험 구간은 14:26:59–14:50:32 KST다. Smoke와 Baseline은 결과 JSON은 있으나 별도 시작·종료 메타데이터가 없다.