DB 연결 풀 대기는 늘고 쿼리는 짧을 때, 풀을 키우기 전에 어떤 연결 보유 경로와 트랜잭션을 확인하나요?

연결 풀 대기가 늘고 개별 쿼리는 짧다면 풀을 키우기 전에 연결이 실제 DB 작업을 하는 시간과 아무 일 없이 점유되는 시간을 분리하겠습니다. 연결을 얻은 뒤 외부 API를 기다리거나 응답 스트리밍을 계속하면 쿼리 시간은 짧아도 연결 보유 시간이 길어져 풀이 고갈됩니다. 먼저 풀 대기 시간, 획득 후 보유 시간, 쿼리 실행 시간, 트랜잭션 시작·커밋 시간을 trace와 DB 세션에서 함께 측정하겠습니다.

연결과 트랜잭션의 경계를 줄입니다

예를 들어 연결을 빌려 주문을 읽고 같은 트랜잭션에서 결제 API를 호출한 뒤 커밋한다면 결제 지연이 연결과 잠금을 붙잡습니다. 가능하면 DB 트랜잭션을 읽기·예약 같은 짧은 단계에서 끝내고 외부 호출은 연결 밖으로 옮기겠습니다. 외부 결과를 받은 후 상태가 그 사이 바뀌지 않았는지 버전 조건·상태 전이 조건으로 다시 갱신해야 합니다. 연결을 반납했다가 재획득하는 것만으로 원래 원자성이 유지되는 것은 아닙니다.

취소·예외·타임아웃 경로에서 rollback과 release가 반드시 실행되는지 확인합니다. 드라이버가 취소된 쿼리를 실제로 중단하는지, 중단되지 않은 작업이 연결을 계속 점유하는지 엔진과 드라이버별로 확인해야 합니다. PostgreSQL의 세션·트랜잭션 상태, SQL Server의 유휴 트랜잭션·블로킹, MySQL의 연결·트랜잭션 상태는 관찰 지표와 명령이 다릅니다. DB 세션이 ‘idle’인지 ‘idle in transaction’인지 같은 세부 상태도 구분하겠습니다.

풀 크기는 전체 DB 예산 뒤에 결정합니다

정상적으로 쿼리를 병렬 처리하는 연결이 부족하고 DB CPU·I/O·잠금에 여유가 있을 때만 풀을 늘리겠습니다. 인스턴스가 10개이고 각 풀을 20개로 만들면 DB에 200개의 동시 연결이 생길 수 있습니다. DB의 최대 연결 수만 보지 말고 관리 연결, 배치, 읽기·쓰기 풀, 복제와 워크로드별 예산을 합산합니다. 풀을 크게 하면 대기가 줄어도 DB가 과도하게 경쟁해 쿼리 지연과 컨텍스트 전환이 늘 수 있습니다.

응답 스트리밍이나 큰 결과를 연결을 빌린 채 보내야 한다면 별도 상한과 읽기 전용 경로를 둡니다. 연결 획득에 deadline을 적용하되 timeout이 자동으로 트랜잭션 정리까지 끝냈다고 가정하지 않겠습니다. 검증은 외부 API 지연, 클라이언트 취소, 예외, DB 장애를 주입해 반환 누락·유휴 트랜잭션·블로킹 체인·풀 대기 p99를 확인하는 방식으로 하겠습니다. 목표는 대기 수를 숨기는 것이 아니라 제한된 연결이 실제 DB 작업에 쓰이고 완료 뒤 확실히 돌아오는 상태입니다.

풀의 대기 요청을 무제한으로 유지하면 DB를 보호하는 대신 애플리케이션 메모리와 요청 deadline을 소진할 수 있습니다. 연결을 기다리는 큐에도 상한과 취소를 두고, 넘친 요청은 빠르게 실패시키거나 낮은 우선순위 작업부터 버리겠습니다. 읽기·쓰기 풀을 나누더라도 같은 DB 전체 예산을 넘지 않아야 합니다. 정상 부하에서 풀 대기가 0에 가까운 것이 목표가 아니라, DB가 감당할 병렬도에서 지연 꼬리와 실패율이 안정적인 점을 찾겠습니다.