Databricks Feature Store가 1초 미만의 최신성으로 피처를 제공하는 방법

머신러닝 모델의 성능은 입력되는 신호의 품질에 좌우됩니다. 사기 탐지 유스케이스는 사용자가 구매 버튼을 누른 후 수 밀리초(ms) 이내에 거래 승인 여부를 결정해야 합니다. 올바른 결정을 내리려면 불과 몇 초 전에 발생한 의심스러운 거래를 감지할 수 있어야 합니다. 사용자의 지난 30일간의 평균 거래와 최근 10분간의 총 거래 금액을 결합하면 잠재적인 사기 행위를 명확히 파악할 수 있습니다. 장기 집계는 사용자의 기본 프로필을 설정하여 정상적인 행동이 무엇인지 판단하는 기준이 되고, 가장 최근 데이터는 이상 행동이 발생하는 즉시 이를 감지하는 데 도움이 됩니다. 개인화 서비스도 마찬가지입니다. 가장 최신의 신호라야 사용자의 현재 의도를 포착하고 참여를 유도할 수 있습니다.

Spark 파이프라인은 Lakehouse에서 대용량 데이터를 처리하여 과거의 기본 피처(baseline features)를 생성하는 검증된 방법입니다. 이러한 배치 작업을 정기적인 일정에 따라 실행하는 방식은 잘 알려져 있지만, 몇 분에서 몇 시간의 지연(lag)이 발생합니다. 사용자에 대한 기본 신호의 경우, 더 단순한 인프라를 사용하는 대가로 이러한 지연을 감수할 수 있습니다. 하지만 모델에 실시간 신호가 필요한 경우 이 인프라는 한계에 부딪힙니다. 기존 피처 스토어 플랫폼에서는 지연 시간을 초 단위나 밀리초 단위로 줄이는 것이 불가능합니다. 실시간 피처의 가치를 실현하기 위해 데이터 사이언티스트는 이러한 집계를 처리하기 위한 복잡한 스트리밍 전용 로직을 구현하고 자체 호스팅 인프라를 구축해야만 합니다.

Databricks Feature Store를 사용하면 피처를 한 번만 작성하고 어디서나 사용할 수 있습니다. 동일한 정의로 오프라인의 대규모 배치 흐름과 온라인의 초실시간 피처 파이프라인을 모두 구동할 수 있습니다. 이 프레임워크는 인프라 부담을 제거하여 지속적인 스트림 처리를 위한 Spark Real-Time Mode (RTM), 스트리밍에 최적화된 온라인 스토리지인 Lakebase, 대규모 검색을 위한 Model Serving을 오케스트레이션합니다. 그리고 한 번 작성된 피처는 수 밀리초 내에 서비스됩니다. Kafka에 이벤트가 도달하는 시점부터 온라인 피처 스토어에서 사용할 수 있게 되기까지의 end-to-end p99 지연 시간은 200ms에 불과합니다.

아키텍처: 200ms 만에 Kafka에서 피처 스토어까지

Databricks Feature Store가 인프라에 구애받지 않는 피처 정의를 가져와 수 밀리초 이내에 일관되게 계산하는 파이프라인을 어떻게 구축하는지 내부 구조를 살펴보겠습니다. 스트리밍 피처의 end-to-end 경로는 다음과 같습니다.

1. 이벤트가 Kafka에 도달 - 신용카드 거래, 광고 노출 또는 클릭스트림 이벤트와 같은 원시 데이터
2. 서버리스 Lakeflow Spark Delta Pipelines의 Spark RTM 파이프라인이 이벤트를 지속적으로 처리하여 실시간으로 롤링 집계(rolling aggregations)를 계산
3. 업데이트된 집계 데이터가 새로운 스트리밍 JDBC 싱크를 통해 Lakebase에 기록되어 온라인 피처 스토어에 저장됨
4. Model Serving 엔드포인트가 추론 시점에 Lakebase에서 최신 피처를 검색하여 모델에 자동으로 공급

