PgBouncer, 처리량 4배 확장 성공!

커뮤니티에서는 PgBouncer가 취소 요청(Cancellation Request)을 직접 처리해야 하는지에 대한 근본적인 질문이 제기되었습니다. 한 의견은 PgBouncer가 단순히 취소 요청을 PostgreSQL로 전달하고, PostgreSQL이 오류 응답을 반환하면 해당 연결의 PgBouncer가 이를 처리하는 방식이 더 효율적일 수 있다고 주장합니다. 이는 단일 연결(Single Connection)의 상태 관리 복잡성을 줄이는 방안으로 제시되었습니다.

분산 환경에서 피어링(Peering) 메커니즘의 필요성이 강조되었습니다. 잘못된 프로세스로 전달된 취소 요청이 세션을 소유한 다른 프로세스로 전달되지 못하는 문제를 해결하기 위함입니다. PostgreSQL이 피어링을 위한 내장 모드나 설정을 지원하는지, 그리고 소켓 재사용(SO_REUSEPORT) 환경에서 IPC(Inter-Process Communication)를 어떻게 활용하는지에 대한 질문이 이어졌습니다. 이는 고가용성(High Availability) 확보를 위한 중요한 논의입니다.

논의에서는 Yandex의 Odyssey와 pgdogdev의 pgdog이 확장 가능한 PgBouncer 대안으로 언급되었습니다. 특히 Odyssey는 확장성(Scalability) 측면에서, pgdog은 개인적인 요구사항 충족 측면에서 긍정적인 평가를 받았습니다. 이러한 솔루션들은 기존 PgBouncer의 한계를 극복하고 더 높은 처리량과 안정성을 제공할 가능성을 시사합니다.

실제 운영 사례로 Kubernetes 환경에서 PgBouncer를 다중 인스턴스(Multiple Instances)로 구성하는 방식이 공유되었습니다. 이는 단일 머신 내에서뿐만 아니라 여러 머신에 걸쳐 부하 분산(Load Balancing)을 용이하게 합니다. 특히 Azure와 같은 클라우드 환경에서 발생할 수 있는 롤링 업데이트(Rolling Outage)로 인한 서비스 중단을 완화하는 데 효과적이라는 경험이 공유되었습니다.