커넥션 비용을 단순히 "느려진다" 수준으로 이해하는지, 아니면 max_connections와 풀 사이즈 트레이드오프까지 운영 관점에서 풀 수 있는지를 가른다.
커넥션 하나를 새로 맺으려면 TCP 소켓을 열고 인증·세션 초기화까지 거쳐야 해서 비용이 크다. 요청마다 이걸 반복하면 응답 지연이 누적되고, 동시 요청이 늘면 DB의 max_connections 한도를 먼저 친다. 커넥션 풀은 미리 만들어 둔 연결을 빌려 줬다가 반납받는 구조로 이 비용을 분산시키고 처리량을 안정화한다. 단 풀 사이즈는 스레드 풀·CPU·DB 자원과 함께 잡지 않으면 풀이 곧 새로운 병목이 된다.
응답 시간 급증의 원인을 추적하다 커넥션 풀 대기 시간 지표에서 단서를 찾은 경험이 있다면 "가장 먼저 마르는 자원" 이야기로 풀어낼 수 있다
장시간 트랜잭션이나 잡혀 있는 락으로 커넥션 누수를 겪은 경험이 있다면 풀 모니터링 항목을 사례로 보여 줄 수 있다
인스턴스 수를 늘리면서 DB의 max_connections를 함께 조정해 본 경험이 있다면 앱·DB 자원 동기화 이야기로 자연스럽게 이어갈 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.