실무에서 커넥션 풀은 “많을수록 좋은 버퍼"가 아니라 DB와 애플리케이션이 동시에 감당할 수 있는 동시성 예산을 나누는 장치에 가깝습니다. 스레드 풀, 큐 길이, 타임아웃, 재시도 정책이 그대로인데 커넥션 풀만 키우면 병목을 없애는 것이 아니라 병목 위치를 뒤로 미루는 것에 그칠 수 있습니다. 그래서 풀 튜닝은 용량 계획과 Little’s Law 기반 포화도 해석, Thread Pool 튜닝, Timeout/Retry/Backoff 설계, Connection Storm과 Thundering Herd 플레이북과 같이 봐야 정확합니다.

이 글은 “풀 크기를 몇으로 할까"라는 질문에 하나의 정답 숫자를 주려는 글이 아닙니다. 대신 어떤 조건에서 풀을 키워야 하고, 어떤 조건에서는 오히려 줄이거나 대기시간 제한을 먼저 걸어야 하는지, 그리고 DB 풀과 HTTP 클라이언트 풀이 어떻게 서로 영향을 주는지까지 실무 기준으로 정리합니다.

이 글에서 얻는 것

• DB 커넥션 풀과 HTTP 클라이언트 풀을 단일 숫자가 아니라 전체 요청 경로의 동시성 예산으로 해석하는 기준을 잡을 수 있습니다.
• pool wait time, in_use, pending, timeout, DB active session 같은 지표를 보고 지금이 “풀 부족"인지 “하류 병목"인지 구분할 수 있습니다.
• 커넥션 풀을 늘리기 전에 무엇을 먼저 확인해야 하는지 우선순위를 정할 수 있습니다.
• 장애 시 임시 완화와 구조 개선을 구분하는 런북 초안을 가져갈 수 있습니다.

핵심 개념/이슈

1) 커넥션 풀은 성능 옵션이 아니라 동시성 상한선이다

풀은 놀고 있는 연결을 재사용해 연결 생성 비용을 줄이는 기능이기도 하지만, 운영에서는 더 중요한 역할이 하나 있습니다. 바로 동시에 하류 자원을 때릴 수 있는 요청 수를 제한하는 상한선입니다. DB가 안정적으로 처리할 수 있는 active query 수가 40인데, 애플리케이션 4대가 각각 50개씩 DB 커넥션을 열 수 있으면 최악의 순간에는 200개의 활성 쿼리가 쏟아질 수 있습니다. 이때 문제는 연결 생성 비용이 아니라 DB 스케줄러, 락, 버퍼 캐시, I/O 대기가 한꺼번에 흔들리는 것입니다.

그래서 풀 크기는 보통 “애플리케이션 하나가 바쁠 때 편한 숫자"가 아니라 아래 질문으로 정해야 합니다.

• DB 또는 외부 API가 안정적으로 감당 가능한 동시 실행 수는 얼마인가
• 애플리케이션 인스턴스 수가 늘어날 때 총합 동시성이 얼마가 되는가
• 풀을 다 못 얻은 요청은 어디에서 얼마나 기다리게 할 것인가
• 기다리는 동안 상위 타임아웃과 재시도가 어떻게 반응하는가

핵심은 커넥션 풀이 부족해서 느린 경우와, 하류가 이미 느린데 풀이 그 사실을 숨기고 있는 경우를 구분하는 것입니다. 후자의 경우 풀을 키우면 체감은 잠깐 나아져도 전체 장애는 더 커질 가능성이 큽니다.

2) DB 풀, HTTP 풀, 워커 수는 따로 보면 안 된다

실무에서 자주 놓치는 점이 하나 있습니다. 요청 하나가 DB만 쓰는 것이 아니라는 점입니다. 예를 들어 주문 API 하나가 아래처럼 흘러간다고 해 봅시다.

1. 애플리케이션 워커 1개 점유
2. DB 커넥션 1개 사용
3. 외부 결제 API 호출을 위한 HTTP 커넥션 1개 사용
4. 후속 이벤트 발행 또는 캐시 갱신

