안녕하세요. 문의 사항이 있습니다.
저희가 Spring boot 에서 pool 을 HikariCP를 사용하고 있습니다. 그런데 디비에서 보면 30분 간격으로 active session 수가 올라가면서 cpu가 높아 집니다. 그래서 여러가지를 찾아 보다 보니까 Pool 설정에 maxLifetime의 기본값이 30분으로 되어 있는걸 확인 했습니다.
혹시 해당 값의 작동 방식과 권고하는 설정값은 어떻게 될까요?
문의 드립니다.
2 Likes
난이도가 높은 질문인듯… 아마 저희 Bro분중에 답변가능하신 숨은 고수가 있을꺼요. 
자체로 찾은 답인데.
maxLifetime은 디비와의 커넥션을 건강한 상태로 유지하기 위해서 기본값이 30 분 마다 과거 30분에 생성된 사용중이지 않은 커넥션을 제거합니다. 그러면 풀은 최소 유지수를 지키기 위해서 새로운 커넥션을 맺습니다.
이 과정에서 디비에서 보면 30분 단위로cpu 사용률은 올라가며 동시에 메모리 사용률은 낮아지는 톱니 모양의 그래프가 발견 됩니다.
그래서 일단 해당 파라메터 값을 0 으로 사용안하게 했는데 이게 맞는 방법인지도 궁금합니다.
2 Likes
안녕하세요.
데이터베이스에 대한 전문성이 부족하지만, 작년 데이터베이스 FailOver 검증 진행 과정에서 “maxLifetime” 값을 조정한 적이 있습니다. FailOver 검증은 AWS 클라우드 환경 Aurora for Mysql에서 Mulai-AZ(이중화)에서 Writer 역할을 수행하는 DB 인스턴스를 중단하는 시나리오로 진행 했습니다.
- Aurora 데이터베이스에서 FailOver 수행
- Aurora 클러스터 Reader 역할을 수행하는 인스턴스가 Writer 역할로 승격 (수초 이내 전환, DNS TTL 5초)
- Aurora 클러스터 Writer 역할을 수행하는 인스턴스는 Reader 역할로 전환
데이터베이스 FailOver 과정은 순조롭게 진행되었지만, Aurora 데이터베이스와 연결된 Kubernetes 파드에서는 연결 오류가 다수 발생함. 원인을 확인 해보니, 기존에 연결된 커넥션 Pool을 reflash 하지 않으면 기존 DB 인스턴스를 계속 바라보는 현상이 발생되어 여러 방안(RDS Proxy, AWS JDBC 드라이버 사용 등)들이 있었지만 결정적으로 “maxLifetime” 값을 조정하는 것으로 협의 되었습니다. 기존 maxLifetime 값 30분 → 3분으로 변경 후 다시 데이터베이스 FailOver를 진행한 결과 3분 이내에 연결된 커넥션 Pool을 Reflash하여 데이터베이스와 파드간 연결이 정상화 되었습니다.
maxLifetime 값에 대한 최적의 값은 환경과 상황에 따라 다를 것 같습니다. 제가 운영하는 서비스에서는 재해 복구(DR) 상황에서 DB가 중단될 경우 3분이내 복구가 되는 것을 목표하기 때문에 maxLifetime 값은 3분으로 조정해서 사용하고 있고 maxLifetime 값을 1분 이내로 설정해서 사용하는 b2c 기업도 있습니다. 다만, maxLifetime을 짧게 설정하는 경우 커텍션 Pool이 자주 재생성되어 CPU 부하 및 커넥션 증가될 위험이 있기 때문에 트레이드 오프(Trade-off)를 잘 고려하여 설정 하는 것을 권장 됩니다. 제가 경험한 내용을 공유 드렸는데, 도움이 될지 모르겠군요.
감사합니다.
1 Like