데이터베이스 커넥션은 데이터베이스와의 연결을 효율적으로 관리하기 위해 TCP 연결을 사용한다. 데이터베이스 커넥션은 생성과 종료에 비용이 많이 들기 때문에, 커넥션 풀을 사용하여 이러한 비용을 줄인다. 커넥션 풀을 통해 미리 생성된 커넥션을 재사용함으로써 성능을 향상시키고 자원 소모를 줄인다. 각 커넥션의 설정은 클라이언트와 DB 서버 양쪽에서 모두 잘 이해하고 설정해야 한다.
DB 서버 설정
1. max_connections
- 클라이언트와 DB 서버 간의 최대 동시 연결 수를 설정한다.
max_connections
값이 4로 설정된 경우, 데이터베이스 서버는 동시에 최대 4개의 클라이언트 연결을 허용한다.- DBCP의 최대 커넥션 수(
maxTotal
)가 DB 서버의max_connections
보다 크면, DB 서버가 허용할 수 있는 최대 커넥션 수를 초과할 수 없다. 즉,max_connections
수가 4이고 DBCP의 최대 커넥션 수가 4라면, 다른 클라이언트는 추가 커넥션을 맺을 수 없다.
2. wait_timeout
- 커넥션이 비활성 상태일 때, 다시 요청이 올 때까지 대기하는 시간이다. 시간이 지나면 비활성 커넥션이 종료된다.
- 커넥션이
wait_timeout
시간 동안 비활성 상태이면 종료된다. 그러나 이 시간 내에 요청이 다시 오면 타이머가 0으로 초기화된다. - 사용 이유:
- 비정상적인 커넥션 종료를 처리하기 위해.
- 커넥션을 사용하고 반환하지 않은 경우 처리.
- 네트워크 단절로 인한 비활성 커넥션 처리.
HikariCP 설정
1. minimumIdle
- 풀에서 유지하는 최소한의 유휴 커넥션 수를 지정한다.
- 유휴 커넥션 수가
minimumIdle
보다 적고, 총 커넥션 수가maximumPoolSize
보다 작으면, HikariCP는 신속하게 추가 커넥션을 생성한다. 기본값은maximumPoolSize
와 동일하며, 이는 풀의 크기를 동적으로 조절할 수 있는 권장 설정이다.
2. maximumPoolSize
- 풀에서 가질 수 있는 최대 커넥션 수를 지정한다.
- 커넥션 풀의 유휴 커넥션과 사용 중인 커넥션을 모두 합쳐서 설정한 최대 수를 초과할 수 없다.
minimumIdle
보다 우선 순위가 높으며, 풀의 크기를 제한한다.
3. maxLifetime
- 풀에서 커넥션의 최대 수명을 설정한다.
- 커넥션이
maxLifetime
을 초과하면, 유휴 상태일 경우 바로 제거되며, 사용 중인 상태일 경우 사용 후 풀로 반환된 후 제거된다. 이 설정은 데이터베이스의wait_timeout
보다 몇 초 짧게 설정하는 것이 좋다.
4. connectionTimeout
- 커넥션을 풀에서 요청하기 위해 대기할 최대 시간을 설정한다.
- 클라이언트가 커넥션을 요청했을 때, 지정된 시간 내에 커넥션을 받을 수 없는 경우
SQLException
이 발생한다. 이 설정은 커넥션 풀에서 커넥션을 대기할 시간을 조절한다.
적절한 커넥션 수를 찾기 위한 과정
- 모니터링 환경 구축: 서버 리소스, 서버 스레드 수, DBCP 설정 등을 포함하여 모니터링 환경을 구축한다.
- 백엔드 시스템 부하 테스트:
nGrinder
와 같은 부하 테스트 도구를 사용하여 시스템의 성능을 평가한다. - Request Per Second (RPS): 초당 처리할 수 있는 요청의 수를 측정한다.
- Average Response Time: 요청에 대한 평균 응답 시간을 측정한다.
- 그래프의 변곡점 분석:
- CPU, 메모리 등 리소스 사용률을 확인한다.
- 스레드 기반 모델을 사용하는 경우, 활성 스레드 수를 확인한다.
- DBCP의 활성 커넥션 수를 확인한다.
- 백엔드 서버 수를 고려하여 DBCP의 최대 풀 크기(
maxPoolSize
)를 결정한다. - 위의 요소들을 종합적으로 고려하여 적절한 커넥션 수를 설정한다.
728x90
'Database' 카테고리의 다른 글
[DB] MVCC (Multiversion Concurrency Control) (0) | 2024.08.17 |
---|---|
[DB] Lock & 2PL (0) | 2024.08.17 |
[DB] Isolation Level (0) | 2024.08.16 |
[DB] Recoverability (0) | 2024.08.16 |
[DB] Serializability (0) | 2024.08.16 |