Apache Druid — 시계열 이벤트를 초 단위로 쿼리하는 컬럼 지향 분석 DB

광고 클릭이나 IoT 센서 값처럼 초 단위로 계속 쌓이는 이벤트 데이터에 대고 "지금 무슨 일이 일어나고 있는가"를 몇 초 안에 답해야 하는 상황에서는 일반적인 OLTP나 배치 위주의 OLAP 구조가 버거워진다. Apache Druid는 이 지점을 겨냥한 실시간 분석 데이터베이스다. 컬럼 기반 저장과 시간 기반 파티셔닝을 축으로 삼아, 실시간으로 들어오는 데이터와 이미 쌓인 과거 데이터를 같은 쿼리 인터페이스에서 빠르게 조회하게 만든다.

컬럼 단위로 저장한다는 것

전통적인 행 기반 저장소는 레코드 하나를 통째로 붙여 저장하지만, Druid는 컬럼 단위로 데이터를 쪼개 저장한다. 같은 타입의 값이 연속으로 놓이기 때문에 압축률이 올라가고, 쿼리가 특정 컬럼 몇 개만 참조할 때 나머지 컬럼은 아예 로드하지 않아도 되니 I/O와 메모리 사용량이 그만큼 줄어든다.

⤢✕

시간을 축으로 쪼갠 파티션과 세그먼트

Druid는 데이터를 시간 단위(시간·일·주 등)로 나눠 파티션으로 저장하고, 각 파티션 안에서는 다시 세그먼트 단위로 관리한다. 조회가 특정 시간대에 몰리는 시계열 워크로드의 특성상, 이렇게 쪼개두면 필요한 시간대의 세그먼트만 골라 읽으면 되므로 검색이 빨라진다.

⤢✕

세그먼트 크기는 보통 500MB~1GB 범위로 잡는 것이 권장된다. 너무 잘게 쪼개면 메타데이터 관리 부담이 커지고, 너무 크게 잡으면 필요 없는 데이터까지 함께 읽게 된다.

실시간과 배치를 한 파이프라인에서

Druid의 수집 모델은 스트리밍 데이터를 초 단위로 인덱싱하는 실시간 수집과, 대용량 히스토리 데이터를 일괄 처리하는 배치 수집을 하나의 시스템 안에서 함께 굴린다. Kafka, Kinesis 같은 스트림 소스는 Indexing Service로, HDFS·S3·로컬 파일 같은 배치 소스는 Hadoop 기반 인덱싱으로 들어와서 결국 같은 Deep Storage에 쌓인다.

⤢✕

역할을 나눠 맡는 노드 구조

Druid 클러스터는 역할이 분리된 여섯 종류의 노드로 구성된다. Coordinator는 메타데이터를 관리하고 세그먼트를 어디에 둘지 할당하며, Overlord는 인덱싱 작업 자체를 관리한다. Historical은 세그먼트를 들고 있으면서 쿼리를 처리하는 노드이고, MiddleManager는 실시간 인덱싱을 수행한다. Broker는 여러 Historical에 쿼리를 라우팅하고 결과를 병합하며, Router는 쿼리를 부하 분산한다. 각 노드 유형은 독립적으로 수평 확장할 수 있고, 복제를 통해 데이터 내구성을 확보한다.

⤢✕

쿼리와 성능을 끌어올리는 장치들

JSON 기반의 네이티브 Druid 쿼리와 ANSI SQL 둘 다 지원하고, COUNT/SUM/MIN/MAX 같은 집계와 다차원 그룹화, 상위 N개만 골라내는 TopN 쿼리를 최적화된 방식으로 처리한다. 성능은 여러 장치가 겹쳐서 만들어진다 — 자주 접근하는 데이터는 메모리에 캐싱하고, 쿼리를 여러 노드에 나눠 병렬로 돌리며, 필터링에는 비트맵 인덱스를 쓴다. 대규모 집계에서는 정확한 값 대신 근사 알고리즘으로 속도를 얻는 선택지도 있고, 세부 데이터를 미리 요약해두는 롤업으로 스토리지와 쿼리 성능을 동시에 아낄 수 있다.

시각화 도구와 어떻게 붙는가

Druid 자체는 쿼리 엔진이라 시각화는 외부 도구에 맡긴다. Druid 개발사인 Imply가 만든 Pivot은 드래그 앤 드롭으로 차트·테이블·피봇 테이블을 구성하는 네이티브 도구고, Grafana는 시계열 시각화에 특화된 만큼 Druid 데이터소스 플러그인과 알림 기능을 통해 이상 징후 감지 대시보드를 만드는 데 자주 쓰인다. Apache Superset은 SQL Lab으로 대화형 쿼리를 짜면서 드릴다운·필터링까지 되는 BI 플랫폼이고, Metabase는 SQL을 몰라도 데이터를 탐색하고 대시보드를 자동 갱신·이메일 보고할 수 있게 해준다.

실제로 어디에 쓰이는가

디지털 마케팅 분석에서는 광고 클릭·페이지뷰·전환율 같은 지표를 마케팅 이벤트를 Kafka로 모아 Druid로 실시간 인덱싱한 뒤 Superset으로 시각화해서, 캠페인 효과를 즉시 확인하고 전략을 조정하는 식으로 쓴다. IoT 데이터 분석은 수백만 개 센서의 값을 시간별로 파티셔닝해 저장하고 Grafana 대시보드로 모니터링하면서 문제를 조기에 발견하는 데 쓰인다. 네트워크 모니터링은 트래픽·패킷 손실·지연 시간 같은 장비 로그를 Druid에 쌓고 Imply UI로 실시간 대시보드를 구성해 성능 문제를 즉시 감지하는 용도다. 금융 거래 분석에서는 거래 이벤트를 실시간으로 인덱싱하면서 히스토리 데이터와 비교해 이상 거래 패턴을 빠르게 짚어내는 데 쓴다.

도입 전에 따져볼 것들

쿼리 성능을 내려면 메모리가 넉넉해야 하고(규모에 따라 다름), 병렬 처리를 위한 다중 코어, Deep Storage와 로컬 캐시를 위한 디스크 공간도 함께 고려해야 한다. 최적화 전략으로는 앞서 언급한 500MB~1GB 세그먼트 크기 조정 외에, 스토리지를 아끼기 위한 적절한 롤업 정책 설정, 워크로드에 맞는 시간 단위 파티션 전략, 필요한 컬럼만 선택하고 불필요한 그룹화를 피하는 쿼리 튜닝이 있다.

장점은 실시간 분석 능력, 높은 쿼리 처리량, 확장성과 유연성, 시간 기반 데이터에 대한 최적화로 요약된다. 반대로 메모리 소비가 크고, 초기 설정이 복잡하며, 시계열이 아닌 데이터에는 상대적으로 비효율적이고, ACID 트랜잭션을 지원하지 않는다는 점은 도입 전에 분명히 감안해야 한다. 결국 Druid는 시계열·이벤트 데이터를 다루는 마케팅·IoT·모니터링 영역에서 실시간 인사이트가 꼭 필요할 때 리소스 계획과 최적화 전략을 함께 세우고 들어가는 편이 맞는 선택지다.