핵심 요약
커넥션 풀은 크다고 빠르지 않다. DB가 동시에 실제로 일할 수 있는 수는 CPU·디스크에 묶여 있어서, 풀을 과하게 키우면 경합·컨텍스트 스위칭으로 오히려 느려진다. 흔한 출발점은 (코어 수 × 2) + 디스크 수 수준이며, 부하 테스트로 조정한다.
1. 사이징 감각
- 커넥션 ≠ 동시성. 10개로도 수천 요청을 처리할 수 있다(대기·재사용)
- 앱 인스턴스 수 × 풀 크기 ≤ DB
max_connections - 서버리스는 인스턴스가 폭증 → 커넥션 고갈 주의
2. 계산 예
| 항목 | 값 |
|---|---|
| 앱 인스턴스 | 4 |
| 인스턴스당 풀 | 10 |
| 총 커넥션 | 40 (≤ max_connections) |
3. 함정
- 서버리스/람다는 동시 실행마다 커넥션 → 외부 풀러(PgBouncer)로 합쳐라
- 풀이 작아 대기가 길면 타임아웃 — 로그로 대기 시간 확인
- 유휴 커넥션도 DB 자원을 먹는다 — idle timeout 설정
자주 묻는 질문
풀을 크게 하면 더 많은 요청을 처리하지 않나요?
일정 지점을 넘으면 DB 내부 경합으로 처리량이 오히려 떨어집니다. 동시 실행 능력은 하드웨어에 묶여 있어, 적정 크기를 부하 테스트로 찾는 게 맞습니다.
서버리스에서 커넥션이 자꾸 고갈됩니다.
함수 인스턴스마다 커넥션을 열어 폭증하기 때문입니다. PgBouncer 같은 외부 풀러를 두거나 데이터 프록시를 사용하세요.
댓글 0