MLflow

이 글에서 다루는 것 MLflow 2.x의 alias 기반 모델 버전 관리로 Champion/Challenger 패턴을 구현하고, FastAPI와 연동한 zero-downtime hot swap 구조를 설계하는 과정 선수지식 Feature Store & Feast - Feast 이 단계에서 해결하려는 문제 MLflow 2.x부터 Staging/Production Stage가 deprecated됩니다. 대신 Registered Model Alias 방식이 공식 권장 패턴이 되었습니다. 이 변화는 단순한 API 교체가 아닙니다. 모델 버전 관리의 책임 구조가 바뀌는 것입니다. 이 글은 Stage 방식의 한계를 분석하고, alias 기반 Champion/Challenger 패턴과 FastAPI와 연동한 zero-downtime hot swap 구조를 설명합니다. ...

이 글에서 다루는 것 모델 등록(MLflow)과 서빙 반영(Triton + FastAPI)을 분리한 구조, explicit 모드, FastAPI Reload API, 확장 전략(replica/batching), Feature Store 연동 패턴 선수지식 GitOps 기반 E2E ML Platform - 모델 반영 제어 MLflow + Triton + FastAPI 등록과 서빙 반영을 분리한 이유 들어가며 ML 시스템을 처음 구축할 때 흔히 다음과 같은 구조를 사용합니다. Train ↓ MLflow Register ↓ Deploy 즉, 모델 등록과 서빙 반영이 거의 같은 단계로 취급됩니다. 이 방식은 간단하고 구현하기 쉽습니다. ...

이 글에서 다루는 것 Drift Gate의 KS statistic 기반 검증, Promotion/Shadow 분기 정책, FastAPI 트래픽 분기(Mirror/Split) 전략 선수지식 GitOps 기반 E2E ML Platform - 운영 환경 반영 제어 Drift Gate / Promotion / Shadow 검증된 변경만 운영 경로에 올림 들어가며 모델 학습 파이프라인을 만들다 보면 다음 질문이 자연스럽게 등장합니다. 어떤 모델을 운영 환경에 반영할 것인가? 많은 프로젝트에서는 다음 기준을 사용합니다. accuracy >= threshold 하지만 운영 환경에서는 이 기준만으로는 충분하지 않습니다. ...

이 글에서 다루는 것 E2E 파이프라인 전체 구조, DAG 레벨 에러 처리(SLA/on_failure_callback), SSOT 패턴(ids.py/policy.py), Promotion/Shadow 분기, Rollback 구조 선수지식 GitOps 기반 E2E ML Platform - 토글 구조 E2E DAG: 학습 성공이 곧 운영 반영을 의미하지 않도록 설계 들어가며 많은 머신러닝 파이프라인은 다음과 같은 형태를 가집니다. Train → Register → Deploy 이 구조는 실험 환경에서는 충분히 동작합니다. 하지만 운영 환경에서는 몇 가지 중요한 문제가 생깁니다. 예를 들어 다음 상황을 생각해볼 수 있습니다. ...

이 글에서 다루는 것 Optional 레이어(Feature Store)를 실제로 ON/OFF하면서 Core 시스템이 독립적으로 동작하는지 검증하는 과정 선수지식 GitOps 기반 E2E ML Platform - GitOps 구조 Optional ON/OFF 확장 기능을 비파괴적으로 붙였다 떼는 구조 들어가며 ML 플랫폼을 설계하다 보면 자연스럽게 다음 질문이 등장합니다. Feature Store를 붙일까? 데이터 파이프라인 시스템을 추가할까? 추가 실험 플랫폼을 도입할까? 이런 시스템들은 대부분 유용합니다. 하지만 동시에 다음과 같은 문제를 가져올 수 있습니다. 플랫폼 복잡도 증가 시스템 의존성 증가 장애 전파 범위 확대 예를 들어 Feature Store를 Core 시스템에 강하게 연결하면 ...

이 글에서 다루는 것 MLflow Registry를 단일 소스로 삼아 Airflow DAG에서 Triton에 모델을 자동 배포하고, 검증 체인(load/ready/infer) 통과 후에만 운영 확정하며, 실패 시 자동 롤백하는 파이프라인을 구축한 과정 선수지식 Triton 서빙 플랫폼 - Triton 구축 이 단계에서 해결하려는 문제 실무 환경에서 모델 배포는 “새 모델을 올리는 작업"이 아니라 “현재 운영 상태를 안전하게 갱신하는 상태 전이(State Transition)“에 가깝다. 이번 단계에서는 MLflow Registry를 단일 소스로 삼아 Triton Inference Server에 모델을 자동 배포하고, 로딩/헬스 체크/실제 추론 검증을 모두 통과한 경우에만 운영 모델을 확정(commit)하며, 중간 단계에서 하나라도 실패하면 이전 운영 상태로 자동 복구되는 최소 롤백 구조를 구현했다. ...