이를 최근 10분 동안의 사용자 거래 금액 합계인 사기 탐지 피처와 연결해 보겠습니다. 유입되는 각 이벤트에는 거래 상세 정보(금액, 위치, 사용자 ID, 가맹점 정보)가 포함되어 있으며, 상태 저장(stateful) 파이프라인으로 라우팅됩니다. 파이프라인은 사용자의 누적 거래 합계를 보유하고 있는 로컬 RocksDB 인스턴스를 참조하며, 만료 시간을 통해 윈도우를 최근 10분으로 유지합니다. 파이프라인은 로컬에서 값을 읽고 증가시킨 다음, 업데이트된 피처 값을 Lakebase에 기록합니다. 따라서 모델에 새로운 거래를 승인하라는 쿼리가 들어오면, 피처 스토어에서 1초 미만의 최신성을 가진 최신 거래 합계를 즉시 사용할 수 있습니다. 이 합계 피처는 사용자의 과거 구매 기준선(baseline)과 함께 가져와 승인 여부를 결정하는 데 사용됩니다. 과거 기준선을 훨씬 초과하는 합계는 모델이 잠재적인 사기 행위를 감지할 수 있는 강력한 지표가 됩니다.

이 파이프라인의 각 구성 요소는 유입되는 이벤트가 라우팅되고, 집계가 계산되며, 피처가 온라인 스토어에 최대한 신속하게 기록되도록 최적화되었습니다.

롤링 윈도우: 수 밀리초 내에 집계 업데이트

인프라에 대해 더 자세히 알아보기 전에, 집계 피처와 배치 동기화 패러다임에서 실시간 업데이트 패러다임으로의 전환에 대해 이야기해 보겠습니다.

시간 윈도우에 따른 집계 피처(예: 개수, 합계, 평균)는 실시간 ML을 위한 강력하고 유연한 신호입니다. 장기 배치 피처는 일정 기간 동안 사용자의 과거 기준선을 설정하여 모델이 각 사용자의 행동에 적응하고 이를 이해할 수 있도록 합니다. 짧고 최신 상태를 유지하는 피처는 변화하는 상황에 신속하게 반응하여 새로운 사용자 관심사나 사기 활동을 구분해 냅니다. 시간 윈도우는 시간 범위(예: 10분)와 이러한 시간 범위가 시간에 따라 어떻게 전개되어야 하는지(예: 중첩 또는 분리)를 정의합니다.

Databricks Feature Store는 3가지 다른 시간 윈도우를 지원합니다.

• 텀블링 윈도우(Tumbling windows)는 실제 시간(wall-clock) 간격에 맞춰 정렬되며, 이전 간격이 끝나는 즉시 시작됩니다. 예를 들어, 10분짜리 텀블링 윈도우는 12:00~12:10을 처리한 후 12:10~12:20을 처리할 수 있습니다. 이벤트는 이러한 고정된 간격으로 배치 처리되며, 간격이 끝날 때 피처 값이 출력됩니다. 즉, 집계 값은 간격 경계에서만 최신 상태가 됩니다.
• 슬라이딩 윈도우(Sliding windows) 역시 실제 시간 간격에 맞춰 정렬되지만, 간격 간의 중첩을 허용합니다. 예를 들어, 슬라이드 간격이 5분인 10분짜리 슬라이딩 윈도우는 12:00~12:10, 12:05~12:15, 12:10~12:20을 차례로 처리할 수 있습니다.
• 롤링 윈도우(Rolling windows)는 실제 시간에 맞춰 정렬되지 않고, 각 이벤트의 타임스탬프에서 밀리초 단위의 해상도로 역방향을 조회합니다. "현재 실제 시간 기준 지난 10분 동안의 거래 합계"는 새 이벤트가 발생할 때마다 윈도우가 이동하므로 항상 최신 상태를 유지합니다. 따라서 롤링 윈도우는 "현재"가 계속해서 변하는 실시간 서빙에 가장 자연스럽게 부합합니다.

텀블링 및 슬라이딩 윈도우는 피처가 자주 변경되지 않을 때 유용합니다. 업데이트를 덜 자주 내보내고 유지 관리 비용이 저렴하며, 더 단순한 예약형 파이프라인에 자연스럽게 통합됩니다. 롤링 윈도우는 이러한 효율성 대신 극대화된 최신성을 제공하며, 이는 모든 새로운 이벤트가 모델에 제공되는 값에 즉각적으로 영향을 미쳐야 하는 신호에 가장 가치 있게 활용됩니다.

