Posts

이 글에서 다루는 것 E2E 파이프라인 전체 구조, DAG 레벨 에러 처리(SLA/on_failure_callback), SSOT 패턴(ids.py/policy.py), Promotion/Shadow 분기, Rollback 구조 선수지식 GitOps 기반 E2E ML Platform - 토글 구조 E2E DAG: 학습 성공이 곧 운영 반영을 의미하지 않도록 설계 들어가며 많은 머신러닝 파이프라인은 다음과 같은 형태를 가집니다. Train → Register → Deploy 이 구조는 실험 환경에서는 충분히 동작합니다. 하지만 운영 환경에서는 몇 가지 중요한 문제가 생깁니다. 예를 들어 다음 상황을 생각해볼 수 있습니다. ...

이 글에서 다루는 것 Optional 레이어(Feature Store)를 실제로 ON/OFF하면서 Core 시스템이 독립적으로 동작하는지 검증하는 과정 선수지식 GitOps 기반 E2E ML Platform - GitOps 구조 Optional ON/OFF 확장 기능을 비파괴적으로 붙였다 떼는 구조 들어가며 ML 플랫폼을 설계하다 보면 자연스럽게 다음 질문이 등장합니다. Feature Store를 붙일까? 데이터 파이프라인 시스템을 추가할까? 추가 실험 플랫폼을 도입할까? 이런 시스템들은 대부분 유용합니다. 하지만 동시에 다음과 같은 문제를 가져올 수 있습니다. 플랫폼 복잡도 증가 시스템 의존성 증가 장애 전파 범위 확대 예를 들어 Feature Store를 Core 시스템에 강하게 연결하면 ...

이 글에서 다루는 것 ArgoCD AppProject와 ApplicationSet을 사용해 dev/prod 환경과 Core/Baseline/Optional 레이어 경계를 구조적으로 강제하는 방법 선수지식 GitOps 기반 E2E ML Platform - 운영 경계 ArgoCD AppProject / ApplicationSet dev/prod와 레이어 경계를 강제하기 들어가며 GitOps를 사용하는 이유는 보통 다음과 같이 설명됩니다. Git이 Single Source of Truth다 배포가 자동화된다 변경 이력을 추적할 수 있다 이 설명은 맞지만, 운영 관점에서 GitOps의 가장 중요한 역할은 따로 있습니다. 바로 배포 경계를 구조로 강제하는 것 ...

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

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

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