PostgreSQL 확장성 향상: PgBouncer 연결 풀링 구현

PostgreSQL은 견고성과 ACID 준수로 유명하지만, 모든 엔터프라이즈급 관계형 데이터베이스와 마찬가지로 극심한 부하, 특히 연결 관리와 관련하여 어려움을 겪습니다. 고부하 애플리케이션이 수평적으로 확장될 때 발생하는 동시 연결의 범람은 데이터베이스 서버를 빠르게 압도하여 높은 지연 시간과 리소스 고갈을 초래할 수 있습니다.

이 문서는 PostgreSQL을 위한 최고의 연결 풀러인 PgBouncer 구현에 대한 포괄적인 가이드 역할을 합니다. 네이티브 연결 처리가 높은 부하에서 비효율적인 이유를 살펴보고, 세 가지 주요 풀링 모드를 정의하며, 구성을 위한 실용적인 단계를 제공하고 배포하여 PostgreSQL 배포의 확장성과 처리량을 극적으로 향상시킬 수 있도록 안내합니다.

병목 현상: 네이티브 PostgreSQL 연결 오버헤드

PostgreSQL은 프로세스당 전용 연결 모델을 사용합니다. 이 아키텍처는 매우 안정적이며 격리를 보장하지만, 스트레스 상황에서 상당한 오버헤드를 발생시킵니다.

리소스 소비: 새 연결마다 서버는 새 백엔드 프로세스를 포크(fork)해야 하므로 메모리와 CPU 리소스를 소비합니다. 수백 또는 수천 개의 유휴 연결이 불필요하게 RAM을 점유합니다.
느린 설정: 새 연결을 설정하는 과정에는 네트워크 핸드셰이크, 인증, 프로세스 초기화가 포함되어 연결을 자주 열고 닫는 애플리케이션 요청에 측정 가능한 지연 시간을 추가합니다.
확장 한계: 이러한 리소스 요구 사항은 성능이 저하되기 전에 PostgreSQL 서버가 현실적으로 처리할 수 있는 동시 연결 수에 실질적인 상한선을 부과합니다.

PgBouncer 소개: 경량 프록시

PgBouncer는 클라이언트 애플리케이션과 PostgreSQL 데이터베이스 서버 사이에 위치하는 경량 프록시 서버 역할을 합니다. 핵심 기능은 PostgreSQL 백엔드에 대해 영구적인 고정 수의 열린 연결을 유지하고, 임시적인 애플리케이션 클라이언트 요청을 위해 이러한 연결을 풀링하고 재사용하는 것입니다.

이 접근 방식은 두 가지 중요한 이점을 제공합니다.

오버헤드 감소: PostgreSQL 서버는 PgBouncer가 유지하는 고정된 연결 풀만 보게 되므로 들어오는 클라이언트 요청에 대한 비용이 많이 드는 프로세스당 연결 포크 주기가 제거됩니다.
처리량 증가: 확립된 연결을 재사용함으로써 PgBouncer는 인증 및 연결 초기화 시간을 최소화하여 애플리케이션 처리량을 상당히 높이고 지연 시간을 줄입니다.

PgBouncer 풀링 모드 이해하기

PgBouncer의 효율성은 선택한 풀링 모드에 크게 좌우됩니다. PgBouncer는 세 가지 기본 모드를 제공하며, 각 모드는 다양한 애플리케이션 아키텍처 및 동시성 요구 사항에 적합합니다.

1. 세션 풀링 (`pool_mode = session`)

세션 풀링은 기본값이자 가장 안전한 모드입니다. 클라이언트가 연결되면 PgBouncer는 클라이언트가 연결을 끊을 때까지 해당 클라이언트에게 풀링된 서버 연결을 할당합니다. 연결은 클라이언트가 명시적으로 세션을 닫을 때만 풀로 반환됩니다.

