chore: 동시 접속 100명 기준 커넥션 풀/스레드 풀 설정 적용

[tnals0924]

어떤 기능인가요?

동시 접속 100명 규모를 안정적으로 처리하도록 HikariCP 커넥션 풀과 Tomcat 스레드 풀 설정을 명시합니다.

현재 운영/개발 환경 모두 커넥션 풀과 스레드 풀 설정이 없어 Spring Boot 기본값(Hikari maximum-pool-size: 10, Tomcat threads.max: 200)으로 동작합니다. 기본값은 배포 환경(CapRover, 소형 인스턴스)과 실제 트래픽 특성을 반영하지 않아 다음과 같은 문제가 있습니다.

• 커넥션 획득 타임아웃 30초(기본값) — 풀이 고갈되면 요청 스레드가 30초간 묶여 장애가 확대됩니다.
• max-lifetime 미설정 — MySQL wait_timeout으로 서버 측에서 먼저 끊긴 커넥션을 획득해 간헐적 실패가 발생할 수 있습니다.
• Tomcat 스레드 200 — 인스턴스 자원 대비 과도해 컨텍스트 스위칭 비용만 늘어납니다.

📝 작업 상세 내용

• application-prod.yml에 HikariCP 설정 추가 (maximum-pool-size: 15, minimum-idle: 15, connection-timeout: 3000, max-lifetime: 1740000 등)
• application-prod.yml에 Tomcat 스레드 풀 설정 추가 (threads.max: 100, min-spare: 20, accept-count: 100)
• application-dev.yml에 동일 설정 적용 (부하 테스트 대상 환경과 운영 환경의 설정 일치)
• 배포 시 처리 중인 요청이 유실되지 않도록 server.shutdown: graceful 적용

📁 참고 자료 (선택)

커넥션 풀 크기 산정 근거

동시 접속 100명이 곧 커넥션 100개를 의미하지 않습니다. Little's law 기준으로 필요 커넥션 수는 처리량 × 요청당 DB 점유 시간입니다.

• 100 VU, think time 1초 → 실질 처리량 약 90~95 req/s
• 요청당 DB 점유 시간 약 20ms → 필요 커넥션 ≈ 2개

여기에 느린 쿼리(납부자 목록 깊은 OFFSET 조회, 엑셀 생성)와 @Async 알림 핸들러가 별도 스레드에서 커넥션을 점유하는 몫(기본 태스크 풀 8)을 더해 15로 산정했습니다. 이보다 크게 잡으면 DB 측 컨텍스트 스위칭과 락 경합이 늘어 오히려 처리량이 떨어집니다.

Tomcat 스레드 > 커넥션 풀 구조

threads.max: 100 > maximum-pool-size: 15 구성은 의도한 형태입니다. 커넥션을 얻지 못한 요청 스레드는 풀에서 대기하다 3초 내 실패하며, 요청 자체를 거절하는 것보다 낫습니다.

관련 파일

• src/main/resources/application-prod.yml
• src/main/resources/application-dev.yml