DB 커넥션 풀 튜닝 실패 사례 분석
Spring Boot는 기본적으로 HikariCP를 사용합니다.
대부분 개발자는 다음 설정만 보고 넘어갑니다.
datasource:
hikari:
maximum-pool-size: 10
connection-timeout: 30000
max-lifetime: 1800000
하지만 이 설정을 제대로 이해하지 못하면 운영 환경에서 장애가 발생합니다.
이번 글에서는 실무에서 실제로 자주 발생하는 HikariCP 장애 5가지 사례를 정리합니다.
1. Connection Pool Exhausted
(커넥션 풀 고갈)
가장 흔한 장애입니다.
로그
의미
발생 상황
예
동시에
구조
10개 → 대기
대기 시간이 connection-timeout을 넘으면
이 발생합니다.
해결 방법
1️⃣ 커넥션 풀 증가
2️⃣ 느린 쿼리 제거
3️⃣ 트랜잭션 범위 축소
2. DB Max Connection 초과
이건 DB 서버가 죽는 케이스입니다.
예
애플리케이션 서버 5대
전체 커넥션
결과
DB가 새로운 연결을 거부합니다.
해결 방법
커넥션 풀은 항상 다음 기준으로 잡아야 합니다.
예
80 / 4 servers = 20
따라서
3. Broken Pipe / Connection Reset
운영에서 많이 보는 로그입니다.
또는
원인
예
- AWS RDS
- NAT Gateway
- Firewall
이 경우 커넥션 풀에 죽은 커넥션이 남아있습니다.
해결 방법
max-lifetime을 DB timeout보다 작게 설정합니다.
예
설정
4. Thread Pool 고갈
이건 커넥션 풀 문제지만 웹 서버까지 영향을 줍니다.
예
커넥션 풀이 부족하면
이 상태가 됩니다.
Tomcat 구조
↓
Tomcat Thread
↓
DB Connection Pool
커넥션이 없으면
결과
서버가 응답을 못 합니다.
해결 방법
connection-timeout을 크게 잡지 않습니다.
보통
정도가 적절합니다.
5. 커넥션 누수 (Connection Leak)
가끔 이런 로그가 보입니다.
의미
예
닫지 않으면
이 발생합니다.
해결 방법
Spring에서는 대부분 다음을 사용합니다.
JpaRepository
JdbcTemplate
이 경우 자동으로 반환됩니다.
그래서 직접
을 쓰지 않는 것이 좋습니다.
6. 실무 추천 설정
보통 Spring Boot 운영 환경에서는 이렇게 시작합니다.
datasource:
hikari:
maximum-pool-size: 20
minimum-idle: 5
connection-timeout: 30000
idle-timeout: 600000
max-lifetime: 1800000
7. 커넥션 풀 설계 기준
설계할 때 고려해야 할 것
DB max_connections
서버 수
트래픽 TPS
쿼리 시간
간단한 공식
예
pool = 8 ~ 16
정리
HikariCP 설정은 단순한 옵션처럼 보이지만 운영 장애와 직결됩니다.
특히 다음 세 가지를 항상 함께 고려해야 합니다.
connection-timeout
max-lifetime
이 설정은 애플리케이션 성능이 아니라 DB 안정성을 위한 설정입니다.
✔ 핵심 한 줄
'DB' 카테고리의 다른 글
| Spring Boot에서 @Transactional을 잘못 쓰면 생기는 7가지 문제 (0) | 2026.03.11 |
|---|---|
| Spring Boot에서 DB 커넥션 풀 크기를 계산하는 방법 (0) | 2026.03.11 |
| Spring Boot HikariCP 커넥션 풀 설정 실무 가이드 (0) | 2026.03.11 |
| 자바 백엔드 성능 최적화의 시작, HikariCP 제대로 알고 쓰기 (0) | 2026.03.11 |
| Redis (0) | 2026.03.10 |
