핵심 메시지

여러 인스턴스가 하나의 DB를 볼 때, 풀의 위치가 곧 커넥션 공유 범위가 됩니다

앱 수가 늘어날수록 중요한 질문은 같습니다. DB의 max_connections 예산을 어디에서 모아 제어할 것인가를 구조로 먼저 정해야 합니다.

공통 목표

DB 연결 총량은 안정적으로 묶고, 앱 확장은 더 쉽게 만들기

단순한 시작점, 중앙 제어, K8s 친화성 중 무엇을 우선할지에 따라 배치가 달라집니다.

방법 1

앱 내장 풀

앱 A
HikariCP
앱 B
HikariCP
→
DB
공유 범위
앱 서버마다 풀이 따로 있어서 확장할수록 풀 수가 같이 늘어납니다.
운영 포인트
구성은 가장 단순하지만, DB가 보는 총 커넥션 수는 앱 전체를 합산해서 따로 계산해야 합니다.
방법 2

외부 프록시 풀

앱 서버들
→
pgBouncer
→
DB
공유 범위
프록시 계층이 여러 앱의 연결을 한곳에 모아 DB 앞단에서 재사용합니다.
운영 포인트
DB 커넥션 예산을 중앙에서 조절하기 좋지만, 프록시 자체의 가용성과 설정을 함께 운영해야 합니다.
방법 3

사이드카 프록시

Pod A 앱
Cloud SQL Proxy
Pod B 앱
Cloud SQL Proxy
→
DB
공유 범위
풀은 Pod 옆 프록시에 붙고, 각 앱은 로컬 프록시를 통해 인증과 TLS 연결을 위임합니다.
운영 포인트
Kubernetes에는 잘 맞지만, DB 총량 제어는 여전히 전체 Pod 수와 프록시 설정을 함께 봐야 합니다.
결정 기준

적은 수의 앱이면 내장 풀이 가장 단순하고, 여러 앱이 하나의 DB 예산을 함께 써야 하면 외부 프록시가 유리합니다. 클라우드 DB의 인증·보안 연결을 표준화해야 하면 사이드카 프록시가 적합합니다.