Connection Pool과 Size 선정 기준 (with HikariCP)

 

 

🔍 1. 커넥션 풀(Connection Pool)이란?

데이터베이스와 연결(Connection)을 미리 만들어 풀(Pool)에 보관해두고, 요청이 들어오면 즉시 꺼내서 사용하고 다시 반납하는 구조.

 

✅ 장점

• 매번 DB 연결을 새로 만들지 않아도 돼서 속도 빠름
• DB 커넥션 수를 제한해 과부하 방지

 

🔍 2. HikariCP란?

• Spring Boot의 기본 커넥션 풀 구현체.
• 빠르고 가벼운 커넥션 풀로, 성능이 뛰어나서 널리 쓰인다.
  
  

📌 3. HikariCP 설정

✅ 3-0. yaml 예시

spring:
  datasource:
    hikari:
      maximum-pool-size: 30
      minimum-idle: 30
      idle-timeout: 60000
      connection-timeout: 3000

 

✅ 3-1. maximum-pool-size

• 커넥션 풀에 생성될 수 있는 최대 커넥션 수
• 예: 30 → 동시에 30개의 커넥션까지 생성 가능
  
• 너무 작으면 요청 대기 많아지고, 너무 크면 DB에 부하 생김
  
  

📖 예시

사용자 100명이 동시에 접속하지만 DB 작업은 20명 정도만 동시에 발생한다면, 30 정도가 적절할 수 있다.

사용자 1명이 병렬로 여러개 요청 할 수 있음.

 

✅ 3-2. minimum-idle

• 유휴 상태로 유지되는 커넥션 수
• 예: 30 → 항상 30개의 커넥션을 유지 (풀 고정 느낌)
• 요청이 없더라도 30개를 만들어 놓기 때문에, 초기 응답이 빠름
  
  

🔥 주의

minimum-idle이 maximum-pool-size보다 크면 무시되고, 기본값 maximum-pool-size로 설정됨  (풀 전체를 항상 대기 상태로 유지)

 

✅ 3-3. idle-timeout

• 유휴 커넥션을 정리하는 시간 (ms)
• 예: 60000 → 60초 이상 아무 작업도 안 한 커넥션은 정리됨
• 단, 최소 유휴 수(minimum-idle)는 항상 유지되기 때문에
  60초 지나도 정리되지 않을 수 있음.
  
  

⭐ 기본값: 600000ms (10분)
🔥 최소 10초 이상 (10000)으로 설정해야 함

 

✅ 3-4. connection-timeout

• 커넥션을 얻기 위해 기다리는 최대 시간 (ms)
• 예: 3000 → 3초 동안 커넥션이 없으면 예외 발생 (ex: SQLTransientConnectionException)
• 너무 짧으면 오류 빈번, 너무 길면 사용자 응답 지연
  
  

📖 예시

DB가 순간적으로 부하 걸릴 때, 커넥션이 없으면 3초 기다리다 포기하게 함

 

🚀 3-5. 핵심 정리

항목명	의미	추천값 예시
maximum-pool-size	동시에 연결 가능한 최대 커넥션 수	20~50
minimum-idle	항상 유지할 유휴 커넥션 수	maximum과 같게 설정 시 성능↑
idle-timeout	유휴 커넥션을 회수하는 시간	60000~300000
connection-timeout	커넥션 못 얻었을 때 최대 대기 시간	2000~5000

 

 

⚠️ 주의할 점

• maximum-pool-size는 DB 서버의 최대 커넥션 수를 초과하면 안 됨.
  
• 유휴 커넥션이 많아지면, 메모리 낭비와 DB 커넥션 고갈 우려 있음.
  
• 실제 서비스 환경에 따라 조정 필수 (트래픽 분석, DB 설정 참고)
  
  

📌 4. 실전에서  minimum-idle 설정

🤔 4-1. minimum-idle을 설정하면 생길 수 있는 상황

1. minimum-idle: 5 설정
   
2. 사용자가 요청해서 커넥션 5개를 다 사용 중
   
3. 추가 요청이 와서 커넥션 1개를 추가 생성함 → 총 6개
   
