Connection Pool

어플리케이션 서버가 DB와 연결되는 과정

1. 유저가 어떤 정보를 서버에 요청함

2. 해당 정보를 응답하기 위해 DB를 조회

3. DB 드라이버(라이브러리)는 DB와 연결을 하기 위해 여러 작업을 거침

   • TCP/IP 연결을 시도함, 이 과정에서 3 wayhandshake 발생

   • 연결이 된다면, DB 에 ID/PW 를 전달

   • DB 는 인증이 됐다면, 내부에 DB 세션을 생성

   • DB 는 커넥션이 완료 됐다고 응답

   • DB 드라이버는 응답을 통해 커넥션 객체를 생성 후 응답

커넥션 풀이란?

매 요청마다 위와 같은(기존 DriverManger로 직접 커넥션 맺는 행위) 패턴을 반복하는 것은 비효율적이며 응답시간에 지연이 발생 할 수 있음 그렇기 때문에 어플리케이션 실행 시 정해놓은 수만큼 미리 DB와 커넥션하여 생성 된 객체를 보관함(풀)에 저장했다가 필요할 때 마다 그냥 바로 꺼내서 씀

장점

1. 성능 향상 (빠른 응답)

   • 매번 DB 연결을 새로 만들면(커넥션 생성) 비용이 큼 → 시간이 많이 듦

   • 커넥션 풀은 미리 연결된 커넥션을 풀에 저장 → 필요할 때 바로 꺼내 씀 → 빠름

2. 리소스 절약 (DB 서버 보호)

   • 풀에서 커넥션 수를 제한할 수 있음 (예: 최대 100개) → 무한하게 연결 생성을 막아 DB 서버가 과부하되는 걸 방지

3. 일관성 유지

   • 풀을 통해 관리되므로 커넥션 누수(연결이 안 끊어져서 DB가 터짐)를 방지

   • 커넥션 자동 회수, 타임아웃 등 정책 적용 가능

4. 스케일 아웃 대비

   • 대규모 트래픽에서도 풀 덕분에 일정 성능 유지 가능

   • 특히 웹 서비스에서는 사용자 수 증가 시 필수

단점

1. 풀 관리 복잡성

   • 최대 커넥션 수, 최소 커넥션 수, 커넥션 유휴 시간 등 설정 필요 → 잘못 설정하면 성능 저하 또는 DB 고립 발생

2. 풀 초과 시 대기 발생

   • 최대 커넥션 수에 도달하면 새 요청은 대기하거나 실패

   • 잘못 설계하면 서비스 지연

3. 장시간 커넥션 방치 위험

   • 커넥션 풀에 커넥션이 너무 오래 살아 있으면 DB 서버 쪽에서 세션 타임아웃 발생 → 커넥션 풀에서는 죽은 커넥션을 재사용 → 에러 발생 가능

4. 초기 메모리 사용량 증가

   • 풀 생성 시 커넥션을 미리 몇 개 만들어두므로 초기 메모리/자원 사용량 증가

대표적인 커넥션 풀 오픈소스

• 그냥 hikariCP 먹었음.