[Feature Store & Feast - Feast] | 🏔️ MLOps Journey

이 글에서 다루는 것

Feature Store-lite 위에 Feast를 얹어, S3 Offline + Redis Online + Feature Server 구성으로 “저장하는 파이프라인"을 “조회 가능한 피처 플랫폼"으로 확장하는 과정

선수지식

Feature Store & Feast - Feature Store-lite

이 단계에서 해결하려는 문제

이전 글(Feature Store-lite)에서 계약(스키마/메타) + 버전화 저장 + 재현성까지 고정했습니다.

하지만 실무에서는 “저장"에서 끝나지 않습니다. 결국 중요한 건 조회 가능(Serving-ready) 상태입니다.

이번 글은 Feature Store-lite 위에 Feast를 얹어 아래를 완성합니다.

Offline Source: S3의 latest/features.parquet (Feast가 읽는 고정 포인터)
Registry: S3에 registry.pb 저장(환경별 분리)
Online Store: Redis 적재(materialize)로 온라인 조회 가능
Feature Server: 상시 서비스 + startup 시 feast apply

즉, “저장하는 파이프라인” -> “조회 가능한 피처 플랫폼"으로 확장하는 단계입니다.

🎯 완료 기준

GitOps로 Feast 계약(repo.py/feature_store.yaml) 배포
Airflow로 S3에 version 유지 + latest overwrite 저장
Feast materialize 실행 -> Redis online 적재
Feast SDK로 online 조회 결과가 None이 아닌 실제 값으로 확인

1️⃣ 전체 구조

2️⃣ 코드/리소스 트리

(A) GitOps (mlops-infra-gitops)

charts/
  feast/
    templates/
      feast-repo-configmap.yaml
      feast-server-deployment.yaml
      feast-server-service.yaml
      redis-deployment.yaml
      redis-service.yaml
    values/
      base.yaml
      dev.yaml
      prod.yaml

apps/
  feast-dev.yaml
  feast-prod.yaml
# ... (sealed-secrets 생략)

(B) Airflow (airflow-dags-dev)

dags/
  dag_data_pipeline_daily_dev_v5.py
  mlops_lib/
    dp/
      build.py
      store.py
  .airflowignore

3️⃣ 설계 포인트 (운영 관점)

(1) Feast repo 자체를 “계약(Contract)“으로 취급

Feast에서 실질적인 계약은 repo.py + feature_store.yaml입니다. 이걸 ConfigMap으로 GitOps 배포하면:

dev/prod에서 동일 계약 유지
코드 수정 없이 배포/롤백 가능
“운영 리소스"로 추적 가능

(2) S3 저장 정책은 “버전 + latest 포인터"로 끝낸다

.../<feature_set>/<version>/ : 재현성
.../<feature_set>/latest/ : 운영 편의

Feast Offline은 latest만 읽으면 되기 때문에, 사용자는 버전을 몰라도 됩니다. 버전은 “재현"이 필요할 때만 꺼내 쓰는 구조가 가장 단단합니다.

(3) Airflow는 생성/저장까지만, Online 적재는 Feast가 담당

Airflow 이미지에 feast/pyarrow/s3fs까지 얹기 시작하면 운영 난이도가 급상승합니다. 그래서 역할을 나눴습니다.

Airflow: feature 생성 + S3 저장(버전/latest)
Feast: materialize + online(redis) 적재 + 조회

4️⃣ GitOps: Feast 배포 (Redis + Feature Server + Repo ConfigMap)

4-1) values (base/dev/prod)

# charts/feast/values/base.yaml
aws:
  region: ap-northeast-2
  credentialsSecretName: aws-credentials

s3:
  bucket: datapipeline-raw-data-keonho
  featurePrefix: feature-store/user_features
  registryPrefix: feast

feastServer:
  image: hoizz/feast-server:0.40.1-s3fs
  port: 6566

redis:
  image: redis:7.2-alpine
  persistence: true

4-2) Feast repo ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: feast-repo
  namespace: {{ .Release.Namespace }}
data:
  feature_store.yaml: |
    project: feature_store_{{ .Values.env }}
    registry:
      path: s3://{{ .Values.s3.bucket }}/{{ .Values.s3.registryPrefix }}/{{ .Values.env }}/registry.pb
    provider: local
    offline_store:
      type: file
    online_store:
      type: redis
      connection_string: redis.{{ .Release.Namespace }}.svc.cluster.local:6379
    entity_key_serialization_version: 2

  repo.py: |
    from datetime import timedelta
    from feast import Entity, FeatureView, Field
    from feast.infra.offline_stores.file_source import FileSource
    from feast.types import Int64, Float64

    user_features_source = FileSource(
        path="s3://{{ .Values.s3.bucket }}/{{ .Values.s3.featurePrefix }}/latest/features.parquet",
        timestamp_field="event_timestamp",
    )
    # ... (Entity, FeatureView 정의 생략)

4-3) Feast 서버 Deployment (subPath + sh 호환 + startup apply)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: feast-server
  namespace: {{ .Release.Namespace }}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: feast-server
  template:
    spec:
      containers:
        - name: feast-server
          image: {{ .Values.feastServer.image }}
          volumeMounts:
            - name: feast-repo
              mountPath: /feast-repo/feature_store.yaml
              subPath: feature_store.yaml
              readOnly: true
            - name: feast-repo
              mountPath: /feast-repo/repo.py
              subPath: repo.py
              readOnly: true
            # ... (aws-credentials mount 생략)
          command: ["/bin/sh","-c"]
          args:
            - |
              set -eux
              cd /feast-repo
              feast apply
              feast serve --host 0.0.0.0 --port 6566
      # ... (volumes 생략)

