데이터베이스 커넥션 풀 설계: 크기·타임아웃·고갈 점검 순서

“풀 크기를 크게 잡으면 요청이 더 잘 버틸까?”

“타임아웃 오류가 나는데, 어느 시간 제한부터 봐야 할까?”

“연결 풀이 고갈됐을 때 DB를 늘려야 하는지 코드부터 봐야 하는지 모르겠다.”

커넥션 풀은 큰 숫자 하나를 정하는 설정이 아니라, 모든 인스턴스가 열 수 있는 총 연결 상한과 연결 점유 시간을 함께 관리하는 대상입니다. 고갈 오류가 생겼다면 최대 풀 크기를 먼저 올리기보다 연결이 어디에서 오래 점유되는지와 대기가 어떻게 쌓였는지부터 확인하세요.

커넥션 풀 크기는 무엇을 기준으로 정해야 할까?

풀 크기는 서버 한 대의 설정값이 아니라, 최대 인스턴스 수를 반영한 총 연결 상한을 기준으로 검토해야 합니다. 오토스케일링 환경에서는 인스턴스 한 대에 무난해 보이는 값도 확장 후에는 DB 연결 한도와 충돌할 수 있습니다.

커넥션 풀은 애플리케이션과 DB 사이의 연결을 미리 확보해 재사용하는 구조입니다. 다만 풀 크기를 늘린다고 처리량이 계속 증가하는 것은 아니며, 연결 수가 DB 처리 능력을 넘으면 경합과 락 경쟁으로 성능이 저하될 수 있습니다. 출처: 커넥션 풀, 몇 개로 설정해야 할까? 아키텍처가 알아야 할 3가지

인스턴스마다 풀이 독립적이고 최대 크기가 같다면, 우선 다음 상한부터 적어 보세요.

예상 최대 연결 수 = 애플리케이션 인스턴스 수 × 인스턴스당 풀 최대 크기

다중 인스턴스 환경에서는 인스턴스별 풀 최대 크기의 합계가 DB 연결 한도 검토에 반영됩니다. 예를 들어 인스턴스 10대가 각각 최대 50개를 사용하면 DB에는 최대 500개의 연결이 요청될 수 있으며, 배치·마이그레이션·관리 도구 같은 다른 연결 소비자도 별도로 고려해야 합니다. 출처: 커넥션 풀, 몇 개로 설정해야 할까? 아키텍처가 알아야 할 3가지

운영값의 시작점은 DB 처리 능력, 인스턴스 수, 연결 한도, 쿼리 특성을 함께 고려해 잡고 부하 측정으로 조정하는 편이 낫습니다. 특정 DB·드라이버의 권장 공식은 확인되지 않았으므로, 실제 값은 사용하는 풀 구현체와 DB의 공식 문서를 기준으로 검증해야 합니다.

타임아웃은 하나로 맞추면 될까?

아닙니다. 풀에서 연결을 기다리는 시간과 새 연결을 만드는 시간, 쿼리 실행 시간, 트랜잭션 시간은 기록할 실패 지점이 다르므로 구분해 관리해야 합니다. 다만 실제 설정 이름과 적용 범위는 Spring Boot, Node.js 드라이버, ORM, DB 종류에 따라 달라집니다.

설정 화면을 볼 때는 다음처럼 역할을 나눠 적어 두면 장애 분석이 쉬워집니다.

• 연결 획득 대기 시간: 풀에 사용할 연결이 없을 때 반환을 기다리는 제한입니다.
• 새 연결 생성 시간: 새 DB 연결을 만드는 과정의 제한입니다.
• 쿼리 실행 시간 제한: SQL 실행이 장시간 지속되는 상황을 다루는 제한입니다.
• 트랜잭션 시간 제한: 하나의 업무 단위가 연결과 잠금을 오래 점유하지 않도록 두는 경계입니다.
• 유휴 연결·연결 수명 설정: 사용하지 않거나 오래된 연결을 정리하는 기준입니다.

