Apache Druid 37: 세그먼트 메타데이터 캐시 기본화와 Hadoop 수집 종료로 달라진 운영 경계

이 릴리스를 봐야 하는 이유

Apache Druid 37.0.0은 2026년 5월 8일 공개됐다. 255개 이상의 변경 사항 중 운영자가 바로 점검해야 할 변화는 두 가지다.

첫째, 세그먼트 메타데이터 캐시(Broker-side segment metadata cache)가 기본값으로 활성화됐다. 이 캐시는 Druid 34에서 도입됐지만, 그동안은 수동으로 켜야 했다. Druid 37부터는 아무것도 안 해도 켜져 있다. Broker의 메모리 사용량이 늘어나는 동시에, 메타데이터 관련 쿼리 성능이 올라간다.

둘째, Hadoop 기반 수집이 완전히 제거됐다. Druid 34에서 deprecated된 기능이 이번 릴리스에서 코드베이스에서 삭제됐다. Hadoop 배치 수집 파이프라인을 아직 쓰는 클러스터는 Druid 37 업그레이드 전에 마이그레이션을 완료해야 한다.

이 글은 두 변화의 배경 원리와 운영 영향을 정리한다.

Druid 아키텍처 간략 배경

변화를 이해하려면 Druid의 컴포넌트 역할을 먼저 파악해야 한다.

Apache Druid 아키텍처 — 메타데이터 흐름 중심

Druid에서 Broker는 클라이언트 쿼리를 받아 어떤 Historical에서 어느 세그먼트를 읽어야 하는지 결정하고, 결과를 병합해 반환한다. 이 결정을 내리려면 Broker는 각 datasource의 세그먼트 목록·스키마·파티셔닝 정보를 알아야 한다.

Druid 37 이전까지, Broker는 이 메타데이터를 sys.segments 같은 시스템 테이블 쿼리나 Coordinator 폴링으로 그때그때 가져왔다. 클러스터 규모가 커질수록 이 메타데이터 조회가 쿼리 오버헤드를 만들었다.

세그먼트 메타데이터 캐시가 기본값이 된 이유

캐시가 없을 때 무슨 일이 생기나

Druid는 실시간 OLAP 시스템으로 자주 새 세그먼트가 생기고, 오래된 세그먼트가 교체된다. sys.segments를 조회하면 Coordinator의 메타데이터 store를 직접 거쳐야 한다. 규모가 큰 클러스터(수천 개 세그먼트)에서는 이 조회 자체가 무거운 쿼리가 됐다.

더 큰 문제는 Druid SQL의 쿼리 플래닝 단계다. 쿼리 플래너는 어느 datasource에 어떤 스키마가 있는지 알아야 최적 실행 계획을 만든다. 캐시 없이 플래닝 때마다 메타데이터를 가져오면, 고동시성 환경에서 Coordinator가 플래닝 부하를 받는 구조가 됐다.

캐시가 켜지면 무엇이 달라지나

druid.sql.planner.metadataSegmentCacheEnable=true(v37 기본값)를 켜면:

Broker는 Coordinator로부터 세그먼트 메타데이터를 주기적으로 폴링해 로컬 캐시에 유지한다.
쿼리 플래닝이 Coordinator 조회 없이 Broker 로컬 캐시에서 진행된다.
sys.segments 조회도 캐시에서 답한다.

성능 이득은 특히 두 곳에서 나타난다. 첫째는 쿼리 플래닝 속도다. 플래닝 때마다 Coordinator 왕복이 없어진다. 둘째는 Coordinator 부하다. 메타데이터 요청이 Broker 캐시에서 흡수되므로 Coordinator가 더 여유로워진다.

운영 주의: Broker 메모리 증가

캐시를 Broker 메모리에 올리기 때문에, 세그먼트 수가 많은 클러스터일수록 Broker 메모리 사용량이 늘어난다. Druid 공식 문서는 이 점을 명시한다.

segment/schemaCache/rowSignature/changed 메트릭(신규)과 segment/schemaCache/rowSignature/column/count 메트릭(신규)을 통해 캐시 크기와 업데이트 빈도를 모니터링할 수 있다.

Broker JVM 힙 크기를 늘리지 않고 Druid 37로 업그레이드하면, 특히 세그먼트 수가 많은 클러스터에서 GC 압박이 커질 수 있다.

증분 세그먼트 메타데이터 캐시 GA

Druid 37에서 또 하나의 변화는 증분 세그먼트 메타데이터 캐시(incremental segment metadata cache) 가 GA됐다는 점이다.

기본 설정은 useIncrementalCache=ifSynced다. 의미는 다음과 같다.

Coordinator가 리더가 된 뒤 메타데이터 store와 최소 한 번 동기화를 완료할 때까지, 캐시에서 읽기를 차단한다.
동기화가 완료되면 증분 업데이트만 반영해 캐시를 유지한다. 매번 전체 스캔 없이 변경분만 처리한다.

이 설정은 Coordinator 재시작 직후 캐시가 불완전한 상태에서 응답하는 문제를 방지한다. 운영 중 Coordinator failover가 발생할 때 중요하다.

Query Blocklist: 재시작 없이 쿼리 차단

Druid 37에서 새로 들어온 운영 도구가 하나 있다. Broker API를 통한 동적 쿼리 차단 목록(query blocklist) 이다.

사용하는 상황

프로덕션에서 특정 쿼리가 클러스터에 과부하를 주거나, 특정 datasource에 대해 특정 유형의 쿼리를 일시적으로 막아야 하는 경우가 생긴다. 기존에는 Druid를 재시작하거나, upstream(Hive, Superset 등)에서 필터링하는 방법밖에 없었다.