4. 요청 끝나면 그 추가 생성된 커넥션은 "idle이 5보다 많으니까" 바로 제거됨
   
5. 그런데 잠시 뒤에 요청 폭주! 커넥션 4개 더 필요!
   → 다시 4개 생성 → 그동안 요청은 대기!
   → ❗ 커넥션 만들 시간 = 응답 지연 발생
   
   

 🚨 핵심 문제 요약

• minimum-idle로 적게 유지하면
  → 트래픽 급증 시 커넥션 생성 지연
  → 응답 느림 / 성능 저하 발생 가능
  
  
• 반면, 풀을 항상 일정하게 유지하면
  → 바로 사용할 커넥션이 있어서 빠름
  → 성능 안정성 높음
  
  

📌 4-2. 그래서 결론은?

🎯 "성능 우선"이면 아래처럼 하자!

minimum-idle: 생략하거나 maximum-pool-size와 동일하게 설정

maximum-pool-size: 예상 동시 접속 수 + 여유분으로 설정

 

⭐ 즉, "풀 사이즈는 고정해라! 유동적인 건 성능 저하의 원인이다!"

새로운 연결을 맺을때까지 시간이 소요되기 때문에 고정적인 성능을 낼 수 없으니 낭비되는 커넥션 자원이 있더라도 minimum과 maximum의 사이즈를 고정시키는게 더 좋다고 한다!

 

 

📌 4-3. 그럼 minimum-idle 왜 만들었을까?

• 리소스 아끼는 게 더 중요한 경우
• AWS Lambda처럼 부하 적은 서버에선 필요 이상으로 연결 유지하면 낭비

 

➡️ 그래서 "성능 vs 리소스 절약"을 개발자가 선택할 수 있게 한 것!

 

🚀4-4. 요약

항목	설정하면 좋은 경우	주의점
minimum-idle 작게 설정	리소스 절약 중요할 때	트래픽 급증 시 커넥션 생성 지연
minimum-idle = maximum-pool-size 또는 생략	성능 우선, 응답속도 중요	메모리/DB 커넥션 자원 많이 씀

 

📌 5. 커넥션 풀 산정 예시 (쪽지 시스템)

예를 들어 "이용자 1000명인 쪽지 시스템"이라면?
👉 핵심은 "평균 동시 요청 수”를 잘 추정하는 것!!

 

✅ 5-1. 쪽지 시스템 특징 분석

• 읽기: 쪽지 목록 보기, 읽기 (DB read)
• 쓰기: 쪽지 보내기 (DB write)
• 주기적 폴링 or 알림 확인: 쪽지 도착 여부 확인 (read or API polling)
  
  

➡️ 대부분 짧은 요청, 짧은 트랜잭션이 많고,지속적인 커넥션 점유는 드물다.

 

✅ 5-2. 동시 접속 사용자 수 추정

• 이용자 수: 1000명
• 일반적으로 10~20% 정도가 동시 접속 중이라고 봄
  
  

👉 추정 동시 접속자 수: 100~200명. 그러나, 모든 요청이 동시에 DB를 때리는 건 아님!

• 네트워크/프론트 처리 + 캐싱 등으로 분산됨
  
• 동시 DB 커넥션은 그보다 훨씬 적음 -> 실제 DB 커넥션 예상: 10~50개
  
  

✅ 5-3. 커넥션 풀 추천값 (HikariCP 기준)

# application.yml 예시
spring:
  datasource:
    hikari:
      maximum-pool-size: 30      # 예상 동시 커넥션 수 + 여유
      minimum-idle: 30           # 풀 고정으로 빠른 응답
      idle-timeout: 60000        # 1분 이상 유휴면 제거
      connection-timeout: 3000   # 커넥션 못 얻으면 3초만 대기

 

🚀 5-4. 추가 팁

• 피크 타임을 모니터링해서 튜닝 필요
• DB가 감당할 수 있는 최대 커넥션 수도 확인해야 함!
• 캐싱(Memcached, Redis 등) 고려하면 풀 더 작게 해도 됨.