MLOps Pipeline

이 글에서 다루는 것 Feast 풀도입 이전 단계로, GitOps + Airflow를 사용해 피처 생성/버전화/재현성의 최소 요건(계약/메타/버전화)을 고정하는 Feature Store-lite 설계 선수지식 Triton 서빙 플랫폼 - dynamic_batching + instance_group 이 단계에서 해결하려는 문제 Feature Store는 “ML 성능"이 아니라 운영 안정성/재현성에서 먼저 갈립니다. “오늘 만든 feature.csv"가 아니라, 아래가 반드시 남아야 운영이 됩니다. 언제 생성됐는지 (generated_at) 어떤 스키마(계약)로 생성됐는지 (schema + schema_hash) 어떤 소스에서 생성됐는지 (source) 어떤 버전으로 저장됐는지 (version) 결과물이 어디 있는지 (feature_uri) Feature Store 도입을 고민하면 흔히 “Feast부터 써야 하나?“가 먼저 나오는데, 도구보다 먼저 피처 생성/버전화/재현 방식이 고정돼야 합니다. ...

에필로그 — “관측·알림·데이터까지 한 번에 이어지는 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 🔄 핵심 문장: ...

이 글에서 다루는 것 기존 v1 데이터 파이프라인에 버전 디렉터리 구조, schema.json, metadata.json, KST 타임라인을 얹어 ML Feature Store에 가까운 v2 파이프라인으로 고도화한 과정 선수지식 Observability 7단계: Data Pipeline 구축 이 단계에서 해결하려는 문제 이전 단계에서 S3 Raw에서 Feature CSV까지 동작하는 엔드투엔드 데이터 파이프라인(v1)을 만들었다. 하지만 실무 ML 플랫폼 입장에서는 “그때 그 실행에서 어떤 데이터를, 어떤 품질로, 어느 버전에 저장했는지"가 시간/버전/스키마/메타데이터까지 한 번에 남아야 한다. 이번 단계에서는 기존 v1 파이프라인을 버리지 않고, 그 위에 버전 디렉터리 구조 + schema.json + metadata.json + KST 타임라인을 얹어 실제 ML Feature Store에 더 가까운 v2 파이프라인으로 고도화했다. ...

이 글에서 다루는 것 S3 Raw 데이터를 Airflow DAG로 추출/검증/가공/저장하는 엔드투엔드 데이터 파이프라인을 구축하여 ML 학습 자동화의 데이터 레이어를 확보한 과정 선수지식 Observability 6단계: FastAPI Dashboard & Alert Library 이 단계에서 해결하려는 문제 모델의 성능은 결국 데이터 품질에서 결정된다. 그런데 데이터를 어떻게 추출하고, 검증하고, 가공하고, 저장하는지까지 자동화하지 않으면 MLOps는 완성되지 않는다. 이번 단계에서는 Raw S3에서 전처리, Feature 생성, 저장까지 이어지는 엔드투엔드 데이터 파이프라인을 직접 구축해 이후 MLflow 학습 자동화와 바로 연결될 데이터 레이어를 다졌다. ...

이 글에서 다루는 것 FastAPI ML 서빙 환경에서 장애를 즉시 감지하고 원인을 추적할 수 있는 대시보드 3종과 Alert Library 4종을 구축한 과정 선수지식 Observability 5단계: 운영 중 실제 이슈 & 해결 과정 이 단계에서 해결하려는 문제 FastAPI는 모델을 서빙하는 입구이자, 장애가 나면 가장 먼저 흔들리는 지점이다. A/B, Canary, 핫스왑 구조 위에서 문제가 생기면 바로 감지되고 원인을 바로 찾을 수 있는 관측 체계가 필요하다. 이번 단계에서는 실제 운영 수준의 FastAPI Observability Dashboard와 Alert Library를 구축한다. ...

이 글에서 다루는 것 dev/prod 완전 분리된 Loki + Promtail 로그 파이프라인을 구축하고, LogQL 기반으로 FastAPI/Airflow 로그를 중앙에서 조회할 수 있는 구조를 만드는 과정을 다룹니다. 선수지식 Observability 3단계: Prometheus/KSM/Kubelet 완전 분리 구조 이 단계에서 해결하려는 문제 운영형 MLOps에서 가장 위험한 장애는 모델이 아닌 로그가 안 보이는 순간이다. FastAPI, MLflow, Airflow가 모두 돌아가도, 로그가 한 번 섞이거나 누락되면 장애 원인을 찾지 못해 운영 자체가 멈춰버린다. dev/prod를 완전히 분리한 Loki + Promtail 로그 파이프라인을 구축해, 모델 핫스왑, 에러 패턴, API 이상 징후까지 한눈에 보이도록 만든다. ...