사용 사례: 준비된 구문, 임시 테이블, 사용자 지정 변수에 대한 SET 명령과 같이 세션별 기능에 크게 의존하는 애플리케이션.
장점: 가장 안전하며 모든 PostgreSQL 기능과 완벽하게 호환됩니다.
단점: 클라이언트 유휴 시간 동안에도 연결이 유지되므로 풀링 효율성이 가장 낮습니다.

2. 트랜잭션 풀링 (`pool_mode = transaction`)

트랜잭션 풀링은 일반적으로 상태 비저장 API를 사용하는 고부하 웹 애플리케이션에 권장됩니다. 서버 연결은 단일 트랜잭션(BEGIN에서 COMMIT/ROLLBACK까지) 기간 동안만 클라이언트에 할당됩니다. 트랜잭션이 완료되는 즉시 연결은 재사용을 위해 대기 중인 다른 클라이언트에게 즉시 풀로 반환됩니다.

사용 사례: OLTP 시스템 및 마이크로서비스에서 흔히 발생하는 짧고 빈번한 트랜잭션.
장점: 서버 리소스의 매우 효율적인 활용.
단점: 애플리케이션이 트랜잭션을 신중하게 관리해야 합니다. 트랜잭션 간에 세션 수준 상태 변경 사항(예: SET extra_float_digits = 3)이 손실되거나 다른 클라이언트에게 유출될 수 있습니다.

⚠️ 트랜잭션 풀링을 위한 모범 사례

pool_mode = transaction을 사용할 때는 pgbouncer.ini에서 server_reset_query = DISCARD ALL을 구성하는 것이 강력히 권장됩니다. 이 명령은 연결이 풀로 반환될 때 남아 있는 세션 상태(임시 테이블, 자문 잠금, 시퀀스 상태)가 즉시 정리되도록 보장하여 다음 클라이언트에 대한 데이터 유출이나 예기치 않은 동작을 방지합니다.

3. 문장 풀링 (`pool_mode = statement`)

문장 풀링은 가장 공격적인 모드입니다. 서버 연결은 각 개별 문장 실행 후 풀로 반환됩니다. 이 모드는 다중 문장 트랜잭션 사용을 효과적으로 방지하며 매우 제한적입니다.

사용 사례: 트랜잭션이 명시적으로 금지되거나 불필요한 매우 특수한 읽기 전용 부하.
장점: 연결 재사용 극대화.
단점: 모든 트랜잭션을 중단시킵니다. 트랜잭션이 사용되지 않음이 보장되는 환경에만 적합합니다.

PgBouncer 설정 및 초기 구성

1. 설치

PgBouncer는 표준 배포 저장소에서 종종 사용할 수 있습니다.

# Debian/Ubuntu에서
sudo apt update && sudo apt install pgbouncer

# RHEL/CentOS에서
sudo dnf install pgbouncer

2. 구성 파일

PgBouncer는 주로 두 가지 구성 파일에 의존하며, 이 파일들은 일반적으로 /etc/pgbouncer/에 위치합니다.

pgbouncer.ini: 데이터베이스, 풀 제한 및 작동 모드를 정의하는 기본 구성.
userlist.txt: PgBouncer가 PostgreSQL 서버에 인증하는 데 사용하는 사용자 및 암호를 정의합니다.

3. 사용자 정의(`userlist.txt`)

보안상의 이유로 PgBouncer는 PostgreSQL의 pg_authid 테이블을 직접 읽지 않습니다. 인증할 수 있는 사용자를 수동으로 정의해야 합니다. 이 파일이 보안 설정(예: pgbouncer 사용자 소유 및 권한 제한)되어 있는지 확인하십시오.