Feature Store 선언적 API를 사용하여 롤링 윈도우 피처를 정의하는 방법이 얼마나 간단한지 확인해 보세요.

Spark Real-Time Mode: 피처 계산을 위한 엔진

기본 인프라를 살펴보면, 높은 처리량으로 실시간 피처를 생성할 수 있게 해주는 것은 바로 스트리밍 파이프라인입니다. 이 파이프라인은 Kafka의 데이터를 온라인 피처 스토어까지 전달합니다. 이 스트리밍 파이프라인은 Spark Structured Streaming의 근본적으로 새로운 실행 모드인 Spark Real-Time Mode (RTM)를 기반으로 작동합니다. RTM은 밀리초 단위의 최신성을 가능하게 하는 핵심 아키텍처 혁신입니다.

동시 스테이지 및 상태 저장 처리

기존의 마이크로배치 모드(MBM)에서 Spark는 스트리밍 데이터를 개별 배치로 처리합니다. 각 배치는 구성 가능한 간격 동안 이벤트를 수집하고, 각 스테이지를 통해 순차적으로 처리한 후, 체크포인트를 수행하고 다음 배치를 시작합니다. 이로 인해 지연 시간의 하한선이 생깁니다. 아무리 공격적으로 튜닝하더라도 상태 저장 집계를 위한 MBM 파이프라인은 일반적으로 수 초에서 수 분 단위로 작동합니다. 반면 RTM은 스테이지를 동시에 실행합니다. 집계 연산자는 업스트림 스테이지가 모든 행의 처리를 완료할 때까지 기다리지 않고, 행을 사용할 수 있는 즉시 신속하게 처리합니다.

롤링 집계에는 두 가지 중요한 스테이지가 있습니다. 첫 번째 스테이지는 데이터 처리, 스키마 검증, 데이터 병합(coalescing), 타입 캐스팅입니다. 이는 일반적인 액션 이벤트를 피처 집계에 적합한 형태로 변환하는 비즈니스 로직을 실행합니다. 두 번째 스테이지는 엔티티별로 데이터를 집계하여 롤링 윈도우 집계를 계산하는 것입니다. 유입되는 각 행은 로컬 RocksDB 상태 스토어의 집계 값을 즉시 업데이트하고 새 값을 다운스트림으로 내보냅니다. 윈도우 만료 역시 행 단위로 발생합니다. 특정 이벤트의 윈도우 기간이 경과하면 파이프라인은 해당 이벤트의 기여도를 제거하고 수정된 집계 값을 Lakebase로 내보냅니다. RocksDB는 각 실행기(executor)에서 로컬로 실행되므로 클러스터의 메모리 용량을 초과하는 상태 크기도 지원할 수 있습니다.

서버리스 RTM의 파이프라인 상태 관리

체크포인팅은 개별 파이프라인 작업자의 장애로부터 파이프라인을 복구할 수 있게 해주므로, 상태 저장 스트리밍의 내결함성(fault tolerance)을 위해 필수적입니다. 하지만 체크포인팅에는 비용이 따릅니다. 마이크로배치 모드에서 Spark는 모든 배치 경계에서 체크포인트를 수행하며, 각 체크포인트는 클라우드 오브젝트 스토어와 상호 작용하므로 파이프라인에 지연 시간을 추가합니다.

RTM은 다른 접근 방식을 취합니다. 계획 및 체크포인팅 비용이 더 긴 간격에 걸쳐 분산됩니다. 체크포인팅 비용은 각 배치 경계에서 파이프라인을 차단하는 대신 해당 간격 동안 처리된 모든 행에 분산됩니다. 이로 인해 결함 허용성(fault tolerance)이 저하되지 않습니다. 정확히 한 번 처리(Exactly-once processing) 보장이 유지됩니다. 장애가 발생하더라도 파이프라인은 Kafka 소스에서 최대 5분 분량의 데이터만 재실행합니다. 상대적으로 재실행 볼륨이 약간 증가하는 대신 정상 상태 처리 대기 시간(latency)이 크게 단축되는 이점이 있습니다.

