DBCP(Database Connection Pool)

DB와 백엔드는 TCP를 통하여 통신하는데, 이때 커넥션 시작과 종료에 3-way handshake와 4-way handshake가 발생하여 비용이 많이 든다
이를 해결하기 위해 미리 커넥션을 만들어두고 필요할 때 사용하는 기술이 DBCP이다.

커넥션 풀에 커넥션들을 미리 맺어두고 필요할때 pool에서 커넥션을 가져오고 사용 후 pool에 반납

DB 설정

• max_connections : client와 맺을 수 있는 최대 connection 수
• wait_timeout : 커넥션이 유지되고 있지만, 아무 요청이 오지않을 때 얼마나 기다리고 close 할지 설정
  • 마지막 요청이후 wait_timeout 만큼 요청이 없어도 대기, 시간 지나면 close
  • 시간내에 요청이 오면 시간을 0초로 초기화
  • 백엔드 측의 비정상적인 connection 종료나 네트워크 오류에 대한 대응

DBCP 설정(백엔드측 설정)

• minimumIdle : pool에서 유지하는 최소한의 idle connection 수
  • pool에서 아무것도 안하고 대기하고 있는 connection을 최소 몇개로 할지
• maximumPoolSize : pool에서 유지할 수 있는 최대 connection 수
  • idle과 active를 합쳐서 최대 몇개로 할지
  • 일반적으로 minimumIdle와 같은 값으로 설정
  • 사용할 백엔드 서버 수를 고려하여 설정정

minimumIdle와 maximumPoolSize의 설정이 충돌할 시에는 maximumPoolSize가 우선권을 가진다.
요청이 많아지면 여유분의 minimumIdle를 만들어야하지만
만약 만들었을때, maximumPoolSize를 초과하면 더 만들지 않음.

• maxLifetime : pool에서 커넥션 최대 수명
  • idle 상태가 이 시간을 넘기면 바로 close
  • active 상태로 사용 중이면 pool로 반환되고 close
  • pool로 반환되지 않으면(active 이면) close되지 않음
  • wait_timeout보다 몇 초 짧게 설정 권장

maxLifetime이 wait_timeout보다 같거나 길면 문제 발생
active이지만 실제로 사용되지 않는(또는 버그로 반환되지 않는) 커넥션은 백엔드에서 close되지 않음
하지만 해당 커넥션은 DB에서 wait_timeout에 의해 종료됨
백엔드에서는 DB에서 종료된 것을 모르고 다시 사용하려 하면 에러 발생

• connectionTimeout : pool에서 커넥션을 빌려오는데 최대 대기 시간

백엔드드 성능 테스트와 문제 찾기

1. 백엔드 부하 테스트로 request per second와 avg response time 측정
2. 해당 지표의 변곡점 찾기

1초당 처리되는 요청이 더 늘어나지 않는다 => 문제 발생
요청 1개당 처리되는 시간이 급격하게 늘어난다 => 문제 발생

3. 백엔드의 CPU와 Memory 사용량 확인 => 리소스 사용 높을 시 백엔드 컨테이너 혹은 서버 추가
4. DB의 CPU와 Memory 사용량 확인 => 리소스 사용 높을 시 레플리카, 캐리 레이어(캐시 서버), 샤딩 등
5. thread per request(spring boot 등) 모델 이라면 active thread 확인(쓰레드가 모자란지 혹은 너무 많은지)
6. DB의 active connection 확인(최대 커넥션만큼 다 사용하고 있는지) => maximumPoolSize와 max_connections 늘리기