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

[tnals0924]

#️⃣연관된 이슈

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

📝작업 내용

동시 접속 100명 규모를 안정적으로 처리하도록 HikariCP 커넥션 풀과 Tomcat 스레드 풀 설정을 명시합니다. 기존에는 두 설정이 모두 없어 Spring Boot 기본값(Hikari maximum-pool-size: 10, Tomcat threads.max: 200)으로 동작하고 있었습니다.

커넥션 풀 크기 산정

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

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

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

수정 내용

설정	기존	변경	이유
hikari.maximum-pool-size	10 (기본값)	15	웹 요청 + @Async 알림 처리 몫 반영
hikari.minimum-idle	미설정	15	풀 크기 고정. 스파이크 시 커넥션 생성 지연이 응답시간에 섞이는 것 방지
hikari.connection-timeout	30초 (기본값)	3초	풀 고갈 시 스레드가 30초간 묶여 장애가 확대되는 것 방지 (fail-fast)
hikari.max-lifetime	미설정	29분	MySQL wait_timeout으로 서버 측에서 먼저 끊긴 커넥션 획득 방지
hikari.keepalive-time	미설정	5분	유휴 커넥션 유효성 사전 검증
tomcat.threads.max	200 (기본값)	100	인스턴스 자원 대비 과도. 동시 접속 100을 정확히 수용
tomcat.threads.min-spare	10 (기본값)	20	트래픽 유입 초기 스레드 생성 지연 완화
tomcat.accept-count	100 (기본값)	100 (명시)	초과 요청 대기 큐
server.shutdown	immediate	graceful	배포 시 처리 중이던 요청 유실 방지

운영(application-prod.yml)과 개발(application-dev.yml) 환경에 동일하게 적용했습니다. 개발 환경이 부하 테스트 대상이 되는 경우 설정이 어긋나면 측정값을 운영에 그대로 대입할 수 없기 때문입니다.

Tomcat 스레드 수 > 커넥션 풀 크기 구조

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

💬리뷰 요구사항(선택)

• MySQL max_connections 확인이 필요합니다. 인스턴스를 여러 개로 띄우는 경우 15 × 인스턴스 수가 DB 서버 한도 안에 들어와야 합니다. 기본값 151 기준으로는 2대까지 안전합니다.
• 위 수치는 "요청당 DB 점유 20ms" 가정에서 도출한 값입니다. 배포 후 k6/run.sh 100 3m으로 실측해 http_req_duration p95가 목표를 넘으면, 커넥션 풀보다 쿼리 자체(깊은 OFFSET 페이지네이션)를 먼저 확인하는 것이 맞다고 생각합니다. 풀 크기를 키워서는 해결되지 않는 종류의 문제입니다.
• 병목 지점을 실측으로 확인하려면 server.tomcat.mbeanregistry.enabled: true와 actuator를 통해 hikaricp.connections.pending, tomcat.threads.busy 지표를 노출하는 방안도 있습니다. 별도 이슈로 분리하는 게 나을지 의견 부탁드립니다.