DBCP (DB connection pool)

유튜브 채널 쉬운코드의 강의 영상으로 공부하면서 작성한 게시글입니다.

---

DBCP

백엔드 서버와 db서버간의 커넥션을 미리 만들어두고 풀링해서 사용하는 기법.

백엔드 서버와 db서버 사이에서 쿼리를 요청하고 응답할 때 tcp기반 connection을 열고, 닫는다. 매 쿼리 요청마다 커넥션을 열고 닫으면 시간적인 비용이 발생하고 서비스 성능에 좋지 않다. 이 문제를 해결하기위해 DBCP를 사용한다.

본격적으로 백엔드 서버가 API요청을 받기 전에 미리 DB서버와 connection을 만들어둔다. 그리고 어플리케이션에서 이 커넥션을 모아놓고 꺼내 쓰고 넣고하는 pool로 관리한다. 이후에 API요청이 오면 pool에서 커넥션을 하나 요청해서 받은 뒤에 db쿼리 요청/응답을 마치고 커넥션을 닫는게 아니라 다시 풀에 반환한다.

 

DBCP 설정 방법

백엔드 서버와 DB서버 각각에서 설정 방법을 알아야 한다.

 

DB 서버측 설정 (Mysql 기준)

max_connections

db가 client와 맺을 수 있는 최대 커넥션 수.

모든 커넥션을 하나의 서버와 연결하는건 어떨까? 별로 좋지 않다.

만약 최대치가 4인데 4개를 모두 하나의 백엔드 서버와 연결했다면 이후 백엔드 서버에 트래픽이 몰려서 서버가 늘어나면 새로생긴 서버는 DB와 커넥션을 맺을 수 없기 때문.

 

wait_timeout

connection이 inactive할 때 다시 요청이 오기까지 얼마의 시간을 기다린 뒤에 close 할 것인지를 결정하는 파라미터

일반적인 상황이라면 백엔드 서버에서 커넥션을 close하면 db 서버에서도 확인하고 커넥션을 제거한다. 하지만 서버측에서 비정상적인 커넥션 종료, 커넥션을 다 썼는데 반환을 안함, 네트워크 단절과 같은 이유로 비정상적인 상태가 되면 DB입장에서는 이 커넥션이 정상인지 아닌지 확인할 수 없다. 그러한 커넥션이 많아지면 DB서버에 안좋은 영향을 미치기 때문에 적절한 시점에서 이 문제를 해결해야한다. 그 때 사용되는 파라미터. 예를들어 60초로 설정하면 마지막 요청으로부터 60초동안 아무런 요청이 오지 않는다면 이 연결을 db서버에서도 끊는다.

 

백엔드 서버측 설정 (Spring HikariCP 기준)

minumumIdle

풀에서 유지하는 최소한의 idel connection 수

idel connection 수가 minimumIdle보다 작고, 전체 커넥션 수도 maximumPoolSize보다 작다면 신속하게 추가로 커넥션을 만든다.

기본값은 maximumPoolSize와 동일(= pool size 고정). 커넥션을 만들어주는 비용이 크기때문에 계속 최대치로 갖고있는 것.

maximumPoolSize

pool이 가질 수 있는 커넥션 수

idle과 active connection 합쳐서 최대 수

maxLifetime

풀에서 커넥션의 최대 수명

maxLifetime을 넘기면 idle일 경우 풀에서 바로 제거. active인 경우 pool로 반환된 후 제거.

그런데 사용도 안하면서 풀로 반환이 안되면 active상태라 maxLifetime은 동작 안한다. 이러면 db측에서 먼저 커넥션을 끊을테고 이후에 백엔드서버에서 그 커넥션으로 요청을 보내도 예외를 뱉을것이다. 그래서 다 쓴 커넥션을 풀에 잘 반환시키는게 중요하다.

DB의 connection time limit보다 2~5초정도 짧게 설정해야 한다. 양쪽 다 60초라면 요청을 보냈는데 딱 db에서 커넥션을 끊을수도 있기 때문.

connectionTimeout

풀에서 커넥션을 받기 위한 대기시간. 모든 커넥션이 사용중일 때 정해진 시간까지 기다리다가 예외를 받는다.

시간을 몇초로 설정할지는 잘 생각해봐야 한다.

 

적절한 커넥션 수를 찾기 위한 과정 (강의자 개인적인 의견)

백엔드서버 여러개, Primary DB서버, secondary DB서버들이 있다고 해보자.

• 메인 DB의 max_connections = 30
• 백엔드서버 2개에 각 maximumPoolSize = 5

하드웨어적으로, 트래픽이 몰리게 된다면 지금 설정한 파라미터들이 적절한가? 할 수 있다.

1. 모니터링 환경 구축 (서버 리소스, 서버 스레드 수, DBCP 등등)

2. 백엔드 시스템 부하 테스트 : nGrinder와 같은 부하테스트 툴이 있다.(웹)

3. request per second, avg response time 확인

이런식으로 그래프가 나올텐데 부하가 어느 포인트부터 그래프가 꺾인다. 성능이 안좋아 지는것.

그런 포인트들에서 모니터링 지표들을 살펴보는 것.

백엔드 서버 DB서버 CPU, 메모리 등 사용률 확인

백엔드 서버 사용률이 문제면 백엔드서버 증설

DB 서버 사용률이 문제면 secondary 서버 추가, 캐시 레이어, 샤딩 등등의 수단 사용.

그런데 둘다 괜찮다?

thread per request 모델이라면 active thread 수 확인. 만약 thread를 다 쓰고있다면 쓰레드를 늘린다. 아니면 전체쓰레드 20개중에 10개만 active상태라면 DBCP의 active connection 수 확인. 이걸 다 쓰고있다면 maximumpoolsize 늘려본다. 더 늘리다가 DB서버의 max_connections와 같아졌는데도 자원이 널널하면 max_connections를 늘려보는 식.

이런 과정을 반복해보면서 확인할 수 있다.