이 글에서 다루는 것 dev/prod 간 메트릭이 교차 수집되는 문제를 라벨 기반으로 완전 분리하고, Prometheus TSDB를 local-path로 전환하여 성능과 안정성을 개선하는 과정을 다룹니다. 선수지식 Observability 2단계: Alertmanager Slack & 트러블슈팅 이 단계에서 해결하려는 문제 dev와 prod는 분리돼 있어야 하는데, 정작 관측 데이터에서는 서로 섞여 보이는 문제가 계속 생겼다. Prometheus/KSM/Kubelet의 라벨과 셀렉터가 조금만 어긋나도 dev에서 prod 메트릭을 읽는 심각한 혼선이 발생한다. 이번 단계에서는 관측 스택을 라벨 기반으로 완전히 절단하는 데 집중한다. 그리고 TSDB는 로컬 디스크로 옮겨 속도와 안정성을 끌어올리고, NFS는 나머지 관측 도구 전용으로 재정비한다. ...

이 글에서 다루는 것 Alertmanager 설정을 SealedSecret으로 관리하고, dev/prod 각각의 Slack 채널로 알람이 정확히 흐르는 관측 파이프라인을 완성하는 과정을 다룹니다. 선수지식 Observability 1단계: kube-prometheus-stack + GitOps 구축 이 단계에서 해결하려는 문제 모델이 잘 학습되고 잘 배포되는 것보다, 문제가 생겼을 때 즉시 감지되는 것이 더 중요할 때가 많다. dev/prod 각각에서 알람이 정확한 Slack 채널로, 깨짐 없이 흐르는 관측 파이프라인을 먼저 완성해야 한다. 이 기반이 갖춰져야 이후 FastAPI 지연, 핫스왑 실패, DAG 에러 같은 운영형 MLOps 이벤트를 실시간으로 감지할 수 있다. ...

🧠 Proof of Automation — 작동 검증 루프 하나의 커밋으로 CI → CD → 학습/등록 → READY → 핫스왑 → 실험 → 관제까지 자동화되었음을 시각적으로 증명합니다. 🧭 목차 # 섹션 0 준비 (CI/CD·GitOps·Secrets 기본 세팅) 1 CI 실행 (GitHub Actions) 2 ArgoCD 자동 동기화 3 Airflow 학습→등록→READY (FAIL/SUCCESS + Slack) 4 MLflow 모델 등록·별칭·아티팩트 5 FastAPI 핫스왑 (/reload) 6 수동 롤백 (운영 복구 가드레일) 7 로그 계층 (Airflow=S3 / FastAPI=NFS) 8 ArgoCD↔Slack 운영 관제 9 보안 자동화 (AWS Rotation + SealedSecrets Re-seal) 10 트래픽 실험 (A/B · Canary · Blue-Green) 11 One-Commit Flow 전체 체인 검증 0) 🧰 준비 (GitOps) charts/fastapi/values/{dev,prod}.yaml에서 ALIAS_SELECTION_MODE/DEFAULT_ALIAS/CANARY_PERCENT 값을 시나리오별로 수정 → git commit → git push (테스트 스크립트) /ops/ab_test.sh 저장 (아래 제공) 1) 🧪 CI 진입 (GitHub Actions) ...

에필로그 — “한 번의 커밋으로 끝까지 가는 자율형 MLOps 플랫폼” 📌 전체 경로 요약 순서 주제 0 🔗 FastAPI A/B·Canary·Blue-Green 서빙 베이스 1 🔗 핫스왑 고도화 (/reload 보안·DAG 자동화) 2 🔗 Slack Alert 통합 (FastAPI·Airflow 공용) 3 🔗 모델 롤백 자동화 (등록 실패 대비 복구) 4 🔗 FastAPI 로그 안정화 (NFS + PV/PVC + Loguru) 5 🔗 Airflow 안정화 & FastAPI HTTPS 보안 6 🔗 GitOps 고도화 (Argo CD·MetalLB·ApplicationSet) 7 🔗 Argo CD Notifications 자동화 (Slack 연동) 8 🔗 CI/CD 운영 자동화 (GitHub Actions·Helm Lint) 9 🔗 시크릿 관리 & 키 회전 자동화 (AWS·SealedSecret) 10 🔗 검증 (Proof of Automation) 🎯 전체 회고 요약 (0~9단계) 단계 핵심 목표 주요 개선점 0 FastAPI 리뉴얼 /predict·/variant·/reload로 A/B·Canary·Blue-Green 공용 라우팅 1 핫스왑 보안/자동화 토큰 인증 /reload + Ingress 화이트리스트/TLS 2 Slack Alert 통합 FastAPI·Airflow 공용 알림 함수 + 실패 콜백 Slack 연동 3 롤백 자동화 등록 실패 시 이전 버전 롤백 + READY 후 자동 /reload 4 로그 안정화 FastAPI=NFS, Airflow=S3 로그 계층 분리·표준화 5 Airflow 안정화·HTTPS Sensor/의존성 정리 + cert-manager 기반 TLS 6 GitOps 전환 MetalLB + SealedSecret + ApplicationSet 배포 구조 7 GitOps 모니터링 ArgoCD → Slack Sync/Health 상태 알림 8 CI/CD 고도화 Helm Lint + kubeconform + yamllint PR/머지 파이프라인 9 SecretOps 표준화 AWS Key Rotation + SealedSecret Re-seal 자동화 🔄 핵심 ...