Connection Pool에 대한 생각

커넥션 풀은 단순한 재사용 도구가 아니다.

DBMS의 Connection Pool은 단순히 커넥션을 재사용하기 위한 장치라기보다는, 시스템 전체의 처리량(TPS), 리소스 사용량(CPU, 메모리), 사용자 경험(응답 속도)을 결정짓는 중요한 제어 지점이라고 생각한다.

어떤 DB든, 커넥션 풀은 필수이다.

MySQL과 MongoDB는 서로 다른 데이터베이스 모델을 갖고 있지만, 둘 다 Connection Pool을 사용해야 하는 이유는 동일하다. HTTP 요청이 들어오고 → 애플리케이션이 DB에 쿼리를 날리고 → 결과를 받아오기까지 이 모든 과정은 결국 네트워크 I/O로 이어진다. 만약 이때마다 새로 커넥션을 맺는다면, 커넥션 생성 및 종료에 드는 오버헤드로 인해 TPS는 급격히 낮아지고, 서버는 빠르게 병목에 도달하게 된다. 그래서 커넥션 풀을 사용하는 것은 선택이 아니라 필수다.

중요한 건 '쓴다'가 아니라 '제어한다'는 것

단순히 커넥션 풀을 “쓴다”가 아니라, 어떻게 “제어”하느냐가 중요하다. 이때 기본적으로 고려해야 하는 설정은 크게 세 가지다.

[1] 최대/최소 커넥션 수: 동시 처리량을 계산하라

이 값은 시스템의 동시 요청 처리 용량과 직결되기 때문에, TPS, 평균 쿼리 처리 시간, 서버 리소스(CPU, RAM)를 고려해서 계산해야 한다. 예를 들어 TPS가 200이고, 평균 쿼리 처리 시간이 50ms라면, 초당 200건 * 0.05초 = 10개의 동시 커넥션이 필요하다. 여기에 30%의 여유를 둬서 13~15개 정도로 max pool size를 설정할 수 있다.

[2] 커넥션 대기시간: 사용자 경험에 직결되는 민감한 값

커넥션 풀이 가득 찬 상태에서 새로운 요청이 들어오면, 얼마나 기다릴지를 설정하는 값이다. 너무 길게 설정하면 사용자는 응답이 오지 않아 새로고침을 반복하게 되고, 결국 재시도 루프로 인해 트래픽이 폭증한다. 너무 짧으면 일시적인 부하에도 실패율이 높아진다. 그래서 대기시간은 “서비스 특성”과 “사용자 기대치”를 기반으로 조절해야 한다.

[3] 커넥션 유지 시간: 유휴 자원과 초기 부하의 균형

유휴 커넥션을 얼마 동안 풀 안에 남겨둘지, 또는 커넥션 자체를 얼마나 유지할지를 설정하는 값이다.
새벽같이 요청이 적은 시간에는 커넥션을 빨리 정리하는 게 이득이지만, 다음 날 오전 트래픽이 몰릴 때 커넥션이 전부 끊긴 상태라면, 다시 커넥션을 만드는 오버헤드로 초기 응답 지연이 생길 수 있다. 이를 해결하기 위해 pre-warm 요청을 사용하거나, 유휴 시간을 충분히 늘려서 대응할 수 있다.

튜닝은 병목 위치가 명확할 때만 의미가 있다

이 모든 튜닝 작업은 결국 트래픽의 위치를 정확히 분석하지 않으면 오히려 시스템을 망가뜨릴 수도 있다.
예를 들어 겉으로는 트래픽이 많아 보여도, 실제로는 쿼리 하나가 너무 느려서 TPS가 낮은 상황이라면, 커넥션 풀을 늘리는 건 오히려 부하를 악화시킨다. 특히 DB CPU 사용률이 80% 이상인 상태에서 커넥션 수를 늘리면, context switching 비용이 증가하면서 전체 처리 속도는 더 느려지고, 에러는 더 자주 발생하게 된다.

병목 위치를 먼저 파악하자

정말로 중요한 건 항상 “지금 병목이 어디서 발생하고 있는가?”를 먼저 보는 것이다.
쿼리가 느리다면 EXPLAIN으로 분석하고, 캐시를 도입하거나 쿼리 구조를 개선하고, 필요하면 샤딩이나 읽기 전용 replica로 분산 처리해야 한다. 정말로 커넥션이 모자란 상황이라면, 시스템 전체 리소스를 고려하여 커넥션 풀을 늘리되, 필요하다면 비동기 큐나 대기열 기반 구조로 요청을 우회하거나, 트래픽을 제어하는 구조로 전환하는 것이 진정한 확장성 확보 전략이다.

커넥션 풀은 설계자의 의도를 드러내는 지점

Connection Pool은 단순한 설정값이 아니라, 시스템의 성능과 확장성, 사용자 경험을 제어하는 핵심 설계 지점이다.
단순히 많이 열고, 오래 유지하고, 넉넉하게 잡는다고 해결되는 게 아니다. 진짜 중요한 건 병목의 위치를 정확히 파악하고, 그에 따라 정확하게 필요한 만큼 설정을 조절하고 구조를 개선하는 일이다.