Redis 피처 스토어

Redis 피처 스토어 (Feature store)

생산 모델(사기 점수, 추천, 동적 가격)의 추론 경로에서 사전 계산된 ML 피처를 서브 밀리초로 서빙하고, 배치·스트리밍 피처를 같은 저장소에서 신선하게 유지하는 온라인 피처 스토어 패턴입니다. Redis 해시 하나가 엔티티의 모든 피처를 보관합니다.

출처: 공식문서 — Redis feature store

언제 Redis를 피처 스토어로 쓰는가

생산 모델(사기 점수, 추천, 동적 가격)이 매 예측·요청마다 수십 개의 사전 계산 피처를 서브 밀리초 읽기로 필요로 하고, 배치·스트리밍 신선도가 섞이며 동시 수집 파이프라인의 높은 쓰기 처리량이 필요할 때, Redis를 온라인 레이어로 사용합니다.

왜 이 문제가 어려운가

온라인 피처 스토어는 수 밀리초의 요청 예산 안에서 추론 호출당 수십 개 피처를 서빙해야 하면서, 배치 잡과 스트리밍 파이프라인이 같은 피처를 아주 다른 주기로 갱신합니다. 대안의 단점:

오프라인 웨어하우스 직접 조회: 추론 호출당 수백 밀리초가 추가되어 실시간 서빙이 불가능
웨어하우스 앞의 전용 캐시: 대기 시간은 풀지만 training-serving skew 유발 — 추론에서 서빙되는 피처가 모델이 학습한 것과 어긋나, 한쪽만 변환을 바꾸면 조용히 정확도 저하
디스크 기반 온라인 스토어: 수백만 엔티티에 걸쳐 모든 사용자 행동이 동시에 수십 개 피처를 갱신해야 하면 처리량 벽에 부딪힘 — 작은 동시 쓰기의 I/O 믹스가 가장 느린 부분
단일 TTL 스토어: 혼합 staleness 처리 불가 — 야간 갱신 배치 피처와 수 초마다 갱신되는 스트리밍 피처가 공존하는데 단일 키별 만료로는 둘 다 표현 못 함. 더 나빠, 실패한 수집 파이프라인은 조용히 오래된 값을 서빙하는 대신 피처를 만료시켜야 함

작동하는 온라인 피처 스토어는 요청율의 서브 밀리초 읽기, 배치·스트리밍 수집의 높은 동시 쓰기 처리량, 피처별 독립 신선도 제어, 업스트림 파이프라인 실패 시 자가 정리 동작이 필요합니다 — 모델 서빙 스택 옆에 전용 인프라를 세우지 않고요.

Redis 솔루션에서 기대할 수 있는 것

단일 샤드에서 초당 수백만 읽기로 추론 엔드포인트에 1ms P99 미만으로 피처 벡터 서빙, Redis Cluster로 그 너머 수평 확장
락·버전 컬럼 없이 같은 엔티티에 대해 배치·스트리밍 수집 동시 실행 — Redis는 샤드당 단일 스레드라 개별 필드 쓰기가 구조적으로 원자적
같은 엔티티 해시 내 개별 피처에 다른 신선도 보장 적용 — 실시간 신호는 초 단위, 배치 집계는 시간 단위, HEXPIRE의 필드별 TTL로
수집 파이프라인 실패 시 오래된 스트리밍 피처가 자가 만료되어, 모델이 조용히 낡은 값 대신 누락 피처를 받게
파이프라인된 HMGET으로 배치 스코어링 시 수백 엔티티의 피처를 단일 왕복으로 조회
Redis Feature Form — Redis 자체 materialize/serve 레이어 — 또는 Feast를 커넥션 문자열 변경만으로 연결해 전용 서빙 코드 불필요
캐시·세션·레이트 리밋을 이미 처리하는 같은 Redis 인스턴스에 온라인 피처 스토어 공동 배치 — 추가 인프라 없음

Redis가 이 솔루션을 어떻게 지원하는가