이 구조에서 워커는 200개인데 DB 풀은 80, HTTP 풀은 20이라면 병목은 HTTP 클라이언트에서 먼저 날 수 있습니다. 반대로 HTTP 풀은 넉넉하지만 DB 락 경합이 심하면 DB 풀이 오래 잡혀 워커가 순식간에 묶입니다. 그래서 커넥션 풀 튜닝은 단일 계층 최적화가 아니라 체인 균형 맞추기입니다.

실무 기본 원칙은 아래처럼 잡는 편이 안전합니다.

• 워커 수가 DB 풀의 여러 배라면, 풀 대기시간과 요청 큐 길이를 반드시 같이 봅니다.
• 한 요청이 평균적으로 DB 1회, 외부 API 2회를 호출한다면 HTTP 풀의 상한이 실제 처리량을 먼저 결정할 수 있습니다.
• DB 풀과 HTTP 풀을 동시에 늘릴 때는 상류 워커 또는 ingress 제한도 같이 봐야 합니다.
• 풀 확장보다 먼저 Admission Control과 동시성 제한이 필요한 경우가 많습니다.

즉, “DB 풀만 20 늘리자"는 결정은 대개 너무 좁습니다. 최소한 워커, DB, HTTP, 큐, 재시도까지 한 묶음으로 봐야 실제 효과를 예측할 수 있습니다.

3) 풀을 크게 잡을수록 좋은 것이 아니라, 느린 작업을 더 오래 붙들 수도 있다

커넥션 풀 확대가 위험한 이유는 풀 자체가 느려서가 아니라 느린 작업을 더 많이 동시에 허용하기 때문입니다. 예를 들어 평균 30ms이던 쿼리가 락 대기와 I/O 병목 때문에 200ms로 늘어나면, 같은 처리량을 내려면 더 많은 active connection이 필요해집니다. 이때 풀을 늘리면 당장의 pending은 줄 수 있습니다. 하지만 DB 입장에서는 동시에 더 많은 느린 작업을 처리해야 하므로 컨텍스트 스위치, 락 대기, shared buffer miss, WAL flush 압력이 올라갈 수 있습니다.

그래서 풀 확대는 아래 조건을 모두 확인한 뒤에 하는 편이 맞습니다.

• DB CPU가 아직 60~70% 이하로 여유가 있다.
• 주요 쿼리의 p95 실행시간이 최근 1주 기준에서 크게 악화되지 않았다.
• 락 대기나 row lock contention이 주요 원인이 아니다.
• 풀 대기시간이 길지만 DB active session은 상대적으로 낮다.
• 애플리케이션의 timeout이 풀 대기보다 먼저 터지지 않는다.

반대로 아래 상황이면 풀 확대보다 다른 조치가 먼저입니다.

• DB CPU 75~80% 이상이 지속되고 있다.
• pg_stat_activity의 active session과 lock wait가 동시에 높다.
• 풀 획득 대기와 함께 쿼리 실행시간 p95가 같이 오른다.
• 재시도 비율이 5~10% 이상으로 올라가 있다.
• 상류 서비스 타임아웃이 짧아 대기 요청이 retry storm으로 번진다.

이 구간에서는 Tail Latency 엔지니어링 플레이북과 Timeout/Retry/Backoff 설계를 먼저 손보는 편이 훨씬 효과적입니다.

4) 사이징 출발점은 트래픽 평균이 아니라 목표 처리량과 체류시간이다

풀 크기를 추정할 때는 감보다 간단한 계산이 낫습니다. 가장 실전적인 출발점은 Little’s Law 식으로 보는 것입니다.

• 필요 동시성 ≈ 처리량(RPS) × 평균 체류시간(초)

예를 들어 특정 API가 초당 120건을 처리하고, DB를 잡고 있는 시간이 평균 40ms라면 평균 동시성은 120 × 0.04 = 4.8 정도입니다. 하지만 평균만 믿으면 안 됩니다. p95에서 120ms, 피크 시간대 2배 트래픽이 온다면 실제 필요 동시성은 훨씬 커집니다. 그래서 운영에서는 대개 아래 순서로 계산합니다.

