서버리스에서 Postgres "too many connections"가 터집니다 — PgBouncer

Question

서버리스 함수(요청마다 인스턴스가 늘어나는 구조)에서 DB를 쓰는데 트래픽이 조금만 늘면 바로 이 에러가 납니다.

error: sorry, too many clients already (FATAL: 53300)

함수 안의 풀 크기를 1~2로 줄여도 동시에 함수 인스턴스가 수백 개 뜨니 결국 한도를 넘습니다. max_connections를 무작정 올리는 게 답은 아닌 것 같은데 어떻게 해야 하나요?

환경: PostgreSQL 16, 서버리스 런타임

김영삼 · Accepted Answer

정확히 보셨습니다. max_connections를 올리는 건 악수입니다 — Postgres는 커넥션마다 프로세스·메모리를 잡아서, 수백 개로 늘리면 컨텍스트 스위칭·메모리로 오히려 느려지고 불안정해집니다. 정답은 외부 커넥션 풀러(PgBouncer)를 앞에 두고 transaction 풀 모드로 운영하는 것입니다. 함수들은 PgBouncer에 붙고(수백 개 OK), PgBouncer가 실제 Postgres 커넥션 소수(예: 20~50개)를 공유·재사용 pool_mode = transaction — 트랜잭션 단위로 커넥션을 빌려주고 반납해 적은 커넥션으로 많은 클라이언트 처리 [pgbouncer] pool_mode = transaction max_client_conn = 5000 default_pool_size = 30 주의 — transaction 모드 제약: 세션 단위 기능이 깨집니다. prepared statement 캐시, SET 세션 변수, advisory lock, LISTE

클라우드선아 · Answer

PgBouncer transaction 모드로 붙이니 커넥션 에러가 사라졌습니다. 그런데 ORM에서 가끔 "prepared statement already exists" 에러가 나는데 이게 말씀하신 제약인가요?

김영삼 · Answer

맞습니다. transaction 모드에선 커넥션이 매번 바뀌어 서버측 prepared statement 이름이 충돌합니다. 드라이버/ORM에서 prepared statement를 비활성화하면 해결됩니다. node-postgres 계열: prepared 사용 안 함(기본 simple query) 또는 statement 캐시 off Prisma: 연결 문자열에 pgbouncer=true(또는 statement_cache_size=0 류 옵션) 풀러를 못 쓰는 환경이면 데이터 프록시/HTTP 기반 드라이버도 대안입니다.

클라우드선아 · Answer

연결 문자열에 pgbouncer 옵션 넣으니 그 에러도 사라졌습니다. 커넥션 모델 자체를 이해하게 됐네요. 감사합니다!

댓글 0