📌 전체 시리즈 경로
🙌 프로젝트 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 부하 테스트)
| 지표 | 값 | 환경 |
|---|---|---|
| 동시 접속 | 100 VU | 3-node bare-metal |
| 총 요청 | 20,553건 | 150초 실행 |
| RPS | 136.98 | FastAPI 2 replicas, Triton 1 replica (CPU-only) |
| 에러율 | 0.00% | 41,106건 검증 전량 통과 |
| p50 / p90 / p95 latency | 126ms / 456ms / 553ms | CPU-only 환경 |
측정 환경: 3-node bare-metal Kubernetes, 로컬 1-replica 환경 측정
상세 산출 근거 및 Proof: airflow-dags-dev README | Proof / Validation
🎯 전체 구조 요약
이 프로젝트는 단순한 모델 배포 시스템이 아니라
운영 환경에서 모델 변경을 통제하기 위한 ML Platform입니다.
전체 구조는 다음과 같이 구성됩니다.
핵심 목표는 다음이었습니다.
학습 성공 = 운영 반영
이 공식을 깨는 것입니다.
운영 환경에서는 다음 구조가 필요합니다.
학습 성공
↓
검증
↓
서빙 준비
↓
운영 반영
즉 운영 반영을 하나의 단계로 분리했습니다.
🧩 플랫폼 레이어 구조
이 플랫폼은 다음 세 개의 레이어로 구성됩니다.
Core
Baseline
Optional
Core (E2E Model Lifecycle)
Core는 모델 생명주기 자동화를 담당합니다.
구성 요소:
Airflow
MLflow
Triton
FastAPI
핵심 역할:
학습
등록
서빙 반영
Baseline (Always-on 운영 기반)
Baseline은 플랫폼 운영에 필요한 기반 시스템입니다.
구성 요소:
MinIO
Prometheus
Grafana
Alertmanager
Loki
Alloy
특징:
Optional과 무관하게 항상 실행
즉 Core-only 상태에서도
운영 기반은 유지됩니다.
Optional (확장 레이어)
Optional은 확장 기능입니다.
예:
Feature Store
Experiment 기능
추가 데이터 시스템
핵심 특징:
Attach / Detach 가능
Optional OFF는 삭제가 아니라
Detach
입니다.
🔁 E2E 모델 운영 흐름
이 플랫폼의 핵심 흐름은 다음입니다.
이 흐름에서 중요한 설계는 다음입니다.
Promotion / Shadow
모델 학습 결과는 두 경로로 분기됩니다.
Promotion
Shadow
Promotion:
품질 기준 통과 (accuracy ≥ threshold, drift 없음)
운영 모델 전환 + FastAPI reload
Shadow:
검증 실패 (accuracy 미달 또는 drift 감지)
운영 반영 중단, 병렬 배포만 수행
이 구조 덕분에
실험 결과
운영 반영
이 두 개를 분리할 수 있습니다.
⚙️ Serving Runtime 구조
이 플랫폼에서는 서빙 시스템을 세 단계로 분리했습니다.
MLflow
Triton
FastAPI
각 시스템의 역할은 다음과 같습니다.
| 시스템 | 역할 |
|---|---|
| MLflow | 모델 기록 |
| Triton | 모델 서빙 |
| FastAPI | 서빙 제어 |
이 구조의 핵심 원칙은 다음입니다.
등록된 모델 ≠ 운영 모델
운영 모델은 다음 상태를 의미합니다.
Triton READY
FastAPI Reload 완료
🔁 One Commit Flow
이 플랫폼은 GitOps 기반으로 Commit 또는 PR로 전체 운영 흐름이 자동 실행되는 구조를 목표로 설계되었습니다.
즉 플랫폼의 전체 흐름은 다음과 같이 자동화됩니다.
Commit / PR
→ CI Validation
→ GitOps Deploy (ArgoCD)
→ Airflow Pipeline
→ Model Register
→ Serving Runtime
→ Observability
→ Auto / Manual Rollback
운영자는 수동 배포 대신
Git Commit / PR
을 통해 전체 ML 플랫폼 운영 흐름을 트리거할 수 있습니다.
📊 Observability 구조
배포 이후 시스템을 감시하기 위해
다음 관측 시스템을 구성했습니다.
Prometheus
Alertmanager
Grafana
관측 대상:
FastAPI error rate
Triton inference 오류
latency 증가
이 데이터를 기반으로 다음이 가능합니다.
자동 롤백
운영 알림
문제 탐지
🔁 Rollback 전략
Rollback은 두 가지 방식으로 구성됩니다.
Auto Rollback
Prometheus metric을 기반으로 실행됩니다.
조건:
error rate 증가
latency 증가
서비스 장애
이 경우 자동 rollback이 수행됩니다.
관측 실패 시에는 Variable 기반 연속 실패 카운터로 추적하며,
3회 연속 실패 시 critical 에스컬레이션 알림을 발생시킵니다.
Manual Rollback
운영자가 직접 rollback을 실행할 수 있습니다.
DAG:
rollback_manual
이 DAG은 다음 작업을 수행합니다.
Triton unload
Triton load
FastAPI reload (best-effort)
Serving 상태 확인
📁 운영 문서 구조
코드 외에도 운영 문서 구조를 함께 구성했습니다.
docs/
├ overview
├ runbook
├ security
└ proof
각 문서의 목적은 다음과 같습니다.
| 문서 | 목적 |
|---|---|
| overview | 아키텍처 설명 |
| runbook | 운영 절차 |
| security | 보안 정책 |
| proof | 실행 증거 |
🔍 Proof 중심 검증
이 프로젝트에서는 시스템 동작을
Proof 파일로 기록했습니다.
경로:
docs/proof/latest/
Proof는 다음 항목을 검증합니다.
Triton READY
FastAPI Health
Reload API
Metrics
Optional ON/OFF
Core-only 상태
즉 시스템이 실제로 동작했음을
파일로 증명합니다.
🧠 설계에서 얻은 교훈
이 플랫폼을 설계하면서 얻은 가장 큰 교훈은 다음입니다.
1️⃣ 학습 파이프라인 ≠ 운영 플랫폼
많은 ML 시스템이 다음 구조에 머뭅니다.
Train → Deploy
하지만 운영 환경에서는 다음 구조가 필요합니다.
Train
↓
Validate
↓
Serve
↓
Observe
↓
Recover
2️⃣ 서빙과 등록을 분리해야 한다
모델 registry는 운영 상태가 아닙니다.
운영 상태는 다음입니다.
Serving Runtime
3️⃣ 운영 시스템은 Observability가 핵심이다
배포보다 중요한 것은
문제 탐지
입니다.
그래서 Observability는 플랫폼의 핵심 구성 요소입니다.
4️⃣ 좋은 프로젝트는 문서 구조까지 포함한다
코드만 있는 프로젝트는
설명 가능한 프로젝트
입니다.
하지만 문서까지 존재하는 프로젝트는
운영 가능한 시스템
입니다.
🏁 마무리
이 프로젝트는
모델 배포 시스템
을 만드는 것이 아니라
운영 환경에서 모델 변경을 통제하는 플랫폼
을 목표로 설계되었습니다.
핵심은 다음입니다.
변경을 안전하게 반영
문제를 빠르게 감지
필요하면 즉시 복구
이 세 가지 원칙을 중심으로
GitOps 기반 ML Platform을 설계했습니다.