Kubernetes

이 글에서 다루는 것 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 구조를 설명합니다. ...

이 글에서 다루는 것 k6 부하 테스트로 Triton + FastAPI 서빙 성능을 실측 검증: 136 RPS, p95 553ms, 에러율 0% (CPU-only 3노드 클러스터) 선수지식 GitOps 기반 E2E ML Platform - 운영 문서화 Load Test: 서빙 성능 검증 실제로 얼마나 버티는가 들어가며 이 시리즈에서 지금까지 다음을 확인했습니다. Triton READY Model Repository Loaded FastAPI Health OK Reload API Success Metrics Exported 하지만 여기서 중요한 질문이 하나 더 남습니다. 실제 트래픽이 들어왔을 때 이 시스템이 버티는가? ...

이 글에서 다루는 것 CPU-only 환경에서 Triton의 dynamic_batching과 instance_group 설정으로 처리량을 높이고 latency를 안정화하는 성능 최적화 과정 선수지식 Triton 서빙 플랫폼 - Alerting 운영 표준 매뉴얼 이 단계에서 해결하려는 문제 Triton을 올리고 모델이 READY 상태가 되면 끝일까? 기본 설정만 사용하면 요청이 하나씩 순서대로 처리됩니다. 동시 요청이 몰리면 큐가 쌓이고, latency가 급격히 올라갑니다. 이 글은 dynamic_batching과 instance_group 설정으로 CPU 환경에서 처리량을 높이고 latency를 안정화한 과정을 설명합니다. 🎯 핵심 요약 기본 설정의 한계: single instance + no batching -> 요청 직렬 처리 instance_group: CPU 인스턴스 수 증가 -> 병렬 추론 처리 dynamic_batching: 요청 자동 묶음 -> 배치 단위 추론으로 처리량 향상 적용 시점: explicit mode에서는 model load 시 config.pbtxt 반영 실측 결과: 136 RPS, p95 553ms, 에러율 0% (100 VU, CPU-only 3노드) 1️⃣ 기본 설정만으로는 무엇이 부족한가 Triton을 처음 실행하면 기본 동작은 다음과 같습니다. ...

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

이 글에서 다루는 것 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 하지만 실제 운영 환경에서는 배포 이후에 더 중요한 문제가 발생합니다. 예를 들어 다음 상황을 생각해볼 수 있습니다. ...

이 글에서 다루는 것 모델 등록(MLflow)과 서빙 반영(Triton + FastAPI)을 분리한 구조, explicit 모드, FastAPI Reload API, 확장 전략(replica/batching), Feature Store 연동 패턴 선수지식 GitOps 기반 E2E ML Platform - 모델 반영 제어 MLflow + Triton + FastAPI 등록과 서빙 반영을 분리한 이유 들어가며 ML 시스템을 처음 구축할 때 흔히 다음과 같은 구조를 사용합니다. Train ↓ MLflow Register ↓ Deploy 즉, 모델 등록과 서빙 반영이 거의 같은 단계로 취급됩니다. 이 방식은 간단하고 구현하기 쉽습니다. ...

이 글에서 다루는 것 Drift Gate의 KS statistic 기반 검증, Promotion/Shadow 분기 정책, FastAPI 트래픽 분기(Mirror/Split) 전략 선수지식 GitOps 기반 E2E ML Platform - 운영 환경 반영 제어 Drift Gate / Promotion / Shadow 검증된 변경만 운영 경로에 올림 들어가며 모델 학습 파이프라인을 만들다 보면 다음 질문이 자연스럽게 등장합니다. 어떤 모델을 운영 환경에 반영할 것인가? 많은 프로젝트에서는 다음 기준을 사용합니다. accuracy >= threshold 하지만 운영 환경에서는 이 기준만으로는 충분하지 않습니다. ...

이 글에서 다루는 것 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의 가장 중요한 역할은 따로 있습니다. 바로 배포 경계를 구조로 강제하는 것 ...