GitOps(ArgoCD)

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

이 글에서 다루는 것 Feature Store-lite 위에 Feast를 얹어, S3 Offline + Redis Online + Feature Server 구성으로 “저장하는 파이프라인"을 “조회 가능한 피처 플랫폼"으로 확장하는 과정 선수지식 Feature Store & Feast - Feature Store-lite 이 단계에서 해결하려는 문제 이전 글(Feature Store-lite)에서 계약(스키마/메타) + 버전화 저장 + 재현성까지 고정했습니다. 하지만 실무에서는 “저장"에서 끝나지 않습니다. 결국 중요한 건 조회 가능(Serving-ready) 상태입니다. 이번 글은 Feature Store-lite 위에 Feast를 얹어 아래를 완성합니다. Offline Source: S3의 latest/features.parquet (Feast가 읽는 고정 포인터) Registry: S3에 registry.pb 저장(환경별 분리) Online Store: Redis 적재(materialize)로 온라인 조회 가능 Feature Server: 상시 서비스 + startup 시 feast apply 즉, “저장하는 파이프라인” -> “조회 가능한 피처 플랫폼"으로 확장하는 단계입니다. ...

이 글에서 다루는 것 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부터 써야 하나?“가 먼저 나오는데, 도구보다 먼저 피처 생성/버전화/재현 방식이 고정돼야 합니다. ...

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

이 글에서 다루는 것 Triton 서빙 환경에서 dev/prod 알럿을 완전히 분리하고, PrometheusRule/Alertmanager/Grafana를 하나의 판단 흐름으로 고정하는 GitOps 기반 Alerting 운영 표준 설계 선수지식 Triton 서빙 플랫폼 - MLflow → Triton 자동 배포 파이프라인 이 단계에서 해결하려는 문제 Observability는 대시보드가 아니라, 사고를 막는 운영 정책입니다. 이 문서는 dev/prod 알럿을 완전히 분리하고, 라벨 실수로 인한 교차 전송까지 구조적으로 차단하며, Triton 서빙 품질을 모델 실행 관점에서 감지하도록 설계된 GitOps 기반 Alerting 운영입니다. ...

이 글에서 다루는 것 MLflow Registry를 단일 소스로 삼아 Airflow DAG에서 Triton에 모델을 자동 배포하고, 검증 체인(load/ready/infer) 통과 후에만 운영 확정하며, 실패 시 자동 롤백하는 파이프라인을 구축한 과정 선수지식 Triton 서빙 플랫폼 - Triton 구축 이 단계에서 해결하려는 문제 실무 환경에서 모델 배포는 “새 모델을 올리는 작업"이 아니라 “현재 운영 상태를 안전하게 갱신하는 상태 전이(State Transition)“에 가깝다. 이번 단계에서는 MLflow Registry를 단일 소스로 삼아 Triton Inference Server에 모델을 자동 배포하고, 로딩/헬스 체크/실제 추론 검증을 모두 통과한 경우에만 운영 모델을 확정(commit)하며, 중간 단계에서 하나라도 실패하면 이전 운영 상태로 자동 복구되는 최소 롤백 구조를 구현했다. ...

이 글에서 다루는 것 Triton Inference Server를 CPU-only GitOps 구조로 배포하고, ONNX 모델 1개의 load/infer 검증 및 Prometheus/Grafana 관측까지 서빙 플랫폼 뼈대를 구축한 과정 선수지식 Observability 8단계: Data Pipeline 고도화 이 단계에서 해결하려는 문제 실무에서 서빙 계층은 곧바로 트래픽과 SLA를 맞는 최전선이다. 모델이 아무리 좋아도 서빙이 불안정하면 운영 시 바로 무너진다. 이번에는 Triton 첫 구축으로 GPU/파이프라인 연동을 일부러 빼고, Triton 자체를 GitOps로 안정적으로 띄우고, 모델 load → infer → metrics 관측까지 서빙 플랫폼 뼈대 구축을 진행했다. ...

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