Photo by panumas nikhomkhai on Pexels
1. 커넥션 풀 크기 설정이 시스템 안정성에 미치는 영향
새로운 서비스를 배포하거나 대규모 트래픽 이벤트를 앞두고 많은 개발자와 시스템 운용 담당자가 데이터베이스 커넥션 풀(Database Connection Pool, DBCP) 크기를 얼마로 설정해야 할지 고민합니다. 기본 설정값인 10을 그대로 사용하다가 대용량 요청이 몰려 커넥션 고사(Connection Exhaustion) 장애를 겪거나, 반대로 무작정 커넥션 수를 100, 200으로 늘려 데이터베이스 CPU 점유율이 100%에 도달하며 전체 시스템이 마비되는 사고가 빈번하게 발생합니다.
데이터베이스 커넥션은 무한정 늘릴 수 있는 자원이 아닙니다. 커넥션 하나당 일정량의 메모리가 할당되며, 스레드가 늘어날수록 CPU의 컨텍스트 스위칭(Context Switching) 오버헤드가 기하급수적으로 증가합니다. 따라서 시스템의 최대 처리량과 데이터베이스의 하드웨어 스펙을 바탕으로 구체적인 수치를 계산하여 적정 커넥션 풀을 산정해야 합니다.
2. 기본 산정 공식: HikariCP 벤치마크 기준 공식
가장 범용적으로 사용되는 HikariCP 공식 위키에서 제안하는 이론적 적정 커넥션 풀 공식은 다음과 같습니다.
적정 커넥션 수 = (데이터베이스 CPU 코어 수 * 2) + Effective Spindle Count
여기서 Effective Spindle Count는 디스크의 스핀들 수(HDD 기준) 또는 concurrent I/O 처리 용량을 의미합니다. 최근 대부분의 클라우드 환경이나 SSD 기반 데이터베이스 서버에서는 이 값을 1 또는 디스크 채널 수로 산정합니다.
예시 수치 적용
8코어 CPU와 NVMe SSD를 사용하는 데이터베이스 서버 A사가 있다고 가정해 보겠습니다.
- CPU 코어 수: 8
- Effective Spindle Count: 1 (SSD 환경 기준 기본값)
- 계산: (8 * 2) + 1 = 17
이 계산에 따르면 해당 DB 서버 전체에서 받아줄 수 있는 최적의 커넥션 수는 약 17개 내외입니다. 개발자들의 직관과 달리, 8코어 서버에서 단 17~20개의 커넥션만으로도 CPU 병목 없이 최대의 I/O 효율을 낼 수 있습니다.
3. 트래픽(TPS) 및 쿼리 응답 시간 기반의 실무 산정 공식
단일 DB 서버 입장의 한계치 외에도, 애플리케이션 관점에서 필요로 하는 커넥션 수를 수치화해야 합니다. 이때 사용하는 핵심 수식은 리틀의 법칙(Little's Law)에 기반합니다.
필요 커넥션 수 = (Peak TPS * 평균 DB 쿼리 수행 시간(초)) * 여유율(Safety Margin)
실무 구체 사례 및 단계별 계산
온라인 쇼핑몰 운영을 담당하는 B사의 상품 조회 API 환경을 예로 들어 계산해 보겠습니다.
- 목표 Peak TPS 측정: 이벤트 기간 중 산출된 피크 타임 초당 요청 수 = 1,200 TPS
- 평균 DB 쿼리 수행 시간 측정: APM 도구로 측정한 API 1회 호출당 DB 쿼리 누적 수행 시간 = 15ms (0.015초)
- 기본 필요 커넥션 계산: 1,200 TPS * 0.015초 = 18개
- 여유율 반영 (30% 추가): 18 * 1.3 = 23.4개 (올림하여 24개)
따라서 전체 애플리케이션 레이어에서 필요한 동시 DB 커넥션 수는 24개입니다.
애플리케이션 인스턴스 분산 계산
만약 B사가 로드밸런서 하단에 동일한 백엔드 애플리케이션 인스턴스를 4대 운영하고 있다면, 각 인스턴스별 HikariCP maximum-pool-size 설정값은 다음과 같이 나뉩니다.
인스턴스당 커넥션 수 = 전체 필요 커넥션 수 / 인스턴스 개수
24개 / 4대 = 6개 (인스턴스당 maximum-pool-size = 6~8 권장)
4. 조건별 커넥션 풀 산정 비교표
시스템 규모와 Peak TPS, 쿼리 속도에 따른 서버별 적정 커넥션 풀 산정 결과를 비교한 예시 표입니다.
| 구분 | Peak TPS | 평균 쿼리 응답시간 | 앱 인스턴스 수 | 총 필요 커넥션 수 | 인스턴스당 설정값 |
|---|---|---|---|---|---|
| 소규모 서비스 (A) | 200 TPS | 10ms (0.01s) | 2대 | 3개 (여유율 포함) | 5개 (최소 유지) |
| 중규모 서비스 (B) | 1,000 TPS | 20ms (0.02s) | 4대 | 26개 (여유율 포함) | 7개 |
| 대규모 서비스 (C) | 5,000 TPS | 8ms (0.008s) | 10대 | 52개 (여유율 포함) | 6개 |
| 복잡한 집계 서비스 (D) | 500 TPS | 150ms (0.15s) | 5대 | 98개 (여유율 포함) | 20개 |
표에서 확인할 수 있듯이, TPS가 높더라도 쿼리 응답시간이 매우 빠르면 필요한 커넥션 수는 적습니다. 반대로 TPS가 낮더라도 쿼리 응답시간이 길면 훨씬 더 많은 커넥션이 소모됩니다. 따라서 커넥션 풀을 무작정 늘리기 전에 slow query 개선이 우선되어야 합니다.
5. 스레드 풀 교착 상태(Deadlock) 방지를 위한 최소 커넥션 공식
단일 요청 처리 과정에서 하나의 스레드가 2개 이상의 DB 커넥션을 동시에 요구하는 트랜잭션이 존재할 경우, 커넥션 풀 부족으로 인한 교착 상태가 발생할 수 있습니다. 이를 방지하기 위한 최소 커넥션 수 산정 공식은 다음과 같습니다.
최소 필요 커넥션 수 = Thread Count * (Maximum Reserved Connections per Thread - 1) + 1
예를 들어, 애플리케이션의 작업 스레드 풀 크기가 20개이고, 하나의 스레드가 중첩 트랜잭션 처리를 위해 최대 2개의 DB 커넥션을 동시에 사용해야 한다면 다음과 같이 계산합니다.
- 스레드 수 (Thread Count): 20
- 스레드당 최대 동시 점유 커넥션 수: 2
- 계산: 20 * (2 - 1) + 1 = 21
이 경우 maximum-pool-size를 최소 21 이상으로 설정해야 스레드 간 커넥션 획득 대기로 인한 교착 상태를 차단할 수 있습니다.
6. 실무 적용 시 점검 체크리스트
계산된 수치를 실제 운영 환경에 적용하기 전, 다음 항목들을 반드시 확인해야 합니다.
- DB Server max_connections 확인: 모든 애플리케이션 인스턴스의 커넥션 수 합계가 DB 서버의 max_connections 설정값의 80%를 초과하지 않는지 점검합니다.
- Connection Timeout 설정: connection-timeout 시간(기본값 보통 30초)이 너무 길면 장애 발생 시 작업 스레드가 동시 다발적으로 대기 상태에 빠지므로 2000ms~3000ms 수준으로 단축을 검토합니다.
- Idle Timeout 및 Max Lifetime: DB 서버의 wait_timeout 설정값보다 HikariCP의 max-lifetime을 최소 30초 이상 짧게 설정하여 끊어진 커넥션을 참조하는 오류를 예방합니다.
- 부하 테스트 수행: 테스트 환경에서 목표 TPS까지 부하를 가하면서 APM 모니터링을 통해 Connection Wait Time 지표가 급증하지 않는지 검증합니다.
7. 현업 적용을 위한 핵심 실행 항목 요약
- 쿼리 수행 시간 및 Peak TPS 측정: APM 또는 모니터링 도구를 활용하여 피크 타임의 TPS와 DB 쿼리 평균 응답 시간을 수치로 수집하세요.
- 공식 기반 수치 산정: '(Peak TPS * 쿼리 시간) * 1.3 / 인스턴스 수' 공식을 적용하여 인스턴스당 기본 커넥션 수를 결정하세요.
- DB 전체 한계 산정 검증: 전체 애플리케이션 인스턴스 수와 인스턴스당 커넥션 수의 곱이 DB 서버 max_connections의 80% 이내인지 확인하세요.
- 교착 상태 방지 최소 수치 검증: 중첩 트랜잭션이 존재한다면 '스레드 수 * (필요 커넥션 수 - 1) + 1' 수치 이상으로 maximum-pool-size를 보장하세요.