Postgres 커넥션 풀러가 또 나왔다고? 'PgDog'이 진짜 노리는 지점

커넥션 풀러가 대체 뭐길래

웹 서비스를 만들다 보면 결국 데이터베이스, 그중에서도 Postgres(포스트그레스)를 많이 쓰게 되죠. 그런데 Postgres에는 은근히 골치 아픈 특성이 하나 있어요. 클라이언트가 접속(커넥션)할 때마다 운영체제 프로세스를 하나씩 새로 띄운다는 거예요. 이게 뭐가 문제냐면, 프로세스 하나가 메모리를 수 메가바이트씩 잡아먹거든요. 그래서 접속이 수천 개로 늘면 메모리가 폭발하고, 프로세스끼리 CPU를 번갈아 쓰느라 오히려 느려져요.

그래서 등장한 게 커넥션 풀러(connection pooler)예요. 이게 뭐냐면, 앱과 데이터베이스 사이에 끼어 앉아서 실제 DB 연결은 몇 개만 유지해두고, 수많은 앱의 요청을 이 몇 개의 연결에 돌려막기(재사용)해주는 중개자예요. 식당으로 치면, 손님(요청)이 아무리 많아도 주방으로 통하는 문(실제 연결)은 몇 개만 두고 웨이터가 효율적으로 오가게 하는 거죠. 이 분야의 오랜 강자가 PgBouncer예요.

그런데 왜 또 새로 만들었을까

PgBouncer는 훌륭하지만 오래된 만큼 한계가 있어요. 대표적으로 싱글 스레드로 동작해요. 코어가 아무리 많은 서버에 올려도 CPU 하나만 쓴다는 뜻이라, 트래픽이 아주 커지면 이 자체가 병목이 돼요. 그래서 이미 PgCat 같은 Rust로 짠 멀티스레드 풀러가 나와 있었고요.

PgDog은 여기서 한 발 더 나가려고 해요. 단순히 ‘연결을 돌려막는’ 걸 넘어서, 샤딩(sharding)까지 품는 걸 목표로 하거든요. 샤딩이 뭐냐면, 데이터가 너무 많아 서버 하나에 다 못 담을 때 여러 대의 DB에 데이터를 조각내서 나눠 담는 기법이에요. 문제는 이렇게 나누면 “이 데이터는 어느 서버에 있지?”를 앱이 일일이 계산해야 해서 코드가 복잡해진다는 거예요. PgDog은 이 라우팅(어느 서버로 보낼지 정하는 것)을 프록시 단에서 대신 해주려 해요. 앱은 그냥 평범한 Postgres에 쿼리를 던지듯 하면, PgDog이 SQL을 들여다보고 알맞은 샤드로 보내주는 거죠.

여기에 Rust와 비동기 처리(Tokio) 기반이라 멀티코어를 제대로 활용하고, 여러 복제본(replica) 사이에 읽기 요청을 나눠주는 로드 밸런싱도 해줘요. 즉 ‘풀링 + 로드밸런싱 + 샤딩’을 한 덩어리로 묶은 차세대 프록시를 지향하는 거예요.

풀링 모드 이야기

커넥션 풀러를 이해하려면 풀링 모드도 알아둘 만해요. 세션 모드는 앱이 연결을 놓을 때까지 DB 연결을 통째로 물려주는 방식이라 안전하지만 효율이 낮아요. 반대로 트랜잭션 모드는 트랜잭션(하나의 묶음 작업) 단위로만 연결을 빌려주고 끝나면 바로 반납받아서, 훨씬 적은 연결로 많은 요청을 처리해요. 대부분의 고성능 세팅이 이 트랜잭션 모드를 써요. 다만 이 모드에선 특정 세션 기능이 안 먹는 등 제약이 있어서, 이걸 얼마나 매끄럽게 지원하느냐가 풀러의 실력이에요.

한국 개발자에게

트래픽이 큰 서비스를 운영하거나, Postgres 데이터가 단일 서버 한계에 부딪히기 시작한 팀이라면 관심 가질 만해요. 지금까지 한국에서 Postgres 샤딩은 앱 레벨에서 직접 구현하거나 Citus 같은 확장을 쓰는 게 보통이었는데, 프록시가 이걸 투명하게 해준다면 앱 코드를 훨씬 단순하게 유지할 수 있거든요. 물론 아직 성숙도는 PgBouncer만 못 하니, 당장 프로덕션에 넣기보다 테스트 환경에서 검증해보는 게 순서예요.

정리하며

“풀링은 기본이고, 이제 샤딩까지 프록시가 알아서 해주는 시대로 가고 있다”는 흐름을 보여주는 프로젝트예요. 여러분의 서비스는 커넥션 풀러를 제대로 쓰고 있나요, 아니면 아직 앱에서 DB에 직접 연결하고 있나요?