'DB 커넥션풀'에 대해 알아보자

 

백엔드 서버와 디비 서버가 있다. 백엔드 서버가 api 요청을 받아 처리하다가 디비에 접근하여 데이터를 조회할 일이 생기면 디비 서버로 쿼리를 요청한다. 디비 서버는 쿼리 요청에 맞게 데이터를 찾아 백엔드 서버로 응답해 줄 것이다. 백엔드 서버는 쿼리 응답을 받고 추가적인 작업을 맞춘 뒤 api 응답을 진행할 것이다.

 

위 상황을 조금만 더 자세히 들여다보자. 백엔드 서버와 디비 서버는 각각 서로 다른 컴퓨터에서 동작을 하기 때문에 쿼리를 요청하고 응답받는 과정에서 네트워크 통신이 일어났을 것이다.

일반적으로 백엔드 서버와 디비 서버 간의 네트워크 통신은 TCP 기반으로 동작한다. TCP 기반의 통신은 높은 송수신 신뢰성이라는 강점을 가진다. TCP 기반의 통신은 연결 지향적인 특징을 가지고 있으므로 본격적으로 데이터를 주고받기 이전에 커넥션을 맺는 과정이 필요하다. (반대로 데이터 송수신이 끝난 뒤에는 커넥션을 끊어주는 과정이 필요하다.)

 

여기서 문제는 커넥션을 맺고 끊어주는 과정이 그리 간단하지 않으며 이에 따른 시간이 소요된다는 것이다. 백엔드 서버와 디비 서버에서 요청/응답을 할 때마다 매번 커넥션을 생성하고 소멸시켜줘야 한다면 시간적인 비용이 많이 발생하게 된다. 이렇게 되면 API 응답 시간도 늘어나게 되고 서비스 성능에 좋지 않은 영향을 끼치게 된다.

 

DBCP(Database Connection Pool)를 이용하면

처음 백엔드 서버를 띄울 때 미리 디비 커넥션을 여러 개 생성하여 커넥션풀을 만들어둔다.

api를 처리하면서 디비에 요청을 해야 하는 경우 생성해 둔 디비 커넥션풀에서 커넥션을 꺼내와서 처리한다. 쿼리 응답 이후에는 사용했던 커넥션을 다시 커넥션풀로 반환한다.

DBCP 설정 방법 (HikariCP / MySql 기준)

디비 커넥션은 백엔드 서버와 디비 서버 사이의 연결이므로 백엔드 서버와 디비 서버 각각에서의 설정 방법을 모두 알아야 한다.

mysql 설정

• max_connections
  • 클라이언트와 맺을 수 있는 최대 커넥션 수
• wait_timeout
  • 커넥션이 inactive 상태(idle)일 때 다시 요청이 오기까지 얼마만큼 기다리다가 close 할 것인지 설정

HikariCP 설정

• minimumIdle
  • 커넥션풀에서 유지하는 최소한의 idle connection 수
  • 기본 값은 maximumPoolSize와 동일 (권장)
• maximumPoolSize
  • pool이 가질 수 있는 최대 커넥션 수 (유휴 커넥션과 사용 중인 커넥션 합쳐서 최대)
• maxLifetime
  • pool에서 커넥션의 최대 수명
  • maxLifetime을 넘기면 idle일 경우 풀에서 바로 제거하고 사용 중이라면 풀로 반환된 후 제거
  • DB의 connection time limit보다 몇 초 짧게 설정하자
• connectionTimeout
  • pool에서 커넥션을 받기 위한 대기 시간

추후 부하 테스트 등을 이용하여 적절한 디비 커넥션 풀 설정을 진행해 보자.