넷플릭스는 Apache Druid를 통해 초당 1,500만 건 이상의 이벤트를 처리하며 대규모 실시간 분석을 수행하고 있으나, 대시보드의 롤링 윈도우(Rolling Window) 쿼리가 생성하는 중복 부하 문제를 해결해야 했습니다. 이를 위해 쿼리에서 시간 범위를 분리하여 처리하는 '구간 인식 캐싱(Interval-Aware Caching)' 레이어를 구축하여 Druid의 계산 리소스를 효율화했습니다. 이 시스템은 과거의 안정된 데이터는 캐시에서 불러오고 오직 최신 데이터만 Druid에 요청함으로써, 대규모 트래픽 상황에서도 쿼리 성능을 안정적으로 유지합니다.

기존 캐싱 방식의 한계와 문제점

롤링 윈도우의 비효율성: 실시간 모니터링 대시보드는 10~30초마다 "최근 3시간"과 같은 쿼리를 반복해서 보냅니다. 시간 범위가 계속 이동하기 때문에 Druid의 기존 전체 결과 캐시(Full-result cache)는 매번 미스(Miss)가 발생합니다.
실시간 데이터 캐싱 제한: Druid는 데이터의 정확성을 위해 실시간 인덱싱 중인 세그먼트의 결과는 캐싱하지 않습니다. 이로 인해 대시보드가 갱신될 때마다 동일한 실시간 세그먼트를 반복해서 스캔하는 낭비가 발생합니다.
하드웨어 확장의 한계: 수십 명의 엔지니어가 동일한 대시보드를 볼 때 발생하는 수천 개의 중복 쿼리를 처리하기 위해 단순히 하드웨어를 증설하는 것은 비용 효율성이 매우 낮습니다.

구간 인식 캐싱의 핵심 아이디어

데이터의 안정성 활용: 3시간 전의 데이터는 이미 확정되어 변하지 않지만, 최근 1분 내의 데이터는 지연 도착 등으로 인해 변할 수 있습니다. 이 차이를 이용해 오래된 데이터는 캐시에서 즉시 반환하고, 최신 구간만 Druid에 쿼리합니다.
쿼리 구조와 시간의 분리: 쿼리문에서 시간 범위(Interval)를 제외한 나머지 구조(필터, 집계 등)를 SHA-256으로 해싱하여 캐시 키로 사용합니다. 이를 통해 서로 다른 시간 범위를 가진 동일한 목적의 쿼리들이 동일한 캐시 항목을 참조할 수 있게 합니다.
버킷팅(Bucketing) 구조: 데이터를 쿼리 단위(예: 1분)별로 잘게 쪼개어 'Map-of-Maps' 형태로 저장합니다. 쿼리가 들어오면 필요한 시간 범위에 해당하는 버킷들을 캐시에서 조회하고, 없는 부분만 골라냅니다.

지수적 TTL을 통한 효율적인 데이터 관리

신선도와 부하의 트레이드오프: 데이터 파이프라인의 지연 시간을 고려해 최신 데이터에 약 5초의 캐시 유지 시간(TTL)을 부여합니다. 이는 대시보드 사용자에게는 거의 실시간으로 느껴지면서도 Druid의 부하를 대폭 줄여줍니다.
데이터 연령에 따른 TTL 차등화: 데이터가 생성된 지 얼마 안 된 버킷은 5~10초의 짧은 TTL을 가집니다. 데이터가 오래될수록 나중에 도착하는 이벤트가 적어지므로, TTL을 지수적으로 늘려 최대 1시간까지 캐시에 보관합니다.
자동 보정: 짧은 TTL 덕분에 최신 데이터 구간에서 발생하는 수정 사항은 빠르게 캐시에 반영되며, 오래된 구간은 긴 TTL을 통해 캐시 적중률을 극대화합니다.

시스템 구현 및 작동 워크플로우

투명한 프록시 구조: Druid Router 단계에서 요청을 가로채는 외부 서비스 형태로 구현되었습니다. 클라이언트 앱을 수정할 필요 없이 캐싱 기능을 끄거나 켤 수 있습니다.
쿼리 분해 및 병합:
1. 들어온 쿼리를 파싱하여 시간 구간을 확인하고 캐시 키(해시)를 생성합니다.
2. 캐시 저장소(예: Redis/Memcached)에서 요청된 구간에 해당하는 연속된 버킷들을 확인합니다.
3. 캐시에 없는 '가장 최신의 불안정한 구간'으로 쿼리 범위를 축소하여 Druid에 요청합니다.
4. 캐시된 결과와 Druid에서 새로 가져온 결과를 병합하여 클라이언트에 반환합니다.

롤링 윈도우 기반의 대규모 대시보드를 운영하는 환경이라면, 모든 데이터를 매번 다시 계산하기보다 이처럼 시간 구간을 나누어 캐싱하는 전략이 Druid 클러스터의 비용 절감과 성능 향상에 매우 효과적입니다. 특히 데이터가 확정되는 속도에 따라 TTL을 다르게 가져가는 '지수적 TTL' 방식은 데이터 정확도와 효율성 사이의 균형을 잡는 유용한 기술적 패턴입니다.