[Spring] MySQL의 wait_timeout 설정과 HikariCP 6.1.0에 추가된 maxLifeTime 분산 기능

1. MySQL의 wait_timeout 설정과 HikariCP 6.1.0에 추가된 maxLifeTime 분산 기능

---

[ MySQL의 wait_timeout 설정과 커넥션 풀의 maxLifeTime 설정이란? ]

외부 리소스와의 연결을 위해, 반드시 추가해야 하는 설정 중 하나가 타임아웃이다. 타임아웃을 제대로 설정하지 않으면, 다른 컴포넌트의 응답이 느려질 때 애플리케이션 전체가 영향을 받을 수 있다. 대표적으로 MSA 환경에서 외부 API와 통신을 할 때 타임아웃 설정이 중요하다. 타임아웃 설정이 존재하지 않으면, 외부 API의 응답이 지연될 때 애플리케이션의 스레드가 대기 상태에 빠져 전체 서비스의 응답 속도가 느려지며 장애를 전파받을 수 있기 때문이다.

데이터베이스 관점에서도 타임아웃 설정은 매우 중요하다. 데이터베이스는 특정 커넥션이 idle(유휴) 상태로 오래 유지되는 것을 허용하지 않는 경우가 많다. 왜냐하면 죽은 커넥션이 데이터베이스 서버의 자원을 낭비하는 등의 문제를 일으킬 수 있기 때문이다. 따라서 데이터베이스 서버는 일정 시간 이상 유휴 상태인 커넥션을 자동으로 종료하는 타임아웃 설정을 제공한다. 대표적으로 MySQL은 wait_timeout 시간 동안 유휴 상태인 커넥션을 자동으로 종료한다. 이를 통해 서버 자원을 효율적으로 관리하고, 불필요한 커넥션이 서버에 부담을 주지 않도록 한다.

 

 

하지만 애플리케이션 입장에서는 정상 상태의 커넥션인데, 갑자기 데이터베이스 커넥션의 연결이 끊어지면 곤란하다. 따라서 애플리케이션에서는 데이터베이스 커넥션 풀을 사용할 때, 커넥션이 일정 시간 이상 유지되지 않도록 즉, 데이터베이스가 연결을 끊어버리기 전에 애플리케이션이 먼저 끊도록 설정하는 것이 중요하다. 대표적으로 HikariCP는 maxLifetime 설정을 통해 커넥션이 일정 시간 이상 유지되지 않도록 관리할 수 있다. 이 설정을 통해 커넥션이 일정 시간 이상 유지되면, 해당 커넥션을 종료하고 새로운 커넥션을 생성하도록 한다. 이를 통해 데이터베이스 서버와 애플리케이션 간의 커넥션 상태를 일치시키고, 예기치 않은 오류를 방지할 수 있다. 참고로 maxLifeTime에 따라 주기적으로 커넥션이 재생성되는 모습을 확인하고 싶다면, TCP 덤프에서 mysql.protocol == 10 으로 필터링하면 확인할 수 있다.

 

 

 

[ HikariCP 6.1.0에 추가된 maxLifeTime 분산 기능 ]

HikariCP 6.1.0에는 추가된 maxLifeTime 분산 기능이 추가되었다. 해당 설정이 존재하기 이전에는 maxLifetime 설정이 모든 커넥션에 동일하게 적용되었다. 예를 들어, maxLifetime을 30분으로 설정하면, 모든 커넥션이 생성된 시점부터 30분 후에 종료되었다. 이로 인해 커넥션 풀 내의 모든 커넥션이 동시에 종료되는 현상이 발생할 수 있었다. 이러한 현상은 커넥션 풀이 갑자기 비어버리는 상황을 초래할 수 있으며, 이는 애플리케이션의 성능 저하나 장애로 이어질 수 있다. 이러한 문제를 해결하기 위해 HikariCP 6.1.0 버전부터는 기본적으로 maxLifeTime의 25% 를 분산시키는 기능이 추가되었다. 이를 통해 maxLifetime이 동일하게 설정되어 있더라도, 각 커넥션의 실제 수명은 다르게 된다. 예를 들어, maxLifetime이 30분으로 설정된 경우, 각 커넥션의 실제 수명은 22.5분에서 37.5분 사이로 분산된다. 이를 통해 커넥션 풀이 갑자기 비어버리는 현상을 방지할 수 있으며, 애플리케이션의 안정성과 성능을 향상시킬 수 있다.

 

 

 

 

참고로 HikariCP의 maxLifeTime 분산 기능에 대한 자세한 내용은 아래 커밋을 참고하면 된다.

https://github.com/brettwooldridge/HikariCP/commit/28f81da4400c4ee7899d1f901c663b8697843b85