Helm

이 글에서 다루는 것 ArgoCD ApplicationSet으로 dev/prod 환경을 단일 템플릿으로 관리하고, MetalLB로 온프레미스 LoadBalancer를 구성하며, App-of-Apps 패턴으로 전체 플랫폼을 선언적으로 동기화하는 GitOps 고도화 과정을 다룹니다. 선수지식 MLOps 운영 고도화 5단계: Airflow 안정화 & FastAPI HTTPS — TLS 보안과 스케줄러 안정화 이 단계에서 해결하려는 문제 환경(dev/prod)이 늘어날수록 ArgoCD Application YAML이 중복되고, 환경 간 설정 드리프트가 발생한다. 온프레미스 환경에서는 클라우드 로드밸런서가 없어 외부 접근이 어렵다. 개별 Application을 수동으로 관리하면 전체 플랫폼 상태를 한눈에 파악하기 힘들다. ...

이 글에서 다루는 것 Airflow Sensor를 reschedule 모드로 리팩토링하고 성공 체인을 보장하는 DAG 구조를 만들고, FastAPI에 cert-manager 기반 TLS + IP 화이트리스트를 적용하는 과정을 다룹니다. 선수지식 MLOps 운영 고도화 7단계: ArgoCD Notifications 자동화 — 배포 상태 Slack 자동 알림 이 단계에서 해결하려는 문제 모델을 등록하는 것보다 더 중요한 건 언제 Reload가 실행되느냐이다. 등록 실패나 READY 미도달 상태에서 /reload가 실행되면 잘못된 모델이 서빙될 수 있다. Airflow 흐름을 한 번 더 단단히 조이고, FastAPI 쪽은 HTTPS·화이트리스트까지 적용해 안전하게 자동화된다는 확신을 주는 구조를 만든다. ...

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

이 글에서 다루는 것 모델 등록 실패 시 이전 안정 버전으로 자동 롤백하고 FastAPI에 즉시 반영하는 복구 루프와, 운영자가 명시적으로 버전을 지정하는 수동 롤백 DAG을 구축하는 과정을 다룹니다. 선수지식 MLOps 운영 고도화 2단계: Slack Alert 통합 — 파이프라인 알림 자동화 이 단계에서 해결하려는 문제 모델 배포는 성공했을 때보다, 실패했을 때의 회복 속도가 운영 품질을 결정한다. 등록이 실패하는 즉시 이전 안정 버전으로 돌아가 FastAPI에 자동 반영되는 완전한 롤백 루프를 구축해야 한다. 이 구조가 있어야 장애 상황에서도 서비스가 끊기지 않고 바로 복구될 수 있다. ...

이 글에서 다루는 것 FastAPI와 Airflow가 흩어져 보내던 알림을 하나의 Slack 인터페이스로 통합하고, SealedSecret 기반으로 Webhook URL을 안전하게 주입하는 구조를 다룹니다. 선수지식 MLOps 운영 고도화 1단계: 핫스왑 고도화 — /reload 보안 강화와 DAG 자동화 이 단계에서 해결하려는 문제 운영 환경에서 가장 무서운 건 문제가 생겼는데 아무도 모르고 있는 상황이다. FastAPI와 Airflow가 각자 흩어져 보내던 알림을 하나의 Slack 인터페이스로 완전히 통합해서, 모델 학습·등록·센서·핫스왑·헬스체크까지 어디에서 무슨 일이 일어나도 즉시 눈에 들어오도록 만든다. ...

이 글에서 다루는 것 /reload 엔드포인트에 3중 보안(토큰·IP 화이트리스트·TLS)을 적용하고, Airflow DAG으로 학습→등록→감시→핫스왑 전체 시퀀스를 자동화하는 과정을 다룹니다. 선수지식 MLOps 운영 고도화 0단계: FastAPI A/B·Canary·Blue-Green 서빙 베이스 — 멀티 모델 라우팅 기반 설계 이 단계에서 해결하려는 문제 모델을 잘 학습시키는 것도 중요하지만, 잘못된 모델이 실수로 핫스왑되는 순간이 더 치명적이다. /reload를 확실하게 잠그고, 학습→등록→감시→핫스왑까지가 Airflow에서 자동으로 흘러가도록 만들어야 한다. 이 단계가 완성돼야 이후 단계에서 안전한 자동 운영(MLOps)을 구현할 수 있다. ...