Feature Store는 Lakeflow Spark Delta Pipelines (SDP)에서 서버리스 RTM 파이프라인을 실행하므로 클러스터 관리와 용량 계획이 전혀 필요하지 않습니다. 머신을 프로비저닝하거나, 실행기(executor) 수를 튜닝하거나, 클러스터 유지 관리에 대해 걱정할 필요가 없습니다. 인프라 업데이트로 인해 파이프라인을 재시작해야 하는 경우, SDP가 핸드오프를 조정합니다. 즉, 기존 클러스터가 중지되기 전에 새로운 서버리스 클러스터가 프로비저닝되어 완전히 준비됩니다. 이러한 조정은 5분 간격의 체크포인팅 시점에 동기화되어 다운타임을 최소화하고 재처리 공백을 방지합니다. 그 결과, 유지 관리 기간 동안 피처 최신성(feature freshness)에 미치는 영향이 거의 제로에 가깝습니다.

Lakebase: 스트리밍 쓰기 오버헤드 최소화

Databricks Feature Store는 추론을 위한 온라인 피처 값을 저장하는 데 Lakebase를 사용합니다. 컴퓨팅과 스토리지를 분리하는 Lakebase 아키텍처를 통해 오토스케일링으로 모델 추론을 위한 가변적인 부하를 처리할 수 있습니다. Online Feature Store는 이 기능을 활용하여 수십 밀리초(ms)의 대기 시간으로 초당 수만 건의 읽기 요청을 처리할 수 있도록 확장합니다.

스트리밍 쓰기는 수신되는 각 Kafka 행마다 새로운 롤링 윈도우 값이 생성되면서 수많은 소규모 업서트(upsert)가 발생하기 때문에 특히 까다롭습니다. 표준 Postgres에서 이러한 패턴은 복구를 용이하게 하기 위해 전체 페이지 쓰기(full page writes)를 사용하므로 대량의 write-ahead log (WAL) 볼륨을 생성할 수 있습니다. 각 체크포인트 이후 페이지의 첫 번째 수정 시, 작은 논리적 변경 사항뿐만 아니라 전체 8KB 페이지 이미지가 write-ahead-log (WAL)에 기록됩니다. 자주 업데이트되는 핫 엔티티 행의 경우, 이로 인해 WAL 증폭(WAL amplification)이 발생하여 쓰기 처리량, 복제 및 복구 오버헤드의 병목 현상이 됩니다.

이제 Lakebase는 컴퓨팅과 분산 스토리지의 분리 구조를 활용하여 표준 Postgres 대비 스트리밍 쓰기 증폭을 최소화합니다. Lakebase 아키텍처를 사용하면 Postgres가 WAL에 전체 8KB 페이지 스냅샷을 반복해서 기록하는 대신, 작고 압축된 변경 레코드를 기록할 수 있습니다. 이러한 압축 레코드는 분산된 safekeeper 노드의 쿼럼(정족수)에 의해 승인되므로 내구성은 여전히 보장됩니다. 충분한 변경 레코드가 누적된 후 복구를 위해 여전히 전체 페이지 스냅샷이 필요하지만, 이는 쓰기 경로를 비대하게 만드는 대신 나중에 스토리지 레이어에서 생성됩니다. Feature Store의 경우, 결과적으로 RTM이 훨씬 적은 WAL 증폭과 최소한의 추가 대기 시간으로 새로운 피처 값을 Lakebase에 지속적으로 게시할 수 있습니다.

Model Serving: 대규모 환경에서의 저지연 피처 검색

마지막 단계는 Lakebase에서 최신 피처를 검색하여 추론 시점에 모델에 전달하는 것입니다. 이 작업은 높은 QPS 및 저지연 워크로드에 최적화된 완전 관리형 서빙 인프라인 Databricks Model Serving에서 처리합니다.

Model Serving은 실시간 ML의 처리량 요구 사항에 맞게 구축되었습니다:

• 완전한 수평적 확장 가능 아키텍처: 추론 서버, 인증 레이어, 프록시 및 속도 제한기(rate limiter)가 모두 독립적으로 확장되어 CPU 엔드포인트에서 100K+ QPS를 유지합니다.
• 빠르고 탄력적인 확장: 과도한 프로비저닝 없이 트래픽 급증 및 감소에 시스템이 적응하여 실제 수요에 맞게 비용을 유지합니다.
• 모델 거버넌스 및 모니터링: AI Gateway를 사용하여 네트워크 액세스를 관리하고, 모델 엔드포인트에 대한 권한을 관리하며, 품질을 모니터링합니다.

Feature Store의 경우 통합이 원활하게 이루어집니다. 모델이 MLflow에 로깅되면 피처 종속성이 기록됩니다. 추론 시점에 Model Serving은 Lakebase에서 필요한 피처를 자동으로 조회하므로, 커스텀 조회 코드나 수동 연결 작업이 필요하지 않습니다. RTM에 의해 계산되어 Lakebase에 저장된 최신 집계 데이터가 검색되어 추론 요청과 투명하게 결합(join)됩니다.

스트리밍을 넘어선 Feature Store

성능이 뛰어난 실시간 기능은 Feature Store가 해결할 수 있는 문제의 일부에 불과합니다. 고려해 볼 만한 다른 두 가지 과제는 다음과 같습니다:

스트림 피처를 위한 학습 데이터

스트림의 짧은 보존 기간(retention window)으로 인해 별도의 오프라인 스토리지를 유지해야 하므로, 스트리밍 피처의 학습 데이터 생성은 어려울 수 있습니다. Databricks Feature Store는 수집된 Kafka 데이터의 오프라인 복사본을 저장하여 이 문제를 해결합니다. 모델 학습을 위해 Feature Store는 스트리밍 파이프라인이 역사적 값(historic values)에 대해 계산하는 것과 동일한 피처 값을 계산하고 시점 기준의 정확한 조인(point-in-time accurate joins)을 수행합니다. 동일한 기능이 온라인 스트리밍 피처를 백필(backfill)하는 데 사용되어 프로덕션에 빠르게 출시할 수 있도록 지원합니다.

통합

위에서 보았듯이 Feature Store는 여러 복잡한 인프라 구성 요소를 오케스트레이션합니다. 이러한 파편화는 거버넌스, 계보(lineage) 및 피처 재사용을 어렵게 만들 수 있습니다. 또한 엔지니어가 시스템 경계를 넘어 변경 사항을 조정해야 하므로 개발 속도가 느려집니다.

Databricks에서 피처는 Unity Catalog의 일급 객체(first-class objects)로, 검색이 가능하고 액세스 제어로 관리되며 전체 계보(lineage)가 추적됩니다. 피처 변환은 모델과 함께 패키징되고, MLflow는 어떤 피처가 사용되었는지 캡처하며, 배포 계보는 모델을 피처 종속성에 연결합니다. 이 플랫폼은 전체 ML 스택을 개발, 배포 및 관리할 수 있는 원스톱 서비스입니다.

Databricks의 Feature Store는 Spark RTM, Lakebase, Model Serving과 같은 핵심 빌딩 블록을 오케스트레이션하므로 인프라를 직접 관리하지 않고도 업계 최고 수준의 대기 시간과 규모를 확보할 수 있습니다. 이러한 각 시스템은 머신 러닝 피처에 대해 200ms 수준의 최신성을 실현할 수 있도록 스트리밍 워크로드에 미세하게 최적화되어 있습니다.

스트리밍 피처를 정의하는 방법은 스트리밍 파이프라인 문서를 참조하세요. 기존 피처를 실험하여 밀리초(ms) 수준의 최신성으로 얼마나 더 강력한 신호를 제공하는지 확인해 보세요.

기반 기술을 더 자세히 이해하려면 더 빠른 쓰기에 관한 Lakebase 블로그 및 RTM 아키텍처 분석을 참조하세요.

이러한 문제를 함께 해결하고 싶으시다면, 현재 채용 중입니다!

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)