에필로그 — “관측·알림·데이터까지 한 번에 이어지는 MLOps 운영 플랫폼” 📌 전체 경로 요약 순서 주제 1 🔗 kube-prometheus-stack + GitOps 구축 2 🔗 Alertmanager Slack & 트러블슈팅 3 🔗 Prometheus/KSM/Kubelet 완전 분리 구조 4 🔗 Loki/Promtail 로그 파이프라인 구축 5 🔗 운영 중 발생한 실제 이슈 & 해결 과정 6 🔗 FastAPI Observability Dashboard & Alert Library 7 🔗 Data Pipeline 구축 8 🔗 Data Pipeline 고도화 9 🔗 검증 🎯 전체 회고 요약 단계 핵심 목표 주요 개선점 1 모니터링 뼈대 구축 kube-prometheus-stack dev/prod 완전 분리 2 Slack 알람 통합 Alertmanager configSecret 표준화 + 알람 라우팅 3 메트릭 교차 수집 제거 KSM/Kubelet 라벨 통일, Prometheus TSDB local-path 4 로그 파이프라인 완성 Loki/Promtail dev/prod 분리 + LogQL Range Query 5 실제 운영 이슈 해결 라벨/Secret/NFS 권한/NFS unmount 문제 일괄 해결 6 FastAPI/Platform 관측 대시보드 FastAPI 서비스 + Kubernetes/Node 플랫폼 관측 체계 완성 7 Data Pipeline 구축 (v1) S3 Raw → Feature ETL 자동화 (Airflow DAG) 8 Data Pipeline 고도화 (v2) 버전·스키마·메타데이터 자동화 + 관측 대시보드 9 검증 Observability 계층, Grafana 대시보드, Datapipeline 🔄 핵심 문장: ...

이 글에서 다루는 것 Airflow Sensor를 reschedule 모드로 리팩토링하고 성공 체인을 보장하는 DAG 구조를 만들고, FastAPI에 cert-manager 기반 TLS + IP 화이트리스트를 적용하는 과정을 다룹니다. 선수지식 MLOps 운영 고도화 7단계: ArgoCD Notifications 자동화 — 배포 상태 Slack 자동 알림 이 단계에서 해결하려는 문제 모델을 등록하는 것보다 더 중요한 건 언제 Reload가 실행되느냐이다. 등록 실패나 READY 미도달 상태에서 /reload가 실행되면 잘못된 모델이 서빙될 수 있다. Airflow 흐름을 한 번 더 단단히 조이고, FastAPI 쪽은 HTTPS·화이트리스트까지 적용해 안전하게 자동화된다는 확신을 주는 구조를 만든다. ...

이 글에서 다루는 것 모델 등록 실패 시 이전 안정 버전으로 자동 롤백하고 FastAPI에 즉시 반영하는 복구 루프와, 운영자가 명시적으로 버전을 지정하는 수동 롤백 DAG을 구축하는 과정을 다룹니다. 선수지식 MLOps 운영 고도화 2단계: Slack Alert 통합 — 파이프라인 알림 자동화 이 단계에서 해결하려는 문제 모델 배포는 성공했을 때보다, 실패했을 때의 회복 속도가 운영 품질을 결정한다. 등록이 실패하는 즉시 이전 안정 버전으로 돌아가 FastAPI에 자동 반영되는 완전한 롤백 루프를 구축해야 한다. 이 구조가 있어야 장애 상황에서도 서비스가 끊기지 않고 바로 복구될 수 있다. ...

이 글에서 다루는 것 /reload 엔드포인트에 3중 보안(토큰·IP 화이트리스트·TLS)을 적용하고, Airflow DAG으로 학습→등록→감시→핫스왑 전체 시퀀스를 자동화하는 과정을 다룹니다. 선수지식 MLOps 운영 고도화 0단계: FastAPI A/B·Canary·Blue-Green 서빙 베이스 — 멀티 모델 라우팅 기반 설계 이 단계에서 해결하려는 문제 모델을 잘 학습시키는 것도 중요하지만, 잘못된 모델이 실수로 핫스왑되는 순간이 더 치명적이다. /reload를 확실하게 잠그고, 학습→등록→감시→핫스왑까지가 Airflow에서 자동으로 흘러가도록 만들어야 한다. 이 단계가 완성돼야 이후 단계에서 안전한 자동 운영(MLOps)을 구현할 수 있다. ...