본문 바로가기
허브 살리기 프로젝트

Connection Timeout Monitoring in Connection Pool

by jay-choe 2024. 2. 11.

운영을 하다보면 예기치 못한 일들이 많이 일어난다.

 

해당 상황들이 실제 서비스의 가용성에 부정적인 영향을 미치는 상황을 방지하기 모니터링 툴을 사용한다.

 

DataDog이나 Prometheus + Grafana와 같은 모니터링 어플리케이션들을 통해

메트릭을 수집하고 주기적으로 확인하여 이상현상을 체크하고

 

확인 할 수 없는 시간대나 갑작스러운 상황에 대비하여 Alert을 걸어서 슬렉으로 확인하거나 메일 혹은 전화를 받는 식으로 빠른 대응 및 원인 파악에 드는 시간을 줄일 수 있게 한다.

 

서비스의 가용성에 부정적인 영향을 미치는 지표는 여러가지가 있어서 당장 장애 상황에 직면하면 당황하기도 하고 뭐가 문제인지 파악이 어렵다.

 

그리고 설정상으로 수집이 안 되고 있는 메트릭이 장애 유발 포인트라면

확인 및 해결까지 많은 시간이 들 것 이며 대고객 서비스라면 금전적인 손실을 입힐 것이다.

 

일반적으로 확인하는 메트릭은 CPU, Memory, Disk 사용량이고

해당 메트릭에서 발견하는 이슈는 스케일 아웃이나 업을 하고 디스크는 교체하면 되는 식으로 대응할 수 있다.

 

근데 특이하게 이런 메트릭으로 대응 할 수 없는 부분이 존재하는데 정상 응답은 하지만 latency가 높은 케이스이다.

 

CPU, Memory에 이상이 없는데 latency가 높게 잡히는 케이스가 뭐가 있을까?

 

여러 케이스가 있겠지만

해당 상황에 직면 했을 때 미리 확인 할 수 있는 메트릭들이 있다면 범위를 좁혀서 파악 할 수 있으므로 알아두면 큰 도움이 될 것이다.

 

이중에 하나가 Connection Pool의 connection timeout 관련 메트릭이다.

 

해당 메트릭은 connection pool에서 커넥션을 얻기까지 대기하는 시간이다.

 

connection timeout이 발생한다는 것은

커넥션을 얻기까지 대기하는 시간이 길다는 뜻이고

 

maximum pool size 만큼의 커넥션이 사용중이라는 것을 의미한다.

 

원인은 요청이 들어오는 수와 DB에서 처리하기 위한

Connection Pool 갯수 사이의 불균형이 있을 수 있다는 말일 수 도 있고

 

해당 유튜브에서 범균님이 말씀하셨던 하나의 트렌젝션에서 3rd party 연동을 하는 등

너무 오래 커넥션을 물고 있을 수 있어서 요청수는 적지만 connection pool이 고갈 되어서 발생 할 수 있다.

 

해당 이슈 상황을 해결하는 방법은

단기적으로는 maximum pool size를 늘리면 되겠지만 pool size만 늘리는 것은 한계가 있을 것이다.

 

새로운 커넥션은 새로운 쓰레드를 만들고 메모리를 점유하게 되고

context switching 오버헤드를 증가시켜서 CPU 사용량이 늘어나게 될 것이다.

 

적정선까지 pool size를 늘려주고 이제 다른 메트릭(CPU, Mem)에도 유의미하게 영향이 간다면

scale out 하는 방식으로 해당 이슈 상황은 무마할 수 있을 것 같다.

(긴박한 상황이니 코드 레벨 까지 파악 할 시간은 없을 것 이므로)

 

이후에 장기적으로 코드 레벨에서 파악을 해서 개선하는 식의 대응이 적절한 것으로 보인다.

 

 

Spring Boot 설정

Spring Boot에서 관련 메트릭을 확인하는 것은 간단하다.
Actuator에서 metrics를 추가해주면 된다. prometheus를 사용하는 경우 저기에 prometheus를 넣어주면 된다.

management:
  endpoints:
    web:
      exposure:
        include: metrics

 

이후에 /actuator/metrics를 호출 했을 때 hikaricp.connections.timeout.count 메트릭이 보일 것이고

 

해당 지표를 모니터링 툴의 그래프에 추가를 해주거나 평상시에는 잘 확인 안 하는 값이니 해당 숫자가 5분 안에 5가 넘어가면 슬렉을 보내는 식으로 alert을 걸어두는 식으로 사용할 수 있다.

 

 

참고

 

 

'허브 살리기 프로젝트' 카테고리의 다른 글

DB가 내부 망에 존재하는 이유  (1) 2024.02.17
CPU Pinning  (0) 2024.02.14
Idle in ALB, Connection Pool  (1) 2024.02.07
TCP, HTTP/HTTPS keep-alive  (1) 2024.02.05
Gradle Java plugin API and Implementation  (0) 2024.01.31