▲

PgDog - 별도 확장없이 Postgres를 샤딩할수 있는 도구

 (github.com/pgdogdev)
4P by GN⁺ 7일전 | ★ favorite | 댓글 1개
  • Rust로 개발된 PostgreSQL용 트랜잭션 풀러 및 논리 복제 관리자로, 수평적 확장과 샤딩 자동화 기능 제공
  • 익스텐션 없이 간편하게 PostgreSQL 데이터베이스를 샤딩 가능, 수백 개 데이터베이스와 수십만 연결 관리에 최적화됨
  • 애플리케이션 계층(OSI 7)에서 동작하는 DB 로드 밸런서로, SELECT는 리플리카로, 나머지는 프라이머리로 자동 라우팅 가능
  • PgBouncer처럼 트랜잭션/세션 풀링을 지원하면서도, 쿼리를 파싱하여 샤드로 자동 라우팅 및 결과 병합까지 수행
  • COPY 및 로지컬 리플리케이션을 이용해 데이터를 샤드로 자동 분배하거나 기존 DB를 무중단 샤딩할 수 있음
  • 구성은 TOML 파일로 간단하게 정의할 수 있으며, 런타임 재구성 가능
  • Postgres 확장을 이용하는 Citus와 달리 DB의 외부 프록시여서 RDS, Cloud SQL 등에서도 사용 가능

프로젝트 소개 및 주요 가치

  • PgDog는 PostgreSQL 데이터베이스를 쉬운 샤딩과 논리 복제, 트랜잭션 풀링, L7 부하 분산 등 전방위적인 수평확장을 지원하는 오픈소스 솔루션임
  • Rust 언어로 개발되어 고성능 및 보안성을 확보함
  • PgDog는 익스텐션 설치 없이, 단일 프록시 배포만으로도 샤딩, 데이터 분산, 장애 복구, 및 유연한 로드밸런싱을 실현함
  • 경쟁 제품(예: PgBouncer, PgCat 등)과 달리, 자동 샤딩 및 논리 복제까지 모두 지원하며, 운영 중 설정 변경 및 실시간 모니터링이 가능한 점이 강점임

주요 기능

부하 분산 (Load Balancer)

  • PgDog는 OSI 7계층 애플리케이션 레벨 프록시로, 여러 PostgreSQL 복제본·기본 노드로 쿼리를 분산하여 장애·부하 방지 역할 수행
  • 분산 전략은 라운드로빈, 무작위, 최소 연결 등 다양하게 제공
  • 쿼리 종류를 판별하여 SELECT는 복제본, 그외 쓰기 쿼리는 기본 노드로 자동 전달하게 분기 처리
  • 건강 체크(Healthcheck) 및 장애 발생 시 자동 페일오버 수행, 네트워크 오류나 하드웨어 장애에도 가용성 보장

트랜잭션 풀링

  • PgDog는 PgBouncer 처럼 트랜잭션·세션 풀링을 통한 효율적인 커넥션 자원 관리로, 수십만 개의 클라이언트도 소수의 백엔드 연결로 커버 가능함

샤딩

  • 쿼리 구문을 직접 파싱하여 샤딩 키 추출 및 최적 라우팅 알고리듬 적용
  • 다중 샤드 데이터베이스 간 교차 샤드 쿼리도 지원하며, 결과를 메모리상에서 통합 후 투명하게 클라이언트로 전달
  • COPY 명령 실행 시 CSV 파싱을 통한 데이터 멀티샤드 분배 지원, 대용량 적재에 편리
  • PostgreSQL 논리 복제 프로토콜을 기반으로 무중단 백그라운드 동기화, 운영 중 실시간 샤드 추가 및 확장 가능

모니터링

  • PgBouncer 스타일의 관리 데이터베이스와 OpenMetrics 엔드포인트 모두 지원
  • Datadog 등 외부 모니터링 및 대시보드 예제 제공

