Connection Pool / DB 커넥션 관리

Connection Pool / DB 커넥션 관리
대부분의 백엔드 서버는 데이터베이스(DB) 와 통신하며 동작한다.
쇼핑몰 서버라면 상품 조회, 주문 생성, 결제 기록 저장, 회원 정보 조회 등 거의 모든 작업이 DB와 연결된다.
그렇다면 요청이 올 때마다 DB 연결을 새로 만들면 될까?
당연하게도 아니다
매 요청마다 DB 연결을 만든다면?
DB 커넥션을 생성하는 과정은 생각보다 비용이 크다.
내부적으로 다음 과정이 발생하기 때문이다.
- TCP 연결 생성
- 인증 (username / password)
- 세션 생성
- 커넥션 초기화
이걸 매 요청마다 반복하면 성능이 급격히 떨어진다.
예를 들어서..
초당 1000 요청이 들어오는 서비스를 가정해보자.
요청마다 DB 연결을 새로 만든다면 초당 1000개의 커넥션 생성, 인증, 세션 생성이 발생한다.
DB 서버 부하는 당연히 올라가고, 연결 생성 오버헤드도 무시 못 할 수준이 된다.
그래서 등장한 개념이 바로 Connection Pool이다.
Connection Pool이란?
Connection Pool은 미리 생성해 둔 DB 커넥션을 재사용하는 방식이다.

애플리케이션이 시작될 때 일정 개수의 커넥션을 미리 만들어 두고,
요청이 들어오면 새로 만드는 대신 Pool에서 하나를 빌려 쓴다.
처리가 끝나면 커넥션을 닫는 게 아니라 Pool로 반환한다.
이 방식 덕분에 연결 생성 비용이 줄고, DB 부하도 낮아지고, 응답 속도도 개선된다.
Connection Pool이 없거나 잘못 설정되면?
1. Connection Storm
트래픽이 급증할 때 수많은 DB 연결이 동시에 생성되면서 DB 서버가 감당하지 못하는 상황이다.

풀 사이즈를 인스턴스 수와 DB max connection을 고려해서 설정해야 하는 이유가 여기 있다.
2. Connection Leak
커넥션을 사용한 뒤 Pool로 반환하지 않으면 커넥션이 점점 고갈된다.
특히 예외 처리가 제대로 안 된 코드에서 자주 발생한다. 트랜잭션 도중 예외가 터졌는데 커넥션 반환 로직이 없으면 그냥 누수된다.
Pool 사이즈보다 요청이 많아지면?
바로 에러가 터지는 게 아니라 대기 큐(Queue)에 쌓인다. 커넥션이 반환될 때까지 요청이 줄 서서 기다리는 방식이다.

그래서 Pool 사이즈를 무작정 늘리는 것도 답이 아니다.
DB 자체의 max connection을 초과하면 결국 DB가 터지기 때문이다.
인스턴스 수, DB max connection, 요청량을 모두 고려해서 적절한 Pool 사이즈를 설정해야 한다.