Aurora MySQL의 숨겨진 idle close 동작 — HikariCP "Failed to validate connection" 추적기
Summary
왜 30초마다 핑을 날리는데 연결이 끊길까? Aurora MySQL의 기괴한 타임아웃 비밀
표준 MySQL만 믿다가는 당한다, HikariCP 커넥션 오류 뒤에 숨겨진 Aurora의 비표준 동작 완벽 분석
HikariCP의 keepalive 옵션이 무색하게 커넥션이 끊기는 현상을 추적하며 발견한 Aurora MySQL의 독특한 동작 방식을 다룹니다. 커뮤니티 MySQL과 달리 Aurora가 왜 두 가지 타임아웃 값을 모두 참조하는지 아키텍처 관점에서 설명하고, 실무에서 바로 적용 가능한 DB 파라미터 최적화 가이드를 제공합니다.
- 01표준 MySQL과 달리 Aurora는 wait_timeout과 interactive_timeout 중 작은 값을 최종 타임아웃으로 선택함
- 02Aurora의 thread-pool 아키텍처와 별도 모니터링 스레드가 idle 커넥션을 관리하는 내부 메커니즘 분석
- 03JDBC의 interactiveClient 옵션이 false임에도 interactive_timeout이 영향을 주는 이유 규명
- 04AWS 공식 문서에서도 확인하기 어려운 60초 주기 모니터 스레드의 실체 확인
- 05커넥션 풀 유지 실패 문제를 해결하기 위한 DB 파라미터 그룹 설정 모범 사례 제시
RECOMMENDATION
Aurora MySQL을 사용하면서 HikariCP의 커넥션 검증 실패 로그가 뜬다면, 클라이언트 설정보다 먼저 DB 파라미터 그룹의 두 타임아웃 값이 동일한지 확인하십시오.
The Problem
HikariCP의 keepaliveTime이 30초로 설정되어 있음에도 불구하고, 서버 측에서 연결이 먼저 끊겨 'Failed to validate connection' 경고 로그가 분당 다수 발생하는 현상이 나타났습니다.
The Solution
표준 MySQL 동작 모델과 다른 Aurora MySQL의 내부 메커니즘을 분석하여, DB 파라미터 그룹의 interactive_timeout이 non-interactive 연결에도 영향을 준다는 사실을 확인하고 두 타임아웃 값을 동일하게 상향 조정했습니다.
The Result
DB 파라미터 수정 후 즉시 경고 로그가 중단되었으며, Aurora의 thread-pool 및 모니터 스레드 기반 idle 세션 관리 방식을 규명하여 향후 유사 문제에 대한 진단 가이드를 마련했습니다.
Trade-off
Aurora의 idle 종료 판정은 별도의 모니터 스레드가 약 60초 주기로 수행하므로, 설정한 타임아웃 값과 실제 종료 시점 사이에 수십 초의 오차가 발생할 수 있는 불확실성이 존재합니다.
Key Concepts
More from 여기어때
View all posts from 여기어때
EKS 컨테이너 메모리 스파이크 추적기
EKSPage CacheLogback2일 전SRE 업무에 AI 녹여내기 — 2편: Alert Adviser로 장애 원인 분석 자동화
GrafanaMCPSlack Bot6일 전SRE 업무에 AI 녹여내기 — 1편: Smart RI Calc로 인프라 비용 산정 자동화
SREAWS KarpenterCost Estimation6일 전WebFlux 전환 부하 테스트를 다시 쓴 이야기
WebFluxSpring BootLoad Testing1주 전데드락을 해결하려다, 락을 줄이게 된 이야기
MySQL InnoDBDeadlockPessimistic Lock1주 전
