이 글에서 다루는 것
Prometheus 기반 Observability 구조, Auto Rollback 정책(error rate/latency/service health), Manual Rollback DAG, 관측 실패 시 정책
선수지식
Observability / Auto Rollback / Manual Rollback
- 배포보다 중요할 수 있는 운영 제어
들어가며
ML 시스템을 구축할 때 많은 관심이 다음 단계에 집중됩니다.
Train
Register
Deploy
하지만 실제 운영 환경에서는
배포 이후에 더 중요한 문제가 발생합니다.
예를 들어 다음 상황을 생각해볼 수 있습니다.
- 모델이 정상적으로 배포되었지만 latency가 급격히 증가한 경우
- 특정 입력 데이터에서 오류율이 증가하는 경우
- inference 요청이 실패하는 경우
이런 상황에서 중요한 질문은 다음입니다.
문제가 발생했을 때 어떻게 감지하고 복구할 것인가?
그래서 이 플랫폼에서는 배포 이후 단계에
다음 세 가지 시스템을 설계했습니다.
Observability
Auto Rollback
Manual Rollback
이 글에서는 이 세 가지 운영 제어 구조를 설명합니다.
Observability 구조
이 플랫폼의 관측 시스템은 다음 스택을 기반으로 구성됩니다.
Prometheus
Alertmanager
Grafana
Metrics Server
이 시스템들은 Baseline 레이어에서 관리됩니다.
관련 Proof:
docs/proof/latest/observability/*
이 Proof 파일들은 실제 클러스터에서
관측 시스템이 실행 중임을 보여줍니다.
Metrics API
먼저 Kubernetes cluster metrics 상태를 확인합니다.
Proof:
docs/proof/latest/observability/metrics_api.txt
결과 예시:
v1beta1.metrics.k8s.io kube-system/metrics-server True
이 결과는 다음 의미를 가집니다.
Kubernetes Metrics API 활성화
Node / Pod resource metrics 사용 가능
즉 다음 명령이 정상 동작합니다.
kubectl top nodes
kubectl top pods
Pod Resource Metrics
실제 Pod 리소스 상태도 확인할 수 있습니다.
Proof:
docs/proof/latest/observability/top_pods_head.txt
예시 일부:
airflow-dev-scheduler CPU 17m MEMORY 508Mi
fastapi-dev CPU 2m MEMORY 111Mi
loki-dev CPU 17m MEMORY 188Mi
minio-dev CPU 4m MEMORY 131Mi
이 정보는 다음 용도로 사용됩니다.
- 서비스 리소스 모니터링
- capacity planning
- anomaly detection
Prometheus Operator
ML 서비스 metrics는 Prometheus가 수집합니다.
Proof:
docs/proof/latest/observability/monitoring_dev_objects.txt
예시:
prometheus.monitoring.coreos.com
alertmanager.monitoring.coreos.com
servicemonitor.monitoring.coreos.com
prometheusrule.monitoring.coreos.com
이 리소스들은 Prometheus Operator가 생성합니다.
구조:
ServiceMonitor
↓
Prometheus
↓
Alertmanager
FastAPI Metrics 수집
FastAPI는 다음 endpoint를 통해 metrics를 노출합니다.
GET /metrics
이 endpoint는 Prometheus FastAPI Instrumentator로 구현되어 있습니다.
관련 코드:
charts/fastapi/app/main.py
예시 코드:
Instrumentator().instrument(app).expose(app,endpoint="/metrics")
즉 FastAPI는 다음 metric을 제공합니다.
http_requests_total
process_cpu_seconds_total
python_gc_objects_collected_total
Custom Alert Rules
이 플랫폼에서는 서비스 관련 alert rule도 정의합니다.
Proof:
prometheusrule.monitoring.coreos.com/fastapi-alerts
prometheusrule.monitoring.coreos.com/triton-alerts
이 rule들은 다음 문제를 감지합니다.
FastAPI error rate 증가
Triton inference 오류
latency 증가
즉 모델 서빙 상태를
Prometheus에서 지속적으로 감시합니다.
Auto Rollback 정책
관측 시스템은 단순히 모니터링만 하지 않습니다.
이 플랫폼에서는 관측 결과를 기반으로
자동 롤백 정책을 적용합니다.
관련 코드:
dags/mlops_lib/observability/auto_rollback.py
Auto Rollback은 다음 조건을 확인합니다.
FastAPI service health
5xx error rate
latency p95
이 값들은 Prometheus query로 가져옵니다.
Error Rate 기준
Error rate는 다음 기준을 사용합니다.
observe_error_rate_threshold = 0.02
즉
5xx error rate > 2%
이면 문제로 판단합니다.
2계층 임계값 설계: Prometheus AlertRule(
fastapi-alerts.yaml)은 5xx error rate > 5%에서 경고 알림을 발생시키고, Airflow Auto Rollback은 > 2%에서 자동 롤백을 실행합니다. 알림은 운영자 인지용(느슨), 롤백은 자동 복구용(엄격)으로 의도적으로 분리한 설계입니다. P95 latency도 동일한 패턴(알림 500ms vs 롤백 800ms)을 따릅니다.
하지만 여기서 중요한 조건이 하나 더 있습니다.
error rate
AND
error request rate
둘 다 증가해야 rollback을 실행합니다.
Latency 기준
Latency는 다음 기준을 사용합니다.
observe_latency_p95_threshold_sec = 0.8
즉
p95 latency > 800ms
이면 문제로 판단합니다.
Service Health 확인
Auto Rollback은 먼저 다음 조건을 확인합니다.
min(up) metric
즉 서비스가 실제로 살아 있는지 확인합니다.
예시 코드:
min_up=self.prom.min_up_in_namespace(namespace=self.tg.namespace)
결과가 다음과 같으면
min_up < 1
서비스 장애로 판단합니다.
Rollback Trigger
이 조건들이 만족되면
자동 롤백이 실행됩니다.
Service unhealthy
OR
Error rate 초과
OR
Latency 초과
이 경우 다음 메시지가 생성됩니다.
AutoRollback: TRIGGERED
그리고 모델 rollback이 실행됩니다.
Observability 실패 시 정책
여기서 중요한 설계 결정이 하나 있습니다.
Observability 시스템이 실패한 경우입니다.
예를 들어 다음 상황입니다.
Prometheus scrape 실패
metric query 실패
network 문제
이 경우 이 플랫폼은 다음 정책을 사용합니다.
Rollback skip
즉
관측 실패 ≠ 서비스 실패
입니다.
이 정책의 목적은 다음입니다.
잘못된 롤백을 방지하는 것
Fail-Open 관측성 강화
단순히 롤백을 건너뛰는 것에서
연속 실패 횟수를 추적하는 에스컬레이션 구조로 강화했습니다.
구현 방식:
Airflow Variable 기반 연속 실패 카운터
XCom 대신 Variable을 사용하는 이유는 다음입니다.
- XCom은 DAG 실행 단위로 상태가 초기화됨
- Variable은 DAG 실행 간 상태가 유지됨
에스컬레이션 정책:
연속 1~2회 실패 → warning 로그
연속 3회 이상 → critical 에스컬레이션 알림
관측 성공 또는 롤백 트리거 → 카운터 리셋
인프라 레벨에서도 PrometheusRule로 이중 감시합니다.
FastAPIScrapingFailure
이 알림은 FastAPI /metrics scrape가 15분 이상 실패할 때 발생합니다.
즉 DAG 레벨(연속 실패 카운터) + 인프라 레벨(PrometheusRule)
이중으로 관측성 사각지대를 감시합니다.
Manual Rollback
자동 롤백과 별도로
Manual Rollback DAG도 존재합니다.
관련 코드:
dags/rollback_manual.py
이 DAG은 다음 상황에서 사용됩니다.
운영자 직접 rollback
실험 rollback
비상 대응
Manual rollback은 다음 단계를 수행합니다.
SSOT 파일 업데이트
↓
Triton unload
↓
Triton load
↓
FastAPI reload
↓
Serving 상태 확인
즉 모델 서빙 상태를
완전히 이전 버전으로 복구합니다.
Rollback SSOT
Manual rollback에서 중요한 개념은
SSOT 파일입니다.
예시:
current.json
config.pbtxt
이 파일은 다음 정보를 저장합니다.
current model version
serving configuration
rollback 시 이 파일을 업데이트하여
모델 상태를 복구합니다.
롤백 FastAPI 확장
기존 rollback은 Triton만 대상이었습니다.
이를 Triton + FastAPI로 확장했습니다.
rollback_minimal()
↓
current.json 복원
↓
Triton unload / load
↓
FastAPI reload (best-effort)
FastAPI reload는 best-effort로 처리합니다.
즉,
FastAPI reload 실패 → 롤백 전체 실패로 처리하지 않음
이유는 다음입니다.
- Triton 상태 복구가 최우선
- FastAPI reload 실패로 Triton 롤백까지 취소되면 안 됨
- FastAPI는 다음 요청 시 Triton의 최신 상태를 참조
Observability의 핵심 목적
이 플랫폼에서 Observability의 목적은
단순한 모니터링이 아닙니다.
오히려 다음을 위한 시스템입니다.
서비스 상태 감시
성능 이상 감지
자동 복구 트리거
운영 대응 지원
즉 배포 이후에도
모델 상태를 지속적으로 관리합니다.
핵심 메시지
ML 플랫폼에서 배포는 끝이 아닙니다.
오히려 다음이 더 중요합니다.
Deploy
↓
Observe
↓
Recover
이 플랫폼에서는 다음 구조로 이를 구현했습니다.
Prometheus Observability
↓
Auto Rollback Policy
↓
Manual Rollback DAG
이 구조 덕분에
- 모델 성능 문제
- inference 오류
- latency 증가
와 같은 문제를
자동으로 감지하고 대응할 수 있습니다.
다음 글
지금까지는 플랫폼의 운영 제어 구조를 살펴보았습니다.
다음 글에서는 마지막 기술 글로
운영 문서화 구조를 설명합니다.
다음 내용이 포함됩니다.
Runbook 문서
Security 문서
Proof 디렉토리 구조
Audit 기록
관련 경로:
docs/runbook/*
docs/security/*
docs/proof/latest/INDEX.md
이를 통해
코드뿐 아니라 운영 문서까지 남긴 이유
를 설명합니다.
설계 판단 (Why This Way?)
Prometheus AlertRule(5%)은 운영자 인지용 경고로, Airflow Auto Rollback(2%)은 자동 복구용으로 임계값을 2계층으로 분리하여 알림과 롤백의 민감도를 다르게 설정했습니다. 관측 시스템 장애가 잘못된 롤백을 유발하지 않도록 관측 실패 시 롤백을 건너뛰고, Auto/Manual Rollback을 분리하여 자동화와 수동 개입의 경계를 명확히 했습니다.
다음에 읽을 글
→ GitOps 기반 E2E ML Platform - 운영 문서화 — Runbook / Security / Proof 디렉토리 구조