Quack: DuckDB에 클라이언트-서버 아키텍처 도입하기

수년 동안 DuckDB는 인프로세스(in-process) 아키텍처를 옹호해 왔습니다. 클라이언트-서버의 구분을 없앰으로써, 데이터 과학자와 개발자에게 애플리케이션이나 노트북 내에서 직접 실행되는 저지연, 고성능 도구를 제공했습니다. 그러나 이러한 설계는 근본적인 한계점을 만들어냈습니다. 바로 여러 프로세스에서 동시에 단일 데이터베이스 파일을 수정하기 어렵다는 점입니다.

이를 해결하기 위해 DuckDB 팀은 전용 클라이언트-서버 프로토콜인 Quack을 도입했습니다. Quack은 DuckDB 인스턴스들이 서로 통신할 수 있게 하여, DuckDB를 엄격한 로컬 도구에서 중앙 집중식 상태와 동시 원격 액세스를 지원할 수 있는 다재다능한 시스템으로 변모시킵니다.

원격 프로토콜의 필요성

인프로세스 시스템은 대화형 분석에는 뛰어나지만, 여러 프로세스가 동일한 데이터셋에 기록해야 하는 텔레메트리 수집이나 대시보드 구축에는 어려움을 겪습니다. 이전에는 사용자들이 커스텀 RPC 레이어, Arrow Flight SQL 프로토콜, 또는 DuckDB를 PostgreSQL 내에 래핑하는 방식(이른바 "EleDucken" 방식)과 같은 우회 방법을 사용해 왔지만, 네이티브 솔루션에 대한 요구는 부정할 수 없는 것이었습니다.

Quack은 사용자가 DuckDB에서 기대하는 단순함과 속도를 유지하면서 서버 관리형 가변 상태(mutable state)의 이점을 제공하도록 설계된 "범용 데이터 랭글링 도구"입니다.

Quack의 작동 방식

Quack은 어떤 DuckDB 인스턴스든 클라이언트 또는 서버로 작동할 수 있게 합니다. 설정은 DuckDB extension을 통해 처리되며, 사용자는 간단한 SQL 명령어를 사용하여 데이터베이스를 서빙하고 원격으로 연결할 수 있습니다.

핵심 기술 설계

HTTP 기반: Quack은 HTTP를 기반으로 구축되어 기존 로드 밸런서, 방화벽 및 인증 시스템과의 호환성을 보장합니다. 이 선택은 또한 DuckDB-Wasm이 Quack을 네이티브하게 지원하도록 하여, 브라우저 기반 인스턴스가 원격 서버에 직접 연결할 수 있도록 합니다.
요청-응답 패턴: 프로토콜은 클라이언트 주도형 요청-응답 모델을 따릅니다. 이는 저지연을 위해 최적화되어 있어, 단 한 번의 왕복(round trip)으로 쿼리를 완료할 수 있습니다.
커스텀 직렬화: 외부 교환 형식을 사용하는 대신, Quack은 새로운 MIME type인 application/duckdb를 사용합니다. 이는 DuckDB의 내부 직렬화 프리미티브(Write-Ahead Log에서 사용되는 것과 동일한 것)를 활용하여, 팀이 외부 형식에 구애받지 않고 데이터 타입을 혁신할 수 있게 합니다.
보안: 기본적으로 Quack은 시작 시 무작위 인증 토큰을 생성하고 localhost에 바인딩됩니다. 프로덕션 환경에서는 SSL 종료를 처리하기 위해 Nginx와 같은 리버스 프록시를 사용하는 것을 권장합니다.

확장 가능한 인증 및 권한 부여

경직된 권한 시스템을 구축하는 대신, Quack은 콜백 기반 모델을 사용합니다. 인증(사용자가 누구인지 확인)과 권한 부여(사용자가 무엇을 할 수 있는지 결정) 모두 사용자가 제공한 코드나 일반 SQL 매크로로 재정의할 수 있어, LDAP 또는 커스텀 텍스트 파일 기반 인증과 통합할 수 있습니다.

성능 벤치마크

프로토콜을 검증하기 위해, 팀은 AWS m8g.2xlarge 인스턴스에서 PostgreSQL 및 Arrow Flight SQL을 대상으로 Quack을 테스트했습니다.

대량 데이터 전송

Quack은 대량의 데이터를 이동할 때 상당한 큰 이점을 보여줍니다. TPC-H lineitem 테이블을 전송하는 테스트에서, Quack은 6,000만 개의 행(CSV 형식으로 76 GB)을 단 4.94초 만에 이동했으며, 이는 Arrow Flight(17.40초)와 PostgreSQL(158.37초)을 크게 능가하는 성능을 있습니다.

작은 쓰기 처리량

여러 스레드에 걸친 작은, 무작위 INSERT 트랜잭션 테스트에서, Quack은 낮은 동시성 시나리오에서 놀랍게도 PostgreSQL을 능가했으며, 8개 스레드에서 약 **5,500 TPS(transactions per second)**에 도달했습니다. PostgreSQL이 8개 이상의 스레드에서 더 잘 확장되지만, Quack은 관측성 및 텔레메트리 데이터를 중앙 집중화하는 데 매우 효율적인 경로를를 제공합니다.

왜 Arrow Flight SQL이 아닌가?

Arrow Flight SQL 프로토콜이 존재함에도 불구하고, 커스텀 프로토콜을 구축하기로 한 결정은 의도적이었습니다. 팀은 두 가지 주요 이유를를 들어

혁신에 대한 제어권: 외부 교환 형식을 사용하면 DuckDB의 새로운 데이터 타입을 빠르게 추가하거나 프로토콜 메시지를 추가하는 데 제한이 생깁니다.

1. 왕복 효율성: Arrow Flight SQL은 모든 쿼리에 대해 최소 두 번의 왕복(CommandStatementQuery 및 DoGet)이 필요합니다. Quack는 단일 왕복 실행을 위해 설계되었으며, 이는 지연 시간에 민감한 작은 업데이트에 매우 중요합니다.

앞으로의 행보

Quack은 현재 core_nightly repository에 사용 가능하며, 2026년 가을 DuckDB v2.0과 함께 프로덕션 릴리스가 예정되어 있습니다. 향후 개발 계획은 다음과 같습니다:

DuckLake Integration: 원격 DuckDB 서버를 DuckLake catalog로 사용하여 성능과 데이터 인라이닝을 개선합니다.
Scaling Concurrency: 8개 이상의 병렬 삽입 스레드를 지원할 수 있도록 핵심 엔진을 개선합니다.
Replication: Quack을 기반으로 복제 프로토콜을 개발하여 읽기 복제본 클러스터를 구축합니다.

인프로세스 효율성과 클라이언트-서버 유연성 사이의 간극을를 좁힘으로써, Quack은 DuckDB를 단순한 로컬 분석용 틈새 도구에서 현대적 데이터 아키텍처의 핵심 구성 요소로 자리매김하게 합니다.