(시나리오: 10 VU × 사진 30 장 업로드·앨범 생성)

구분	내용
동시 사용자(VU)	Ramp-up 0 → 10 (1 분) → 유지 10 (3 분) → Ramp-down 1 분
1 Iteration	① Presigned URL 1회 (30 장 한꺼번에) → ② 이미지 PUT 30회 → ③ 앨범 POST 1회
피크 처리량 계산	10 VU × 32 req / 8 s ≅ 40 req/s (그래프 실제 30 ~ 60 req/s와 일치)
전송 데이터	30 장 x 1 MB x 10 VU = 300 MB
시험 목적	오토스케일링 + DB 병목 식별

10명이 한꺼번에 30 장을 올려도 평균 응답은 < 200 ms이지만, DB 커넥션 풀이 10개로 제한돼 tail-latency(p99) 가 최대 29 초까지 늘어났습니다.

• 향후 계획

kafka 도입 -Kafka로 “앨범 생성”을 비동기 큐로 전환하면 API 서버에서는 커넥션 풀 문제가 사라질것으로 예상

# 부하 테스트 결과 종합 보고서

(시나리오: 10 VU × 사진 30 장 업로드·앨범 생성)

구분	내용
동시 사용자(VU)	Ramp-up 0 → 10 (1 분) → 유지 10 (3 분) → Ramp-down 1 분
1 Iteration	① Presigned URL 1회 (30 장 한꺼번에) → ② 이미지 PUT 30회 → ③ 앨범 POST 1회
피크 처리량 계산	10 VU × 32 req / 8 s ≅ 40 req/s (그래프 실제 30 ~ 60 req/s와 일치)
전송 데이터	30 장 x 1 MB x 10 VU = 300 MB
시험 목적	오토스케일링 + DB 병목 식별

지표	p50	p95	p99	max
http_req_duration	60 ms	170 ms	5 s	29 s
http_req_failed	0 %
iteration_duration	7 s	18 s	25 s	32 s

해석 – 95 % 요청은 200 ms 이내지만, 꼬리(1 %)가 최대 29 s 까지 치솟음.

항목	수치·패턴	의미
Connections Size	10 고정	maximumPoolSize = 10
Active	피크 10 / 평균 0.7	부하 시 10 개 전부 사용
Idle	부하 시 0	여유 없음
Pending	최대 95	커넥션 못 받은 스레드 대기
Acquire Time	피크 1.2 s	커넥션 대기 시간
Timeout Count	5	5 건은 1.2 s 대기 후 실패

결론 – CPU, GC, 네트워크는 여유지만 “DB 커넥션 풀(10 개) 포화 → 대기열·타임아웃 → p99 지연” 이 원인.

구간	DB 사용	관찰된 병목
Presigned-URL 발급	대량의 SELECT	잡히지 않음
이미지 PUT(GCS)	DB 미사용	없음
앨범 POST (INSERT + 사진 30 건)	대량 WRITE	커넥션 풀 포화 → 대기·타임아웃

→ 병목은 “생성(WRITE) 경로” 에 집중.

우선도	조치	목표 지표
★★★★★	Hikari maximumPoolSize 10 → 40(DB max_connections ≥ 60 확보)	Pending ≈ 0, Acquire p99 < 50 ms
★★★★☆	Batch/Bulk INSERT 적용hibernate.jdbc.batch_size = 50	Connection Usage Time ↓
★★★★☆	앨범 생성 비동기화(메타 저장 → Pub/Sub로 후처리)	API 응답 시 < 200 ms 유지
★★★☆☆	Client→GCS 직접 PUT(서버는 URL만 기록)	서버 네트워크·CPU 부하 ↓
★★☆☆☆	READ 전용 시나리오 부하 재실행	조회 병목 여부 추가 확인

10명이 한꺼번에 30 장을 올려도 평균 응답은 < 200 ms이지만, DB 커넥션 풀이 10개로 제한돼 tail-latency(p99) 가 최대 29 초까지 늘어났습니다.

• 향후 계획
  kafka 도입 -Kafka로 “앨범 생성”을 비동기 큐로 전환하면 API 서버에서는 커넥션 풀 문제가 사라질것으로 예상