DB 커넥션 부족을 잡았던 경험

배경

회사 IoT 플랫폼 서버를 국외에서 국내 리전으로 모두 옮기고 있다. 배포 시점 이후 페어링한 기기들은 모두 신규 국내 서버에서 관리되나, IoT 기기 특성상 기기 페어링을 유지한 채로 데이터를 다른 서버로 옮기는 것이 불가능하다. 따라서 당분간 기존의 서버와 신규 서버가 동시에 운영되어야 하는 상황이다. 
 
이런 와중에 우리 회사의 Open api를 사용하여 서비스를 운영하는 회사에서 Api 이용이 너무 느리다는 이슈를 보고해 줬고, DB 커넥션 부족을 확인하여 문제를 풀이했던 경험을 소개한다.
 

 

원인 파악

당장 확인할 수 있는 로그는 다음과 같았다. 

 

Servlet filter 사용자 요청 인입 기록
/// 5초 이상의 텀 /// 
DB 조회 결과 로그
IoT 플랫폼 서버 Api 호출
IoT 플랫폼 서버 Api 응답
Servlet filter 사용자 응답 기록

 
사용자 요청이 인입 ~ DB 조회 결과까지의 지연이다. 가장 먼저 떠오른 생각은 세 가지였다. 
 
1. RequestMapping, TokenFilter에 문제가 있나?
2. DB 커넥션 점유를 못하고 있나?
3. DB 조회가 매우 느린가?
 
만약 1, 3번 문제였다면 기존에도 동일한 이슈가 발생했었어야 할 것이다. 변경이 일어난 부분은 IoT 플랫폼 서버 호출 부 (외부 Api 호출) 뿐이니 2번의 의심과 맞물려, 혹시 DB 커넥션이 Api 처리까지 모두 점유하고 있나? 설마 OSIV가 켜져있나?로 이어질 수 있었다.
 

해결 

OSIV가 필요한 곳을 빠르게 찾았다. 연관 관계 사용처를 찾았고, LazyLoading이 사용되는 곳은 없는지 확인했다. 가장 먼저 OSIV를 끄고, 혹시 모르니 커넥션 풀도 늘렸다. HotFix로 빠르게 운영 배포하였고, 문제가 해결되었다는 소식을 들을 수 있었다. 구체적인 이유는 다음과 같다.
 
1. 신규 IoT 플랫폼 서버에서 특정 기기의 Api 응답이 비정상적으로 느린 문제가 있었음을 후에 알게 되었다.
2. OSIV로 DB 커넥션이 요청-응답 주기 전체를 포함하고 있어, 길어진 Api 응답에 커넥션 점유 시간도 늘게 되었다.
3. 커넥션 할당을 위해 대기하는 시간이 길어지고, 이것이 응답 지연으로 이어졌다.
 

정리

재밌는 운영 경험이었다. 사실 OSIV나 커넥션 부족 문제 그런 것보다는, 우리 회사 Open api 서비스를 이용하는 다른 사업장들에겐 굉장히 큰 문제겠구나, 내가 작업하는 이 서비스가 누군가의 사업에 큰 이슈가 되겠구나를 봤던 순간이었다.
 
중국 출장 중에 급하게 전달받아 봤던 이슈였고, 심지어 다른 미팅 중에 귀만 열어두고 노트북을 두들겼던 상황이라 더 기억에 남는 것도 있다. 여러 다이나믹한 일들이 많았던 이번 스프린트라 더 기억에 남는 것도 있는 것 같다.
 
서비스에 더 책임감을 느끼게 된 경험이었다.