실제로 각 엔티티(사용자, 계정, 아이템)는 fs:user:{id} 같은 결정적 키의 단일 Hash입니다. 해시는 그 엔티티의 모든 피처를 피처당 필드 하나로 담습니다(배치 materialize 집계 + 스트리밍 갱신 신호). 그래서 HMGET 한 번으로 모델이 필요한 부분집합을 한 왕복에 반환합니다. 키 수준의 EXPIRE는 배치 materialization 주기에 맞춰 파이프라인이 갱신을 멈추면 엔티티 전체가 자가 정리되게 하고, 필드별 HEXPIRE는 각 스트리밍 피처가 해시 나머지와 독립된 더 짧은 만료를 갖게 합니다.

Hashes가 한 키 아래에 엔티티의 모든 피처를 묶음 — HMGET으로 모델이 필요한 모든 것을 단일 네트워크 왕복에 읽고, 작은 해시는 listpack 인코딩으로 메모리를 압축
HSET이 임의 필드 부분집합을 원자적으로 기록 — 배치·스트리밍 파이프라인이 락·버전 컬럼 없이 같은 엔티티의 겹치거나 분리된 피처를 동시 갱신
HEXPIRE/HTTL(Redis 7.4+)로 필드별 TTL — 스트리밍 피처(5분 신선도)와 배치 피처(24시간 신선도)가 독립 만료로 같은 해시에 공존, mixed-staleness 문제가 한 줄의 서버 측 보장이 됨
키 수준 EXPIRE로 배치 갱신기가 실패하면 엔티티가 완전히 사라져, 추론이 조용히 낡은 값 대신 누락 엔티티를 보게 함(모델 핸들러가 감지·폴백 가능)
Pipelining으로 여러 엔티티의 HMGET을 한 왕복에 묶음 — 모델이 한 번에 수백 엔티티 피처를 필요로 하는 배치 스코어링의 올바른 원시 연산
메모리에서의 서브 밀리초 읽기·쓰기로 피처 스토어를 추론의 임계 경로에서 벗어나게 — 모델 서버의 요청 예산을 피처 조회가 아니라 모델에 사용

에코시스템

Redis Feature Form — Redis의 자체 피처 엔지니어링 플랫폼. Python 정의 파일로 피처·라벨·피처 뷰를 정의하고, registered provider로 materialize하며, serve로 Redis에서 저지연 온라인 스토어로 서빙. quickstart 참고.
Python: Feast가 Redis를 일급 온라인 스토어 프로바이더로 제공 — Feast online_store 블록을 Redis 커넥션 문자열로 가리키면 RedisOnlineStore 백엔드가 materialization·서빙 처리
Compute: Apache Spark 배치 잡이 야간 materialization을 실행, Redis Feature Form / Feast materialize 명령이나 spark-redis 커넥터로 Redis에 기록
Streaming: Apache Flink나 Kafka Streams가 실시간 피처를 계산하고 필드별 HEXPIRE와 함께 HSET으로 Redis에 기록 — 각 스트리밍 신호가 자신의 신선도 창 유지
인프라: Kubernetes가 모델 서빙 컨테이너 옆에 Redis 파드를 공동 배치, 수평 파드 오토스케일링으로 추론 부하 추적; Redis Enterprise/Cloud의 Active-Active geo-distribution이 온라인 스토어를 지역 간 복제해 각 추론 클러스터 근처에서 저지연 읽기

더 알아보기 (Learn more)

사기 스코어링 모델용 Redis 온라인 피처 스토어를 직접 만드는 코드 예제: redis-py, node-redis, go-redis, Jedis, Lettuce, redis-rs, StackExchange.Redis, Predis, redis-rb — 배치 피처 벌크 로드, 필드별 TTL의 스트리밍 갱신, 단일 사용자 1ms 미만 조회, 수백 사용자 파이프라인 배치 읽기 데모 포함.
Redis Hashes — 엔티티 피처의 기본 구조.
Redis Search·Query — 피처 메타데이터 보조 인덱싱.