구성 및 런타임

  • 주요 환경: Kubernetes(Helm 차트 제공), Docker, 로컬 환경(Rust 빌드)에서 손쉽게 배포·테스트 가능
  • 통상적으로 2개의 설정 파일(pgdog.toml, users.toml)만 작성하면 최소 샤딩 및 유저 기반 운영 환경 구성 완료
  • 설정 값은 대부분 실시간으로 수정 가능하며, 프로세스 재시작 없이 동적으로 반영

성능 및 라이선스

  • PgDog는 Rust와 Tokio 기반의 고성능 비동기 네트워크 프록시로, 데이터 이동 최소화 및 성능 저하 억제에 집중
  • 벤치마크 결과를 공식 문서에 제공하여 성능 기준 설정 가능
  • AGPL v3 오픈소스 라이선스 적용, 기업 내부 사용 및 사설 커스터마이징에 완전 개방
  • 단, 퍼블릭 클라우드 서비스 제공 기업은 코드 수정 시 그 내역을 공유해야 하는 조건 존재

프로젝트 현황 및 기여

  • 현재는 초기 단계로 얼리어답터의 자체 도입을 권고, 기능별 안정화는 꾸준히 업데이트
  • 기능별 테스트 및 벤치마크도 지속적으로 진행
  • 오픈소스 커뮤니티의 기여 환영, 자세한 내용은 Contribution Guidelines 참고

결론

  • PgDog는 운영 환경에서 PostgreSQL의 수평적 확장성, 고가용성, 자동 샤딩을 필요로 하는 개발팀 및 기업 현장에 뛰어난 솔루션 제공
  • 별도의 익스텐션이나 복잡한 인프라 구축 없이도, 신속히 적용 및 Customizing 가능한 점이 큰 장점임