5️⃣ s3fs 포함 Feast 이미지 준비 (필수)

Feast materialize가 S3 parquet를 읽으려면 s3fs가 필요합니다.

FROM feastdev/feature-server:0.40.1
RUN pip install --no-cache-dir s3fs fsspec

docker build -t hoizz/feast-server:0.40.1-s3fs .
docker push hoizz/feast-server:0.40.1-s3fs

6️⃣ Airflow: “버전화 저장 + latest overwrite” (parquet 기준)

Feast는 Offline을 latest/features.parquet로 고정해 읽기 때문에, Airflow가 latest를 매번 갱신해줘야 합니다.

(1) DAG: 흐름만 담당

# dags/dag_data_pipeline_daily_dev_v5.py (요약)
with DAG(
    dag_id="data_pipeline_daily_dev_v5",
    default_args=DEFAULT_ARGS,
    start_date=datetime(2026, 1, 1),
    schedule="0 0 * * *",
    catchup=False,
    tags=["dp", "feature-store"],
) as dag:
    t_build = PythonOperator(task_id="build_features", python_callable=build_features)
    t_store = PythonOperator(
        task_id="store_features",
        python_callable=store_features,
        # ... (op_kwargs 생략)
    )

    t_build >> t_store

(2) build: parquet/csv + event_timestamp 보장

Feast 기준: event_timestamp 필수
build 단계에서 Feast 요구사항을 충족시키면 파이프라인이 안정해집니다.

(3) store: version + latest 동시 저장(4파일 세트)

.../<feature_set>/<version>/ 저장 (재현성)
.../<feature_set>/latest/ overwrite (운영 편의)
동일 prefix에 parquet/csv/schema/metadata를 묶어서 저장

7️⃣ Feast 운영/검증 루틴 (성공 체크)

7-1) s3fs 포함 여부 확인

POD=$(kubectl -n feature-store-dev get pod -l app=feast-server \
  -o jsonpath='{.items[0].metadata.name}')
kubectl -n feature-store-dev exec -it "$POD" -- sh -lc '
python - << "PY"
import s3fs, fsspec
print("s3fs OK:", s3fs.__version__)
PY
'

7-2) materialize 실행 (예: 최근 2일)

kubectl -n feature-store-dev exec -it "$POD" -- sh -lc '
cd /feast-repo
feast materialize \
  "$(date -u -d "2 days ago" +%Y-%m-%dT%H:%M:%S)" \
  "$(date -u +%Y-%m-%dT%H:%M:%S)"
'

7-3) online 조회 확인

kubectl -n feature-store-dev exec -it "$POD" -- sh -lc '
python - << "PY"
from feast import FeatureStore
store = FeatureStore("/feast-repo")
resp = store.get_online_features(
  features=["user_features:f_total_events_7d"],
  entity_rows=[{"user_id": 1001}],
)
print(resp.to_df())
PY
'

8️⃣ 트러블슈팅

ConfigMap 전체 mount로 repo가 꼬임 -> subPath로 파일만 마운트
/bin/sh에서 pipefail 깨짐 -> set -eux로 고정
materialize 시 “Install s3fs” 오류 -> s3fs 포함 커스텀 이미지로 교체
image repo 이름 오타로 ErrImagePull -> values/base.yaml의 image repo 정확히 교정

설계 판단 (Why This Way?)

스키마·버전화가 선행된 상태에서 Feast를 조회 계층으로만 추가하여 도입 범위를 최소화했고, latest 고정 경로 + version 디렉토리 이중 구조로 Feast 설정 변경 없이 최신 피처 접근과 재현성을 동시에 확보했습니다. Airflow와 Feast의 역할을 분리하여 이미지 의존성 충돌과 장애 범위를 격리했습니다.

다음에 읽을 글

→ MLflow Model Registry: alias 기반 모델 버전 관리 — promotion/shadow alias 전략

이 글에서 다루는 것#

선수지식#

이 단계에서 해결하려는 문제#

🎯 완료 기준#

1️⃣ 전체 구조#

2️⃣ 코드/리소스 트리#

(A) GitOps (mlops-infra-gitops)#

(B) Airflow (airflow-dags-dev)#

3️⃣ 설계 포인트 (운영 관점)#

(1) Feast repo 자체를 “계약(Contract)“으로 취급#

(2) S3 저장 정책은 “버전 + latest 포인터"로 끝낸다#

(3) Airflow는 생성/저장까지만, Online 적재는 Feast가 담당#

4️⃣ GitOps: Feast 배포 (Redis + Feature Server + Repo ConfigMap)#

4-1) values (base/dev/prod)#

4-2) Feast repo ConfigMap#

4-3) Feast 서버 Deployment (subPath + sh 호환 + startup apply)#

5️⃣ s3fs 포함 Feast 이미지 준비 (필수)#

6️⃣ Airflow: “버전화 저장 + latest overwrite” (parquet 기준)#

(1) DAG: 흐름만 담당#

(2) build: parquet/csv + event_timestamp 보장#

(3) store: version + latest 동시 저장(4파일 세트)#

7️⃣ Feast 운영/검증 루틴 (성공 체크)#

7-1) s3fs 포함 여부 확인#

7-2) materialize 실행 (예: 최근 2일)#

7-3) online 조회 확인#

8️⃣ 트러블슈팅#

설계 판단 (Why This Way?)#

다음에 읽을 글#