DB 커넥션풀은 얼마나 해야할까?

커넥션 풀(Connection Pool)을 늘려야 하나?

 

백엔드 엔지니어라면 한 번쯤 해봤을 난제임.

특히 "쿼리 실행은 빠른데 반환이 느린" 기묘한 상황은 단순 성능 문제가 아닐 확률이 높음.

 

이런 상황에서 체크해야 할 핵심 포인트들을 정리해봄.

 

---

 

1. 쿼리는 빠른데 왜 '반환'이 느릴까?

쿼리 자체는 DB 엔진에서 10ms 만에 끝났는데, 애플리케이션에서 결과가 오기까지 500ms가 걸린다면 다음 세 가지를 의심해야 함.

• Connection Acquisition Wait (커넥션 획득 대기):
• 애플리케이션이 DB에 "나 일 좀 하게 커넥션 하나만 줘"라고 했는데, 풀에 남는 게 없어서 줄 서서 기다리는 시간임. 쿼리 실행 시간(Execution Time)에는 포함되지 않지만, 전체 응답 시간(Latency)은 박살 남.
• 네트워크 전송 및 직렬화 비용:
• 쿼리는 빨리 끝났지만 결과 데이터셋(Result Set)이 너무 크면, 이걸 네트워크로 쏘고 애플리케이션에서 객체로 변환(Parsing)하는 데 시간이 다 감.
• DB 리턴 후 로직 병목:
• 의외로 DB 문제가 아니라, DB에서 데이터를 가져온 뒤 애플리케이션 단에서 수행하는 복잡한 루프나 로직이 원인일 때가 많음.

 

---

 

2. CPU 스파이크 vs 커넥션 풀의 상관관계

CPU가 높다고 무작정 풀을 늘리면 불에 기름을 붓는 격이 될 수 있음.

• 풀을 늘려야 하는 경우 (Good):
  • DB CPU는 널널한데 애플리케이션 쪽에서 커넥션 부족으로 Timeout이 발생할 때.
  • 동시 접속자(Concurrency)는 많은데 각 쿼리는 매우 가벼울 때.
• 풀을 늘리면 안 되는 경우 (Bad):
  • CPU가 이미 80~90%를 찍고 있을 때: 커넥션을 더 늘리면 DB는 더 많은 프로세스/스레드를 관리해야 함. 이때 발생하는 컨텍스트 스위칭(Context Switching) 오버헤드 때문에 CPU는 더 튀고 성능은 더 떨어지는 악순환에 빠짐.
  • 락(Lock) 경합이 심할 때: 커넥션이 많아질수록 같은 자원을 두고 싸우는 놈들만 늘어남.
  •  

---

 

3. 판단을 위한 체크리스트 (Decision Matrix)

상황별로 어떻게 대응할지 결정할 때 아래 기준을 참고하면 좋음.

지표	상태	판단
DB CPU	여유로움	커넥션 풀을 조금씩 늘려보며 처리량(Throughput) 확인
DB CPU	매우 높음	풀 확장 금지. 쿼리 튜닝이나 인덱스 확인이 우선
Active Connections	Max치 근접	커넥션 부족 가능성 높음. Wait Time 지표 확인 필요
Query Exec Time	빠름	애플리케이션 단의 커넥션 획득 대기열이나 네트워크 확인
Query Exec Time	느림	풀 문제가 아님. 쿼리 자체가 무거워서 CPU를 잡고 있는 것

---

4. 실전 대응 팁

1. 공식부터 적용해보기: PostgreSQL이나 HikariCP에서 추천하는 기본 공식이 있음.무작정 100, 200개 잡는 것보다 서버 코어 수에 맞춰 최적화하는 게 훨씬 효율적임.
   Connections = (Core Count X2) + {Effective Spindle Count}

모니터링 지표 고도화: 단순히 'CPU'만 보지 말고, Connection Wait Time과 Active Sessions를 같이 봐야 함. 쿼리가 빠른데 느리다면 반드시 대기 시간 지표에서 답이 나옴.

Read/Write 분리: CPU가 튀는 게 조회(Select) 때문이라면 풀을 늘릴 게 아니라 Read Replica를 늘려서 부하를 분산하는 게 정석임.

 

---

요약:

쿼리는 빠른데 느리다면 커넥션을 못 잡아서 줄 서 있는 건 아닌지부터 확인하자.

하지만 DB CPU가 이미 징징대고 있다면 커넥션 풀을 늘리는 건 자살행위임.

 

오히려 풀을 줄이는 게 전체 성능에 도움이 될 수도 있음.