1. 평시 RPS, 피크 RPS, 이벤트 시 RPS를 분리
2. DB 점유시간 평균과 p95를 분리
3. 쿼리 수가 API별로 다른 경우 상위 20% API를 따로 계산
4. 계산값에 안전 여유 **20~30%**만 더하고, 나머지는 큐와 admission control로 처리

예시를 들어보겠습니다.

• 피크 RPS: 180
• 요청당 평균 DB 점유시간: 35ms
• p95 DB 점유시간: 90ms
• 애플리케이션 인스턴스: 3대

평균 기준 총 동시성은 180 × 0.035 = 6.3입니다. p95 기준으로는 180 × 0.09 = 16.2입니다. 여유를 25% 넣으면 총 DB 풀 상한은 대략 20 전후에서 출발할 수 있습니다. 이를 3대로 나누면 인스턴스당 6~8 수준부터 시작해 실제 wait time을 보고 조정할 수 있습니다. 여기서 핵심은 대개 처음부터 40, 50을 줄 필요가 없다는 점입니다. 오히려 낮게 시작하고 지표로 올리는 편이 안전합니다.

5) 진짜로 봐야 하는 지표는 “풀 크기"가 아니라 “기다림의 질"이다

운영 대시보드에서 maxPoolSize=30, active=30만 보고 “풀이 꽉 찼네"라고 말하면 절반만 본 것입니다. 진짜로 중요한 것은 아래 조합입니다.

• pool_acquire_p95/p99: 커넥션을 얻기까지 기다린 시간
• pending_threads 또는 pending_acquires: 풀을 기다리는 요청 수
• in_use / max 비율: 현재 점유율
• DB active session, lock wait, slow query 비율
• 애플리케이션 전체 latency p95/p99와 timeout 비율
• 재시도율, 큐 길이, 워커 사용률

권장 해석 기준은 아래처럼 잡을 수 있습니다.

• pool_acquire_p95가 10ms 이하면 대체로 양호
• pool_acquire_p95가 20~50ms로 오르기 시작하면 피크 패턴과 함께 관찰
• pool_acquire_p99가 100ms 이상이면서 API latency도 같이 오르면 병목 조사 시작
• pending이 지속적으로 0이 아닌 상태가 5분 이상 이어지면 일시적 스파이크인지 구조 병목인지 분리
• DB active session이 낮은데 acquire latency만 높다면 애플리케이션 풀 설정 또는 커넥션 누수 의심
• DB active session과 lock wait가 함께 높다면 하류 병목이므로 풀 확대는 보수적으로

즉, 풀은 숫자 하나로 보는 것이 아니라 대기시간이 어디서 생기는지를 읽는 센서로 써야 합니다.

6) 장애에서 자주 보이는 패턴은 “커넥션 부족"보다 “커넥션 체류시간 증가"다

현장에서 더 흔한 문제는 풀 크기가 원래 너무 작았던 경우보다, 평소에는 맞던 풀이 특정 상황에서 갑자기 오래 점유되는 경우입니다.

대표 패턴은 이렇습니다.

• 느린 쿼리 또는 인덱스 미스 때문에 DB 점유시간 증가
• 긴 트랜잭션이 커넥션을 오래 보유
• 외부 API 타임아웃이 길어 DB 트랜잭션을 연 채로 대기
• 배포 직후 connection storm으로 새 인스턴스들이 동시에 하류 연결 시도
• 재시도가 겹쳐 동일한 하류에 중복 부하 발생

이때 커넥션 풀을 늘리는 것은 원인을 치우는 것이 아니라 증상을 옮기는 것에 가깝습니다. 특히 “DB 트랜잭션을 잡은 채 외부 API 호출"은 풀 포화의 고전적인 원인입니다. 이 문제는 쿼리 튜닝이나 락 개선보다 먼저 트랜잭션 경계 정리로 해결되는 경우도 많습니다.

