Skip to content
Published on

AI Platform Feature Store 동기화 설계

🇰🇷KO🇺🇸EN🇯🇵JA
Authors
  • Name
    Twitter
AI Platform Feature Store 동기화 설계

문제 정의

Feature Store 동기화와 Kubeflow-KServe 스택의 공통 실패 지점은 오프라인/온라인 불일치를 운영 후반에 발견하는 것이다. 학습-서빙 parity를 초기 설계로 강제해야 한다.

아키텍처/원리

  • 이벤트 기반 CDC + 스트리밍 머티리얼라이즈로 온라인 피처 최신성 보장.
  • 학습 파이프라인에서 사용한 변환 로직을 피처 뷰로 재사용.
  • 서빙 계층은 모델 버전과 피처 버전을 동시에 pinning.

구현 예시 1

feature_store:
  offline_store: bigquery
  online_store: redis
  sync:
    source: kafka_cdc
    freshness_sla_sec: 300
    backfill_window_days: 7

구현 예시 2

def check_point_in_time(entity_ts, feature_ts):
    if feature_ts > entity_ts:
        raise ValueError("leakage detected")
    return True

구현 예시 3

SELECT entity_id, max(event_ts) AS latest, now()-max(event_ts) AS lag
FROM online_feature_events
GROUP BY entity_id
HAVING now()-max(event_ts) > interval '5 minutes';

구현 예시 4

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: model-with-feature-view
spec:
  predictor:
    model:
      modelFormat:
        name: sklearn
    env:
      - name: FEATURE_VIEW_VERSION
        value: v2026_03_04

운영 팁

  • 학습셋 생성 시 point-in-time join 검증을 CI에 넣는다.
  • 온라인 피처 freshness SLA를 알람 지표로 승격한다.
  • 모델 배포와 피처 스키마 변경을 원자적으로 승인한다.

트러블슈팅

  1. 온라인 추론값과 오프라인 재현 불일치: feature transformation 코드 중복 제거.
  2. backfill 후 품질 급락: time-travel 기준시점 오류 점검.
  3. 서빙 5xx 급증: 피처 조회 타임아웃/서킷브레이커 적용.

체크리스트

  • point-in-time join 테스트
  • freshness SLA 대시보드
  • feature schema contract 테스트
  • 모델/피처 버전 동시 롤백 절차
  • backfill 런북

결론

AI 플랫폼의 핵심은 모델이 아니라 데이터 일관성이다. Feature Store parity를 못 지키면 MLOps 자동화는 의미가 없다.

참고 자료

Discuss on Twitter • View on GitHub