핵심은 모든 값을 같은 숫자로 맞추는 일이 아니라, 오류가 났을 때 어느 단계에서 제한이 먼저 작동했는지 알 수 있게 만드는 것입니다. 예를 들어 연결 획득 대기가 끝났다면 풀에 즉시 쓸 연결이 없었다는 상태를 뜻할 수 있지만, 그 배경은 느린 쿼리, DB 응답 지연, 반환 경로 문제, 동시 요청 증가처럼 다를 수 있습니다.

요청의 전체 허용 시간, 재시도 정책, DB 작업 특성을 먼저 문서화한 뒤 각 제한을 대응시키세요. 구체적인 우선순위와 시간값은 이 글에서 일반화할 수 없으므로, 실제 변경 전에는 사용하는 프레임워크·드라이버·DB의 공식 문서와 운영 환경을 함께 확인해야 합니다.

풀이 고갈됐을 때 왜 크기부터 올리면 안 될까?

풀 고갈은 ‘연결이 부족하다’는 관측 결과일 뿐, 최대 연결 수가 작다는 원인을 바로 증명하지는 않습니다. 대기열, 장시간 점유, 반환 경로, DB 지연, 인스턴스 변화를 나눠 확인한 뒤에만 크기 조정을 검토하세요.

고갈 시에는 다음 순서로 원인을 좁힐 수 있습니다.

1. 증상 시점의 풀 메트릭을 확보합니다. 활성·유휴·대기 연결 수와 연결 획득 대기 시간을 같은 시각 기준으로 봅니다.
2. 느린 쿼리와 긴 트랜잭션을 확인합니다. 활성 연결이 높게 유지된다면 어떤 SQL 또는 트랜잭션이 연결을 오래 점유하는지 추적합니다.
3. 연결 반환 경로를 점검합니다. 예외 처리, 스트림 처리, 비동기 작업 경계에서 연결이 정상 반납되는지 라이브러리 사용 방식을 확인합니다.
4. 인스턴스 변화와 요청량을 대조합니다. 배포, 스케일아웃, 배치 실행, 트래픽 변화와 오류 시점이 겹치는지 봅니다.
5. 원인을 좁힌 뒤에만 풀 크기를 조정합니다. DB 여유와 총 연결 상한을 다시 계산하고 작은 변경 단위로 검증합니다.

느린 쿼리가 후보라면 풀 설정만 변경하지 말고 실행 계획, 인덱스, 반환 행 수, 잠금 대기를 함께 검토해야 합니다. 반대로 연결 누수가 의심될 때도 풀 구현체의 경고만으로 원인을 단정하지 말고, 오류 요청의 추적 정보와 트랜잭션 경계, 예외 로그를 연결해 실제 반환 경로를 확인하세요.

운영 중에는 어떤 지표를 함께 봐야 할까?

설정값만 보면 고갈의 원인을 구분하기 어렵기 때문에, 풀 상태와 DB 작업 상태를 같은 시간축에서 비교해야 합니다. 최소한 활성 연결 수, 유휴 연결 수, 대기 요청 수, 연결 획득 대기 시간은 함께 확인할 항목으로 두세요.

다음 질문에 답할 수 있도록 대시보드와 로그를 정리하면 좋습니다.

• 이 오류는 연결 획득 대기 실패인가, 새 연결 생성 실패인가?
• 활성 연결이 늘어난 원인은 요청량 증가인가, 쿼리 지연인가?
• 인스턴스 수가 바뀔 때 총 연결 상한도 함께 바뀌었는가?
• 타임아웃 뒤 재시도가 DB 부하를 더 키우고 있지는 않은가?

이 지표들은 풀 크기를 변경할지, 쿼리와 트랜잭션을 먼저 살필지 판단하는 출발점입니다. 특정 메트릭 이름과 수집 방법은 사용하는 풀·APM·DB에 따라 다르므로, 각 도구가 제공하는 지표 정의를 확인해 같은 의미의 값끼리 비교해야 합니다.

