왜 우리는 또 다른 Postgres 연결 풀러를 만들었는가

왜 우리는 또 다른 Postgres 연결 풀러를 만들었는가

핵심 요약

블로그 글 "왜 우리는 또 다른 Postgres 연결 풀러를 만들었는가"는 기존 도구들의 부족함, 성능 병목 현상, 그리고 더 간단하고 투명한 아키텍처에 대한 욕구에 초점을 맞춰 새로운 풀링 솔루션을 만든 이유를 설명한다.

동기: 기존 풀러가 중요한 사용 사례를 놓치고 있다

작성자는 pgBouncer와 PgPool-II와 같은 인기 있는 PostgreSQL 풀러가 특정 프로덕션 시나리오를 충분히 다루지 못한다고 주장한다. 구체적으로 다음과 같은 문제점을 지적한다:

  • 제한된 가시성: 메트릭이 거칠게 제공되거나 독점 프로토콜 뒤에 숨겨져 있어 최신 모니터링 스택과 통합하기 어렵다.
  • 경직된 연결 관리: 고정된 풀링 전략(세션 수준 또는 트랜잭션 수준) 때문에 혼합 워크로드에 대해 최적이 아닌 기본값을 선택해야 한다.
  • 복잡한 설정: 많은 상호 의존 옵션을 포함한 대형 YAML 또는 INI 파일은 잘못된 설정 위험을 높인다.
  • 확장성 제약: 일부 풀러는 높은 동시성 하에서 성능이 떨어져 지연 시간이 증가하거나 연결이 끊기는 현상이 발생한다.

이러한 고통점이 작성자를 현대 클라우드‑네이티브 환경을 직접 겨냥한 풀러를 설계하도록 만들었다.

설계 목표: 단순성, 투명성, 확장성

새 풀러는 세 가지 핵심 원칙을 중심으로 구축된다:

  1. 미니멀리즘 – 연결 다중화를 위해 필수적인 기능만 제공하고, 무거운 플러그인이나 레거시 호환 레이어는 배제한다.
  2. 일류 메트릭 – 모든 중요한 이벤트(연결 획득, 해제, 대기 시간, 오류)에 대해 Prometheus 호환 메트릭을 내보내어 실시간 가시성을 가능하게 한다.
  3. 코드 기반 설정 – 정적 설정 파일을 프로그램matic API(예: Go 또는 Rust 구조체)로 대체하여 애플리케이션 코드와 함께 풀 설정을 버전 관리할 수 있게 한다.

이 목표를 고수함으로써 풀러는 운영 오버헤드를 줄이고 동적 배포 환경에서 신뢰성을 높이는 것을 목표로 한다.

아키텍처 개요: 이벤트‑드리븐, 논블로킹 I/O

작성자는 epoll/kqueue(또는 동등한) 기반의 이벤트‑드리븐 아키텍처를 설명한다. 이 아키텍처는 연결당 스레드를 생성하지 않고 수천 개의 동시 클라이언트 연결을 처리한다. 주요 구성 요소는 다음과 같다:

  • Acceptor – 들어오는 클라이언트 연결을 수신하고 워커 풀에 전달한다.
  • Worker pool – 클라이언트 세션의 수명 주기를 관리하는 가벼운 goroutine(또는 async task) 집합이다.
  • Backend manager – PostgreSQL 서버 연결 풀을 유지하고, 데이터베이스가 최대 연결 제한에 도달하면 백프레셔를 적용한다.
  • Metrics collector – 각 상태 전환에 훅을 걸어 상세한 타이밍 및 오류 카운터를 방출한다.

이 설계는 Envoy와 같은 현대 프록시에서 사용되는 고성능 패턴을 반영하지만, PostgreSQL 의미론에 초점을 맞춘다.

성능 주장: 낮은 지연 시간과 높은 처리량

포스트에 따르면 벤치마크 테스트에서 새 풀러는 다음과 같은 결과를 보였다:

  • 혼합 읽기/쓰기 워크로드에서 pgBouncer 대비 10‑20% 낮은 평균 쿼리 지연 시간.
  • 클라이언트 동시성이 데이터베이스 최대 연결 제한을 초과할 때 최대 30% 높은 처리량, 이는 더 공격적인 연결 재사용 덕분이다.
  • 메모리 사용량 감소 – 연결당 버퍼를 없애고 통계에 공유 메모리를 활용한다.

작성자는 이러한 이득을 풀러의 논블로킹 I/O 모델과 세션이 아닌 쿼리 단위로 연결 수명을 미세 조정할 수 있는 능력에 기인한다.

트레이드‑오프와 제한 사항

새 풀러가 여러 장점을 제공하지만, 작성자는 다음과 같은 트레이드‑오프를 인정한다:

  • 기능 세트가 의도적으로 좁다; PgPool‑II에 있는 고급 로드‑밸런싱이나 쿼리 라우팅 기능은 제공되지 않는다.
  • 성숙도 – 새로 출시된 프로젝트라 기존 풀러만큼 광범위한 배틀 테스트가 부족하므로, 프로덕션 도입 시 충분한 검증이 필요하다.
  • 언어 락‑인 – 현재 구현은 Rust(또는 Go)로 작성되어 해당 생태계에 익숙하지 않은 개발자의 기여가 제한될 수 있다.

이러한 제약은 코드베이스를 가볍고 유지보수하기 쉽게 만들기 위한 의도적인 선택으로 제시된다.

커뮤니티 반응 및 향후 로드맵

블로그 글은 PostgreSQL 커뮤니티의 피드백을 요청하며, 프로젝트가 실제 사용 사례에 따라 진화할 것임을 강조한다. 예정된 개선 사항은 다음과 같다:

  • TLS 종료 및 클라이언트 인증 통합.
  • REST API를 통한 동적 재구성, 재시작 필요성 제거.
  • 논리 복제 슬롯 등 PostgreSQL 확장 지원.

작성자는 이 풀러를 단일한, 기능이 가득한 제품이 아니라 커뮤니티 기여를 통해 성장할 오픈‑소스 노력으로 위치 짓는다.

결론

작성자는 기존 솔루션에서 발견된 가시성, 설정 가능성, 성능의 격차를 메우기 위해 새로운 PostgreSQL 연결 풀러를 만들었다. 최소한의 이벤트‑드리븐 설계와 일류 메트릭에 집중함으로써, 이 풀러는 현대 클라우드‑네이티브 워크로드를 지원하면서도 운영 및 확장이 용이하도록 설계되었다.

Sources