MLOps Pipeline

이 글에서 다루는 것 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 구조를 설명합니다. ...

이 글에서 다루는 것 k6 부하 테스트로 Triton + FastAPI 서빙 성능을 실측 검증: 136 RPS, p95 553ms, 에러율 0% (CPU-only 3노드 클러스터) 선수지식 GitOps 기반 E2E ML Platform - 운영 문서화 Load Test: 서빙 성능 검증 실제로 얼마나 버티는가 들어가며 이 시리즈에서 지금까지 다음을 확인했습니다. Triton READY Model Repository Loaded FastAPI Health OK Reload API Success Metrics Exported 하지만 여기서 중요한 질문이 하나 더 남습니다. 실제 트래픽이 들어왔을 때 이 시스템이 버티는가? ...

이 글에서 다루는 것 CPU-only 환경에서 Triton의 dynamic_batching과 instance_group 설정으로 처리량을 높이고 latency를 안정화하는 성능 최적화 과정 선수지식 Triton 서빙 플랫폼 - Alerting 운영 표준 매뉴얼 이 단계에서 해결하려는 문제 Triton을 올리고 모델이 READY 상태가 되면 끝일까? 기본 설정만 사용하면 요청이 하나씩 순서대로 처리됩니다. 동시 요청이 몰리면 큐가 쌓이고, latency가 급격히 올라갑니다. 이 글은 dynamic_batching과 instance_group 설정으로 CPU 환경에서 처리량을 높이고 latency를 안정화한 과정을 설명합니다. 🎯 핵심 요약 기본 설정의 한계: single instance + no batching -> 요청 직렬 처리 instance_group: CPU 인스턴스 수 증가 -> 병렬 추론 처리 dynamic_batching: 요청 자동 묶음 -> 배치 단위 추론으로 처리량 향상 적용 시점: explicit mode에서는 model load 시 config.pbtxt 반영 실측 결과: 136 RPS, p95 553ms, 에러율 0% (100 VU, CPU-only 3노드) 1️⃣ 기본 설정만으로는 무엇이 부족한가 Triton을 처음 실행하면 기본 동작은 다음과 같습니다. ...

이 글에서 다루는 것 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 관리 비용을 기준으로 판단한다. ...

이 글은 GitOps 기반 E2E ML Platform이 구조적으로 분리되어 있고, 실제로 동작하며, 운영 관측과 복구까지 가능한 상태임을 캡처와 실행 결과로 검증하는 기록입니다. 🧭 목차 # 섹션 0 준비 1 GitOps 경계 검증 2 Core-only 검증 3 Optional ON 검증 4 Airflow E2E DAG 실행 검증 5 Serving Runtime 검증 6 Observability 검증 7 운영 문서 / Proof 구조 검증 8 최종 결론 0) 🧰 준비 이번 검증은 다음 기준으로 진행했습니다. ...

📌 전체 시리즈 경로 순서 주제 0 GitOps 기반 ML Platform을 설계한 이유 1 Core / Baseline / Optional 아키텍처 2 ArgoCD AppProject / AppSet 경계 3 Optional ON/OFF 확장 구조 4 E2E DAG와 운영 반영 분리 5 Drift Gate · Promotion · Shadow 6 MLflow · Triton · FastAPI 서빙 구조 7 Serving Runtime 동작 확인 8 Observability · Rollback (Auto / Manual) 9 Runbook · Security · Proof 문서 구조 10 부하 테스트 (k6 · Triton + FastAPI) 11 최종 검증 (Proof of Platform) 🙌 프로젝트 GitHub 저장소 GitHub 코드: [GitOps] mlops-platform DAG 코드: [DAG] airflow-dags 📊 Impact Summary 지표 Before After 비고 모델 배포 소요 시간 수동 ~40분 DAG 자동화 ~13분 약 68% 단축 장애 감지 수동 대시보드 확인 Prometheus 60초 윈도우 내 SLO 위반 자동 감지 자동 롤백 수동 대응 5~15분 smoke test ~35초, observe ~95초 자동 복구 로컬 1-replica 미검증 모델 차단 없음 Drift Gate + Shadow 분기 100% 차단 20/20 시나리오 Shadow 격리 없음 프로덕션 무영향 10/10 검증 완료 성능 검증 (k6 부하 테스트) ...

이 글에서 다루는 것 Runbook / Security / Proof / Audit 운영 문서 구조와 Proof 파일 생성 방식 선수지식 GitOps 기반 E2E ML Platform - 운영 제어 구조 운영 문서화 Runbook / Security / Proof 디렉토리까지 남긴 이유 들어가며 많은 프로젝트는 다음 단계에서 멈춥니다. 코드 작성 README 작성 하지만 실제 운영 환경에서는 다음 문제가 발생합니다. 서비스 장애 발생 운영자가 시스템 구조를 모름 복구 절차 문서 없음 보안 정책 위치 불명확 이 경우 시스템이 아무리 잘 만들어져 있어도 ...

이 글에서 다루는 것 Prometheus 기반 Observability 구조, Auto Rollback 정책(error rate/latency/service health), Manual Rollback DAG, 관측 실패 시 정책 선수지식 GitOps 기반 E2E ML Platform - 실제 동작 확인 Observability / Auto Rollback / Manual Rollback 배포보다 중요할 수 있는 운영 제어 들어가며 ML 시스템을 구축할 때 많은 관심이 다음 단계에 집중됩니다. Train Register Deploy 하지만 실제 운영 환경에서는 배포 이후에 더 중요한 문제가 발생합니다. 예를 들어 다음 상황을 생각해볼 수 있습니다. ...

이 글에서 다루는 것 Triton READY 상태, Model Repository, FastAPI health/models/reload API, Metrics endpoint를 실제 실행 결과(Proof)로 검증 선수지식 GitOps 기반 E2E ML Platform - 모델 등록/서빙 반영 분리 Serving Runtime Proof 실제로 READY / Reload / Metrics까지 살아 있는가 들어가며 지금까지 이 시리즈에서는 다음을 설명했습니다. ML 플랫폼 구조 GitOps 환경 설계 Optional 레이어 분리 E2E 파이프라인 Drift Gate / Promotion 전략 MLflow + Triton + FastAPI 서빙 구조 하지만 여기서 중요한 질문이 하나 남습니다. ...