```text:userlist.txt
"app_user" "MD5HASH_OF_PASSWORD_OR_PLANTEXT"
"admin_user" "another_hash"

> 참고: 평문 암호도 가능하지만, `psql -c "SELECT md5('your_password')"`와 같은 도구를 사용하여 원시 암호에서 생성된 MD5 해시를 사용하는 것이 더 안전합니다.

### 4. `pgbouncer.ini` 구성

`pgbouncer.ini` 파일은 풀러의 동작을 정의합니다. 아래 예제는 트랜잭션 풀링을 사용하는 일반적인 웹 애플리케이션 설정을 위해 맞춤화되었습니다.

```ini:pgbouncer.ini Snippet
[databases]
# 클라이언트 연결 문자열 정의:
# <데이터베이스 이름> = host=<pg_서버_ip> port=<pg_포트> dbname=<db_이름> user=<pgbouncer_인증_사용자>
myappdb = host=10.0.0.5 port=5432 dbname=productiondb user=pgbouncer_service

[pgbouncer]

; 수신 구성
listen_addr = *
listen_port = 6432

; 인증 구성
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt

; 풀링 모드 (애플리케이션 요구 사항에 따라 설정)
pool_mode = transaction
server_reset_query = DISCARD ALL

; 연결 제한 및 크기
; PgBouncer에 대한 최대 총 클라이언트 연결 수
max_client_conn = 1000

; PgBouncer가 데이터베이스당 열어 두는 최대 연결 수 (풀 크기)
default_pool_size = 20

; 모든 데이터베이스에 걸쳐 풀에 허용되는 최대 연결 수
max_db_connections = 100

; 풀이 소진될 때 예약할 슬롯 수
reserve_pool_size = 5

; 로깅 및 관리
admin_users = postgres, admin_user
stats_users = postgres

모니터링 및 관리

PgBouncer는 관리자가 풀러의 상태, 통계 및 연결을 실시간으로 모니터링할 수 있는 pgbouncer라는 유사 데이터베이스를 노출합니다. 정의된 admin_users 중 하나를 사용하여 PgBouncer 수신 포트(예: 6432)에 연결합니다.

psql -p 6432 -U admin_user pgbouncer

주요 관리 명령:

명령	설명	사용 참고
`SHOW STATS;`	연결 통계(요청, 바이트, 총 지속 시간)를 표시합니다.	성능 분석에 유용합니다.
`SHOW POOLS;`	구성된 모든 데이터베이스에 대한 풀 상태를 표시합니다.	`cl_active`, `sv_active`, `sv_idle`을 모니터링합니다.
`SHOW CLIENTS;`	PgBouncer에 연결된 모든 클라이언트 연결을 나열합니다.
`RELOAD;`	연결을 중단하지 않고 구성을 다시 로드하려고 시도합니다.
`PAUSE;`	새 쿼리 수신을 중지하고 현재 트랜잭션이 완료될 때까지 기다립니다.	유지 관리 또는 PgBouncer 업그레이드 전에 사용됩니다.

확장 팁

배치: PgBouncer를 애플리케이션과 동일한 서버 또는 전용의 네트워크 최적화된 머신에 설치하여 애플리케이션과 풀러 간의 지연 시간을 최소화하십시오.
풀 크기 조정: default_pool_size는 합리적인 수(일반적으로 10-50)로 설정해야 하며, 이는 일반적으로 PostgreSQL 서버 자체에서 허용되는 연결 수보다 훨씬 적습니다. 과도한 풀 크기는 풀링의 목적을 무효화합니다.
클라이언트 제한: max_client_conn을 사용하여 연결 폭풍이 PgBouncer 자체를 압도하는 것을 방지하십시오. 이는 강력한 프런트엔드 스로틀 역할을 합니다.

결론

PgBouncer 연결 풀링을 구현하는 것은 고동시성 환경에서 PostgreSQL 확장성을 개선하기 위한 가장 영향력 있는 단계라고 할 수 있습니다. 연결 관리를 중앙 집중화하고 효율적인 풀링 모드를 활용함으로써 애플리케이션은 연결 오버헤드를 극적으로 줄이고, 데이터베이스 서버에서 안정적인 메모리 사용량을 유지하며, PostgreSQL의 안정성을 저해하지 않으면서 더 높은 요청 처리량을 달성할 수 있습니다.