[SQL] 데이터베이스의 커넥션 풀

데이터 베이스의 커넥션 풀

데이터베이스 커넥션 풀(Database Connection Pool)은 애플리케이션에서 데이터베이스와의 연결을 효율적으로 관리하기 위한 핵심적인 메커니즘임.

커넥션 풀을 제대로 이해하고 활용하기 위해서는 내부 동작 방식, 관련 설정 파라미터, 풀링의 장단점과 튜닝 방법 등을 종합적으로 살펴봐야 함.

 

커넥션 풀의 필요성

1. 데이터베이스 연결(커넥션) 비용 절감

애플리케이션이 데이터베이스에 접근하기 위해서는 네트워크 소켓을 열고, 인증 과정 등을 거쳐 커넥션을 맺어야 함.

이 과정은 CPU, 메모리 등 리소스를 많이 사용하고, 지연 시간이 발생함.

매 요청마다 새 커넥션을 생성하는 것은 비효율적이며, 대규모 트래픽 상황에서는 병목이 심해짐.

 

2. 자원(커넥션 수) 제한

데이터베이스가 동시에 처리할 수 있는 커넥션 수에는 물리적/논리적인 한계가 있.

무분별하게 커넥션을 생성하면 DB 서버 자원이 고갈되어 애플리케이션 성능이 급격히 저하될 수 있.

 

3. 재사용성

커넥션 풀은 일정 개수의 커넥션을 미리 확보해두고, 필요 시 재사용함으로써, 커넥션 생성과 정리(Connection Teardown) 비용을 절감함.

 

커넥션 풀의 기본 동작 방식

1. 초기화(Initialization)

애플리케이션이 시작되거나, 커넥션 풀이 최초로 초기화될 때, 미리 설정된 최소 커넥션 수(minimum pool size)만큼 데이터베이스 연결을 생성해 둠.

 

2. 대기열(Pool)에서 커넥션 획득

애플리케이션 로직이 DB 접근이 필요할 때, 커넥션 풀에 ‘커넥션을 빌려달라’(getConnection)고 요청함.

커넥션 풀은 사용 가능한 커넥션 중 하나를 즉시 반환함.

만약 사용 가능 커넥션이 없다면, 풀의 동작 방식에 따라 새로운 커넥션을 생성하거나, 또는 연결이 반환될 때까지 대기함.

 

3. 사용 후 반환(Return)

작업을 마친 애플리케이션 로직은 사용한 커넥션을 ‘반납’(close)함.

여기서 close()는 실제로 DB 커넥션을 종료하는 것이 아니라, 풀에서 재사용 가능한 상태로 돌려놓는 과정을 말함.

 

4. 풀 관리(Pool Maintenance)

풀은 백그라운드에서 아이들(Idle) 커넥션을 정리하거나, 유효성 검사를 통해 제대로 동작하지 않는(죽은) 커넥션을 제거함.

이를 통해 커넥션 풀이 안정적으로 동작하도록 관리함.

 

주요 커넥션 풀 구현체와 특징

1. HikariCP

비교적 가벼우면서도 높은 성능을 제공하는 커넥션 풀임.

낮은 지연시간, 높은 처리량을 보장하며, Spring Boot 등과 연동 시 기본 풀로 권장되는 추세임.

코드가 간결하고, 내부 메커니즘이 최적화되어 있어 다른 풀보다 성능상 이점이 많음.

 

2. Apache Commons DBCP

비교적 오래된 풀로, 여러 프로젝트에서 표준적으로 쓰였음.

성능 최적화가 중요해진 최근 추세에서는 HikariCP로 많이 대체되고 있지만, 여전히 레거시 시스템에서 사용되는 경우가 많음.

 

3. C3P0

Java 애플리케이션에서 종종 사용되었던 풀임.

커넥션 검증 메커니즘, 다양한 설정 제공 등 유연성이 높지만, 성능 면에서는 HikariCP나 다른 경량 풀에 비해 느린 편으로 평가됨.

 

4. BoneCP

한동안 인기 있었으나 현재는 유지보수가 활발하지 않음.

HikariCP로 넘어가거나 다른 풀로 대체되는 추세임.

 

주요 설정 파라미터와 의미 : 풀 크기 설정

1. 최소 풀 크기(Minimum Idle, Minimum Pool Size)

풀에서 유지할 최소 커넥션 수임.

애플리케이션이 유휴 상태여도 이 수만큼은 항상 유지하여, 갑작스러운 트래픽 증가 시에도 빠르게 대응할 수 있음.

 

2. 최대 풀 크기(Maximum Pool Size)

풀에서 관리할 수 있는 최대 커넥션 수임.

