Database Connection Pool
데이터베이스와 백엔드 서버가 데이터를 주고받을 때 TCP 프로토콜을 기반으로 데이터를 전달받음.
TCP 를 기반으로 데이터를 송수신하기 위해서는 매번 connection 을 열고 닫아줘야하는데 이때 시간적인 비용이 발생함 → 서비스 성능에 좋지 않음
DBCP
커넥션 N 개를 미리 열어놓고 connection 을 반환하는 방식으로 연결을 수립하고 종료하는 시간을 절약하는 방식으로 동작함
설정방법
백엔드 서버와 데이터베이스 서버에서의 설정을 통해 명시할 수 있음
MySQL
- max_connections
- client 와 맺을 수 있는 최대 connection 수
- wait_timeout
- connection 이 inactive 할 때 다시 요청이 오기까지 얼마의 시간이 지난뒤 close 할지를 결정
- 백엔드에서 비정상적으로 connection 이 종료되었을때
- connection 을 다쓰고 반환을 하지 않았을 때
- 네트워크 단절 상태가 발생했을 때
- connection 이 inactive 할 때 다시 요청이 오기까지 얼마의 시간이 지난뒤 close 할지를 결정
DBCP 설정 (Hikari 기준)
- minimumIdle
- pool 에서 유지하는 최소한의 idle connection 수
- idle connection 수가 minimumIdle 보다 작고, 전체 connection 수도 maximumPoolSize 보다 작다면 신속하게 추가 connection 수를 만든다.
- 기본값은 maximumPoolSize와 동일함 (pool_size 고정)
- 트래픽이 밀려올경우 바로 데이터를 주고 받을 수있게
- 만약 minimumIdle connection 수가 작으면 커넥션을 수립하는 과정에서의 오버헤드가 발생할 수 있기 때문에
- maximumPoolSize
- pool 이 가질 수 있는 최대 connection 수
- idle 과 active (in-use) connection 합쳐서 최대 수
- maxLifeTime
- pool 에서 connection 의 최대 수명
- maxLifeTime 을 넘기면 Idle 일경우 pool에서 바로 제거, active 인 경우 pool로 반환된 후 제거 (pool 로 반환 안되면 maxLifeTime 동작하지 않음)
- pool 로 반환을 잘 시켜주는 것이 중요함
- DB의 wait time 보다 짧게 설정해야함 (why?)
- 커넥션 요청중간에 wait timeout 으로 연결이 끊길 수 있기 대문에
- connectionTimeout
- pool 에서 connection 을 받기 위해 대기하는 시간
- client 타입에 따라서 적절하게 설정해야함
적절한 connection 수를 찾기 위한 과정
- 모니터링 환경 구축 (서버 리소스, 서버 스레드, DBCP 등)
- 백엔드 시스템 부하 테스트
- request per second
- avg per respond
- 백엔드 서버, DB 서버의 CPU, MEM 등 리소스 확인
- thread per request 라면 active thread 수 확인
- DBCP 의 active connection 수 확인
- 사용할 백엔드 서버 수를 고려하여 DBCP 의 max pool size 결정
참고
https://d2.naver.com/helloworld/5102792
https://www.youtube.com/watch?v=zowzVqx3MQ4&list=PLcXyemr8ZeoREWGhhZi5FZs6cvymjIBVe&index=30
'데이터베이스' 카테고리의 다른 글
[데이터베이스] - 2Phase Commit (0) | 2024.02.11 |
---|---|
[MongoDB] - MongoDB Replicaset (0) | 2024.01.10 |
[데이터베이스] - 2PL 과 LOCK (0) | 2024.01.04 |
[데이터베이스] - 트랜잭션 동시성 제어 (2) (1) | 2024.01.04 |
[데이터베이스] - 트랜잭션 동시성 제어 (1) (0) | 2024.01.04 |