이 글에서 다루는 것 MLflow Alias 기반으로 A/B·Canary·Blue-Green 세 가지 서빙 전략을 하나의 FastAPI 앱에서 처리하는 구조를 설계하고, 이후 운영 자동화의 공통 베이스를 만드는 과정을 다룹니다. 선수지식 [TS] Airflow 기초 자동화 트러블슈팅 — Airflow → MLflow → FastAPI 연동 기본 흐름 Level 3은 이 글부터 시작합니다. 이 단계에서 해결하려는 문제 운영 환경에서 모델은 언제든 교체될 수 있고, 그 순간이 서비스 품질이 가장 크게 흔들리는 위험 구간이다. 이후 모든 자동화(학습·등록·핫스왑·롤백)의 기반이 되는 A/B·Canary·Blue-Green 전략을 모두 처리할 수 있는 FastAPI 서빙 구조부터 잡아야 한다. 이 뼈대가 완성돼야 Airflow, MLflow, ArgoCD와 연결된 운영형 MLOps 파이프라인을 만들 수 있다. ...

🧩 실전 시나리오 기반 구성 배경 이 프로젝트는 단순 실습을 넘어서, 실제 발생하는 다음과 같은 문제들을 해결하기 위한 MLOps 인프라 구축을 목표로 설계되었습니다. 여러 모델 실험 결과가 뒤섞여 추적이 어려운 문제 → MLflow Tracking 서버 + PostgreSQL 메타데이터 저장소 구성 모델 파일 및 로그가 로컬에만 저장되어 협업 및 재현성이 떨어지는 문제 → S3 기반 artifact store 구성 + pyfunc 기반 모델 서빙 구조 설계 수작업 DAG 등록, 모델 배포 등의 비효율적 운영 문제 → Airflow + GitSync 연동으로 파이프라인 자동화 및 버전 관리 가능 ...

이 글에서 다루는 것 Airflow DAG에서 조건부 모델 등록 후 FastAPI 핫스왑까지 E2E 자동화 흐름을 실험합니다. 선수지식 MLOps 플랫폼 구축 5단계: FastAPI 서빙 및 핫스왑 구조 구축 — FastAPI 모델 로딩과 /reload API 구조 이 단계에서 해결하려는 문제 개별 컴포넌트(Airflow, MLflow, FastAPI)를 각각 구성했지만, 학습부터 서빙까지의 자동화 흐름을 E2E로 검증해야 실제 운영 가능 여부를 판단할 수 있습니다. 이 단계에서는 Airflow DAG에서 모델 학습 → 성능 기준 분기 → MLflow 등록 → FastAPI 핫스왑까지 전체 파이프라인을 실험합니다. ...

이 글에서 다루는 것 MLflow에 등록된 모델을 FastAPI로 서빙하고, Stage 기반 핫스왑과 모델 정보 조회 API를 구축합니다. 선수지식 MLOps 플랫폼 구축 4단계: Airflow GitSync + Secret 연동 — Helm 배포와 Secret 마운트 패턴 이 단계에서 해결하려는 문제 모델을 수동으로 서빙 서버에 복사하면 배포 실수와 버전 불일치가 발생합니다. MLflow Registry에서 Stage별 모델을 자동 로딩하는 구조를 만들어, 코드 변경 없이 모델을 교체할 수 있도록 합니다. 📐 아키텍처 구성도 🐳 FastAPI 커스텀 이미지 Dockerfile FROM python:3.12 WORKDIR /app COPY app /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"] requirements.txt fastapi==0.110.2 uvicorn==0.29.0 mlflow==2.13.0 pandas==2.1.4 scikit-learn==1.6.1 pydantic==2.7.1 boto3==1.34.113 numpy==1.26.4 packaging==24.2 psutil==7.0.0 scipy==1.15.3 setuptools==69.5.1 빌드 & 푸시 docker build -t ghcr.io/hoizz/fastapi-ml:mlflow-model-info . docker push ghcr.io/hoizz/fastapi-ml:mlflow-model-info 📄 app/main.py (핵심 부분) app = FastAPI() model = None model_info = {} def load_model_from_mlflow(): global model, model_info tracking_uri = os.environ.get("MLFLOW_TRACKING_URI") model_name = os.environ.get("MODEL_NAME") model_stage = os.environ.get("MODEL_STAGE", "Production") mlflow.set_tracking_uri(tracking_uri) model_uri = f"models:/{model_name}/{model_stage}" model = mlflow.pyfunc.load_model(model_uri) client = MlflowClient() latest = client.get_latest_versions(name=model_name, stages=[model_stage])[0] model_info = { "model_name": model_name, "stage": model_stage, "version": latest.version, "run_id": latest.run_id, "model_uri": model_uri, } @app.on_event("startup") def startup_event(): load_model_from_mlflow() @app.get("/model-info") def get_model_info(): return model_info @app.post("/predict") async def predict(request: Request): input_data = await request.json() prediction = model.predict(input_data) return {"prediction": prediction.tolist()} 전체 코드: GitHub (main.py) ...