✅ 왜 커넥션 풀이 중요한가?
웹 애플리케이션은 데이터베이스와 끊임없이 통신합니다.
하지만 DB 연결(Connection)은 매우 비싼 리소스입니다.
매 요청마다 새로 연결하면 성능 저하와 시스템 과부하가 발생하죠.
그래서 등장한 것이 바로 커넥션 풀(Connection Pool) 입니다.
커넥션을 미리 만들어 풀(pool)로 보관하고, 필요할 때 재사용하는 구조로,
DB 연결 비용을 최소화하면서 성능을 끌어올릴 수 있습니다.
🧩 커넥션 풀의 구조와 작동 방식
커넥션 풀은 다음과 같은 방식으로 동작합니다:
- 애플리케이션 시작 시, 일정 개수의 DB 커넥션을 생성해 풀에 보관합니다. ( idleTimeout, maxLifetime, validation failure 만족 시 히카리가 해당 세션을 종료시킴. 그 전까지는 재사용)
- 사용자가 요청을 보내면, 풀에서 커넥션을 하나 꺼내어 처리합니다.(유휴커넥션이 다 죽은 경우 사용자가 다시 커넥션 요청하면 다시 세션 자동 생성)
- 처리가 끝나면 커넥션을 반환하여 재사용합니다.
- 동시에 요청이 몰리면, 풀에서 꺼낼 수 있는 커넥션이 부족해질 수 있으며, 이 경우 대기 상태가 발생합니다.
-- 애플리케이션 구동 직후 세션상태정보를 확인 할 수 있다.
SELECT sid, status, machine
FROM v$session
WHERE username = 'MY_APP_USER';
-- MySQL은 information_schema.PROCESSLIST 또는 SHOW PROCESSLIST 사용💡 커넥션을 반환하지 않으면 풀 고갈이 발생합니다. 이는 전체 시스템 지연의 원인이 됩니다.
⚙️ 커넥션 풀 설정 – 꼭 알아야 할 3대 항목
1. 최대 풀 사이즈 (maximumPoolSize)
- 동시에 사용할 수 있는 커넥션 수의 상한선
- 너무 작으면 대기 시간이 늘고, 너무 크면 DB 자원 고갈 위험
- 권장 기준: CPU 코어 수 × 2~4, 또는 TPS 기반 계산
2. 최소 유휴 커넥션 수 (minimumIdle)
- 시스템이 놀고 있을 때도 유지할 커넥션 수
- 초기 요청에 대응할 수 있게 미리 준비된 커넥션
3. 커넥션 대기 시간 (connectionTimeout)
- 커넥션을 풀에서 꺼낼 수 없을 때 대기할 최대 시간 (밀리초)
- 이 시간을 초과하면 예외 발생 → TimeoutException
항목예시 값
| maximumPoolSize | 20 | |
| minimumIdle | 자원을 아끼려면 0으로 할 수 있겠지만 실시간 트래픽이 있는 서비스에서는 최소 수준은 유지해야 서비스가 느려지지 않음 | 5 |
| connectionTimeout | 3000 (3초) | |
| idleTimeout | 유휴 상태로 컨넥션이 살아있는 시간. 이 시간이 지나면 제거됨 | 600000 (10분) |
| maxLifetime | 1800000 (30분) |
curl http://localhost:8080/actuator/metrics/hikaricp.connections ( 실시간 확인 - Spring Boot Actuator + Hikari)
idle = 0 이면 유휴 커넥션이 하나도 없는 상태
🔍 주요 커넥션 풀 라이브러리 비교: HikariCP vs DBCP vs UCP
항목HikariCPDBCPUCP (Oracle)
| 성능 | 🔥 매우 빠름 | 보통 | 빠름 |
| Spring 기본 | ✅ 내장됨 | ❌ | ❌ |
| 커스터마이징 | 높음 | 낮음 | Oracle 특화 |
| 모니터링 지원 | JMX, Micrometer | 제한적 | Oracle EM |
| 사용 대상 | Spring Boot, 일반 Java | 레거시 환경 | Oracle 제품군 |
Spring Boot 환경이라면 HikariCP가 기본이며, 성능과 안정성 모두 뛰어납니다.
🚨 커넥션 풀 고갈 방지 전략
✔️ 커넥션 반환 철저
- 커넥션을 반납하지 않으면 풀 고갈 발생
- try-with-resources 또는 finally 블록 사용 권장
try (Connection conn = dataSource.getConnection()) { // DB 작업 수행 } catch (Exception e) { // 예외 처리 }
✔️ 느린 쿼리 줄이기
- 한 커넥션을 오래 점유하면 풀 회전율이 떨어짐
- 느린 쿼리는 튜닝하거나 캐시 활용
- 예: 자주 조회하는 마스터 데이터 → Redis 캐싱
✔️ TPS 기준 풀 크기 계산
- 예: 초당 요청 100건, 평균 처리 시간 0.2초라면
→ 100 * 0.2 = 20개의 커넥션이 필요
✔️ 모니터링 도입
- Spring Actuator + Micrometer + Prometheus + Grafana
- 커넥션 사용량, 대기 시간, 실패율 등을 시각화하여 실시간 대응
🧪 실전 예시: Spring Boot + HikariCP 설정 (application.yml)
spring:
datasource:
url: jdbc:mysql://db-host:3306/mydb
username: user
password: pass
hikari:
maximum-pool-size: 20
minimum-idle: 5
connection-timeout: 3000
idle-timeout: 600000
max-lifetime: 1800000✅ 마무리 요약
- 커넥션 풀은 DB 성능 최적화의 핵심 요소
- 무작정 큰 풀은 오히려 오버헤드 → 시스템 리소스와 TPS를 기준으로 설정
- HikariCP 사용 권장, 반환 철저, 쿼리 최적화, 모니터링 도입이 중요
다음 글에서는 👉 DB 세션 모니터링 방법 을 실습 중심으로 다룹니다.
댓글