부하 상황에서 커넥션 풀(Connection Pool)이 고갈되는 이유

기능을 배포했습니다. 부하 테스트(Load testing)는 괜찮아 보였습니다. 트래픽이 급증하고, 지연 시간(Latency)이 상승하며, 데이터베이스가 연결을 끊기 시작합니다. 가장 먼저 드는 생각은 애플리케이션 계층을 확장(Scale)하는 것입니다. 그러지 마세요. 병목 현상(Bottleneck)은 컴퓨팅 자원이 아닙니다. 바로 여러분의 커넥션 풀(Connection Pool)입니다.

대부분의 개발자는 커넥션 풀을 한 번 설정하면 잊어버려도 되는 설정값으로 취급합니다. ORM에 기본 풀 크기를 설정하고, 타임아웃(Timeout)을 늘린 뒤 다음 작업으로 넘어갑니다. 그렇게 하면 작동은 합니다, 문제가 생기기 전까지는 말이죠. 커넥션 풀링(Connection pooling)은 마법이 아닙니다. 이는 엄격한 한계가 있는 유한한 자원이며, 잘못 설정할 경우 실제 운영 환경의 동시성(Concurrency) 상황에서 처리량(Throughput) 저하를 보장하게 됩니다.

핵심 문제는 max_connections가 실제로 무엇을 제어하는지 오해하는 데 있습니다. 이는 워커 스레드(Worker threads)에 따라 확장되지 않습니다. 쿼리 복잡도(Query complexity)에 따라 자동 조정되지도 않습니다. 이는 엄격한 상한선(Hard ceiling)입니다. 모든 들어오는 요청이 데이터베이스 핸들(Database handle)을 필요로 하는데 풀이 고갈되면, 애플리케이션은 우아하게 대기열(Queue)에 쌓이지 않습니다. 차단(Block)됩니다. 스레드(Threads)가 쌓입니다. 메모리(Memory)가 팽창합니다. 결국 OS 제한에 도달하거나 서킷 브레이커(Circuit breakers)를 트리거하게 됩니다.

수학적으로 살펴봅시다. 만약 API가 16개의 워커 프로세스(Worker processes)를 실행하고 풀 크기가 20이라면, 여러분은 이미 자원을 두고 싸우고 있는 것입니다. 여기에 데이터베이스에 접속하는 백그라운드 작업(Background jobs), 상태 확인(Health checks), 관리자 엔드포인트(Admin endpoints)를 추가하면 고갈(Starvation)은 보장됩니다. 해결책은 단순히 숫자를 늘리는 것이 아닙니다. 요청 동시성(Request concurrency)이 아니라 실제 쿼리 동시성(Query concurrency)에 맞춰 풀 용량을 정렬하는 것입니다.

대부분의 프레임워크는 풀 크기를 10에서 20 사이로 기본 설정합니다. 이는 로컬 개발 환경에서는 수용 가능합니다. 하지만 운영 환경(Production)에서는 끔찍합니다. 기능적인 기준점은 전통적인 데이터베이스의 경우 (CPU 코어 수 * 2) + 유효 디스크 스핀들(Effective disk spindles)에서 시작하지만, 반드시 데이터베이스의 엄격한 연결 제한과 애플리케이션의 실제 동시 쿼리 프로필(Concurrent query profile)을 기반으로 상한선을 정해야 합니다. 추측하지 말고 측정하세요.

팀들은 관례적으로 풀 크기(Pool size)를 설정하지만, 커넥션 검증(Connection validation)과 유휴 시간 제한(Idle timeout)은 무시하곤 합니다. 풀에 머물러 있는 오래된(Stale) 커넥션은 체크아웃(Checkout)될 때 소켓 에러(Socket error)를 발생시킵니다. 당신은 재시도(Retry)를 하고, 누수(Leak)가 발생하며, 결국 풀을 더 빠르게 고갈시킵니다. 단순히 생성 시점에만 검증하는 것이 아니라, 체크아웃 시점에 활성 검증(Active validation)이 필요합니다.

다음은 Node.js PostgreSQL 클라이언트를 위한 올바른 기본 설정(Baseline configuration)입니다. 이는 정적인 기본값들을 명시적인 생명주기 제어(Lifecycle controls)로 대체합니다:

