Dev 환경 DB의 Too many connections 문제 해결하기 (Feat. DB 계정 분리의 필요성)

사건 발생

역시나 평화롭게 출근해서 업무를 보던 중 개발용 DB에서 데이터를 확인하기 위해 Datagrip에서 테이블을 조회를 했는데 생각하지도 못한 상황이 발생했다.(사실 대부분의 문제는 예상 범위 밖의 상황에서 발생하긴 했지만..)

Too many connections

사용자가 폭주할 타이밍은 절대 아니었고 애초에 개발용 환경이었기 때문에 트래픽이 원인일 가능성은 0에 수렴한다고 판단했다. 우선 나의 로컬에서 Docker 컨테이너에 올라가 있던 Spring 서버를 중단시킨 후에 SHOW PROCESSLIST 명령어를 사용해 현재 connections을 확인했다.

SHOW PROCESSLIST 조회 결과

해당 결과를 처음 봤을 때 원인을 특정할 수 없어서 현재 발생하는 증상을 정리하고 그동안 어렴풋 알고 있었던 DB Connections에 대해 간단하고 빠르게 학습을 진행하였다.

현재 증상
1. 데이터 그립에서 조회 시 Max connections 에러 발생.
2. 도커 컨테이너를 정리하기 전에 테스트해본 결과 개발 환경의 서비스(개발용 DB와 연결되어 있는)는 정상적으로 동작한다. 
-> 2번 부분에서 고개를 갸우뚱하게 되었다. 문제가 있다고 생각한 DB와 연결된 서비스가 읽기 쓰기를 수행하고 있었기 때문이다

DB Connection? HikariCP?

DB Connection이란 서버와 DB 사이에 열려있는 연결(세션/TCP 연결)을 말한다. 위의 SHOW PROCESSLIST 결과에 나온 것들이 connection들이고 현재 그것이 최대 허용 수보다 초과해서 생성하려는 문제가 발생한 것이다.
HikariCP는 스프링에서 사용하는 DB 커넥션 풀 라이브러리다. DB와의 연결을 그때그때 처음부터 실행하면 비효율적이기 때문에 생성된 DB 커넥션을 보관하며 필요할 때 빌려주고 회수하며 스프링에서 커넥션 관리를 효율적으로 할 수 있게 도와준다.
(더 자세한 이론들은 친절한 블로그들이 많다!! 트러블 슈팅에 대한 글이므로 설명은 여기까지..)

간단한 시각화

그래서 문제가 뭐지.. 프론트 개발자님 혹시?

하지만 위의 내용을 공부하고 GPT와 함께 끝장 토론을 해봐도 원인을 찾을 수 없었다. 혼자 골머리를 앓던 와중에 중간중간 Max connections가 뜨지 않고 조회가 되는 순간이 생겼고 그 타이밍에 맞춰 processList를 조회해 보니 20개가 줄어들어 있는 것을 발견할 수 있었다.

왜 줄어들었지..

트래픽이 늘어났다 줄어들었다 할 가능성은 0인데 왜 이런 상황이 벌어질까하는 고뇌에 빠져있었는데 정말 다행스럽게 오전 시간을 다 보내기 전에 그 시점을 찾을 수 있었다. 옆에서 열심히 기능 테스트를 진행하고 계시던 프론트 개발자분이 스프링 컨테이너를 재시작할 때 순간적으로 Connections의 수가 20개 감소하고 Max connections이 발생하지 않았다. 
"XX님 혹시 로컬에서 서버 돌리고 계세요....???" 라고 여쭤보니 확인할 게 있어서 백엔드 레포에서 pull 받아 로컬에서 돌리고 있다고 답변해주셨다.(프론트1, 백엔드1 로 개발팀이 구성되어 있어서 가끔 로컬에서 pull 받아 확인할 때가 종종 있다.) 이때부터 슬슬 머릿속에서 퍼즐이 맞춰지기 시작했고 빠르게 문제를 해결할 수 있었다.

문제 발생 원인

우선 개발용 DB의 Max connection은 60, hikari.minimum-idle은 20으로 설정되어있었다. 즉 DB는 최대 60개의 커넥션을 허용할 수 있고 Spring은 켜지는 시점에 20개(최소 연결 수)의 커넥션을 생성하여 관리한다.
평소에는 나(20) + DEV Spring Conatainer(20) + Data grip/event_scheduler/rdsadmin(3~4) = 약 43개의 connection만 생성됐기 때문에 최대 허용 수인 60을 넘지 않았다. 하지만 여기서 프론트 개발자분의 커넥션까지 합쳐져서 60개를 초과하는 상황이 발생했다. 

평소 connections

문제 발생 했을 때 connections

문제를 해결하기 위해서는 다양한 방법이 있었는데(Max Connections 증가 등등) 개발용 환경에서 각 컨테이너가 커넥션을 20개를 최소로 갖는 것은 꽤 과할 수 있다 판단했다. 혹시나 부족한 상황이 만약에 발생하더라도 hikari.maximum-pool-size로 충분히 대처가 가능하다 생각했고 개발환경에서 3개의 컨테이너 모두 최대 커넥션을 연결하는 상황이 동시에 발생하는 상황은 극히 드물 것이라 판단해서 개발용 환경에서 hikari.minimum-idle 사이즈를 줄이는 방법을 선택했다.
현재 우리 회사의 설정 파일은 공통으로 적용할 내용은 상속받고 각 환경에 맞는 설정은 개별 파일에서 관리를 하고 있다. 이때는 hikari에 관한 내용이 COMMON에 작성되어 있었기 때문에 각각의 환경에 맞는 값을 설정했고 문제는 깔끔하게 해결되었다.

설정 파일 구조

아하 포인트 (계정 분리 필요성)

문제를 해결하면서 개인적으로 흥미로운 점이 있었는데 바로 전공 시절에 배웠던 DB 계정에 대한 필요성을 몸소 느꼈던 점이었다. 많이 들어왔고 많은 분들이 알고 있을 읽기/쓰기의 권한을 분리해서 보안을 높인다는 것이 아닌 각각의 계정을 쓰는 것이 필요하다고 생각이 들었다. 이번 상황의 원인을 빠르게 찾지 못했던 이유 중 하나가 SHOW PROCESSLIST의 결과에서 사용자를 구분할 수 없었던 것이다.
User, IP의 값이 모두 동일하게 보여졌기 때문에 여러 서버가 연결되어 있을 것이란 생각을 바로 하지 못하고 IP로 구분해서 DEV EC2 20개 + Local 40개라고만 생각을 했다. IP는 별도의 설정이 불가능하기 때문에 DEV, 나의 Local, 동료의 Local 설정에서 DB 접속 계정이 달랐다면 DB에 연결되어 있는 서버가 여러 개였다는 것을 금방 눈치챘을 것 같다. 만약 동료 개발자가 그때 컨테이너를 재실행하지 않았다면 하루종일 나의 서버가 40개를 점유하고 있다고 생각했을지도 모른다......

(왼쪽) - User 분리 X, (오른쪽) - User 분리 O

최근에 읽었던 "주니어 백엔드 개발자가 반드시 알아야 할 실무 지식이라는 책"에서 관리자 계정은 분리해서 사용하는 것이 중요하다고 읽었었다. 문제가 생겼을 때 로그 기록을 통해 분석할 수 있다는 내용이었는데 해당 내용을 비슷하게 몸소 경험하게 되면서 큰 깨달음 얻으며 이번 문제도 해결~ 성공~!