전 포스팅에서 k6로 300 VUs 부하테스트를 돌렸더니 평균 응답시간이 4초가 넘게 나왔다. 원인을 찾아보니 application-prod.yaml에 Hikari 설정 자체가 없어서 기본값인 커넥션 풀 10개로 돌아가고 있었다.

문제

avg=4.15s / p(90)=5.73s / p(95)=6.09s

300명이 동시에 주문 요청을 보내면 DB 커넥션 풀이 금방 고갈된다. 커넥션을 얻지 못한 요청들은 줄을 서서 대기하게 되고, 그게 응답 지연으로 이어지는 구조였다.

HikariCP란? Spring Boot에서 기본으로 사용하는 DB 커넥션 풀 라이브러리다. 커넥션 풀이란 DB 연결을 미리 여러 개 만들어두고 요청이 들어올 때마다 재사용하는 방식인데, 풀 사이즈가 너무 작으면 동시 요청이 몰릴 때 병목이 생긴다. 기본값은 maximum-pool-size: 10으로, 동시에 10개의 DB 연결만 허용한다.

해결

application-prod.yaml에 Hikari 설정이 아예 없었기 때문에 아래 설정을 추가해주었다.

hikari:
  maximum-pool-size: 30      # 최대 커넥션 수 (기본값 10 → 30으로 증가)
  minimum-idle: 10           # 유휴 상태에서 유지할 최소 커넥션 수
  connection-timeout: 30000  # 커넥션 획득 대기 최대 시간 (30초)
  idle-timeout: 600000       # 유휴 커넥션 유지 시간 (10분)
  max-lifetime: 1800000      # 커넥션 최대 수명 (30분)

핵심은 maximum-pool-size를 10에서 30으로 늘린 것이다. 동시에 처리할 수 있는 DB 연결이 3배로 늘어나니 대기 줄이 줄어들 수밖에 없다.

결과

항목	튜닝 전	튜닝 후	개선율
avg	4.15s	1.69s	59% ↓
p(90)	5.73s	3.4s	41% ↓
p(95)	6.09s	4.62s	24% ↓

설정 몇 줄 추가했을 뿐인데 평균 응답시간이 4.15초 → 1.69초로 약 60% 개선됐다.

코드 한 줄 안 바꾸고 설정만으로 이 정도 성능 차이가 난다는 게 인상적이었다. 기본값이 항상 최선은 아니다. 특히 트래픽이 몰리는 서비스라면 커넥션 풀 사이즈는 반드시 확인하고 튜닝해야 한다는 걸 이번에 직접 체감하게 되었다.