(데이터베이스) DBCP 왜 쓸까? 안쓰면 뭐가 안좋아질까? + DBCP 관련 정리

DB 커넥션 오버헤드: 단순한 열고 닫기가 아니다

1. 커넥션 오버헤드란?

DB 커넥션을 열고 닫는 작업은 단순한 네트워크 통신을 넘어서서 다음과 같은 리소스 비용이 발생한다.

📌 네트워크 관점

• open connection: TCP 3-way-handshake
• close connection: TCP 4-way-handshake
• 각 핸드셰이크마다 커널-유저 공간 전환, 시스템 콜 비용, 패킷 송수신 대기가 발생한다.

📌 OS 관점 (컨텍스트 스위칭 + IO 대기)

• DB 작업은 대부분 IO-bound (대기 시간이 많음)
• 요청마다 새로운 스레드 → 스레드 생성/종료 비용
• OS는 스레드 전환 시 컨텍스트 스위칭 비용이 발생
  → CPU 캐시 무효화, 레지스터 백업/복구 비용
• 대기 시간이 많은 DB 작업은 결국 낮은 처리량과 높은 레이턴시로 이어짐

👉 따라서 DBCP는 커넥션을 재사용함으로써 위와 같은 비용을 크게 줄이는 효과가 있다.

---

2. 커넥션 풀 크기, 많다고 좋은가?

❗️커넥션 풀을 크게 잡는다고 항상 좋은 게 아니다.

커넥션 풀이 너무 크면?

• DB 서버 입장에서 동시 커넥션 수가 증가 → 메모리, 커널 스레드, 쿼리 처리 병목
• 대부분의 RDBMS는 동시에 처리 가능한 쿼리 수에 제한이 있음
• 연결만 많고 CPU나 IO가 한정되면 → DB 응답이 느려짐 → 백엔드 전체가 대기 상태

커넥션 풀이 너무 작으면?

• 트래픽 피크 시간에 커넥션 풀 고갈
• 백엔드 스레드는 DB 커넥션을 기다리며 blocked 상태
• 이는 곧 HTTP 요청 처리 지연 → 응답 타임아웃 → 서비스 장애로 이어질 수 있음

스레드풀과의 유사점

• 커넥션 풀도 일종의 자원 풀로, 스레드풀처럼 한정된 자원을 재사용함
• 둘 다:
  • 자원이 너무 많으면 오히려 병목 발생 (문맥 전환, CPU 오버헤드)
  • 자원이 너무 적으면 대기 큐 적체 → 처리 지연

👉 최적의 풀 크기는 다음을 기준으로 설정:

• 평균/최대 TPS
• DB 처리 속도
• 백엔드에서 비동기 처리 유무
• DB 서버의 max_connections 여유

---

🔁 결론 요약

항목설명

커넥션 열고 닫기	TCP 통신 + IO 대기 + 컨텍스트 스위칭 → 고비용
커넥션 풀 목적	커넥션 재사용으로 오버헤드 최소화
너무 큰 풀	DB 리소스 고갈, 응답 지연
너무 작은 풀	요청 처리 대기 → 백엔드 지연 발생
적정 풀 크기	시스템 리소스와 트래픽 분석 기반으로 조정 필요