Query Proxy
서비스가 다양한 분석 백엔드에 통일된 인터페이스로 접근하도록 중재하는 프록시 아키텍처
핵심 개념
Query Proxy(또는 Query Builder)는 온라인 서비스와 AI 에이전트가 Snowflake, StarRocks, ClickHouse, Iceberg 등 다수의 분석 백엔드에 접근할 때 발생하는 라이브러리·인증·프로토콜 파편화를 해결하는 중간 계층이다. 서비스 팀은 단일 gRPC 엔드포인트만 사용하면 되고, 플랫폼 팀은 쿼리 패턴을 관찰·최적화할 수 있는 통제 지점을 확보한다.
주요 기능
통일 인터페이스
- gRPC + 서비스 간 인증으로 기존 TP 데이터베이스 접근과 유사한 경험 제공
- Arrow/Parquet 기반 강타입 스키마 와이어 프로토콜로 대용량 결과 효율 전송
- 결과를 30MB 단위 Parquet 파일(ZSTD 압축)로 분할, 동시 다운로드로 처리량 극대화
가드레일과 쿼리 최적화
- 서비스 자격증명별 Rate Limit + 쿼리 셰이프별 Quota (실행 시간, 스캔 바이트 기반)
- AI Agent가 Proxy 로그를 분석하여 파생 테이블(derived table) 자동 생성 제안
- 향후 Materialized View + 쿼리 리라이트 기능으로 BI 도구 의존 감소
데이터 페더레이션
- Hot(Postgres/StarRocks) + Warm(Iceberg/Delta) 데이터를 시간 기준 분할로 단일 쿼리에서 결합
- 클라이언트가 보조 쿼리와 시간 분할 파라미터를 gRPC 호출에 포함
- 완전한 페더레이션 최적화는 어렵지만, Hot/Warm 분리는 실용적이고 즉시 적용 가능
내장 쿼리 엔진 (미래)
- DuckDB/DataFusion을 Proxy 내부에 통합하여 캐시된 Parquet 위에서 쿼리 리라이트·페더레이션 강화
- 서비스·에이전트 쿼리를 Proxy로 집중시키면 캐싱과 파생 테이블 최적화 효과 극대화
Trino Gateway와의 비교
| 측면 | Query Proxy | Trino Gateway |
|---|---|---|
| 대상 | 서비스·에이전트의 분석 백엔드 접근 | 분석가·ETL의 Trino 클러스터 접근 |
| 프로토콜 | gRPC + Parquet | HTTP/JDBC |
| 페더레이션 | Hot/Warm 이종 DB 조합 | 동종 Trino 클러스터 간 라우팅 |
| 캐싱 | Parquet 결과 캐시 | 없음 (엔진 의존) |
연관 개념
- Query Optimization — 쿼리 가드레일과 리라이트
- Distributed SQL Engine Operations — Trino Gateway와 보완적 관계
- DuckDB — Proxy 내장 쿼리 엔진 후보
- Data Pipeline Fundamentals — Reverse ETL 인터페이스로서의 활용