▲
GN⁺ 7일전  [-]
Hacker News 의견

  • Lev에게 인사하면서 현재 40TB 규모의 Postgres 데이터베이스 샤딩을 위해 PgDog과 직접 구축을 비교 중인 상황 설명, Vitess for PostgreSQL처럼 동작하는 솔루션이 필요하다고 언급, scatter gather 기능 외에도 etcd 같은 것에 기반한 설정 관리, 샤드 분할, 전체 샤드에 스키마 변경을 적용하는 best-effort 트랜잭션 등이 필요하다고 강조, pg_query.rs로 쿼리 재작성 경험 질문, AST 타입의 불변성과 딥 클론 부족 때문에 재작성에 어려움 느낌 공유, 결국 Visitor 패턴을 지원하는 sqlparser crate 사용 중이라는 점과 shadow tables, 논리적 복제를 기반으로 PG용 온라인 스키마 변경을 사이드 프로젝트로 개발 중임을 이야기

    • 협업 제안에 기뻐하며 연락처 공유, 설정 관리는 이미 K8s나 다양한 CD 도구로 해결 가능하고 PgDog의 구성 리로드 동기화 가능함을 설명, best-effort 트랜잭션으로 전체 샤드 스키마 변경 이미 동작 중이고, 아이디엄포턴트한 스키마 변경이 제일 좋지만 실패 시 2단계 커밋도 검토 대상임을 언급, 샤드 분할은 논리적 복제로 가능함을 예로 들며 Instacart에서 10TB+ 경험 언급, 복제 슬롯 오픈 후 N 인스턴스로 복구, 샤드 넘버 일치하지 않는 데이터 삭제 및 논리적 복제를 통한 재동기화 절차 공유, Pg 17의 논리적 복제를 streaming replica에서 사용해서 병렬 분할 아이디어, 외래 테이블로 직접 데이터를 COPY하는 방법도 구상 중임을 밝힘, pg_query.rs가 이제는 가변적으로 동작하는 듯해 최근에는 실제로 쿼리 재작성 및 생성에 적극 활용 중이며, 100% Postgres 파서 기반이라는 점이 중요 장점임을 강조, "deparse" 기능이 곳곳에 있어서 복잡한 작업 가능성 높음

  • Vitess for Postgres가 있다면 Yugabyte가 그 역할을 하는 것 아니냐는 질문

  • 핵심 기능만 보면 작지만, PgDog을 통해 코드 배제하고 읽기는 리드 레플리카, 쓰기는 프라이머리로 분리하는 기능이 엄청난 이점이라고 생각, 많은 앱이 R/W 분리를 직접 지원하지 않기 때문에 프록시 레벨에서 처리하면 과거에 큰 속도 개선 경험함을 공유하며 프로젝트 칭찬

    • 이미 pgcat에서도 이 기능 사용 가능하다는 안내와 pgcat 링크 공유

    • Instacart에서 Makara를 이용해 R/W 분리 했었는데, 파이썬이나 Go 등 여러 언어 환경에서 매번 똑같이 구현하는 것이 꽤 번거로웠던 경험 공유

  • 프로젝트 인상 깊다는 평과 함께 완전 자동화된 샤딩에는 약간 거리감, 일반적으로 샤딩은 테넌시 경계에서 이뤄지고 이 경계를 넘는 행위에 마찰이 있기를 원함을 설명, 샤드 간 조인은 인-샤드 조인과 성능, 메모리, CPU 측면에서 다르기 때문에 이를 명확히 드러냈으면 좋겠다고 의견, 하지만 프로젝트 자체에는 의심이 없고 활용 사례가 매우 많을 거라 밝힘

    • 왜 일부러 마찰을 원하냐고 물으면서, 샤드 간 조인 성능 이슈는 대부분 잘 이해되고 실시간 메트릭으로 추적 가능하며, 결국 양쪽 방법이 필요하고 앱 코드에서 조인하는 대안은 그리 바람직하지 않다고 덧붙임

  • PgDog을 눈여겨보고 있는 중이며 매우 인상적이라고 평가, 출시 축하와 계속 발전 기대 표현

    • 15년의 여정이 이제 시작됐음을 밝힘

  • 네트워크 계층에서 투명성과 호환성을 유지하며 분산 쿼리를 처리하는 점이 핵심 매력이라는 의견, 현재 문서상의 제한은 당연하며 트레이드오프가 필요할 것으로 기대, 어떻게 해결할지 궁금하며 추가 논의가 있다면 함께하고 싶다고 제안

  • PgDog 같은 솔루션에서 최대 어려움은 샤딩된 복잡 쿼리를 마지막 1%까지 제대로 처리하거나(혹은 비정상 쿼리 검출), 격리성과 일관성을 완전히 보장하는 것이라고 언급

  • 문서를 보자마자 Unique Index 지원 여부를 가장 먼저 확인했으나, 아직은 쿼리 재작성과 별도 실행엔진이 필요해서 지원하지 않는 점이 아쉽다고 피드백, 그래도 가능성이 보여 기대함

    • 작은 보상으로 모든 샤드에서 유일한 프라이머리 키 생성은 이미 지원하며 관련 문서 링크 공유, 크로스샤드 유니크 인덱스 구현은 모든 쿼리에서 확인해야 하기에 비용이 비싸 아이디어를 오픈함

  • 수년 만에 본 가장 흥미로운 Postgres 프로젝트라 강조, 제공된 벤치마크는 기본 커넥션 풀링만 다루는 것 같아 쿼리 파싱이나 샤드 간 조인이 동작할 때 결과가 궁금하다고 의견

    • 쿼리 파서는 캐싱되어 준비 쿼리 또는 플레이스홀더 활용 시 락과 해시 조회만 추가되어 거의 비용이 없다고 설명, 샤드 간 조인의 경우 필터가 최적이 아닐 때 쿼리 처리 비용이 높아질 수 있고, 결과 집합이 클 때 디스크로 페이징 필요할 수도 있다고 예상, OLTP에 우선 집중해 최대한 조인을 푸쉬다운하려 하고, 곧 샤드 간 조인 수요도 커질 것으로 예측

  • Postgres 확장성에 꼭 필요한 혁신이라는 평가와 함께 출시 축하

  • 프로젝트가 굉장히 훌륭해 보이며 출시 축하

    • 수년 간의 노력이 들어간 결과임을 강조
답변달기