Projects

이 글은 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 부하 테스트) ...

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는 ‘피처 생성’이 아니라 운영 재현성의 기준 📌 시리즈 전체 경로 요약 순서 주제 1 Contract 기반 Feature Store-lite 구축 2 Feast 확장으로 조회 가능한 플랫폼 완성 3 Proof로 운영 신뢰성 검증 이 시리즈는 “Feast를 써봤다”가 아니라, Feature Store를 운영 가능한 시스템으로 고정하는 과정을 기록했습니다. 🎯 전체 회고 요약 단계 목표 고정된 기준 1 Feature Store-lite 뼈대 구축 Contract 분리 + 버전 1단 + 재현성 메타 2 Feast로 플랫폼 확장 version + latest 정책 + offline/online 일관성 3 Proof로 신뢰성 확보 E2E 검증 + 장애 재현·복구 🔄 이 시리즈를 관통하는 한 문장 Contract → Build → Versioned Store → Latest Pointer → Apply → Materialize → Online Read ...

🧭 목차 구분 증명 핵심 A. GitOps 분리 Triton dev/prod 독립 배포 및 상태 고정 B. 모델 제어 NFS model-repo 분리 + explicit load 통제 C. 서빙 검증 load → ready → infer E2E 성공 D. 관측 가능성 /metrics → Prometheus → Grafana 연계 E. 배포 통제 MLflow→Airflow 검증 체인 + commit/rollback F. 알럿 분리 Alertmanager null default 기반 dev/prod 분리 G. 알럿 실증 Triton latency 알럿 E2E 동작 A. Triton GitOps & Dev/Prod 분리 1️⃣ ArgoCD Applications (GitOps 기준) ✔ dev/prod 애플리케이션 상태 증명 ...

에필로그 — “GitOps 기반 Triton 서빙이 ‘배포→검증→관측→알림’ 루프로 고정” 📌 전체 경로 요약 순서 주제 1 🔗 Triton (CPU-only) GitOps 통합: ONNX 1개 서빙 + Prometheus/Grafana 관측 2 🔗 MLflow → Triton 자동 배포 파이프라인 구축 (Airflow · 검증 체인· 최소 롤백) 3 🔗 Alerting 운영 표준 매뉴얼 (Dev/Prod 분리 + Triton Serving Alerts) 4 🔗 Triton 운영형 서빙 플랫폼 (GitOps · 검증 · Alerting) - 검증 🎯 전체 회고 요약 단계 핵심 목표 주요 개선점 1 Triton 서빙 기반 GitOps 분리 · explicit load · 관측 2 배포 자동화 MLflow 단일 소스 · 검증 기반 commit/rollback 3 알람 운영 null default · namespace 라우팅 · latency 알럿 🔄 핵심 문장: ...

🧭 목차 구분 증명 포인트 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 🔄 핵심 문장: ...

🧠 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 자동화 🔄 핵심 ...