왜 connection pooling(PgBouncer)이 필요한가요?

Question

Accepted Answer

**Connection pooling**은 요청마다 새 연결을 여는 대신, 적은 수의 데이터베이스 연결을 많은 클라이언트 요청에 걸쳐 재사용합니다. PostgreSQL 연결은 **비쌉니다**(각각 상당한 메모리를 사용하는 별도 프로세스), 따라서 pooling은 부하 하의 성능과 확장성에 필수적입니다. **PgBouncer**가 표준 pooler입니다.

## 문제: PostgreSQL 연결은 비쌈

```text
각 PostgreSQL 연결 = 별도 OS 프로세스, 약 5-10MB 메모리 사용.
  ✗ 연결 열기에 오버헤드 (프로세스 생성, 인증, 설정)
  ✗ 많은 연결 (예: 바쁜 앱의 수천 개) → 막대한 메모리 사용, 경합
  ✗ Postgres에 max_connections 제한 (흔히 약 100); 초과 = 오류
→ 요청마다 연결 열기/닫기, 또는 수천 개 유지는 확장되지 않음.
```

## 해결책: connection pool

```text
POOL은 Postgres에 대한 적은 수의 재사용 가능한 연결을 유지.
애플리케이션 요청이 pool에서 연결을 빌려 사용하고 반환.
  ✓ 연결 재사용 (요청별 열기/닫기 오버헤드 없음)
  ✓ 많은 앱 요청이 적은 DB 연결 공유 (예: 클라이언트 10000개 → 연결 20개)
  ✓ max_connections 내 유지, 리소스 사용 제어 → 확장
```

## PgBouncer — 표준 외부 pooler

```text
PgBouncer는 애플리케이션과 PostgreSQL 사이에 위치 — 가볍고 효율적.
Pooling 모드:
  Session   → 클라이언트의 전체 세션 동안 연결 할당
  Transaction → TRANSACTION 동안만 연결 유지 (가장 효율적 — transaction 간
               연결 반환; 흔한 선택)
  Statement → 문장별 (가장 공격적; 제한적)
→ Transaction pooling은 일반 웹 앱의 연결 재사용을 극대화.
```

## pooling이 일어나는 곳

```text
애플리케이션 수준 → 많은 ORM/드라이버 라이브러리에 내장 pool (앱 인스턴스별)
외부 pooler (PgBouncer) → Postgres 앞의 공유 pool (많은 앱 인스턴스 /
  서버리스에 최적, 인스턴스별 pool이 여전히 DB를 압도할 경우)
→ 서버리스는 특히 외부 pooler 필요 (많은 단명 인스턴스).
```

## 왜 중요한가

Connection pooling은 PostgreSQL을 **규모 있게** 운영하는 데 필수 지식입니다. PostgreSQL 연결이 독특하게 비싸므로(각각 상당한 메모리를 사용하는 별도 OS 프로세스), pooling이 왜 필요하고 어떻게 동작하는지 이해하는 것은 성능 있고 확장 가능한 배포에 중요한 시니어 수준 지식입니다.

핵심 문제는 단순한 접근법 — 요청마다 연결을 열거나, 바쁜 애플리케이션에서 수천 개의 연결을 유지 — 이 Postgres에서 확장되지 않는다는 것입니다: 연결은 비싸고(프로세스당 메모리, 생성 오버헤드), Postgres에 쉽게 초과되는 `max_connections` 제한(흔히 약 100)이 있어 오류와 리소스 고갈을 유발합니다. **Connection pooling**은 많은 애플리케이션 요청이 공유하는(빌리고 반환) 적은 수의 재사용 가능한 연결을 유지하여 이를 해결합니다 — 따라서 수천 개의 클라이언트가 수십 개의 데이터베이스 연결로 서비스될 수 있어, 요청별 오버헤드를 제거하고 제한 내에 머뭅니다.

**PgBouncer**(표준 외부 pooler)와 그 **pooling 모드** — 특히 **transaction pooling**(transaction 동안만 연결 유지, 재사용 극대화, 웹 앱의 흔한 선택) — 을 이해하는 것은 중요한 실용 지식입니다.

**pooling이 일어나는 곳**(인스턴스별 애플리케이션 수준 pool, 대 많은 인스턴스나 서버리스를 위한 PgBouncer 같은 외부 pooler)을 아는 것은 핵심 아키텍처 요점입니다 — **서버리스는 특히 외부 pooler가 필요**합니다. 많은 단명 인스턴스가 그렇지 않으면 연결로 Postgres를 압도하기 때문입니다(흔하고 실제적인 문제).

연결 관리가 부하 하의 확장성과 안정성에 직접 영향을 미치고(Postgres의 연결당 프로세스 모델이 이를 첨예하게 만듦), pooling(특히 transaction pooling이 있는 PgBouncer)이 표준적이고 필수적인 솔루션이므로, connection pooling — Postgres가 왜 필요로 하는지, 어떻게 동작하는지, PgBouncer와 그 모드, 서버리스 고려사항 — 을 이해하는 것은 PostgreSQL을 규모 있게 운영하는 중요한 시니어 수준 지식이며, Postgres를 확장할 수 있는 사람과 연결 제한 실패를 겪는 사람을 구별하는 프로덕션 시스템의 자주 중대한 우려사항입니다.