NFS

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

이 글에서 다루는 것 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 관측까지 서빙 플랫폼 뼈대 구축을 진행했다. ...

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

이 글에서 다루는 것 dev/prod 완전 분리된 Loki + Promtail 로그 파이프라인을 구축하고, LogQL 기반으로 FastAPI/Airflow 로그를 중앙에서 조회할 수 있는 구조를 만드는 과정을 다룹니다. 선수지식 Observability 3단계: Prometheus/KSM/Kubelet 완전 분리 구조 이 단계에서 해결하려는 문제 운영형 MLOps에서 가장 위험한 장애는 모델이 아닌 로그가 안 보이는 순간이다. FastAPI, MLflow, Airflow가 모두 돌아가도, 로그가 한 번 섞이거나 누락되면 장애 원인을 찾지 못해 운영 자체가 멈춰버린다. dev/prod를 완전히 분리한 Loki + Promtail 로그 파이프라인을 구축해, 모델 핫스왑, 에러 패턴, API 이상 징후까지 한눈에 보이도록 만든다. ...

이 글에서 다루는 것 dev/prod 간 메트릭이 교차 수집되는 문제를 라벨 기반으로 완전 분리하고, Prometheus TSDB를 local-path로 전환하여 성능과 안정성을 개선하는 과정을 다룹니다. 선수지식 Observability 2단계: Alertmanager Slack & 트러블슈팅 이 단계에서 해결하려는 문제 dev와 prod는 분리돼 있어야 하는데, 정작 관측 데이터에서는 서로 섞여 보이는 문제가 계속 생겼다. Prometheus/KSM/Kubelet의 라벨과 셀렉터가 조금만 어긋나도 dev에서 prod 메트릭을 읽는 심각한 혼선이 발생한다. 이번 단계에서는 관측 스택을 라벨 기반으로 완전히 절단하는 데 집중한다. 그리고 TSDB는 로컬 디스크로 옮겨 속도와 안정성을 끌어올리고, NFS는 나머지 관측 도구 전용으로 재정비한다. ...

이 글에서 다루는 것 Alertmanager 설정을 SealedSecret으로 관리하고, dev/prod 각각의 Slack 채널로 알람이 정확히 흐르는 관측 파이프라인을 완성하는 과정을 다룹니다. 선수지식 Observability 1단계: kube-prometheus-stack + GitOps 구축 이 단계에서 해결하려는 문제 모델이 잘 학습되고 잘 배포되는 것보다, 문제가 생겼을 때 즉시 감지되는 것이 더 중요할 때가 많다. dev/prod 각각에서 알람이 정확한 Slack 채널로, 깨짐 없이 흐르는 관측 파이프라인을 먼저 완성해야 한다. 이 기반이 갖춰져야 이후 FastAPI 지연, 핫스왑 실패, DAG 에러 같은 운영형 MLOps 이벤트를 실시간으로 감지할 수 있다. ...

이 글에서 다루는 것 kube-prometheus-stack을 dev/prod 네임스페이스로 완전 분리하고, ArgoCD GitOps로 재현 가능한 Observability 뼈대를 구축하는 과정을 다룹니다. 선수지식 Airflow 7단계: DAG CI 구축 — Level 3 마지막 포스트 이 단계에서 해결하려는 문제 모니터링은 한 번 세팅해두고 끝나는 게 아니라, 클러스터를 갈아엎어도 같은 모습으로 다시 살아나야 하는 인프라다. kube-prometheus-stack을 dev/prod로 완전히 분리하고, 모든 구성을 YAML + GitOps로 고정해서 Observability 스택을 재현할 수 있는 뼈대를 먼저 만든다. 🎯 핵심 요약 목표 ...

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