Observability

이 글은 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) 🧰 준비 이번 검증은 다음 기준으로 진행했습니다. ...

이 글에서 다루는 것 Triton READY 상태, Model Repository, FastAPI health/models/reload API, Metrics endpoint를 실제 실행 결과(Proof)로 검증 선수지식 GitOps 기반 E2E ML Platform - 모델 등록/서빙 반영 분리 Serving Runtime Proof 실제로 READY / Reload / Metrics까지 살아 있는가 들어가며 지금까지 이 시리즈에서는 다음을 설명했습니다. ML 플랫폼 구조 GitOps 환경 설계 Optional 레이어 분리 E2E 파이프라인 Drift Gate / Promotion 전략 MLflow + Triton + FastAPI 서빙 구조 하지만 여기서 중요한 질문이 하나 남습니다. ...

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

이 글에서 다루는 것 기존 v1 데이터 파이프라인에 버전 디렉터리 구조, schema.json, metadata.json, KST 타임라인을 얹어 ML Feature Store에 가까운 v2 파이프라인으로 고도화한 과정 선수지식 Observability 7단계: Data Pipeline 구축 이 단계에서 해결하려는 문제 이전 단계에서 S3 Raw에서 Feature CSV까지 동작하는 엔드투엔드 데이터 파이프라인(v1)을 만들었다. 하지만 실무 ML 플랫폼 입장에서는 “그때 그 실행에서 어떤 데이터를, 어떤 품질로, 어느 버전에 저장했는지"가 시간/버전/스키마/메타데이터까지 한 번에 남아야 한다. 이번 단계에서는 기존 v1 파이프라인을 버리지 않고, 그 위에 버전 디렉터리 구조 + schema.json + metadata.json + KST 타임라인을 얹어 실제 ML Feature Store에 더 가까운 v2 파이프라인으로 고도화했다. ...

이 글에서 다루는 것 S3 Raw 데이터를 Airflow DAG로 추출/검증/가공/저장하는 엔드투엔드 데이터 파이프라인을 구축하여 ML 학습 자동화의 데이터 레이어를 확보한 과정 선수지식 Observability 6단계: FastAPI Dashboard & Alert Library 이 단계에서 해결하려는 문제 모델의 성능은 결국 데이터 품질에서 결정된다. 그런데 데이터를 어떻게 추출하고, 검증하고, 가공하고, 저장하는지까지 자동화하지 않으면 MLOps는 완성되지 않는다. 이번 단계에서는 Raw S3에서 전처리, Feature 생성, 저장까지 이어지는 엔드투엔드 데이터 파이프라인을 직접 구축해 이후 MLflow 학습 자동화와 바로 연결될 데이터 레이어를 다졌다. ...

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

이 글에서 다루는 것 Observability 스택 운영 중 실제로 마주친 이슈들(크로스 스크랩, Alertmanager 충돌, NFS 권한, TSDB 병목 등)의 원인 분석과 재발 방지 구조를 다룹니다. 선수지식 Observability 4단계: Loki/Promtail 로그 파이프라인 구축 이 단계에서 해결하려는 문제 관측, 알림, 로그 시스템은 세팅보다 운영 이후가 진짜 시작이다. 실운영 환경에서 반드시 마주치는 문제들(dev/prod 크로스 스크랩, Alertmanager 충돌, NFS 권한, TSDB 병목 등)을 정리하고, 왜 문제가 생겼는지에서 어떻게 해결했는지, 다시는 반복되지 않도록 구조 자체를 잡아주는 단계다. ...