MLOps - # 7 Monitoring

jaewonnow_·2025년 11월 24일

MLOps

목록 보기
7/11

모니터링

→ 발전을 위해 왔던 길을 Review하고 Improve 해나가는 과정

Metric

메트릭은 시간별로 데이터가 수집되기에 그 양이 많다. 그래서 외부에 메트릭을 저장하는 DB를 두는데, 대표적으로 프로메테우스(Prometheus)가 있다.

시간이 지남에 따라 추이가 변하는 데이터를 메트릭(Metric)이라고 한다.

1. 실시간 시스템 및 인프라 모니터링

배포된 모델 서버 상태: 모델이 배포된 서버(예: Kubernetes 클러스터)의 CPU 사용률, 메모리, 디스크 I/O 등의 인프라 메트릭을 실시간으로 추적하여 병목 현상이나 장애를 조기에 감지해야 할 때 필요하다.

서비스 품질 (QoS): 모델 예측 API의 응답 지연 시간(Latency), 처리량(Throughput), 에러 코드 비율 등을 실시간으로 감시하고 시각화한다.

2. 운영 메트릭 및 경고 (Alerting)

실시간 경고: 특정 임계값(예: API 에러율 5% 초과, 서버 메모리 80% 초과)을 넘을 경우, Slack이나 이메일 등으로 자동 경고를 보내는 시스템을 구축하려면 Grafana의 강력한 경고 기능이 필요요할 때 사용한다.

비즈니스 메트릭 모니터링: 모델 예측 결과와 관련된 비즈니스 지표(예: 추천 클릭률, 사기 탐지 건수)를 수집 및 시각화하여 모델의 실제 비즈니스 영향을 파악해야 할 때 유용하다.

3. 데이터 드리프트(Data Drift) 감지

• 모델 예측 결과의 통계적 분포나 입력 피처의 통계가 시간이 지남에 따라 변하는 데이터 드리프트 현상을 모니터링할 때, Prometheus의 시계열 데이터 저장 능력이 활용될 수 있다.

3-1. 데이터 드리프트 감지란?

데이터 드리프트(Data Drift)

Training–Serving Skew ⊂ Data Drift (일부 경우)
→ Data Skew는 시스템의 버그 , Data Drift는 세상의 변화

= 운영 중 들어오는 데이터의 분포가 학습 데이터의 분포와 달라지는 현상

대표적으로:

  • feature 값 분포가 변화
  • 카테고리 비율이 변함
  • 평균/표준편차가 달라짐 → 결국 모델이 “낯선 데이터(= 세상의 변화)”를 만나게 되어 정확도 저하 발생

모델이 내는 예측값 - 그게 틀린답인지 아닌지는 어떻게 판단할까?

예측 품질 모니터링 = “예측값 vs 실제값(정답)” 비교

→ 문제는 정답(라벨)이 실시간으로 바로 생기지 않는다

그래서 모니터링 전략이 “라벨 유무에 따라” 2가지로 나뉨

라벨(정답)이 있는 경우 → Supervised Monitoring

이상적인 케이스

예를 들어:

  • 모델이 고객의 “이탈 여부”를 예측하고,
  • 실제로 2주 뒤 “진짜 이탈했는지 여부” 데이터가 들어오는 경우.

라벨(정답)이 없는 경우 → Proxy Monitoring (간접 품질 추정)

이게 현업에서 가장 흔한 상황.

예를 들어:

  • 추천 시스템, 실시간 광고, 챗봇 등은 즉시 정답을 모름.
  • 라벨(정답)이 늦게 들어오거나, 아예 들어오지 않을 수도 있음.

그래서 “예측이 변하는 패턴”을 가지고 간접적으로 품질을 추정한다.

Trigger

모니터링된 결과를 바탕으로 어느 시점에서부터 성능 저하로 정의할지 시점을 판단해야 한다.

  1. 규칙 정의: 팀은 모델의 재학습이 필요한 시점을 정의하는 규칙을 만듭니다. 예를 들어, "모델의 정확도가 90% 아래로 떨어지면", "새로운 데이터가 10GB 이상 쌓이면", "매주 일요일 자정에"와 같은 규칙을 정합니다.

  2. 자동화: 이 규칙은 코드로 작성되어 MLOps 파이프라인의 모니터링 시스템에 등록됩니다. 이 시스템은 규칙에 따라 데이터를 지속적으로 감시합니다.

  3. 실행: 규칙의 조건이 만족되면, 모니터링 시스템이 재학습 파이프라인을 자동으로 실행하도록 명령을 내립니다.

재학습 트리거는 주로 MLOps 파이프라인의 모니터링 컴포넌트에서 관리된다. 이 컴포넌트는 모델의 성능과 데이터를 지속적으로 감시하며, 특정 조건이 충족될 때 재학습을 시작하는 신호를 보낸다.

Trigger 설계

ML 서비스는 “사용자 행동, 데이터 도착, 성능 변화” 같은 이벤트로 움직이는 게 핵심.

그래서 단순 cron 보단 Kafka / Webhook / Airflow Sensor 같은“Event-Driven Trigger” 구조가 훨씬 적합

profile
0 to 100 Data Engineer

0개의 댓글