Database Connection Pool

Overview

Connection 생성 비용을 줄이지만 동시에 사용할 수 있는 연결 수를 제한한다.

핵심 원리

Thread만 늘리면 Connection 대기와 요청 지연이 누적될 수 있다.

flowchart LR; A[Request] --> T[Thread Pool]; T --> C[Connection Pool]; C --> D[(Database)]; T -.대기.-> C

실무에서 발생하는 문제

요청 Thread 수, Pool 크기, DB 최대 연결의 곱을 따로 보지 않으면 Pool 대기열이 길어지고 획득 Timeout이 연쇄적으로 발생한다. 느린 Query나 긴 Transaction이 Connection을 오래 점유하는지도 함께 확인한다.

Trade-off

Pool을 크게 하면 대기는 줄 수 있지만 DB Memory와 Context Switching 비용이 늘어난다. 작은 Pool은 DB를 보호하지만 Application 대기를 늘리므로 실제 Query 시간과 동시 요청으로 용량을 정한다.

흔한 오해

Connection Pool은 DB 성능을 높이는 장치가 아니다. 죽은 연결 검증, Transaction 반환, Timeout 계층이 잘못되면 Pool 자체가 장애 전파점이 된다.

Interview Questions

• 이 기술이 해결하는 핵심 문제는 무엇인가?
• 내부에서는 어떤 순서로 동작하는가?
• 운영 환경에서 어떤 지표와 실패 모드를 확인해야 하는가?

왜 필요한가

TCP 연결과 DB 인증을 요청마다 반복하지 않고 제한된 Connection을 재사용한다. 동시에 DB가 감당할 수 있는 연결 수를 넘지 않도록 Application의 Backpressure 경계 역할도 한다.

내부 동작

요청은 Idle Connection을 빌리고 없으면 최대 크기 안에서 생성하거나 대기한다. 사용 뒤 반드시 반환하며, 획득 제한 시간이 지나면 빠르게 실패한다. HikariCP의 maximumPoolSize, connectionTimeout, maxLifetime은 DB와 Network의 종료 정책보다 짧고 일관되게 맞춘다.

Example

초당 200요청이고 Query가 평균 50ms라면 평균 동시 사용량은 단순 근사로 10개지만 P99, Transaction 안의 다중 Query, Spike를 포함해 검증해야 한다. 부하 테스트에서 Active가 상한에 붙고 Pending과 획득 시간이 함께 오르면 증설 전에 느린 Query와 보유 시간을 찾는다.

Production Considerations

Active/Idle/Pending, 획득 시간, 사용 시간, Timeout, DB connection 수를 한 화면에서 본다. Leak Detection은 진단용으로 제한해 사용하고, 배포나 DB Failover 뒤 Stale Connection이 교체되는지 시험한다.

Related Topics

Thread Pool, 부하 테스트, RDS·MSK 연결과 함께 전체 동시성 예산을 계산한다.