const pool = new Pool({
  max: 30, // DB의 max_connections와 일치시키고 검증된 동시성(Concurrency)에 맞춤
  idleTimeoutMillis: 10000, // 유휴 핸들(Idle handles)을 공격적으로 회수
...

maxUses에 주목하십시오. PostgreSQL과 MySQL 모두 커넥션 생명주기 제한(Connection lifecycle limits)을 추적합니다. 강제적인 로테이션(Rotation)은 오래된 상태(Stale state)의 누적을 방지합니다. error 리스너(Listener)는 표준 pool.connect() 호출로는 드러나지 않는 비동기적 네트워크 단절을 포착합니다. 이것이 없다면, 깨진 소켓(Broken sockets)은 운영 환경의 트랜잭션(Transaction)을 오염시킬 때까지 활성 세트(Active set)에 남아 있게 됩니다.

설정을 넘어, 코드에서 커넥션 누수(Connection leaks)가 있는지 감사(Audit)하십시오. 수동으로 체크아웃할 때마다 finally 블록 내에서 release()를 호출해야 합니다. ORM은 이를 추상화하지만, 로우 쿼리(Raw queries)와 트랜잭션 래퍼(Transaction wrappers)는 이러한 안전장치를 우회합니다. 만약 풀 사용량 지표(Pool usage metrics)가 트래픽이 적은 동안에도 서서히 상승한다면, 누수가 발생하고 있는 것입니다. 풀 이벤트 리스너(Pool event listeners)를 추가하십시오. 체크아웃 지속 시간(Checkout duration)을 로그로 남기십시오. 대기 큐(Waiting queue)가 엄격한 임계값(Hard threshold)을 초과할 때 알림을 보내도록 설정하십시오.

또한 읽기(Read)와 쓰기(Write) 풀을 분리해야 합니다. 이들을 혼합하는 것은 경합(Contention)을 보장하는 것과 같습니다. 쓰기는 행 잠금(Row locks)에 의해 차단됩니다. 읽기는 그 뒤에서 대기하게 됩니다. 쿼리를 명시적으로 라우팅(Route)하십시오. 용량이 더 크고 검증 오버헤드(Validation overhead)가 낮은 읽기 복제본(Read replica) 풀을 사용하십시오. 기본(Primary) 풀은 타이트하게 유지하고, 검증하며, 오직 변이(Mutations) 작업만을 위해 예약해 두십시오.

커넥션 고갈(Connection exhaustion)을 일시적인 네트워크 오류로 취급하지 마십시오. pool exhausted 에러는 용량 계획(Capacity planning)에 대한 신호입니다. 백프레셔(Backpressure)를 구현하십시오. 큐(Queue)가 쌓이도록 방치하는 대신, Retry-After 헤더와 함께 503 Service Unavailable을 반환하십시오. 그러면 다운스트림 서비스(Downstream services)가 우아한 성능 저하(Graceful degradation)를 처리할 것입니다. 사용자들은 통제된 스로틀링(Throttling)과 연쇄적 장애(Cascading failure) 사이의 차이를 느끼게 될 것입니다.

네 가지 지표를 모니터링하십시오: 활성 커넥션(Active connections), 유휴 커넥션(Idle connections), 대기 요청(Waiting requests), 그리고 평균 체크아웃 시간(Average checkout time)입니다. 만약 체크아웃 시간이 평균 쿼리 실행 시간(Average query execution time)을 초과한다면, 풀의 크기가 너무 작거나 쿼리가 블로킹(Blocking)되고 있는 것입니다. 대기 요청이 증가한다면, 커넥션 누수(Leaking connections)가 발생하고 있거나 동시성 모델(Concurrency model)이 풀 크기와 일치하지 않는 것입니다.

커넥션 풀을 튜닝하는 것은 배포 단계의 작업이 아닙니다. 그것은 지속적인 피드백 루프(Feedback loop)입니다. 인위적인 스파이크(Synthetic spikes)가 아닌, 실제 트래픽 분포를 시뮬레이션하는 부하 테스트(Load tests)를 수행하십시오. 풀 지표를 관찰하십시오. 조정하십시오. 검증하십시오. 반복하십시오. 추측을 멈추고 측정을 시작하십시오. 애플리케이션이 자체 리소스 관리 문제로 질식한다면, 데이터베이스는 확장(Scale)될 수 없습니다.