→ 발전을 위해 왔던 길을 Review하고 Improve 해나가는 과정
메트릭은 시간별로 데이터가 수집되기에 그 양이 많다. 그래서 외부에 메트릭을 저장하는 DB를 두는데, 대표적으로 프로메테우스(Prometheus)가 있다.
시간이 지남에 따라 추이가 변하는 데이터를 메트릭(Metric)이라고 한다.
• 배포된 모델 서버 상태: 모델이 배포된 서버(예: Kubernetes 클러스터)의 CPU 사용률, 메모리, 디스크 I/O 등의 인프라 메트릭을 실시간으로 추적하여 병목 현상이나 장애를 조기에 감지해야 할 때 필요하다.
• 서비스 품질 (QoS): 모델 예측 API의 응답 지연 시간(Latency), 처리량(Throughput), 에러 코드 비율 등을 실시간으로 감시하고 시각화한다.
• 실시간 경고: 특정 임계값(예: API 에러율 5% 초과, 서버 메모리 80% 초과)을 넘을 경우, Slack이나 이메일 등으로 자동 경고를 보내는 시스템을 구축하려면 Grafana의 강력한 경고 기능이 필요요할 때 사용한다.
• 비즈니스 메트릭 모니터링: 모델 예측 결과와 관련된 비즈니스 지표(예: 추천 클릭률, 사기 탐지 건수)를 수집 및 시각화하여 모델의 실제 비즈니스 영향을 파악해야 할 때 유용하다.
• 모델 예측 결과의 통계적 분포나 입력 피처의 통계가 시간이 지남에 따라 변하는 데이터 드리프트 현상을 모니터링할 때, Prometheus의 시계열 데이터 저장 능력이 활용될 수 있다.
데이터 드리프트(Data Drift)
Training–Serving Skew ⊂ Data Drift (일부 경우)
→ Data Skew는 시스템의 버그 , Data Drift는 세상의 변화
= 운영 중 들어오는 데이터의 분포가 학습 데이터의 분포와 달라지는 현상
대표적으로:
예측 품질 모니터링 = “예측값 vs 실제값(정답)” 비교
→ 문제는 정답(라벨)이 실시간으로 바로 생기지 않는다
그래서 모니터링 전략이 “라벨 유무에 따라” 2가지로 나뉨
이상적인 케이스
예를 들어:
이게 현업에서 가장 흔한 상황.
예를 들어:
그래서 “예측이 변하는 패턴”을 가지고 간접적으로 품질을 추정한다.
모니터링된 결과를 바탕으로 어느 시점에서부터 성능 저하로 정의할지 시점을 판단해야 한다.
규칙 정의: 팀은 모델의 재학습이 필요한 시점을 정의하는 규칙을 만듭니다. 예를 들어, "모델의 정확도가 90% 아래로 떨어지면", "새로운 데이터가 10GB 이상 쌓이면", "매주 일요일 자정에"와 같은 규칙을 정합니다.
자동화: 이 규칙은 코드로 작성되어 MLOps 파이프라인의 모니터링 시스템에 등록됩니다. 이 시스템은 규칙에 따라 데이터를 지속적으로 감시합니다.
실행: 규칙의 조건이 만족되면, 모니터링 시스템이 재학습 파이프라인을 자동으로 실행하도록 명령을 내립니다.
재학습 트리거는 주로 MLOps 파이프라인의 모니터링 컴포넌트에서 관리된다. 이 컴포넌트는 모델의 성능과 데이터를 지속적으로 감시하며, 특정 조건이 충족될 때 재학습을 시작하는 신호를 보낸다.
ML 서비스는 “사용자 행동, 데이터 도착, 성능 변화” 같은 이벤트로 움직이는 게 핵심.
그래서 단순 cron 보단 Kafka / Webhook / Airflow Sensor 같은“Event-Driven Trigger” 구조가 훨씬 적합