(데이터베이스) 실전에서의 DBCP 설정 최적화: 병목 분석까지

 실전에서의 DBCP 설정 최적화: HikariCP 튜닝부터 병목 분석까지

---

1. 개요: DBCP란 무엇인가?

DBCP(Database Connection Pooling)는 DB 연결(Connection)을 매번 생성·종료하지 않고 재사용하도록 설계된 구조이다. Java/Spring 환경에서는 HikariCP가 가장 널리 사용되는 DBCP 구현체다.

• 매 요청마다 TCP 3-way/4-way handshake를 반복하는 것은 불필요한 I/O 및 컨텍스트 스위칭 비용을 유발한다.
• 따라서 HikariCP 같은 커넥션 풀을 사용하면 성능 최적화 및 리소스 안정성 확보에 유리하다.

---

2. HikariCP 핵심 설정

✅ maxLifetime

• 커넥션 객체의 최대 수명 (ms 단위)
• 유휴 상태일 경우 바로 제거되고, 사용 중일 경우 반환된 후 제거
• DB 서버의 connection timeout보다 몇 초 짧게 설정해야 함
  (예: DB wait_timeout=300s → HikariCP maxLifetime=270000ms)

✅ connectionTimeout

• 커넥션을 가져오기 위해 풀에서 기다리는 최대 시간
• 지정 시간 내 사용 가능한 커넥션이 없으면 예외 발생
• 대개 3~10초 수준으로 설정하며, RPS가 높아질수록 이 값을 줄이고 풀 크기를 확장하는 방향으로 조정

---

3. 커넥션 풀 크기 결정 절차: 실전 접근

✅ 1단계: 모니터링 환경 구축

• APM 도구: Pinpoint, New Relic, Datadog
• 주요 지표: RPS(Requests per second), ART(Average Response Time), Active Threads, Active DB Connections

 

✅ 2단계: 부하 테스트 진행

• 도구: nGrinder, JMeter, Gatling 등
• 목적: 동시 접속, 요청 수 증가에 따른 병목 탐지

✅ 3단계: 지표 분석

• RPS 증가에 따라 ART도 상승하면 병목 의심
• 병목 지점이 WAS인지, DB인지 판단 필요

✅ 4단계: 커넥션 풀/DB 병목 구분

시나리오	의미	조치
Active Thread 수 < Pool Size	DB 대기 없음	문제 없음
Active Thread 수 = Pool Size	커넥션 부족	maximumPoolSize 증가 고려
Pool Size < RPS 대비 부족	커넥션 경합 발생	백엔드 서버 증설 또는 DB 튜닝 필요

 

---

4. 커넥션 풀 크기 설계 전략

❗️커넥션 풀은 많다고 좋은 게 아니다

• 커넥션 수가 많아지면 DB의 max_connections 리소스 한계에 부딪히고,
• 동시에 쿼리 처리 성능이 낮아져 DB 병목을 유발할 수 있다

설계 가이드라인

1. 리소스 사용률 확인.

 

 

2. 어느 구간에서 병목인지 확인 (WAS,DB)

위 상황에서 DB에서 오버헤드가 크다면 DB 쪽에서 시스템 확충 필요

1. secondary   (select쿼리가 많다)

2.cache layer  (db가 직접적인 부하를 받는거를 방)

3.sharding  

* DB 관련 서버 확충에 대해서는 나중에 다른 글로 더 깊게 정리할 예

 

 

3. WAS , DB에 대한 리소스 사용률에는 큰 이슈 없으나 RPS,ART에서 병목이 모니터리 될때

*thread per request 모델이라면 activeThread 수 확인 

원인1. (was poolsize)

1. WAS maximumpoolsize가 5이고 ,  acive Therad도 5라면  maximumpoolsize 가 부족한 것을 의심할 필요 있다.

 

원인2. (db max_connections)

active Therad가  50/100 으로 maximumpoolsize가 여유가 있는데 병목이 있다면?

1. DBCP의   max_connections 수 확인 필요

2. max_connections 수가 active Thread와 동일하다면  늘려줄 필요 있다

 

항목	예시
DB 서버의 max_connections	60
백엔드 서버 수	3대
HikariCP maximumPoolSize	15
합계	15 * 3 = 45 < 60 (적절)

 

👉 팁: WAS가 4대가 될 가능성이 있다면?

• 현재: 3대 * 15 = 45
• 예비로 1대 더 확장할 경우 여유 고려하여 60까지 확보 필요
• 또는 동적으로 커넥션 풀을 확장하거나, DB를 수평 확장(Sharding, Replica)

---

6. 병목 대응 시나리오 정리

병목 위치	원인	대응
WAS	스레드 수 부족 / 커넥션 부족	maximumPoolSize 조정, WAS 수 증가
DB	커넥션 경합, 처리 지연	max_connections 증가, 쿼리 튜닝
전체 병목	아키텍처적 한계	Cache Layer, Read Replica, Sharding 등 구조 개선

 

---

7. 고도화된 대응 전략

✅ DB 성능 향상

• Secondary Read Replica로 읽기 분산
• Redis 등 Cache Layer 도입
• Table 파티셔닝, 인덱싱 튜닝

✅ WAS 확장

• 서버 수 수평 확장
• 부하 분산을 위한 L4 스위칭

---

🔚 마무리: 설정은 데이터 기반으로

HikariCP 설정은 단순한 수치 조정이 아니라 트래픽, 아키텍처, DB 성능을 고려한 종합적인 조정이 필요하다.

설정 기준:

• maxLifetime < DB wait_timeout
• connectionTimeout: 서비스 SLA에 맞게 설정 (3~10초)
• maximumPoolSize: 요청 패턴 및 WAS 수 고려하여 산정
• Active Thread 수 = Pool Size일 경우 → 병목 발생 중

측정하지 않은 튜닝은 의미가 없다.
데이터 기반 튜닝과 병목 추적이 실전 DBCP 설정의 핵심이다.

 

 

사진 출처 - 유튜브 쉬운코드