그래서 사고 때는 “풀이 모자라다"보다 먼저 아래를 봐야 합니다.

1. 풀을 오래 점유한 상위 요청은 무엇인가
2. 그 요청이 실제로 DB 일을 오래 한 것인가, 아니면 외부 대기 때문에 붙들린 것인가
3. 타임아웃 순서와 재시도 정책이 대기를 증폭시키고 있지 않은가
4. 신규 인스턴스 기동, 배치 시작, 캐시 만료 같은 이벤트가 같이 있었는가

이 질문을 먼저 던지면 문제 절반은 방향이 잡힙니다.

실무 적용

1) 사이징 의사결정 기준(숫자·조건·우선순위)

커넥션 풀 관련 의사결정 우선순위는 보통 아래 순서가 안전합니다.

1순위, 체류시간 원인 확인

• 쿼리 p95, 락 대기, 외부 API 대기, 트랜잭션 길이를 먼저 봅니다.
• 체류시간 증가가 원인이면 풀 확대보다 원인 제거가 우선입니다.

2순위, 대기 한도와 타임아웃 정렬

• 풀 대기 타임아웃은 전체 API timeout의 20~30% 이내로 두는 편이 좋습니다.
• 예를 들어 API deadline이 1초면 pool wait는 150~250ms 안에서 먼저 실패시키는 편이 낫습니다.

3순위, 총합 동시성 상한 관리

• 인스턴스당 풀 크기보다 인스턴스 수 × 풀 크기의 총합을 먼저 관리합니다.
• 총합이 DB 안정 active session의 1.2~1.5배를 넘기면 보수적으로 봅니다.

4순위, 풀 확대는 여유가 확인된 뒤

• DB CPU 70% 이하, 락 대기 낮음, 쿼리 p95 안정, retry low 상태에서만 단계적으로 확대합니다.
• 한 번에 2배 올리기보다 10~20% 단위로 조정하고 1~2일 관찰합니다.

2) 추천 시작값과 경계 조건

정답 숫자는 아니지만, 출발점으로는 아래 기준이 실전적입니다.

• 단순 CRUD API, 인스턴스당 CPU 2코어: DB 풀 8~16에서 시작
• 읽기 비중 높고 쿼리 짧음: 12~20 범위 검토 가능
• 긴 트랜잭션, 배치, 분석 쿼리 혼재: 온라인 트래픽 풀은 더 작게, 별도 워크로드 분리 우선
• HTTP 클라이언트 풀은 대상 서비스별로 분리하고, 상류 워커 수의 30~60% 수준에서 시작
• 풀 대기 p95가 20ms 아래이고 DB 여유가 충분하면 소폭 확대 검토
• 풀 대기 p95가 높아도 DB CPU/lock wait가 높으면 확대보다 쿼리/락/재시도 점검 우선

특히 DB와 HTTP를 모두 쓰는 API는 두 풀의 곱이 아니라 더 작은 쪽이 실제 상한이 됩니다. 이 기본 사실을 놓치면 한쪽만 늘리고 “왜 개선이 없지"라는 상황이 반복됩니다.

3) 장애 대응 런북

커넥션 풀 포화가 의심될 때는 아래 순서가 빠릅니다.

1단계, 대기와 실행을 분리해서 본다
풀 획득 대기시간과 실제 쿼리/외부호출 시간을 분리합니다. 기다림이 길어진 것인지, 하류 실행이 길어진 것인지 먼저 구분해야 합니다.

2단계, 총합 동시성과 인스턴스 변화 확인
오토스케일링, 롤링 배포, 배치 시작으로 전체 커넥션 총합이 갑자기 늘지 않았는지 봅니다.

3단계, 재시도와 timeout 증폭 차단
재시도율이 올라가면 풀 포화는 더 빨리 악화됩니다. 상위 timeout과 retry budget을 임시로 줄여 증폭을 먼저 끕니다.

4단계, 오래 잡고 있는 상위 요청 식별
상위 5개 슬로우 경로가 전체 점유시간의 대부분을 차지하는 경우가 많습니다. 대개 여기서 빠르게 이득이 납니다.