배포 전에는 무엇을 남겨야 할까?

배포 전 점검의 목표는 큰 풀을 만드는 일이 아니라, 어떤 조건에서 총 연결 상한과 대기 경계가 달라지는지 설명할 수 있게 만드는 일입니다. 값 자체와 함께 그 값을 고른 근거, 재검토 조건, 장애 시 확인 순서를 남기세요.

• 최대 인스턴스 수를 기준으로 총 연결 상한을 계산했다.
• 웹 서버, 워커, 배치, 관리 도구 등 DB 연결 주체를 구분했다.
• 연결 획득 대기, 연결 생성, 쿼리, 트랜잭션 관련 제한의 역할을 구분했다.
• 오류 시 확인할 풀 메트릭과 DB 메트릭을 정했다.
• 풀 고갈 시 크기 변경 전에 따를 원인 추적 순서를 문서화했다.
• 스케일아웃과 재시도 정책이 총 DB 부하에 미칠 영향을 검토했다.

부하 테스트에서는 정상 요청만 보지 말고, 일부 DB 작업이 느려지는 경우와 연결 생성이 지연되는 경우를 분리해 관찰하세요. 목표는 임의의 숫자를 통과하는 것이 아니라, 어떤 조건에서 대기열이 늘고 어떤 제한이 먼저 작동하는지 파악하는 것입니다.

결론

커넥션 풀 설계의 기준은 ‘인스턴스당 몇 개’가 아니라, 총 연결 상한과 연결 점유 시간을 함께 설명할 수 있는가입니다. 풀 고갈 오류가 나면 최대 크기를 올리기 전에 대기 지표, 느린 작업, 반환 경로, 인스턴스 변화를 순서대로 확인하세요.

먼저 최대 인스턴스 수와 인스턴스당 풀 최대 크기를 곱해 총 연결 상한을 적어 보세요. 그다음 요청 경로 안에서 각 타임아웃의 역할을 나누고, 장애 시 볼 지표를 정하면 설정값 변경을 더 명확한 근거로 검토할 수 있습니다.

자주 묻는 질문

커넥션 풀 크기를 CPU 코어 수로 정해도 되나요?

CPU 코어 수만으로 풀 크기를 확정하기는 어렵습니다. DB 연결 한도, 인스턴스 수, 쿼리 특성, 연결 점유 시간을 함께 보고 총 연결 상한부터 확인하세요.

풀 고갈 오류가 나면 DB 연결 수를 바로 늘려야 하나요?

바로 늘리기보다 연결이 오래 점유된 이유를 먼저 확인해야 합니다. 느린 쿼리, 긴 트랜잭션, 반환 경로 문제, 인스턴스 증가, DB 지연에 따라 대응이 달라집니다.

연결 획득 대기 시간과 쿼리 타임아웃은 같은 값으로 두면 안 되나요?

두 제한은 관찰하려는 실패 지점이 다르므로 역할을 구분하는 편이 낫습니다. 정확한 설정 항목과 값은 사용하는 풀·드라이버·ORM의 문서와 전체 요청 제한 시간을 기준으로 정해야 합니다.

유휴 연결을 많이 유지하면 항상 유리한가요?

항상 유리하다고 단정할 수는 없습니다. 연결 생성 비용, DB 자원, 트래픽 변동 방식, 실제 풀 메트릭을 함께 보고 조정해야 합니다.

제 도움이 필요하시다면

이 글은 특정 DB나 프레임워크의 설정값을 처방하는 자료가 아니라, 커넥션 풀 고갈을 점검할 때 필요한 질문과 기록 항목을 정리한 안내입니다. 실제 환경을 변경하기 전에는 사용하는 DB·드라이버·프레임워크의 공식 문서와 현재 운영 제약을 함께 검토하세요.

알레오의 서비스 정보는 알레오 공식 웹사이트에서 확인할 수 있습니다.