앱 연결과 연결 풀

결론부터

앱 인스턴스별 연결 수를 합산하고, 연결을 빌려 쓰는 범위가 앱의 상태 사용과 맞는지 확인한다.

앱 하나에서 풀 크기 10은 작아 보여도 앱 인스턴스가 20개면 최대 200개다. 배치·마이그레이션·관리 도구의 연결도 같은 서버 예산을 사용한다.

이 장에서 처음 나오는 말3개

연결 풀Connection pool

미리 만든 DB 연결을 여러 요청이 재사용하도록 관리한다.

세션Session

클라이언트가 DB에 연결한 동안 유지하는 상태의 범위.

TLSTransport Layer Security

통신 암호화와 서버 신원 검증에 쓰는 프로토콜.

연결 문자열을 나누어 읽기

다음은 값을 치환해야 하는 형태 예시다. 호스트·DB·role·인증서 경로는 실제 환경에서 확인한다. 비밀번호는 코드나 문서의 URI에 넣지 않고 비밀 관리 수단으로 주입한다.

host=db.example.internal port=5432 dbname=appdb user=app_runtime sslmode=verify-full sslrootcert=/path/to/ca.crt

verify-full은 신뢰하는 CA와 호스트 이름을 확인한다. 암호화 연결만 성립하는 것과 올바른 서버에 연결했다는 검증을 구분한다. 사용 드라이버마다 TLS 옵션 표현이 다르다. (libpq 연결 옵션, SSL 검증)

풀 크기를 더하기

예를 들어 앱 Pod 6개가 각각 최대 10개, 배치가 10개, 관리용 여유가 10개라면 최소 80개의 예산을 고려한다. 롤링 배포로 Pod가 일시적으로 늘어나는 경우도 포함한다. 이 숫자는 계산 예시이지 권장값이 아니다. 쿼리 한 개가 쓰는 메모리와 동시 작업량을 함께 봐야 한다.

로컬 예제에서는 다음으로 설정과 현재 연결을 확인한다.

SHOW max_connections;
SELECT datname, state, count(*)
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY datname, state
ORDER BY datname, state;

max_connections 전체를 앱에 배정하지 않는다. 예약 연결과 관리 여유가 있고, 연결 수를 늘리는 것이 CPU·I/O 처리량 증가를 뜻하지도 않는다. (연결 설정)

풀링 모드가 바꾸는 것

모드	서버 연결을 돌려주는 시점	앱에서 확인할 점
Session	클라이언트 세션 종료	연결을 오래 붙잡는 클라이언트가 많으면 공유 효과 제한
Transaction	트랜잭션 종료	다음 트랜잭션이 같은 서버 연결을 쓴다고 가정할 수 없음

트랜잭션 풀링에서는 임시 테이블이나 세션 SET, 세션 잠금이 다음 요청에도 남아 있다는 가정이 깨질 수 있다. 트랜잭션 안의 SET LOCAL처럼 범위가 일치하는 방식을 검토한다. prepared statement 지원도 풀러 버전·설정·프로토콜에 따라 확인해야 한다. (PgBouncer 기능 호환 표)

CNPG·Supabase에서의 연결

CNPG는 PgBouncer를 Pooler 리소스로 관리할 수 있다. 읽기·쓰기 역할과 풀링 모드를 명시하며, 앱 내부 풀과 외부 풀러가 함께 있으면 각 단계의 대기와 시간 제한을 구분한다. (CNPG 연결 풀링)

Supabase는 직접 연결과 풀러 연결을 제공한다. 장기 서버·서버리스 실행·마이그레이션 도구가 어떤 연결을 지원하는지 확인한 뒤 고른다. 모든 작업에 하나의 URI를 복사하지 않는다. (Supabase 연결 안내)

이해 확인: 앱의 연결 획득 대기가 길면 max_connections부터 늘릴까? 긴 쿼리·미종료 트랜잭션·작은 풀·DB 자원 포화를 먼저 구분한다. 각각 해결할 위치가 다르다.