FerroDruid
Rust-native Apache-Druid-compatible OLAP
Rust-native, Apache-Druid-spec-compatible real-time OLAP database입니다. Druid REST API, native query JSON, Druid SQL을 지원하고 Druid segment v9/v10 binary를 읽고 씁니다 — JVM 없이, ZooKeeper 없이, 6-process control plane 없이. single binary는 200 MB 미만 RAM에서 1초 이내에 부팅됩니다.
전통적인 Apache Druid cluster는 단일 query를 제공하기 전에도 6개 이상의 JVM process, ZooKeeper, external metadata database, 16 GB+ RAM이 필요합니다. FerroDruid의 single-binary mode는 이 모두를 self-contained AMI로 제공되는 하나의 process로 대체합니다. v0.2.0은 8가지 native query type(timeseries, topN, groupBy, scan, search, segmentMetadata, dataSourceMetadata, timeBoundary)을 모두 제공하고, Druid SQL(SELECT, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, 30+ functions, EXPLAIN PLAN FOR, MSQ task endpoint, ~95% core SQL parity)을 실행하며, 40+ Druid-compatible REST endpoint를 노출하고, Druid segment v9/v10을 읽고 쓰며, Kafka 및 Kinesis supervisor와 native batch에서 ingest합니다. Basic auth(Argon2id) + RBAC가 기본 ON이고, TLS는 rustls를 사용하며, 첫 부팅 시 고유한 random admin password를 생성합니다.
해결하고자 하는 과제
Apache Druid는 강력한 실시간 OLAP 엔진이지만, 기존 클러스터는 단 하나의 쿼리를 처리하기 전에도 6개 이상의 JVM 프로세스, ZooKeeper, 외부 메타데이터 데이터베이스, 그리고 16GB 이상의 RAM을 필요로 합니다. 이러한 6개 프로세스 제어 평면을 구축, 운영 및 모니터링하는 부담은 매우 크며, 평가 환경이나 소규모 배포에는 과도할 수 있습니다. Druid의 API와 세그먼트 형식을 사용하고 싶지만, JVM 및 ZooKeeper 제품군을 운영하는 부담은 피하고 싶은 것이 과제입니다.
작동 원리
- 1
단일 바이너리로 부팅
single-binary 모드는 JVM, ZooKeeper, 외부 메타데이터 데이터베이스 없이 단일 프로세스로 실행되며, 1초 미만으로 부팅되고 200MB 미만의 RAM을 사용합니다. 메타데이터에는 SQLite를 사용하고 딥 스토리지에는 로컬 파일시스템을 사용하며, 자체 포함된 AMI 형태로 제공됩니다.
- 2
Druid 와이어 프로토콜 지원
Druid REST API, 네이티브 쿼리 JSON 및 Druid SQL을 지원하고 Druid 세그먼트 v9/v10 바이너리 파일을 읽고 씁니다. 8가지 네이티브 쿼리 형식을 모두 제공하며 40개 이상의 Druid 호환 REST 엔드포인트를 노출하므로, 기존 Druid 클라이언트나 Apache Superset 커넥터를 바로 연결할 수 있습니다.
- 3
잠긴 상태로 시작, 첫 로그인 시 비밀번호 변경
기본 인증(Argon2id) 및 RBAC가 기본으로 활성화되며, rustls를 통한 TLS가 제공됩니다. 첫 부팅 시 해당 인스턴스에 고유한 새로운 임의의 admin 비밀번호를 생성하고(기본 비밀번호나 공유 비밀번호는 사용하지 않음) 인스턴스 시스템 로그에 한 번 기록합니다. admin 계정은 변경 필수(must-change)로 표시되므로 운영자가 새 비밀번호를 POST할 때까지 모든 API 엔드포인트가 HTTP 403을 반환하여 첫 로그인 시 비밀번호 변경을 강제합니다.
주요 특징
Druid-spec wire-compatible(REST + native JSON + Druid SQL, segment v9/v10) — 기존 Druid client 및 query가 동작합니다.
하나의 binary, JVM / ZooKeeper / six-process control plane 없음; 200 MB 미만 RAM에서 sub-second boot.
8 native query types + Druid SQL(~95% core parity) + Kafka / Kinesis ingest; auth + RBAC 기본 ON.
포함 사항
- 자체 포함된 Amazon Linux 2023 AMI (Graviton / arm64, t4g, c7g, m7g, r7g 클래스 인스턴스 지원)
- single-binary 모드 — JVM, ZooKeeper, 외부 메타데이터 데이터베이스 없이 단일 프로세스로 실행되며, 1초 미만으로 부팅되고 200MB 미만의 RAM을 사용 (SQLite 메타데이터 및 로컬 파일시스템 딥 스토리지)
- 8가지 Druid 네이티브 쿼리 형식 전체(timeseries, topN, groupBy, scan, search, segmentMetadata, dataSourceMetadata, timeBoundary) 및 40개 이상의 Druid 호환 REST 엔드포인트
- Druid SQL (SELECT / WHERE / GROUP BY / HAVING / ORDER BY / LIMIT, 30개 이상의 함수, EXPLAIN PLAN FOR, MSQ 태스크 엔드포인트, 핵심 SQL과 약 95% 일치)
- Druid 세그먼트 v9/v10 바이너리 파일 읽기 및 쓰기 지원, Kafka 및 Kinesis 감독자(supervisor) 및 네이티브 배치를 통한 수집
- 기본적으로 활성화되는 보안 — 기본 인증(Argon2id) 및 RBAC, rustls를 통한 TLS, 첫 부팅 시 인스턴스별로 생성되며 첫 로그인 시 변경해야 하는 임의의 admin 비밀번호
- ALB 배후 배포용 CloudFormation 템플릿 (marketplace/cloudformation/ami.yaml), 지원되는 토폴로지인 single-binary single-node 구성 (멀티 노드는 기본적으로 fail-closed 동작)
주요 활용 사례
6개 프로세스의 JVM 및 ZooKeeper 클러스터를 운영하지 않고 Druid 호환 실시간 OLAP를 구동하려는 팀
Druid REST API, 네이티브 쿼리 JSON, Druid SQL 또는 Apache Superset 커넥터를 사용하는 기존 클라이언트를 위한 백엔드
1초 미만으로 부팅되고 200MB 미만으로 실행되는 경량 바이너리를 사용한 Druid 기능 평가 및 개발 환경
Kafka 및 Kinesis 감독자 또는 네이티브 배치를 통해 수집하는 스트리밍 및 시계열 분석용 단일 노드 구성
자주 묻는 질문
실제 Apache Druid와 얼마나 호환되나요?
FerroDruid는 Druid REST API, 네이티브 쿼리 JSON 및 Druid SQL을 지원하며, 세그먼트 v9/v10을 읽고 씁니다. 8가지 네이티브 쿼리 형식을 모두 포함하며 40개 이상의 Druid 호환 REST 엔드포인트를 제공하고, 핵심 Druid SQL 호환성은 약 95%(100% 아님)입니다. 라이브 와이어 deep-match는 Apache Druid 30.0.1에 대해 5/5, Apache Superset 커넥터와도 5/5 일치했습니다. 솔직한 구현 범위 안내: 라이브 검증은 Druid 30.0.1 및 single-binary 모드를 기준으로 수행되었으며, Druid 31부터 36까지는 실행 중인 클러스터에 대해 아직 상호 검증되지 않은 사양 기준 설계 목표입니다.
JVM, ZooKeeper 또는 외부 메타데이터 데이터베이스가 필요한가요?
single-binary 모드에서는 전혀 필요하지 않습니다. 단일 프로세스가 1초 미만으로 부팅되고 200MB 미만의 RAM을 사용합니다. 이는 6개 이상의 JVM 프로세스, ZooKeeper, 외부 메타데이터 데이터베이스 및 16GB 이상의 RAM을 필요로 하는 기존 Druid 클러스터와 대조적입니다. 지원되는 single-binary 경로는 메타데이터로 SQLite를 사용하고 딥 스토리지로 로컬 파일시스템을 사용합니다.
멀티 노드 구성을 실행할 수 있나요?
지원되는 토폴로지는 single-binary single-node이며, 멀티 노드 구성은 기본적으로 fail-closed 동작합니다. 솔직히 말씀드리면, 라이브 검증은 single-binary 모드를 기준으로 수행되었으며, 현재로서는 실행 중인 멀티 노드 클러스터로 검증되지 않았습니다. 자세한 내용은 docs/KNOWN_LIMITATIONS.md를 참고하시기 바랍니다.
보안은 어떻게 처리되며, 첫 로그인 절차는 어떻게 되나요?
기본 인증(Argon2id) 및 RBAC가 기본으로 활성화되며, rustls를 통한 TLS가 제공됩니다. 첫 부팅 시 AMI는 해당 인스턴스에 고유한 새로운 임의의 admin 비밀번호를 생성하고(기본 비밀번호나 공유 비밀번호는 절대 사용하지 않음) 인스턴스 시스템 로그에 한 번 기록합니다. admin 계정은 변경 필수(must-change)로 표시되므로 운영자가 /druid-ext/basic-security/authentication/db/basic/users/admin/credential 경로로 새 비밀번호를 POST할 때까지 모든 API 엔드포인트가 HTTP 403을 반환합니다. 순환(rotated)된 자격 증명은 영구 저장되어 재부팅 후에도 유지됩니다.
어떻게 배포하며 라이선스 및 비용 청구는 어떻게 진행되나요?
제공된 CloudFormation 템플릿(marketplace/cloudformation/ami.yaml)을 사용해 Application Load Balancer 배후에 배포하십시오. TLS는 ALB에서 종료하며 service 포트를 인터넷에 직접 노출하지 마십시오. 클라이언트(REST API, 네이티브 쿼리 JSON, Druid SQL 또는 Apache Superset 커넥터)가 로드 밸런서 엔드포인트를 가리키도록 설정합니다. 본 리스팅은 고정된 릴리스 버전의 Apache-2.0 소스에서 빌드된 하드닝되고 검사되었으며 지원이 포함된 배포판을 판매하며, 코드 자체는 Apache-2.0으로 유지됩니다. AMI는 실행 중인 인스턴스 시간당 AWS에 의해 자동으로 미터링되며, 제품 내에 별도의 미터링 코드는 포함되어 있지 않습니다.
요금제 모델
시간당 software fee + EC2(t4g / c7g / m7g / r7g class, Arm). instance type별 metered 과금.
