GitOps(ArgoCD)

이 글에서 다루는 것 MLflow 2.x의 alias 기반 모델 버전 관리로 Champion/Challenger 패턴을 구현하고, FastAPI와 연동한 zero-downtime hot swap 구조를 설계하는 과정 선수지식 Feature Store & Feast - Feast 이 단계에서 해결하려는 문제 MLflow 2.x부터 Staging/Production Stage가 deprecated됩니다. 대신 Registered Model Alias 방식이 공식 권장 패턴이 되었습니다. 이 변화는 단순한 API 교체가 아닙니다. 모델 버전 관리의 책임 구조가 바뀌는 것입니다. 이 글은 Stage 방식의 한계를 분석하고, alias 기반 Champion/Challenger 패턴과 FastAPI와 연동한 zero-downtime hot swap 구조를 설명합니다. ...

이 글에서 다루는 것 Airflow Executor 세 종류를 비교하고, MLOps 파이프라인에서 KubernetesExecutor를 선택한 이유와 RBAC·pod_template·KPO 실전 구성을 다룹니다. 선수지식 MLOps 운영 고도화 9단계: 시크릿 관리 & 키 회전 자동화 — SealedSecret + AWS 키 로테이션 이 단계에서 해결하려는 문제 Airflow를 Kubernetes 위에 올리면 Executor 선택이 필요하다. LocalExecutor, CeleryExecutor, KubernetesExecutor 중에서 MLOps 파이프라인에 가장 적합한 것을 선택하는 것은 단순한 설치 옵션이 아니라 운영 구조에 대한 결정이다. Task 격리, 동적 리소스 할당, Broker 관리 비용을 기준으로 판단한다. ...

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

이 글에서 다루는 것 Runbook / Security / Proof / Audit 운영 문서 구조와 Proof 파일 생성 방식 선수지식 GitOps 기반 E2E ML Platform - 운영 제어 구조 운영 문서화 Runbook / Security / Proof 디렉토리까지 남긴 이유 들어가며 많은 프로젝트는 다음 단계에서 멈춥니다. 코드 작성 README 작성 하지만 실제 운영 환경에서는 다음 문제가 발생합니다. 서비스 장애 발생 운영자가 시스템 구조를 모름 복구 절차 문서 없음 보안 정책 위치 불명확 이 경우 시스템이 아무리 잘 만들어져 있어도 ...

이 글에서 다루는 것 Prometheus 기반 Observability 구조, Auto Rollback 정책(error rate/latency/service health), Manual Rollback DAG, 관측 실패 시 정책 선수지식 GitOps 기반 E2E ML Platform - 실제 동작 확인 Observability / Auto Rollback / Manual Rollback 배포보다 중요할 수 있는 운영 제어 들어가며 ML 시스템을 구축할 때 많은 관심이 다음 단계에 집중됩니다. 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 설계 의도 들어가며 머신러닝 프로젝트를 처음 접하면 보통 이런 흐름으로 시작합니다. 데이터를 준비한다 모델을 학습한다 모델을 배포한다 이 흐름은 학습이나 실험에는 충분합니다. 하지만 운영 환경에서는 이야기가 조금 달라집니다. 운영 환경에서는 다음 질문이 먼저 등장합니다. ...

GitOps로 계약 배포 + Airflow 버전화/Latest 저장 + Feast 조회까지 E2E 증명 🧭 목차 구분 증명 포인트 A. GitOps 분리 dev·prod 독립 배포 + 상태 고정(Synced/Healthy) B. Contract 고정 계약(schema / repo)을 운영 리소스로 배포·마운트 C. 파이프라인 Airflow DAG E2E 성공 D. 저장 정책 S3 version 1단 + latest 동시 유지 E. 재현성 schema_hash·metadata로 생성 조건 기록 F. Feast 검증 s3fs → materialize → online 조회 성공 이 글은 설명이 아니라 증거(Proof)만 남깁니다. ...