!원문 캡처 · stackgres.io

StackGres 1.19은 Citus 클러스터에 쿼리 라우터(Query Router)를 추가해 조정 노드의 쿼리 처리 부담을 여러 노드로 분산하는 기능을 도입했다. StackGres 제작사 OnGres는 이 기능으로 단일 조정 노드가 병목이 되는 문제를 줄일 수 있다고 설명한다.

Citus의 일반적인 구성에서는 클라이언트 쿼리가 조정 노드 한 곳으로 들어간다. 조정 노드는 쿼리를 분석하고 계획한 뒤, 필요한 샤드가 있는 작업자 노드에 쿼리를 전달하고 결과를 모은다. 작업자 노드를 늘려 데이터와 저장 작업을 분산해도 쿼리 진입점은 하나여서, 조정 노드의 CPU가 병목이 될 수 있다.

Citus 11부터 작업자 노드에 직접 접속해 분산 쿼리를 실행할 수 있지만, OnGres는 작업자 노드가 쿼리 라우팅과 데이터 처리 역할을 함께 맡으면 자원 경쟁이 생길 수 있다고 지적한다. 쿼리 라우터는 샤드 데이터를 저장하지 않고 Citus 메타데이터를 보유해 쿼리를 계획하고 작업자 노드로 전달하는 별도 진입점이다.

StackGres에서 사용하는 방법

StackGres는 쿼리 라우터를 선언적으로 만들고 Citus 토폴로지에 등록한다. 라우터는 조정 노드의 설정을 기본적으로 상속하며, 각 라우터는 단일 인스턴스다. Kubernetes Service를 통해 클라이언트 연결을 라우터들에 분산할 수 있다. 여러 라우터를 두면 라우터 계층의 고가용성을 확보할 수 있다고 OnGres는 설명한다.

라우터는 샤드가 없는 메타데이터 노드로 등록된다. 조정 노드는 라우터의 Patroni가 시작되기 전에 해당 노드를 shouldhaveshards = false로 등록해 샤드가 배치되지 않도록 한다. 라우터가 연결 가능해지면 조정 노드가 citus_activate_node()로 활성화한다. 조정 노드는 계속 필요하며, 분산 테이블 생성 등 DDL과 메타데이터 변경 작업을 맡는다.

라우터는 참조 테이블도 보유할 수 있다. 기존 참조 테이블을 나중에 추가한 라우터로 복제하려면 spec.configurations.citus.autoReplicateReferenceTables: true를 설정할 수 있다. StackGres는 이 옵션이 기본값으로 꺼져 있다고 밝힌다. 복제 중에는 block_writes 방식으로 참조 테이블 쓰기가 차단되므로, 쓰기 트래픽에 영향을 줄 수 있고 큰 참조 테이블은 피하는 것이 좋다고 안내한다.

쿼리 라우터 수는 SGShardedCluster의 queryRouterClusters 속성으로 지정한다. 조정 노드 설정을 그대로 상속하는 대신 라우터의 설정, 인스턴스 프로필, 초기화 스크립트를 재정의할 수도 있다. 자세한 내용은 쿼리 라우터 문서, SGShardedCluster 재정의 문서에서 확인할 수 있다.

벤치마크 결과와 조건

OnGres는 StackGres 1.19.3, PostgreSQL 18.4, Citus 14.1.0을 사용해 pgbench 기반 벤치마크를 실행했다. 작업자 노드는 각각 64 vCPU와 512GiB 메모리를 갖췄고, 조정 노드와 쿼리 라우터도 각각 64 vCPU 구성이었다. 벤치마크의 쿼리는 준비된 문장을 사용한 단일 행 기본 키 조회였다. 연결 풀링은 비활성화했다.

OnGres의 측정에서 단일 조정 노드는 연결 400개일 때 초당 약 55만 트랜잭션에서 성능이 정체됐다. 쿼리 라우터 3개를 사용한 경우에는 초당 143만 트랜잭션을 기록했으며, p50 지연 시간은 1ms, p99은 4ms였다. 이 수치는 해당 벤치마크 구성에서 얻은 결과이며, 다른 워크로드에서도 같은 성능이 나온다는 뜻은 아니다.

StackGres 제작사는 쿼리 라우터가 Citus 자체의 패치나 포크가 아니라 StackGres가 제공하는 아키텍처 패턴이라고 설명한다. Citus와 StackGres의 기능 및 적용 조건은 Citus 통합 문서, StackGres 1.19.3 릴리스 노트, StackGres 빠른 시작 문서에서 확인할 수 있다.