이 글은 GitOps 기반 E2E ML Platform이

구조적으로 분리되어 있고, 실제로 동작하며, 운영 관측과 복구까지 가능한 상태임을

캡처와 실행 결과로 검증하는 기록입니다.

🧭 목차

0) 🧰 준비

이번 검증은 다음 기준으로 진행했습니다.

• GitOps 구조는 ArgoCD Project / Application / Root App 기준으로 확인
• Optional 레이어는 ON / OFF 실행 결과로 확인
• Airflow 파이프라인은 E2E DAG orchestration 실행 결과 기준으로 확인
• 서빙 상태는 Triton READY / FastAPI health / reload / metrics 기준으로 확인
• 운영 관측은 Prometheus / Alertmanager / ServiceMonitor / PrometheusRule 기준으로 확인
• 모든 결과는 docs/proof/latest/ 기준 최신 스냅샷으로 정리

사용한 주요 경로:

docs/proof/latest/projects.txt
docs/proof/latest/apps.txt
docs/proof/latest/root-apps.txt
docs/proof/latest/core_only/*
docs/proof/latest/optional_on/*
docs/proof/latest/e2e_success/*
docs/proof/latest/observability/*

1) 🧭 GitOps 경계 검증

1-1) ArgoCD Project 경계 검증

📸 proof-01-projects.png

✅ 확인 포인트:

• AppProject가 baseline, bootstrap, dev, optional, prod 로 분리되어 있으며

  project(default)는 기본 제공 프로젝트로 존재

• dev는 -dev, prod는 -prod namespace 범위를 대상으로 함

• optional은 feature-store / feast 전용 레이어로 분리됨

• 각 AppProject는 GitOps repository

  (mlops-infra-gitops)를 주요 source로 사용하며,

  일부 baseline 컴포넌트는 Helm chart repository를 함께 사용

🧩 의미:

단순 namespace 이름 구분이 아니라,

ArgoCD AppProject 수준에서 배포 경계를 강제하고 있음을 증명합니다.

즉 dev / prod / optional / baseline이 구조적으로 분리된 GitOps 환경입니다.

1-2) ArgoCD Application 전체 구조 검증

📸 proof-02-01-apps-list.png

📸 proof-02-02-apps-list.png

✅ 확인 포인트:

• Core: airflow-dev/prod, mlflow-dev/prod, fastapi-dev/prod, triton-dev/prod
• Baseline: alloy-*, loki-*, minio-*, monitoring-*
• Optional: feast-dev/prod, optional-envs-dev/prod
• 대부분 앱이 Synced / Healthy 상태
• Root Application (root-apps / root-baseline / root-optional)을 통해 GitOps 레이어별 ApplicationSet이 관리

🧩 의미:

문서상 Core / Baseline / Optional 구분이 아니라,

실제 ArgoCD Application 목록 자체가 레이어 구조를 반영하고 있음을 보여줍니다.

1-3) Root Application 구조 검증

📸 proof-03-root-apps.png

✅ 확인 포인트:

• root-apps가 bootstrap 프로젝트 아래에서 동작
• AppProject, Application, ApplicationSet 리소스를 함께 관리
• mlops-core ApplicationSet 존재 확인

🧩 의미:

이 플랫폼은 단순히 앱 몇 개를 수동 등록한 구조가 아니라,

Root App → Project → AppSet → App 으로 이어지는 GitOps 운영 구조를 갖고 있음을 증명합니다.

2) 🧱 Core-only 검증

2-1) Optional OFF 실행 검증

📸 proof-04-01-optional-off-run.png

📸 proof-04-02-optional-off-run.png

📸 proof-04-03-optional-off-run.png

✅ 확인 포인트:

• feast-dev, feast-prod, optional-envs-dev, optional-envs-prod, root-optional 삭제 수행

• 대기 후 optional scope app 제거 완료 메시지 확인

• Optional 레이어 ON/OFF는 Makefile 기반 운영 스크립트로 관리

• Root Application은 AppProject와 ApplicationSet을 함께 관리하며

  Core 레이어 애플리케이션은 ApplicationSet(mlops-core)을 통해 생성

🧩 의미:

Optional OFF가 단순 개념이 아니라,

실제 ArgoCD 앱 레벨에서 Optional 레이어를 분리(detach)하는 동작임을 증명합니다.

2-2) Optional 앱 제거 완료 검증

📸 proof-05-optional-scope-zero.png

✅ 확인 포인트:

• argocd app list | grep optional, grep feast 결과로 Optional 관련 앱이 더 이상 조회되지 않음
• feast-dev, feast-prod namespace 내부 리소스도 제거됨

🧩 의미:

Optional 레이어 관련 앱과 주요 리소스가 제거되어,

Core/Baseline만 남는 Core-only 상태가 실제로 만들어졌음을 보여줍니다.

2-3) Core-only 상태 헬스 검증

📸 proof-06-core-health-probes-fastapi.png

✅ 확인 포인트:

• dev 엔드포인트(https://fastapi.local/health) → status=ok
• prod 엔드포인트(https://fastapi.prod/health) → status=ok

🧩 의미:

Optional 기능을 제거한 뒤에도

FastAPI 기반 core serving 엔드포인트가 정상 유지됨을 보여줍니다.

2-4) Feature Store namespace 비파괴 유지 검증

📸 proof-07-feature-store-ns-retained.png

✅ 확인 포인트:

• feature-store-dev, feature-store-prod namespace는 Active 상태로 유지됨
• kubectl get all 기준 namespace 내부 워크로드 리소스는 제거된 상태임

🧩 의미:

Optional OFF는 namespace 삭제가 아니라

비파괴 Detach 방식으로 설계되었음을 증명합니다.

이로 인해 재부착 안정성과 운영 경계 유지가 가능합니다.

3) 🔌 Optional ON 검증

3-1) Optional ON 실행 검증

📸 proof-08-optional-on-run.png

✅ 확인 포인트:

• optional-envs-dev, optional-envs-prod, feast-dev, feast-prod 동기화 성공
• 전체 ON 프로세스가 정상 완료됨

🧩 의미:

Optional 레이어를 필요할 때 다시 붙일 수 있는

Attach 가능한 확장 구조임을 증명합니다.

3-2) Optional 앱 복구 검증

📸 proof-09-optional-scope-restored.png

✅ 확인 포인트:

• feast-dev, feast-prod, optional-envs-dev, optional-envs-prod, root-optional 생성
• 상태가 Synced / Healthy 로 복구됨

🧩 의미:

Optional 기능은 코어에 박혀 있는 구조가 아니라,

필요 시 안전하게 attach / detach 가능한 독립 레이어임을 증명합니다.

4) 🔄 Airflow E2E DAG 실행 검증

4-1) E2E DAG 전체 성공 흐름 검증

📸 proof-09-01-e2e-dag-success.png

📸 proof-09-02-e2e-dag-success.png

✅ 확인 포인트:

• e2e_full DAG에서 dp.extract_raw_data → dp.validate_data → dp.build_features → dp.store_features → drift_gate → train_and_evaluate → check_result → register_model_task → check_model_ready → deploy → commit_current → fastapi_reload → observe_post_deploy_metrics → summarize_run 흐름이 성공
• shadow_start, notify_failure, rollback_minimal 태스크는 이번 실행에서 분기 조건상 skipped 처리됨
• dp, deploy TaskGroup 포함 전체 orchestration chain이 정상 종료됨

🧩 의미:

이 플랫폼이 단순히 Triton/FastAPI가 떠 있는 구조가 아니라,

Airflow가 데이터 준비부터 운영 반영 후 관측까지 전체 흐름을 제어하는 E2E ML Platform 임을 증명합니다.

4-2) Promotion / Shadow 분기 구조 검증

📸 proof-09-03-branch-promotion-shadow.png

📸 proof-09-04-branch-promotion-shadow.png

✅ 확인 포인트:

• check_result 이후 정책 및 임계값에 따라 promotion_start 또는 shadow_start 로 분기
• 성공 사례에서는 register_model_task → check_model_ready → deploy 흐름으로 이어져 MLflow register 및 FastAPI reload까지 진행
• 차단 사례에서는 shadow_start 와 notify_failure 흐름이 선택되며, Slack 알림에 Branch: shadow, reason: below_threshold, Shadow path selected 메시지가 남음

🧩 의미:

이 플랫폼은 학습 완료를 곧바로 운영 반영으로 보지 않고,

임계값 및 정책 기반으로 promotion / shadow 경로를 실제로 분기하는 운영형 ML 파이프라인임을 증명합니다.

4-3) READY Sensor 배포 게이트 검증

📸 proof-09-05-model-ready-sensor.png

✅ 확인 포인트:

• promotion 경로 실행에서는 check_model_ready 태스크가 register 이후, deploy 이전 단계에서 성공
• shadow 분기 실행에서는 check_model_ready 가 skipped 처리되어, 배포 게이트가 promotion 경로에서만 적용됨
• 모델이 READY 상태가 되기 전까지 deploy 단계가 진행되지 않음

🧩 의미:

등록된 모델이 존재한다고 바로 운영에 반영하는 것이 아니라,

READY sensor를 명시적 배포 게이트로 사용하는 안전한 운영 반영 구조임을 증명합니다.

4-4) Manual Rollback DAG 실행 검증

📸 proof-09-06-manual-rollback-dag.png

📸 proof-09-07-manual-rollback-dag.png

✅ 확인 포인트:

• rollback_manual DAG에서 validate_conf → load_ctx → guard_repo → write_ssot_files → rollback_triton → reload_fastapi → verify_convergence 전 단계 성공 (validate_conf는 입력값 검증 및 path traversal 방지 가드)
• rollback 이후 /models 응답에서 SSOT 기준 served version이 이전 버전으로 복원되고, Slack에도 FastAPI reload 결과가 기록됨
• clear pod-local cache 수행 후 cache_pod_local 이 비워진 상태로 확인되어, pod-local override가 아닌 SSOT 기준 상태로 수렴했음을 확인

🧩 의미:

자동 rollback과 별개로,

운영자가 명시적으로 복구를 수행할 수 있는 수동 롤백 가드레일이 실제 DAG로 구현되어 있음을 증명합니다.

5) 🚀 Serving Runtime 검증

5-1) Triton READY 상태 검증 (dev/prod)

📸 proof-10-triton-ready.png

✅ 확인 포인트:

• HTTP/1.1 200 OK
• repository index 결과에서 dev 환경은 best_model, best_model_shadow, prod 환경은 best_model이 로드된 상태를 확인

🧩 의미:

dev/prod 환경에서 Triton이 단순 실행 중인 것이 아니라,

실제 READY 상태의 모델을 로드해 서빙 가능한 런타임임을 증명합니다.

5-2) FastAPI health / models / metrics 검증 (dev/prod)

📸 proof-11-01-fastapi-health.png

📸 proof-11-02-fastapi-models.png

📸 proof-11-03-fastapi-dev-metrics.png

📸 proof-11-03-fastapi-prod-metrics.png

✅ 확인 포인트:

• /health → status=ok
• /models → alias A/B의 version, run_id 노출
• /metrics → http_requests_total, process/python 메트릭 노출

🧩 의미:

FastAPI가 단순 gateway가 아니라

운영 상태 조회 + serving metadata 노출 + metrics exporter 역할까지 수행함을 증명합니다.

5-3) Reload API 성공 검증

📸 proof-12-reload-variant-a-b.png

✅ 확인 포인트:

• status: success
• variant: A, B
• version: 79, 9
• run_id: e57473991dc14de6a57dc7e5dfa1aa70

🧩 의미:

FastAPI /variant/{alias}/reload API가 실제로 성공했고,

Triton 서빙 상태와 연결된 reload 경로가 운영에서 사용 가능한 수준으로 동작했음을 증명합니다.

6) 📊 Observability 검증

6-1) Metrics API 활성화 검증

📸 proof-13-metrics-api.png

✅ 확인 포인트:

• v1beta1.metrics.k8s.io APIService가 AVAILABLE=True

🧩 의미:

Kubernetes cluster-level metrics가 활성화되어,

node / pod 리소스 usage를 조회할 수 있는 metrics API 기반이

실제로 준비되어 있음을 증명합니다.

6-2) Prometheus / Alertmanager / ServiceMonitor / Rule 검증 (dev/prod)

📸 proof-14-monitoring-objects.png

✅ 확인 포인트:

• Prometheus / Alertmanager 리소스 존재
• fastapi-(dev|prod)-sm 포함 ServiceMonitor 다수 존재
• fastapi-alerts, triton-alerts 포함 PrometheusRule 존재

🧩 의미:

dev/prod 환경에서 단순 모니터링 설치가 아니라,

FastAPI / Triton 서빙 계층을 대상으로 한 ServiceMonitor 기반 metrics 수집과 PrometheusRule 기반 alert 정책이 함께 배포되어 있음을 증명합니다.

6-3) Pod 리소스 관측 검증

📸 proof-15-top-pods-head.png

✅ 확인 포인트:

• airflow-*, fastapi-*, loki-*, minio-*, feast-* 등의 CPU / Memory 사용량 확인 가능

🧩 의미:

관측 시스템이 단순 설정으로 끝난 것이 아니라,

실제 워크로드 리소스 사용량까지 확인 가능한 상태임을 보여줍니다.

6-4) Grafana 대시보드 검증

Dev 환경

📸 proof-15-01-grafana-dashboard-dev.png

Prod 환경

📸 proof-15-02-grafana-dashboard-prod.png

✅ 확인 포인트:

• Grafana에서 FastAPI 요청량, Pod CPU/Memory, Triton inference 및 서빙 리소스가 시각화됨
• Prometheus가 수집한 메트릭이 Grafana 대시보드에 연결되어 있음
• 서비스 상태, API 트래픽, 서빙 계층, 리소스 사용량을 한 화면에서 확인 가능

🧩 의미:

이 플랫폼은 메트릭을 단순히 수집하는 데서 끝나지 않고,

Prometheus 기반 수집 결과를 Grafana에서 시각적으로 확인할 수 있는 observability 흐름까지 갖춘 상태임을 보여줍니다.

7) 📁 운영 문서 / Proof 구조 검증

7-1) Proof Index 검증

📸 proof-16-proof-index.png

✅ 확인 포인트:

• core_only/, optional_on/, e2e_success/, observability/ 디렉토리가 분리되어 존재
• projects.txt, root-apps.txt, root-baseline.txt, root-optional.txt 등 GitOps 경계 관련 proof 파일 존재
• pv.txt, pvc_all.txt 등 스토리지 관련 proof 파일도 함께 정리됨

🧩 의미:

이 프로젝트는 코드만 있는 것이 아니라,

플랫폼 상태를 카테고리별로 증명하는 proof 체계를 함께 갖고 있음을 보여줍니다.

7-2) 운영 문서 디렉토리 구조 검증

📸 proof-17-docs-structure.png

✅ 확인 포인트:

• docs/overview
• docs/runbook
• docs/security
• docs/proof
• docs/feature-store

🧩 의미:

이 프로젝트는 단순 구현물이 아니라

구조 설명(overview), 운영 절차(runbook), 보안 정책(security), 실행 증거(proof) 를 분리해 관리하는 문서형 플랫폼임을 보여줍니다.

8) 🏁 최종 결론

8-1) 전체 검증 요약

8-2) 결론

이 플랫폼은 GitOps 기반으로 배포 경계를 나누고,

Optional 기능을 독립적으로 다루며,

Airflow가 E2E 운영 반영 흐름을 제어하고,

Triton / FastAPI 서빙 경로와 Observability까지 포함해

실제로 검증 가능한 운영형 E2E ML Platform임을 Proof로 확인했습니다.