5단계, 풀 확대는 마지막 카드로 쓴다
DB 여유가 분명하고 대기만 병목일 때만 소폭 늘립니다. 그 외에는 원인 치료 없이 문제 면적만 넓어질 수 있습니다.

4) 팀 운영 규칙으로 문서화할 것

지속적으로 덜 흔들리려면 아래 항목을 런북이나 운영 표준에 적어 두는 편이 좋습니다.

• 서비스별 DB 풀 상한과 근거 지표
• 인스턴스 수 증가 시 총합 동시성 계산 방식
• 풀 대기 타임아웃과 API deadline 관계
• 배포 시 connection warm-up, preStop, connection storm 완화 절차
• 슬로우 쿼리와 장기 트랜잭션을 주간으로 점검하는 루틴

이걸 문서화해 두면, 트래픽이 늘 때마다 사람마다 다른 감으로 풀 숫자를 올리는 일을 꽤 줄일 수 있습니다.

트레이드오프/주의점

첫째, 풀을 너무 작게 잡으면 정상 피크에서도 대기가 과도해질 수 있습니다. 그래서 무조건 작은 풀을 선호하면 안 됩니다. 중요한 것은 작은 숫자 자체가 아니라 측정 가능한 근거로 키우는 방식입니다.

둘째, 풀을 너무 크게 잡으면 DB가 느린 요청을 더 많이 동시에 처리하게 되어 tail latency와 락 경합이 악화될 수 있습니다. 특히 쓰기 비중이 높거나 긴 트랜잭션이 섞이면 더 위험합니다.

셋째, 애플리케이션 풀만 보고 판단하면 오판하기 쉽습니다. DB 내부 active session, lock wait, slow query, 외부 API timeout을 같이 봐야 합니다.

넷째, 풀 포화는 자주 “부족” 문제가 아니라 “보유 시간이 길어진 문제"입니다. 트랜잭션 범위, 쿼리 계획, 재시도, 배치 간섭을 같이 봐야 합니다.

다섯째, 같은 서비스라도 평시와 이벤트 시간대의 최적값이 다를 수 있습니다. 그래서 하드코딩된 숫자보다 경보 기준과 재평가 주기가 더 중요합니다.

체크리스트 또는 연습

체크리스트

• 서비스별로 DB 풀 상한의 근거 지표가 문서화되어 있다.
• pool_acquire_p95/p99, pending, timeout, DB active session을 같은 화면에서 본다.
• 인스턴스 수 변화 시 총합 동시성 상한을 계산한다.
• API deadline, pool wait timeout, DB query timeout 순서가 정렬돼 있다.
• 재시도 정책이 풀 포화를 증폭시키지 않는지 주기적으로 점검한다.
• 장기 트랜잭션과 슬로우 쿼리 상위 목록을 주간으로 검토한다.

연습 과제

1. 현재 운영 중인 API 하나를 골라 피크 RPS × DB 점유시간 p95로 필요한 총 동시성을 계산해 보세요. 지금 풀 상한과 얼마나 차이 나는지 숫자로 확인해 보면 감 대신 기준이 생깁니다.
2. HikariCP나 클라이언트 풀 메트릭에서 acquire p95, pending, timeout을 한 화면에 모아 보세요. 그다음 같은 시간대의 DB lock wait를 붙여 보면 풀 부족과 하류 병목이 분리됩니다.
3. 최근 한 달간 배포 직후 latency가 튄 적이 있다면, 신규 인스턴스 기동 시점과 커넥션 생성 급증 시점을 겹쳐 보세요. connection storm가 원인이면 풀 숫자보다 기동 절차를 먼저 손봐야 합니다.

관련 글

• 백엔드 커리큘럼: 회복탄력성 단계
• 용량 계획과 Little’s Law 기반 포화도 해석
• Thread Pool 튜닝
• Timeout/Retry/Backoff 설계
• Connection Storm과 Thundering Herd 플레이북
• Admission Control과 동시성 제한