HikariCP Connection Pool 이란?

 

 

문서 개요

💡 spring-boot-starter-data-jpa를 의존성에 추가하면 HikariCP가 자동으로 포함됩니다.

Spring Boot 기본 Connection Pool인 HikariCP의 핵심 설정을 이해하고,

AWS RDS Multi-AZ failover 상황에서 안정적으로 복구하는 방법을 다룹니다.

 

 

1. Connection Pool이란?

DB에 쿼리를 보내려면 먼저 연결(Connection)을 만들어야 합니다.
이 연결을 만드는 데 약 50ms가 걸리는데, 요청마다 만들고 끊으면 낭비입니다.

[Pool 없이] — 요청마다 연결을 새로 만들고 끊음 (느림)

요청1 → 연결 생성(50ms) → 쿼리 → 연결 종료 
요청2 → 연결 생성(50ms) → 쿼리 → 연결 종료 
요청3 → 연결 생성(50ms) → 쿼리 → 연결 종료

[Pool 있으면] — 미리 연결을 만들어놓고 빌려쓰고 반납 (빠름)

Pool: [연결1, 연결2, 연결3, ... 연결10] ← 앱 시작 시 미리 생성

요청1 → 연결1 빌림 → 쿼리 → 반납 
요청2 → 연결2 빌림 → 쿼리 → 반납 
요청3 → 연결1 빌림 → 쿼리 → 반납 ← 반납된 연결 재사용!

 
HikariCP는 Spring Boot가 기본으로 사용하는 Connection Pool 라이브러리입니다.
가장 빠르고 가벼운 것으로 유명합니다. 😊😊
 
 

2. 핵심 설정값 하나씩 이해하기

2-1. connection-timeout — "연결 빌리려고 얼마나 기다릴까?"

connection-timeout: 3000  # 3초

 
Pool에 남은 연결이 없을 때, 새 연결을 받을 때까지 최대 대기 시간입니다.

요청 → Pool에 남은 연결 있어?
         ├─ 있음 → 바로 사용
         └─ 없음 → 3초 기다림...
                    ├─ 3초 안에 반납된 연결 생김 → 사용
                    └─ 3초 지남 → SQLTransientConnectionException 에러!

 
기본값은 30초인데, failover 상황에서 30초를 기다리면 사용자에게 30초간 로딩이 걸립니다.
3초로 줄이면 빨리 실패하고 빨리 재시도할 수 있습니다.

 

 

2-2. keepalive-time — "놀고 있는 연결, 살아있는지 확인하기"

keepalive-time: 60000  # 1분

Pool에서 사용되지 않고 놀고 있는(idle) 연결에 주기적으로 ping을 보내서 살아있는지 확인합니다.
 

Pool: [연결1(사용중), 연결2(대기중), 연결3(대기중)]
                          │               │
                   1분마다 "야 살아있어?" 핑
                          │               │
                   "응!" ← 정상          "..." ← 죽었네
                                                 → 버리고 새 연결 생성

 

왜 필요한가?

Multi-AZ failover가 발생하면:

1. Primary DB가 죽음

2. AWS가 Standby를 새 Primary로 승격 (DNS 변경)

3. 하지만 Pool에 있는 연결들은 아직 "죽은 Primary"를 가리키고 있음!
   Pool: [연결1→죽은DB, 연결2→죽은DB, 연결3→죽은DB]

4. keepalive가 ping을 보냄 → "다 죽었네!" → 전부 제거

5. 새 연결 생성 → DNS가 새 Primary를 가리킴
   Pool: [연결4→새DB, 연결5→새DB, 연결6→새DB]

6. 서비스 복구!

 
이 설정이 없으면 죽은 연결을 max-lifetime(30분)까지 계속 사용하려고 시도합니다.
그 30분 동안 모든 DB 요청이 실패합니다. 🥲🥲

 

 

2-3. max-lifetime — "연결의 수명"

max-lifetime: 1800000  # 30분

하나의 연결을 최대 30분만 사용하고, 폐기 후 새로 만듭니다.
 

연결1 생성 ──────── 30분 경과 ──────── 폐기 → 새 연결 생성

 
왜 계속 쓰지 않는 걸까?

• 네트워크 장비(방화벽, 로드밸런서)가 오래된 연결을 끊을 수 있음
• DB 설정 변경 시 기존 연결에 반영이 안 될 수 있음
• 메모리 누수 같은 미묘한 문제가 누적될 수 있음

 
주기적으로 교체해서 항상 건강한 연결을 유지하는 것입니다.

AWS RDS는 idle connection을 기본 약 30분 후 끊습니다.

max-lifetime을 30분으로 맞추면 RDS가 끊기 전에 우리가 먼저 교체합니다.

 

 

 

2-4. validation-timeout — "연결이 유효한지 확인하는 시간"

validation-timeout: 2000  # 2초

Pool에서 연결을 꺼낼 때, 이 연결이 아직 쓸 수 있는 상태인지 확인합니다.
그 확인에 최대 2초를 기다립니다.
 

Pool에서 연결 꺼냄 → "이 연결 아직 쓸 수 있어?" (SELECT 1 실행)
                       ├─ 2초 안에 응답 → 사용
                       └─ 2초 초과     → 이 연결 버리고 다른 연결 사용

 

2-5. minimum-idle / maximum-pool-size — "Pool 크기"

minimum-idle: 5         # 최소 5개는 항상 대기
maximum-pool-size: 20   # 최대 20개까지 확장