Druid 37부터는 Coordinator API를 통해 runtime에 차단 규칙을 추가하거나 제거할 수 있다.

POST /druid/coordinator/v1/config/broker
{
  "queryBlocklist": [
    {
      "datasource": "wikipedia",
      "queryType": "groupBy",
      "context": { "priority": 0 }
    }
  ]
}

차단 규칙의 조건은 AND 로직이다. 위 예시에서 차단 대상은 wikipedia datasource이면서 groupBy 쿼리이면서 priority=0 컨텍스트를 가진 요청이다. 세 조건 중 하나라도 맞지 않으면 차단되지 않는다.

주의할 점

차단 목록은 재시작 없이 동작하지만, Druid 서비스가 재시작되면 초기화된다. 영구적으로 유지하려면 설정 파일에 반영해야 한다.

Hadoop 기반 수집 제거: 가장 큰 breaking change

Hadoop 기반 수집(druid-hadoop-based-indexing)은 Druid 34에서 deprecated 공지가 났고, Druid 37에서 코드베이스에서 완전히 삭제됐다.

영향 범위

다음 상황에 해당하면 Druid 37 업그레이드 전에 마이그레이션이 필요하다.

batchDataFiles / hadoopDependencyCoordinates 를 사용하는 배치 수집 잡
HDFS에서 직접 파일을 읽어 Druid 세그먼트를 만드는 파이프라인
HadoopIndexTask 또는 HadoopDruidIndexer를 사용하는 워크플로

대체 경로

기존 방법	권장 대체
HadoopIndexTask	Native Batch Indexing (inputSource: s3/gcs/hdfs/local)
Hadoop 기반 HDFS 수집	SQL-based ingestion 또는 Native Batch with hdfsInputSource
MapReduce 기반 MiddleManager	Kubernetes Indexer (K8s MiddleManager-less mode)

Druid의 Native Batch 수집은 HDFS도 hdfsInputSource로 읽을 수 있다. Hadoop 클러스터를 사이에 두지 않고 직접 Druid가 HDFS 파일을 읽는 방식이다.

Kafka/Kinesis deprecated parser 제거

스트리밍 수집에서도 breaking change가 하나 있다. 오래된 parser 스펙 포맷이 Kafka/Kinesis supervisor에서 제거됐다.

기존 supervisor spec에 이런 구조가 있다면 수정이 필요하다.

{
  "ioConfig": {
    "topic": "my-topic",
    "inputFormat": null,
    "parser": { ... }
  }
}

Druid 37에서는 ioConfig에 inputFormat을 명시해야 한다.

{
  "ioConfig": {
    "topic": "my-topic",
    "inputFormat": {
      "type": "json"
    }
  }
}

Druid 37 업그레이드 체크리스트

업그레이드 전 확인

Hadoop 수집 파이프라인 존재 여부
HadoopIndexTask / HadoopDruidIndexer 검색

Kafka/Kinesis supervisor parser 구조
parser 키 대신 inputFormat 명시 여부

Broker JVM 힙 크기
세그먼트 수 * avg 메타 크기 추정 후 여유 확인

업그레이드 후 모니터링

segment/schemaCache/rowSignature/changed
캐시 업데이트 빈도 확인

segment/schemaCache/rowSignature/column/count
캐시 크기 추이

Broker JVM GC 메트릭
Old-gen GC 빈도/시간 증가 여부

쿼리 플래닝 latency
캐시 효과로 감소하는지 확인

캐시를 끄고 싶다면

druid.sql.planner.metadataSegmentCacheEnable=false 설정으로 Broker 캐시 비활성화 가능
하지만 쿼리 플래닝 성능과 Coordinator 부하 증가를 감수해야 함
Broker 메모리 제약이 있는 소규모 클러스터에서는 일시적으로 끄는 것이 현실적일 수 있음

운영자 업그레이드 체크리스트

이 릴리스를 한 문장으로 요약하면

Druid 37의 핵심은 오래된 기술 부채(Hadoop 수집, legacy parser)를 정리하면서, 운영 현장에서 오래 요청됐던 Broker-side 메타데이터 캐시를 기본으로 활성화한 것이다.

업그레이드를 검토하는 운영자에게 실질적인 순서는 이렇다.

Hadoop 수집 파이프라인이 있다면 Native Batch 또는 SQL-based ingestion으로 먼저 마이그레이션한다.
Kafka/Kinesis supervisor spec에서 parser 키가 있는지 검색해 inputFormat으로 교체한다.
Broker JVM 힙 여유를 확인한다. 세그먼트가 많은 클러스터라면 힙을 늘리는 것이 안전하다.
업그레이드 후 segment/schemaCache 메트릭과 Broker GC 지표를 모니터링한다.
필요하면 query blocklist API를 활용해 문제가 되는 쿼리를 재시작 없이 격리한다.

References

Apache Druid 37.0.0 Release (2026-05-08): https://github.com/apache/druid/releases/tag/druid-37.0.0
Apache Druid Release Notes (37.0.0): https://druid.apache.org/docs/latest/release-info/release-notes/
Apache Druid Upgrade Notes: https://druid.apache.org/docs/latest/release-info/upgrade-notes/
PR #19075: Enable segment metadata cache on Broker by default: https://github.com/apache/druid/pull/19075
PR #19011: Broker Config and Query Blocklist: https://github.com/apache/druid/pull/19011
Apache Druid Hadoop-based ingestion docs: https://druid.apache.org/docs/latest/ingestion/hadoop/
Imply: Introducing Apache Druid 32.0 (projection background): https://imply.io/blog/introducing-apache-druid-32-0/