FastAPI

이 글에서 다루는 것 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을 처음 실행하면 기본 동작은 다음과 같습니다. ...

이 글에서 다루는 것 모델 등록(MLflow)과 서빙 반영(Triton + FastAPI)을 분리한 구조, explicit 모드, FastAPI Reload API, 확장 전략(replica/batching), Feature Store 연동 패턴 선수지식 GitOps 기반 E2E ML Platform - 모델 반영 제어 MLflow + Triton + FastAPI 등록과 서빙 반영을 분리한 이유 들어가며 ML 시스템을 처음 구축할 때 흔히 다음과 같은 구조를 사용합니다. Train ↓ MLflow Register ↓ Deploy 즉, 모델 등록과 서빙 반영이 거의 같은 단계로 취급됩니다. 이 방식은 간단하고 구현하기 쉽습니다. ...

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

이 글에서 다루는 것 FastAPI ML 서빙 환경에서 장애를 즉시 감지하고 원인을 추적할 수 있는 대시보드 3종과 Alert Library 4종을 구축한 과정 선수지식 Observability 5단계: 운영 중 실제 이슈 & 해결 과정 이 단계에서 해결하려는 문제 FastAPI는 모델을 서빙하는 입구이자, 장애가 나면 가장 먼저 흔들리는 지점이다. A/B, Canary, 핫스왑 구조 위에서 문제가 생기면 바로 감지되고 원인을 바로 찾을 수 있는 관측 체계가 필요하다. 이번 단계에서는 실제 운영 수준의 FastAPI Observability Dashboard와 Alert Library를 구축한다. ...

이 글에서 다루는 것 Airflow Sensor를 reschedule 모드로 리팩토링하고 성공 체인을 보장하는 DAG 구조를 만들고, FastAPI에 cert-manager 기반 TLS + IP 화이트리스트를 적용하는 과정을 다룹니다. 선수지식 MLOps 운영 고도화 7단계: ArgoCD Notifications 자동화 — 배포 상태 Slack 자동 알림 이 단계에서 해결하려는 문제 모델을 등록하는 것보다 더 중요한 건 언제 Reload가 실행되느냐이다. 등록 실패나 READY 미도달 상태에서 /reload가 실행되면 잘못된 모델이 서빙될 수 있다. Airflow 흐름을 한 번 더 단단히 조이고, FastAPI 쪽은 HTTPS·화이트리스트까지 적용해 안전하게 자동화된다는 확신을 주는 구조를 만든다. ...

이 글에서 다루는 것 Pod 재시작 시 로그가 유실되지 않도록 NFS 기반 PV/PVC를 구성하고, Loguru로 구조화된 파일 로깅을 적용하여 FastAPI 서빙 로그를 영속화하는 과정을 다룹니다. 선수지식 MLOps 운영 고도화 3단계: 모델 롤백 자동화 — 스냅샷 기반 자동 롤백 이 단계에서 해결하려는 문제 FastAPI Pod가 재시작되거나 스케일 다운되면 컨테이너 내부에 쌓인 로그가 모두 사라진다. 핫스왑 이력, 예측 요청 기록, 에러 트레이스가 유실되면 장애 원인을 추적할 수 없다. Pod 라이프사이클과 독립적으로 로그를 보존하는 구조가 필요하다. ...

이 글에서 다루는 것 모델 등록 실패 시 이전 안정 버전으로 자동 롤백하고 FastAPI에 즉시 반영하는 복구 루프와, 운영자가 명시적으로 버전을 지정하는 수동 롤백 DAG을 구축하는 과정을 다룹니다. 선수지식 MLOps 운영 고도화 2단계: Slack Alert 통합 — 파이프라인 알림 자동화 이 단계에서 해결하려는 문제 모델 배포는 성공했을 때보다, 실패했을 때의 회복 속도가 운영 품질을 결정한다. 등록이 실패하는 즉시 이전 안정 버전으로 돌아가 FastAPI에 자동 반영되는 완전한 롤백 루프를 구축해야 한다. 이 구조가 있어야 장애 상황에서도 서비스가 끊기지 않고 바로 복구될 수 있다. ...