Architecture

📌 전체 시리즈 경로 순서 주제 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 부하 테스트) ...

이 글에서 다루는 것 Core / Baseline / Optional 세 레이어의 설계 기준과 실제 GitOps 배포 구조에서의 구현 선수지식 GitOps 기반 E2E ML Platform - 설계 의도 Core / Baseline / Optional 운영 가능한 경계를 먼저 설계 들어가며 ML 플랫폼을 설계할 때 흔히 하는 접근은 필요한 도구를 하나씩 붙여 나가는 방식입니다. 예를 들어 다음과 같은 식입니다. Airflow 설치 MLflow 추가 Triton 추가 Monitoring 추가 Feature Store 추가 이 방식은 처음에는 빠르게 시스템을 만들 수 있습니다. ...

이 글에서 다루는 것 GitOps 기반 E2E ML Platform의 4가지 설계 원칙과 시리즈 전체 구조 선수지식 이 글부터 시작 가능 (시리즈 첫 글) Kubernetes, ArgoCD 기본 개념을 알면 더 좋음 GitOps 기반 E2E ML Platform 설계 의도 들어가며 머신러닝 프로젝트를 처음 접하면 보통 이런 흐름으로 시작합니다. 데이터를 준비한다 모델을 학습한다 모델을 배포한다 이 흐름은 학습이나 실험에는 충분합니다. 하지만 운영 환경에서는 이야기가 조금 달라집니다. 운영 환경에서는 다음 질문이 먼저 등장합니다. ...

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 ...

이 글에서 다루는 것 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 🔄 핵심 문장: ...

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