트래픽 적을 때:
  Pool: [연결1, 연결2, 연결3, 연결4, 연결5]
         └──── 최소 5개는 항상 유지 ────┘

트래픽 많을 때:
  Pool: [연결1, 연결2, ... 연결15, ... 연결20]
         └────── 필요에 따라 최대 20개까지 자동 확장 ──────┘

20개 다 사용 중이면:
  → connection-timeout(3초) 동안 대기
  → 3초 내에 반납된 연결이 없으면 에러

 
 
적정 Pool 크기 공식 (참고):

connections = (CPU 코어 수 * 2) + 유효 디스크 수

예: 2 vCPU 서버
  → (2 * 2) + 1 = 5 ~ 10개가 적정
  → 20개는 여유를 둔 설정

Pool이 너무 크면 DB에 부담이 됩니다. db.t4g.micro는 최대 약 20개 연결을 권장합니다.

 

 

3. 설정 예시 (YAML)

application-prod.yml (Multi-AZ 환경)

spring:
  datasource:
    master:
      jdbc-url: ${SPRING_DATASOURCE_MASTER_JDBC_URL}
      username: ${SPRING_DATASOURCE_MASTER_USERNAME}
      password: ${SPRING_DATASOURCE_MASTER_PASSWORD}
      driver-class-name: org.postgresql.Driver
      # HikariCP 설정
      connection-timeout: 3000       # 3초 — 빠른 실패/재시도
      validation-timeout: 2000       # 2초 — 연결 유효성 검사
      max-lifetime: 1800000          # 30분 — RDS idle timeout에 맞춤
      keepalive-time: 60000          # 1분 — 죽은 연결 감지
      minimum-idle: 5                # 최소 유지 연결 수
      maximum-pool-size: 20          # 최대 연결 수

 

application-dev.yml (단일 인스턴스 환경)

spring:
  datasource:
    master:
      jdbc-url: ${SPRING_DATASOURCE_MASTER_JDBC_URL}
      username: ${SPRING_DATASOURCE_MASTER_USERNAME}
      password: ${SPRING_DATASOURCE_MASTER_PASSWORD}
      driver-class-name: org.postgresql.Driver
      # HikariCP 설정 (Dev는 보수적으로)
      connection-timeout: 3000
      validation-timeout: 2000
      max-lifetime: 1800000
      minimum-idle: 5
      maximum-pool-size: 10          # Dev는 더 작게

 

Dev환경처럼 Multi-AZ failover가 없는 경우 keepalive-time을 넣지 않아도 됩니다.

 

 

 

4. Failover 시 전체 흐름

Multi-AZ failover가 발생했을 때, HikariCP 설정이 어떻게 서비스를 복구하는지 전체 흐름입니다. 🤓

[정상 상태]
  Pool: [연결1→Primary, 연결2→Primary, 연결3→Primary]
  모든 요청 정상 처리 중

          ↓ Primary 장애 발생!

[0초] AWS가 failover 시작
  - Primary 인스턴스 비정상 감지
  - Standby를 새 Primary로 승격 시작
  - DNS 변경 진행 중

          ↓

[0~60초] 요청 실패 구간
  - Pool의 기존 연결로 쿼리 시도 → 실패
  - connection-timeout(3초) 후 빠르게 에러 반환
  - 클라이언트는 재시도 가능

          ↓

[~60초] keepalive가 감지
  - 1분 주기로 idle 연결에 ping → 응답 없음
  - 죽은 연결 전부 Pool에서 제거
  - DNS가 새 Primary를 가리킴

          ↓

[60~120초] 복구
  - 새 요청이 들어옴 → Pool에 연결 없음
  - HikariCP가 새 연결 생성 시도
  - DNS가 새 Primary를 가리키므로 → 새 Primary에 연결 성공!
  - Pool: [연결4→새Primary, 연결5→새Primary]

          ↓

[~120초] 서비스 정상화
  - 모든 요청 정상 처리
  - Pool이 minimum-idle(5개)까지 자동 채움

 

 

 

5. 설정값 요약 표

설정 기본값 권장값 역할

connection-timeout	30초	3초	Pool에서 연결 대기 시간
keepalive-time	0 (비활성)	60초	유휴 연결 생존 확인 주기
max-lifetime	30분	30분	연결 최대 수명
validation-timeout	5초	2초	연결 유효성 검사 시간
minimum-idle	pool size와 동일	5	최소 유지 연결 수
maximum-pool-size	10	10~20	최대 연결 수

 

 

6. 주의사항

Pool 크기와 DB 연결 한계

DB가 허용하는 최대 연결 수 ≥ (서비스 수 × maximum-pool-size)

예: db.t4g.micro (최대 ~20 연결)
  - Event 서비스 Pool: 10개
  - Partner 서비스 Pool: 5개
  - 기타: 5개
  → 합계 20개 → 한계에 가까움

  Pool 크기를 늘리려면 DB 인스턴스 사양도 함께 올려야 합니다.

 

HikariCP 설정 위치 (Spring Boot)

@ConfigurationProperties(prefix = "spring.datasource.master")로 바인딩하는 경우,
HikariCP 속성은 prefix 바로 아래에 위치합니다:

# 올바른 위치
spring.datasource.master:
  jdbc-url: ...
  connection-timeout: 3000     # ← 여기 (prefix 바로 아래)

# 잘못된 위치 (동작 안 함)
spring.datasource.master:
  hikari:                       # ← 이렇게 하면 안 됨
    connection-timeout: 3000