이 값을 넘어서는 요청이 들어오면, 보통 대기하게 되거나 예외가 발생하게 됨.

설정에 따라 다름.

 

3. 초기 풀 크기(Initial Pool Size)

애플리케이션 시작 시 미리 열어둘 커넥션 수임.

보통 최소 풀 크기와 동일하게 맞추는 경우가 많음.

 

주요 설정 파라미터와 의미 : 커넥션 유효성 및 시간 제한 설정

1. Connection Timeout

애플리케이션이 커넥션 풀에서 커넥션을 요청했을 때, 풀에 여유가 없어 대기하는 최대 시간을 설정함.

이 시간이 초과되면 예외를 발생시키거나 원하는 예외 처리 로직을 통해 요청을 실패 처리함.

 

2. Idle Timeout

오랫동안 사용되지 않는 커넥션을 풀에서 제거하기 위한 기준 시간임.

데이터베이스나 네트워크 장비에 의해 커넥션이 중간에 끊길 수도 있기 때문에, 너무 오래된 커넥션은 폐기 후 새 커넥션으로 대체하는 것이 안정적임.

 

3. Max Lifetime

한 커넥션이 생성된 이후 최대 얼마나 오래 살아있을 수 있는지 설정함.

DB 드라이버나 방화벽 정책 등에서 특정 시간 후 커넥션을 강제로 종료하는 환경도 있기 때문에, 적절한 값으로 설정하여 풀 내부의 ‘Zombie’ 커넥션을 제거할 수 있음.

 

4. Validation Query

커넥션을 빌려주기 전에, 혹은 Idle 상태의 커넥션에 대해 일정 주기로 유효성을 검증할 때 사용하는 쿼리임.

예를 들면, SELECT 1.

HikariCP 등은 성능 이슈로 자체적인 ‘isValid()’ 메서드를 활용하기도 함.

 

주요 설정 파라미터와 의미 : 기타 설정

1. Leak Detection

커넥션을 획득한 후 사용자가 제대로 반환하지 않을 경우, 누수(leak)가 발생함.

HikariCP는 LeakDetectionThreshold 등을 설정하여, 특정 시간 이상 커넥션이 반환되지 않으면 로그를 남기는 기능을 제공함.

 

2. Isolation Level

트랜잭션 격리 수준을 풀에서 통일되게 설정할 수 있음.

DB 및 애플리케이션에서 일관성을 유지하기 위해 주의해야 함.

 

3. Reap/Housekeeping Interval

풀에서 주기적으로 백그라운드 작업(Idle 커넥션 정리 등)을 수행하는 간격을 설정함.

 

커넥션 풀 동작 시나리오 예시

1. 서비스 기동

HikariCP 예를 들면, minimumIdle = 10, maximumPoolSize = 50으로 설정했다고 가정함.

애플리케이션이 시작되면 최소 10개의 커넥션을 DB에 미리 연결해둠.

 

2. 요청 증가

트래픽이 몰리면 동시에 여러 스레드가 DB 요청을 시도함.

풀에서 대기중인 커넥션이 남아있다면 즉시 할당해줌.

 

3. 풀의 커넥션 고갈

동시에 10개가 넘는 스레드가 커넥션을 요구해서 풀에 여유가 없으면, 풀은 maximumPoolSize 이하로 새 커넥션을 생성함.

만약 이미 50개가 모두 사용 중이라면, connectionTimeout 기간 동안 대기시키거나, 즉시 에러를 던질 수 있음.

 

4. 작업 완료 후 반환

각 스레드는 쿼리 실행이 끝난 후 connection.close()를 호출함.

실제 DB 커넥션이 닫히는 게 아니라, 풀에서 'Idle 상태'로 반환함.

 

5. 정리 및 유지보수

백그라운드로 동작하는 풀 메인터넌스 스레드가 Idle Timeout, Max Lifetime 등을 기준으로 오래된 커넥션을 교체함.

이때 유효성 검사를 통해 죽어있는 커넥션도 제거함.

 

커넥션 풀 튜닝 전략

1. 적정 풀 크기 결정

너무 작으면 트래픽 처리 시 대기 시간이 늘어날 수 있고, 너무 크면 오히려 DB 자원이 부족해져서 성능이 저하될 수 있음.

애플리케이션의 스레드 수, DB 서버 사양, 처리해야 하는 TPS 등을 종합하여 적절한 풀 크기를 산정해야 함.

 

2. Connection Timeout 설정

너무 짧게 설정하면 애플리케이션에서 불필요하게 예외가 발생할 수 있고, 너무 길면 사용자 응답 지연이 길어질 수 있음.

SLA(Service Level Agreement)에 맞춰 합리적인 시간을 설정해야 함.

 

