DB 커넥션 풀이 필요한 이유에 대해 설명해 주세요.

[chxghee]

• 데이터 베이스 커넥션의 생애주기에 대해 서도 설명해 주세요
• 풀의 크기를 설정할 때 고려해야 할 점에 대해서도 설명해 주세요.

키워드

• 핸드셰이크

[chxghee]

1. 커넥션 풀을 사용하지 않는다면?

커넥션 풀을 사용하지 않는 경우, DB 요청이 발생할 때마다 새로운 연결을 생성하고 종료합니다.

요청 도착
 → DB driver 연결 요청
   → TCP 소켓 생성
     → TCP 3-way handshake
       → DB 인증
         → 쿼리 실행
           → 요청 종료
             → TCP 소켓 close (4-way handshake)

요청 한 번당 TCP 소켓 연결이 하나 생성되고, 요청이 끝나면 즉시 종료됩니다.

---

2. 커넥션 풀을 사용하지 않을 때의 문제점

성능 저하

• 매 요청마다 TCP 연결 handshake 가 발생.
• 매 요청마다 DB 인증 수행
• 네트워크 왕복 비용 증가

자원 낭비

• DB 서버에서 세션 생성과 해제를 반복
• OS 파일 디스크립터 및 메모리 소모 증가

확장성 부족

• 요청 수 증가 시 DB 연결 수가 급격히 증가
• DB max_connections 초과 위험
• 트래픽 증가에 취약한 구조

---

3. 커넥션 풀을 사용한다면?

커넥션 풀은 애플리케이션 시작 시 여러 개의 DB 커넥션을 미리 생성하고, 이를 재사용합니다.

애플리케이션 시작
 → TCP 소켓 여러 개 생성 (스프링 기본 값은 10개의 커넥션)
   → TCP handshake 및 DB 인증 (1회)

요청 도착
 → 커넥션 풀에서 커넥션 획득
   → 쿼리 실행
     → 요청 종료
       → 커넥션 반환 (TCP 연결 유지)

효과

• TCP handshake 및 DB 인증 비용 제거
• DB 세션 재사용
• 커넥션 수 상한 제어 가능
• 안정적인 동시 요청 처리

---

Q. DB 연결은 소켓을 사용하는데 이 소켓을 닫지 않고 계속 사용하면 되는 것 아닌가요?

NO.

다음과 같은 이유들을 생각해 보면 안된다는 것을 쉽게 알 수 있습니다.

• 하나의 TCP 소켓은 여러 요청을 동시에 처리할 수 없다.
• DB 트랜잭션은 커넥션 단위로 관리된다.
• 여러 스레드가 하나의 소켓을 공유하면 요청–응답 순서가 보장되지 않는다.
• 네트워크 장애나 DB 재시작 시 죽은 연결을 감지하고 회수할 수 없다.
• 커넥션 수에 대한 상한선과 대기 제어가 불가능하다.

커넥션 풀은 단순히 소켓을 유지하는 것이 아니라,
여러 개의 소켓을 안전하게 관리하고 재사용하기 위한 관리 계층입니다!

[chxghee]

커넥션 풀 크기 설정 시 고려할 점 (수정중)

커넥션 풀 크기는 “클수록 좋은 값”이 아닙니다.
DB 커넥션은 비싼 자원이기 때문에 필요한 만큼만 적절하게 유지하는 것이 중요합니다.

좀 더 깊게 말해서, DB를 보호하면서 안정적으로 처리할 수 있는 동시성 수준을 기준으로 정해야 합니다.

---

1. DB 서버의 한계

• DB는 동시 연결 수에 제한이 있다.
• 예: max_connections (MySQL, PostgreSQL)

풀 크기는 반드시 다음 조건을 만족해야 한다.

(애플리케이션 수 × 풀 크기) ≤ DB max_connections

이를 넘으면 연결 생성 자체가 실패한다.

---

2. 애플리케이션 동시성 수준

커넥션은 동시에 DB 작업을 수행하는 요청 수만큼만 필요하다.

• 모든 요청이 DB를 쓰는 것은 아니다.
• CPU 연산, 외부 API 호출, 캐시 조회도 존재한다.

풀 크기를 무작정 키우면 대부분의 커넥션은 idle 상태가 된다.

---

3. DB 작업 특성 (짧고 빠른가, 긴가)

• 쿼리가 짧고 빠르면 작은 풀로도 충분하다.
• 쿼리가 오래 걸리면 커넥션 점유 시간이 길어져 더 많은 커넥션이 필요해질 수 있다.

하지만 이 경우에도:

• 풀을 키우기보다
• 쿼리 최적화가 우선이다.

---

4. CPU 코어 수와의 관계

DB 작업은 결국 CPU를 사용한다.

• 커넥션 수가 CPU 코어 수를 크게 초과하면
• 컨텍스트 스위칭 증가
• 오히려 성능 저하 발생

그래서 일반적으로:

풀 크기 ≈ (CPU 코어 수 × 2) 내외

가 출발점으로 자주 사용된다.

---

5. 대기 전략 (백프레셔)

풀 크기는 처리량을 늘리는 도구가 아니라
동시 요청을 제한하는 장치이기도 하다.

• 풀 초과 요청은 대기
• 대기는 자연스러운 백프레셔 역할
• 무제한 연결보다 장애를 늦게, 작게 만든다