Kubernetes

이 글에서 다루는 것 Core / Baseline / Optional 세 레이어의 설계 기준과 실제 GitOps 배포 구조에서의 구현 선수지식 GitOps 기반 E2E ML Platform - 설계 의도 Core / Baseline / Optional 운영 가능한 경계를 먼저 설계 들어가며 ML 플랫폼을 설계할 때 흔히 하는 접근은 필요한 도구를 하나씩 붙여 나가는 방식입니다. 예를 들어 다음과 같은 식입니다. Airflow 설치 MLflow 추가 Triton 추가 Monitoring 추가 Feature Store 추가 이 방식은 처음에는 빠르게 시스템을 만들 수 있습니다. ...

이 글에서 다루는 것 GitOps 기반 E2E ML Platform의 4가지 설계 원칙과 시리즈 전체 구조 선수지식 이 글부터 시작 가능 (시리즈 첫 글) Kubernetes, ArgoCD 기본 개념을 알면 더 좋음 GitOps 기반 E2E ML Platform 설계 의도 들어가며 머신러닝 프로젝트를 처음 접하면 보통 이런 흐름으로 시작합니다. 데이터를 준비한다 모델을 학습한다 모델을 배포한다 이 흐름은 학습이나 실험에는 충분합니다. 하지만 운영 환경에서는 이야기가 조금 달라집니다. 운영 환경에서는 다음 질문이 먼저 등장합니다. ...

이 글에서 다루는 것 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 즉, “저장하는 파이프라인” -> “조회 가능한 피처 플랫폼"으로 확장하는 단계입니다. ...

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