3. Idle/Max Lifetime 설정

DB나 인프라에서 TCP 연결을 끊는 정책이 있는지, 방화벽 정책, 사용 시나리오 등을 고려해야 함.

너무 긴 시간으로 설정하면 ‘Half-Open’ 커넥션이 남을 수 있고, 너무 짧으면 불필요한 커넥션 생성 비용이 올라감.

 

4. 유효성 검사(Validation Query)

풀에서는 커넥션을 '빌려주기 전' 또는 'Idle 상태'에서 검사할 수 있음.

빈번한 검사는 성능 오버헤드를 유발하지만, 검사 없이는 죽은 커넥션을 잡아내지 못해 장애를 유발할 수 있음.

HikariCP가 지원하는 isValid() 메서드를 사용하는 것이 쿼리를 직접 실행하는 것보다 가벼울 수 있음.

 

5. Leak Detection

커넥션을 빌려간 후 닫지 않는 상황은 결국 풀 고갈로 이어짐.

log나 모니터링 시스템을 통해 누수가 있는지 주기적으로 점검해야 함.

애플리케이션 레벨에서도 try-with-resources(Java) 같은 방식을 통해 close를 자동으로 수행하게 만드는 것이 좋음.

 

운영 모니터링

1. 지표 수집

풀에서 현재 사용 중인 커넥션 수, Idle 상태 커넥션 수, 대기 시간 등을 모니터링하면 문제 조기 파악에 도움이 됨.

예를 들어, HikariCP는 HikariDataSource를 통해 MBean 기반 지표를 제공하기도 함.

 

2. 알람 설정

최대 커넥션 수에 근접하는 상황이 빈번히 발생하면 경고를 주고, 원인을 분석(트래픽 증가, 누수, DB 성능 문제 등)해야 함.

풀 규격 이상의 트래픽이 들어오는다면 애플리케이션 구조나 배포 아키텍처(수평 확장, DB 샤딩 등)을 재검토해야 함.

 

3. 버전 호환성

사용 중인 JDBC 드라이버, DB 서버 버전, 풀 구현체의 버전이 서로 호환되는지 반드시 확인해야 함.

버전 업데이트 시 커넥션 풀 동작 방식이 미묘하게 바뀌거나, 특정 설정 옵션이 추가/제거될 수 있으므로 주의가 필요함.

 

실제 운영 시 시나리오 예시

1. 시스템 부하가 낮을 때

최소 풀 크기만큼 커넥션을 유지하며, 대부분 Idle 상태로 관리됨.

CPU나 메모리 사용률은 높지 않지만, 백엔드 DB와 연결은 유지되고 있어 빠른 응답이 가능함.

 

2. 시스템 부하가 급증할 때

요청 증가로 풀에서 즉시 빌려갈 수 있는 커넥션이 줄어들거나 고갈될 수 있음.

풀은 최대 풀 크기까지 커넥션을 확장하면서, 병렬 처리량을 높임.

만약 최대 풀 크기까지 커넥션이 모두 사용 중이라면, 추가 요청은 타임아웃이 발생하거나 예외가 발생할 수 있음.

 

3. 성능 저하나 장애가 발생했을 때

데이터베이스가 오작동하거나 네트워크 지연이 크게 늘어나면, 커넥션 풀에 쌓이는 요청이 많아지고, 대기 시간이 길어짐.

이 과정에서 제대로 반환되지 않는 커넥션 누수가 있다면, 풀 고갈로 이어져 더 큰 장애로 확산될 수 있음.

 

정리

1. 커넥션 풀의 핵심 목적

커넥션 생성/해제 비용을 절약하고, 제한된 DB 리소스를 효율적으로 관리하기 위함임.

 

2. 설정 파라미터와 모니터링 중요성

최적의 성능을 위해서는 적절한 최소/최대 풀 크기, 타임아웃, 유효성 검증 전략 등을 세심하게 튜닝해야 함.

모니터링 지표(사용 중인 커넥션 수, 대기열, 타임아웃 발생 횟수)를 통해서 실시간 상태를 파악하고, 운영 환경 변화에 대응해야 함.

 

3. HikariCP의 대세화

최근 Java 기반 애플리케이션에서 커넥션 풀이 필요하다면, 성능과 유지보수 측면에서 HikariCP가 최우선으로 고려됨.

 

4. 실수 방지: 커넥션 누수

커넥션 풀 이용 시 가장 흔하고 심각한 문제는 ‘커넥션을 제대로 반환하지 않는 것’임.

try-with-resources(Java) 또는 finally 블록에서 close()를 호출하는 습관을 반드시 지켜야 함.