내용 정정: Aurora MySQL이라는 이유만으로 HikariCP keepaliveTime이 불필요하다고 단정할 수 없습니다. DB·프록시·방화벽의 연결 제한, 드라이버와 HikariCP 버전에 따라 판단해야 합니다. 기존의 “Aurora Proxy” 표기는 AWS 서비스명인 RDS Proxy로 바로잡습니다.
keepaliveTime이 하는 일
HikariCP가 풀의 유휴 연결을 주기적으로 확인하는 설정입니다. 사용 중인 쿼리의 실행 시간을 제한하거나 Failover로 끊긴 트랜잭션을 복구하지는 않습니다. 값은 maxLifetime보다 작아야 하며 기본값·최솟값은 사용 버전의 문서를 확인합니다. HikariCP 공식 설정 문서.
설정 판단 순서
| 확인 항목 | 판단 방향 |
|---|---|
| DB·네트워크 유휴 제한 | 연결이 중간 장비에서 먼저 끊기는지 확인하고 keepalive 적용 검토 |
| maxLifetime | 인프라의 연결 수명 제한에 여유를 두어 설정; 실행 중인 연결은 즉시 강제 폐기하지 않음 |
| idleTimeout | minimumIdle보다 많은 유휴 연결을 줄이는 역할. 고정 크기 풀에서는 효과가 달라짐 |
| connectionTestQuery | JDBC4 isValid를 지원하는 드라이버는 우선 기본 검증 사용 |
| RDS Proxy | Proxy 사용만으로 애플리케이션 풀 설정이 모두 무효가 되는 것은 아님 |
피해야 할 일반화
minimumIdle=10처럼 모든 서비스에 통용되는 숫자는 없습니다. 동시 실행 수와 DB 수용량을 기준으로 풀 크기를 결정합니다. connectionTestQuery는 연결을 빌릴 때마다 무조건 실행되는 쿼리라는 의미가 아니며, exceptionOverride는 예외에 따른 폐기 판단 기능이지 실패한 업무를 자동으로 재실행하는 기능이 아닙니다.
변경 효과 확인
같은 부하 조건에서 설정 전후 연결 생성·검증 오류, active/idle/pending 연결과 응답 지연을 비교합니다. 유휴 뒤 첫 요청 실패와 Failover 중 실패를 따로 재현하고, 실패한 트랜잭션의 재시도·멱등성은 별도로 설계합니다. 측정 없는 “최적값” 대신 엔진·드라이버·풀 버전과 네트워크 제한을 기록하세요.
DB 장애 뒤 커넥션 복구 점검 사례는 Aurora MySQL Signal 11 Crash 분석과 Spring Boot 커넥션 오류 대응 전략에서 이어집니다.