Airflow

이 글에서 다루는 것 DagBag 기반 test_dag_integrity.py로 DAG 파싱 오류·핵심 task 존재·운영 설정을 배포 전에 자동 검증하고, GitHub Actions로 push 시점에 CI를 실행하는 구조를 다룹니다. 선수지식 Airflow 6단계: KubernetesExecutor 선택 이유 — CeleryExecutor 대비 장단점 분석 이 단계에서 해결하려는 문제 DAG 파일에 오타가 하나 들어가면 Airflow Scheduler가 파싱 오류를 감지하고 해당 DAG을 비활성화한다. 문제를 발견하는 것은 배포 후 수십 분이 지난 시점이다. 이 비용을 push 시점으로 앞당겨서 파싱 오류를 운영 전에 잡는 구조를 만든다. ...

이 글에서 다루는 것 Airflow Executor 세 종류를 비교하고, MLOps 파이프라인에서 KubernetesExecutor를 선택한 이유와 RBAC·pod_template·KPO 실전 구성을 다룹니다. 선수지식 MLOps 운영 고도화 9단계: 시크릿 관리 & 키 회전 자동화 — SealedSecret + AWS 키 로테이션 이 단계에서 해결하려는 문제 Airflow를 Kubernetes 위에 올리면 Executor 선택이 필요하다. LocalExecutor, CeleryExecutor, KubernetesExecutor 중에서 MLOps 파이프라인에 가장 적합한 것을 선택하는 것은 단순한 설치 옵션이 아니라 운영 구조에 대한 결정이다. Task 격리, 동적 리소스 할당, Broker 관리 비용을 기준으로 판단한다. ...

이 글에서 다루는 것 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 이 구조는 실험 환경에서는 충분히 동작합니다. 하지만 운영 환경에서는 몇 가지 중요한 문제가 생깁니다. 예를 들어 다음 상황을 생각해볼 수 있습니다. ...

GitOps로 계약 배포 + Airflow 버전화/Latest 저장 + Feast 조회까지 E2E 증명 🧭 목차 구분 증명 포인트 A. GitOps 분리 dev·prod 독립 배포 + 상태 고정(Synced/Healthy) B. Contract 고정 계약(schema / repo)을 운영 리소스로 배포·마운트 C. 파이프라인 Airflow DAG E2E 성공 D. 저장 정책 S3 version 1단 + latest 동시 유지 E. 재현성 schema_hash·metadata로 생성 조건 기록 F. Feast 검증 s3fs → materialize → online 조회 성공 이 글은 설명이 아니라 증거(Proof)만 남깁니다. ...

이 글에서 다루는 것 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 즉, “저장하는 파이프라인” -> “조회 가능한 피처 플랫폼"으로 확장하는 단계입니다. ...

이 글에서 다루는 것 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부터 써야 하나?“가 먼저 나오는데, 도구보다 먼저 피처 생성/버전화/재현 방식이 고정돼야 합니다. ...

🧭 목차 구분 증명 포인트 A. Observability 메트릭·로그·알람 dev/prod 완전 분리 B. FastAPI & Platform Observability FastAPI + Platform 대시보드 정상 동작 C. Data Pipeline Raw→Feature ETL 자동 실행 성공 D. Data Pipeline Advanced 버전·스키마·메타데이터·관측 등 운영형 구조 A. Observability 계층 Observability 계층(모니터링 + 로그 수집 + 알람)이 GitOps 기반으로 dev/prod 완전 분리 + 자동화 되어 있음을 증명합니다. 1️⃣ ArgoCD Applications (GitOps 기반 구성) ✔ 1-1. CLI로 전체 Application 상태 확인 kubectl -n argocd get applications ...

에필로그 — “관측·알림·데이터까지 한 번에 이어지는 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 파이프라인으로 고도화했다. ...