기술 도입 전 부하테스트 및 VT , WebClient 도입 비교 - 100-hours-a-week/5-yeosa-wiki GitHub Wiki

• 30초동안 VUs 0 → 50 점진적 증가
• 1분동안 VUs 50 유지
• 30초동안 VUs 50 → 0 점진적 감소
  • 현재 서비스상으로는 폭발적인 트래픽 증가를 유도할 요소가 없음
  • 실서비스에서 접속자 수가 증가/감소하는 상황 상정

Metric	값	의미
http_req_duration	평균 3초, 최대 19초, p95 9초	요청 처리 시간이 매우 느림, I/O에 의한 스레드 점유 심각
iteration_duration	평균 4초, p99 12초	실제 응답까지 걸리는 전체 시간
vus	21	동시 접속자는 많지 않지만, 처리 지연으로 backlog 발생
http_req_failed	0	오류는 없지만 성능 저하 심각

• 현재 RestTemplate + @Transactional 로직이 CompletableFuture와 함께 비동기 실행되며, 스레드가 차단 됨.
• 10초 이상 커넥션이 반환되지 않아 connection leak detection 트리거 다수 발생
  • 대부분 AI서버 호출 시 RestTemplate를 스레드가 점유하고 있어 발생하는 문제
• 스레드 수가 부족하여 새 요청은 대기하면서 지연 가중 중
• 현재 http request duration 평균 3초, 최대 19초로 요청 처리 시간이 매우 느림
  • AI 서버 처리 속도 향상 + 메시지큐 도입으로 해결 가능

• Virtual Thread 도입
  • 비용 적은 스레드 생성을 통해 효율적인 Thread per task 가능
  • 블로킹이 줄어들어 DB 커넥션 반환 지연 문제 완화 가능
• WebClient 마이그레이션
  • 현재 사용중인 RestTemplate는 동기식 블로킹 I/O 기반으로 병렬 요청 많을수록 스레드 고갈 위험
    • 현재 중복 여부, 저화질 여부, 태깅은 병렬로 요청 중
  • RestTemplate는 유지보수 중단 예정이고, WebClient는 공식 비동기 대체 API임
  • I/O 응답 대기 시간동안 스레드 반환 가능 → virtual thread와 시너지 가능
• Messaging Queue 도입
  • 현재 AI로직은 모두 외부 HTTP I/O + DB 처리를 담당함 → 실패 시 재시도 필요
  • 한 api 요청에서 5개의 요청이 동시에 처리되어 과도한 부하 유발 가능
  • 메시지 큐 도입을 통해
    • 분산된 백그라운드 처리 가능 → 분석 요청 시 메시지만 발행, 처리 서버는 여유에 따라 소비
    • 재시도 / DLQ 구성 가능 → 실패 요청 보관 및 재처리 용이
    • 큐 적체 모니터링 가능 → 시스템 처리 한계 파악 가능
    • 사용자 응답 속도 향상 → 분석 결과는 나중에 반영해도 되므로 빠른 응답 가능

Metric	RestTemplate only	RestTemplate + VT	WebClient + VT
avg duration	64ms	5ms	6ms
p99 duration	1000ms	17ms	35ms
max duration	1s	84ms	138ms
http_req_failed	0/s	0/s	0/s

VT 도입 전

VT 도입 후

WebClient 도입 후

• VT 도입 시점에 duration 감소 등 성능상 최대 개선
• 병렬 요청 처리, 연결 재활용 등 고려하면 WebClient + VT 조합이 가장 안정적이고 확장성 있음 ⇒ 현시점 AI 요청 시 백엔드 내부의 병목은 없음
• 하지만 백엔드 → AI 요청 시 Timeout 에러 다수 발생
• AI 서버의 성능 향상으로는 한계가 있음 ⇒ MQ 도입 필수