서버리스 인스턴스 동결과 Postgres 풀러 클라이언트 슬롯 고갈: Next.js·Supabase 운영 사례와 로컬 재현

Abstract

서버리스 함수는 응답 뒤 실행 환경이 얼어붙는다. 이때 앱이 트랜잭션 풀러에 연 커넥션이 어떻게 남는지는 잘 드러나지 않는다. 이 논문은 Next.js·Vercel·Supabase로 만든 사내 도구 zenith에서 2026년 7–9월에 반복된 커넥션 장애를 장애 기록 11건과 커밋 16건으로 재구성하고, 원인을 네 기제로 나눈다. 핵심 장애는 풀러 클라이언트 슬롯 200개의 고갈이었고, 풀 상한을 10에서 4로 낮춘 뒤에도 재발했다. 동결된 인스턴스에서는 유휴 타이머가 실행되지 않으므로, 점유가 요청을 한 번이라도 처리한 인스턴스 수 W에 비례한다는 모형 W·min(q, m)을 세웠다. 프로세스 정지 신호로 동결을, TCP 프록시로 슬롯 상한 40을 흉내 낸 재현 실험에서 타이머에만 맡긴 두 구성의 최대 점유는 모든 조건에서 min(W·min(q, m), 40)과 같았고, 실패 인스턴스는 상한 4에서 W = 16일 때 6개였다. 풀 전체가 조용해진 뒤 소켓을 닫는 반납 구성은 인스턴스를 8개에서 16개로 늘려도 최대 점유가 32–36개로 상한 40 아래였고 실패가 없었다. 그 대가로 성공 요청의 지연 중앙값이 2.6–8.7 ms 늘었다. 동결이 유휴 타이머보다 짧고 그동안 소켓이 끊긴 경우에는 세 방어 구성 중 쿼리 전 풀 교체만이 첫 요청과 재시도를 모두 성공시켰다.

주요 기여

• 운영 기록 11건과 커밋 16건으로 장애 계보를 재구성한다. 원인을 네 가지 기제(얼어붙은 소켓의 슬롯 점유, 죽은 소켓 hang, 동시 요청 간 반납 간섭, 파이프라인 문장 유실)로 나눈다.
• 인스턴스 동결 아래의 슬롯 점유 모형을 세운다. 타이머 기반 정리에서는 점유가 활성 인스턴스가 아니라 한 번이라도 요청을 처리한 인스턴스 수에 비례한다는 예측을 낸다.
• 프로세스 정지 신호(SIGSTOP)로 동결을 흉내 내는 재현 환경을 만든다. 그 환경에서 예측과 세 가지 반납 구성의 차이를 측정한다.

결론

응답 직후 얼어붙는 서버리스 인스턴스에서 타이머 기반 정리와 풀 상한은 풀러 클라이언트 슬롯의 점유를 제한하지 못했다. 재현 실험에서 점유는 min(W·min(q, m), L)을 따랐고, 상한을 낮추면 고갈 시점만 늦춰졌다. 풀 전체가 조용해진 뒤 소켓을 닫는 반납은 인스턴스를 8개에서 16개로 늘려도 최대 점유를 32–36개로 유지했다. 그 대가는 요청당 연결 수립(루프백에서 p50 2.6–8.7 ms 증가)과 반납 대기 시간이다. 죽은 소켓 hang에는 쿼리 전 풀 교체가 첫 요청과 재시도를 모두 살렸다. 후속 과제는 실제 플랫폼에서 동결 중 타이머 동작을 확인하는 일과 반납 대기의 비용을 측정하는 일이다.