Connection Pool 완벽 이해
DB 커넥션을 효율적으로 관리하는 Pool의 동작 원리와 장애 상황을 체험합니다.
왜 알아야 하나요?
금요일 저녁 6시, 긴급 장애 발생!
"DB 연결이 안 돼요! 모든 API가 타임아웃이에요!"
원인 분석 결과...
한 개발자가 connection.close()를 빠뜨렸고, 배포 후 커넥션이 점점 고갈되었습니다.
이게 바로 Connection Leak!
Pool 원리를 이해하면 이런 장애를 예방하고 빠르게 대응할 수 있습니다.
한눈에 보기
Pool이 미리 만들어둔 커넥션을 빌려주고 돌려받는 구조입니다.
핵심 개념
DB 연결을 새로 만드는 건 비용이 비싸요:
- TCP 3-way handshake (~3ms)
- TLS 핸드셰이크 (~10ms, HTTPS의 경우)
- DB 인증 및 세션 생성 (~5ms)
- 총: 약 20-50ms 소요!
요청마다 이 과정을 반복하면? 성능이 바닥을 칩니다. Pool은 미리 연결해두고 재사용해서 이 비용을 없애요.
Pool의 최대 커넥션 수. 기본값 10. 공식: CPU 코어 × 2 + 1
최소 유휴 커넥션 수. 트래픽 변동이 크면 낮게 설정.
커넥션 획득 대기 시간. 기본 30초. 초과 시 SQLException 발생.
커넥션 누수 감지 시간. 이 시간 동안 반환 안 하면 경고 로그.
실무에서는
Connection conn = dataSource.getConnection(); // 쿼리 실행... // conn.close() 빠뜨림! ❌
→ 커넥션 누수 → Pool 고갈 → 전체 장애
try (Connection conn = dataSource.getConnection()) {
// 쿼리 실행...
} // 자동으로 close() 호출 ✅→ try-with-resources로 자동 반환!
직접 체험하기
실제 HikariCP Pool을 모니터링하고, 커넥션 누수를 직접 발생시켜보세요.
커넥션을 획득하고, 쿼리를 실행하고, 반드시 반환합니다. 이게 정상적인 사용 패턴이에요!
Connection Pool이 필요한 이유: DB 연결 생성에는 TCP 핸드셰이크 + 인증이 필요해요 (약 10-50ms)
적정 Pool 크기: CPU 코어 수 × 2 + 1 (너무 크면 DB에 부담, 너무 작으면 대기 발생)
주의: try-with-resources 또는 finally에서 반드시 connection.close() 호출!
더 알아보기
관련 주제
- • Transaction 관리와 커넥션
- • JPA/Hibernate의 커넥션 관리
- • Read-Replica와 커넥션 분리
모니터링 도구
- • Spring Actuator /metrics
- • HikariCP JMX MBean
- • Micrometer + Prometheus