#7 - PgBouncer로 이해하는 대규모 PostgreSQL 커넥션 풀링

PgBouncer로 이해하는 대규모 PostgreSQL 커넥션 풀링

1. 대규모 PostgreSQL 운영 사례

OpenAI는 PostgreSQL을 단일 Master + 약 50대 Replica(Read Only) 구조로 확장 운영하고 있는 것으로 공개적으로 알려져 있습니다. 이 구조의 핵심은 쓰기와 읽기의 분리, 그리고 연결(Connection) 관리의 효율화입니다.

PostgreSQL은 구조적으로 클라이언트 연결 1개당 서버 백엔드 프로세스 1개를 생성합니다. 이는 안정성과 단순성 측면에서는 훌륭하지만, 대규모 트래픽 환경에서는 매우 비싼 비용 구조가 됩니다.

이 문제를 해결하기 위해 OpenAI를 포함한 대규모 서비스들은 PgBouncer 같은 외부 커넥션 풀러(Connection Pooler) 를 필수 인프라로 사용합니다.

2. PostgreSQL 커넥션은 왜 비싼가?

PostgreSQL은 Thread 기반이 아니라 Process 기반 구조
커넥션 1개 = OS 프로세스 1개
각 프로세스는 메모리, 컨텍스트 스위칭 비용을 동반

즉,

커넥션 수 ↑ → 메모리 사용량 ↑ → CPU 컨텍스트 스위칭 ↑ → 전체 성능 저하

그래서 max_connections 값을 무작정 키우는 것은 근본 해결책이 아닙니다.

3. Spring Boot(HikariCP)만으로는 왜 부족한가?

Spring Boot는 기본적으로 HikariCP라는 매우 훌륭한 커넥션 풀을 제공합니다.

하지만 이 풀은 "애플리케이션 내부" 에만 존재합니다.

문제는 여기서 시작됩니다

인스턴스 1대 → HikariCP 풀 1개
인스턴스 50대 → HikariCP 풀 50개
결과적으로 PostgreSQL은 여전히 수천 개의 실제 커넥션을 받게 됨

특히 다음 환경에서는 문제가 커집니다.

Kubernetes / Auto Scaling
마이크로서비스 아키텍처
트래픽 스파이크가 잦은 서비스

👉 이때 필요한 것이 애플리케이션 외부에서 커넥션을 통제하는 계층, 즉 PgBouncer입니다.

4. PgBouncer란 무엇인가?

PgBouncer는 PostgreSQL 전용 경량 커넥션 풀러입니다.

애플리케이션과 PostgreSQL 사이에 위치
수많은 클라이언트 커넥션을 소수의 실제 DB 커넥션으로 재사용
PostgreSQL의 프로세스 수를 강력하게 제어

5. 전체 아키텍처 한눈에 보기

핵심 포인트

애플리케이션 수가 늘어나도 PostgreSQL 커넥션 수는 PgBouncer에서 제한
Replica 확장 시 읽기 트래픽 분산 용이
DB 서버 안정성 대폭 향상

6. PgBouncer Pool Mode 이해하기

PgBouncer는 커넥션을 어떻게 재사용할지에 따라 Pooling Mode를 제공합니다.

Mode	설명	특징
session	클라이언트 접속 동안 서버 커넥션 유지	가장 단순, 효율은 낮음
transaction	트랜잭션 단위로 서버 커넥션 할당	⭐ 가장 많이 사용
statement	SQL 1문장 단위	제약 많음, 특수 상황

👉 대부분의 웹 서비스는 transaction 모드를 사용합니다.

7. pgbouncer.ini 실전 설정 예시

ini

[databases]
# 실제 운영에서는 DB alias 를 통해 접근을 제한한다
mydb = host=127.0.0.1 port=5432 dbname=mydb

[pgbouncer]
# ================================
# Network / Listener
# ================================
listen_addr = 0.0.0.0
listen_port = 6432

# ================================
# Authentication (HBA 기반 보안)
# ================================
# ⚠ 공식 문서 기준 주의사항
# auth_hba_file 옵션은 auth_type = hba 인 경우에만 사용된다
# (scram-sha-256, md5 와 동시에 사용되지 않음)

# --------------------------------
# [권장 기본 구성 – 실전 표준]
# --------------------------------
# PostgreSQL 최신 권장 인증 방식
# 대부분의 운영 환경에서는 scram-sha-256 만으로 충분하다
auth_type = scram-sha-256

# PgBouncer 가 참조할 사용자 인증 정보 파일
# 이 파일은 PostgreSQL 에서 SELECT 로 조회하여
# 자동 생성하는 것이 일반적인 운영 패턴
auth_file = /etc/pgbouncer/userlist.txt

# --------------------------------
# [HBA 모드 사용 시에만 설정]
# --------------------------------
# auth_type = hba 로 설정한 경우에만 활성화됨
# PostgreSQL 의 pg_hba.conf 와 동일한 개념의 접근 제어 파일
# IP / USER / DATABASE 단위 접근 제어 가능
# auth_hba_file = /etc/pgbouncer/pg_hba.conf

# ================================
# Pooling Strategy
# ================================
# ================================
# 실전에서는 transaction 모드가 표준
pool_mode = transaction

# PgBouncer 가 받을 수 있는 최대 클라이언트 연결 수
max_client_conn = 5000

# 실제 PostgreSQL 로 연결되는 커넥션 수 제어
default_pool_size = 100
min_pool_size = 10
reserve_pool_size = 20

# ================================
# Connection Lifecycle
# ================================
# idle server connection 정리
server_idle_timeout = 60
server_lifetime = 3600

# ================================
# Logging / Process
# ================================
logfile = /var/log/pgbouncer/pgbouncer.log
pidfile = /var/run/pgbouncer/pgbouncer.pid

# ================================
# Admin
# ================================
admin_users = postgres

8. 주요 설정 항목 해설

🔹 listen_addr / listen_port

애플리케이션이 접속할 PgBouncer 주소와 포트
보통 PostgreSQL 대신 6432 포트를 사용

🔹 pool_mode = transaction

트랜잭션 단위로 커넥션 재사용
성능과 안정성의 균형이 가장 좋음

🔹 max_client_conn

PgBouncer가 받을 수 있는 최대 클라이언트 연결 수
DB 보호를 위한 1차 방어선

🔹 default_pool_size

실제 PostgreSQL로 연결될 최대 커넥션 수 (DB당)

9. 언제 PgBouncer가 반드시 필요한가?

✅ 반드시 필요

대량 트랜잭션 처리 서비스
Kubernetes / Auto Scaling 환경
다수의 Read Replica 운영
PostgreSQL 커넥션 부족 오류를 자주 경험하는 경우

❌ 굳이 필요 없는 경우

소규모 단일 서버
동시 접속자 수가 매우 적은 서비스
단순 CRUD 중심 내부 도구

10. 공식 문서 링크

PgBouncer 공식 사이트: https://pgbouncer.org
PgBouncer Usage 문서: https://www.pgbouncer.org/usage.html
open ai 8억명 서비스
https://openai.com/ko-KR/index/scaling-postgresql/

한 줄 정리

PgBouncer는 성능 최적화 도구가 아니라, 대규모 PostgreSQL 시스템을 "살아있게 만드는 생명 유지 장치"다.