[MLOps] 06 Model Monitoring - Prometheus

포스팅 개요

모델의 serving(배포)까지 성공했다면, 그 다음 단계는 무엇일까요?

그것은 바로 배포한 모델이 우리의 의도대로 동작하고 있는지에 대한 확인일 것입니다.

모델이 서비스화 되는 과정에서 예상치 못한 문제가 발생하지는 않았는지, 모델 자체가 불완전하지는 않은지 등 사전에 고려하지 못한 이슈를 발견하고 해결하기 위해 우리는 모델을 모니터링 할 필요가 있습니다.

이에 본 포스팅에서는 ML Model Monitoring의 방법론과 Prometheus, Grafana에 대하여 정리해보겠습니다.

Model Monitoring

Model Monitoring과 그 구성 요소

Model Monitoring이란, ‘serving한 모델의 지속 가능한 운영을 위한 관리’로 정리할 수 있습니다.

그렇다면 모델의 지속 가능한 운영을 위해 구체적으로 무엇을 모니터링 해야 할까요?

아래 Model Monitoring이 포함해야할 구성 요소들을 살펴봅시다.

• 구글에서 발표한 논문인 The MLTest Score: ARubric for ML Production Readiness and Technical Debt Reduction에서는 reliable한 production level의 ML Model의 monitoring의 일곱 가지 구성 요소에 대해 소개합니다.
• The MLTest Score: ARubric for ML Production Readiness and Technical Debt Reduction
  • Dependency changes result in notification: ML model에 종속된 요소들의 변화
  • Data invariants hold in training and serving inputs: training input에서와 serving input에서의 데이터 불변량이 동일한지
  • Training and serving features compute the same value: training features와 serving features이 같은 값을 계산하는지
  • Models are not too stale: 모델 업데이트가 필요하지는 않은지
  • The model is numerically stable: 모델이 수치적으로 안정적인지 → 갑자기 NaN 또는 무한대 값이 발생하지 않는가에 대한 모니터링을 의미합니다
  • The model has not experienced dramatic or slow-leak regression in training speed, serving latency, throughput, or RAM usage: 모델이 느려지고 있지는 않은지
  • The model has not experienced a regression in prediction quality on served data: 모델이 serving에서의 데이터에 대해 잘 예측하고 있는지
• ML model에 대한 monitoring 요소들과 Operation에서의 monitoring 요소들로 나누어 살펴볼 수도 있습니다. Operation에서의 monitoring 요소들은 DevOps에서의 monitoring요소로도 볼 수 있겠습니다.
• ML monitoring vs Ops monitoring
  • ML
    • Input Data Distribution
    • Feature Distribution
    • Output Data Distribution
    • Performance (Evaluation)
    • Mode Stability
  • Ops
    • Request Latency
    • Request Error Rate
    • CPU, Memory Utilization
    • Disk I/O
    • Network Traffic

• Question? Answer!
  • 이슈 발생을 알리는 알람 로직
  • 분석을 위한 로그 기록
  • 이슈를 해결한 commit 추가한 후 새로 배포를 했을 때 정상적으로 작동하는지를 확인하기 위한 end-to-end test의 자동화
• Model Monitoring의 목적은 문제 발견에 그치는 것이 아니라, 발견한 문제에 대한 해결까지일 것입니다. 이를 위해서는 모델에 이슈가 생겼을 때 관리자에게 이슈가 발생했다는 사실이 전달되어야 하며, 문제가 해결된 뒤 서비스가 정상적으로 작동하는지 확인할 수 있어야 합니다.

위와 같은 구성 요소들을 갖춘 Model Monitoring 오픈소스로는 Prometheus와 Grafana가 있습니다.

Prometheus

Prometheus & Grafana

Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud - Prometheus

Prometheus는 2012년 SoundCloud 에서 만든 모니터링 및 알람 프로그램으로, 쿠버네티스에 종속적이지 않고, binary 혹은 docker container 형태로도 사용 및 배포가 가능합니다. 그러나 구조 상 쿠버네티스와 궁합이 맞고, 다양한 플러그인이 오픈소스로 제공되기 때문에 쿠버네티스 생태계의 오픈소스 중에서는 사실상의 표준이라고 할 수 있습니다.

특징

• 수집하는 Metric 데이터를 다차원의 시계열 데이터 형태로 저장
• 데이터 분석을 위한 자체 언어 PromQL 지원
• 시계열 데이터 저장에 적합한 TimeSeries DB 지원
• 데이터 수집하는 방식이 Pull 방식
  • 모니터링 대상의 Agent가 Server로 Metric을 보내는 Push 방식이 아닌, Server가 직접 정보를 가져가는 Pull 방식
  • Push 방식을 위한 Push Gateway 도 지원
• 다양한 시각화 툴과의 연동 지원
• 다양한 방식의 Alarming 지원

구조

https://prometheus.io/docs/introduction/overview/

• Prometheus Server
  • 시계열 데이터를 수집하고 저장
• Service Discovery
  • Monitoring 대상 리스트를 조회
  • 사용자는 쿠버네티스에 등록하고, Prometheus Server 는 쿠버네티스 API Server 에게 모니터링 대상을 물어보는 형태
• Exporter
  • Prometheus가 metrics을 수집해갈 수 있도록 정해진 HTTP Endpoint를 제공하여 정해진 형태로 metrics 를 Export
  • Prometheus Server가 이 Exporter의 Endpoint 로 HTTP GET Request를 보내 metrics를 Pull 하여 저장
  • 하지만, 이런 pull 방식은 수집 주기와 네트워크 단절 등의 이유로 모든 Metrics 데이터를 수집하는 것을 보장할 수 없기 때문에 Push 방식을 위한 Pushgateway 제공
• Pushgateway
  • 보통 Prometheus Server 의 pull 주기(period) 보다 짧은 lifecycle 을 지닌 작업의 metrics 수집 보장을 위함
• AlertManager
  • PromQL 을 사용해 특정 조건문을 만들고, 해당 조건문이 만족되면 정해진 방식으로 정해진 메시지를 보낼 수 있음
    • ex) service A가 5분간 응답이 없으면, 관리자에게 slack DM과 e-mail을 보낸다.
• Grafana
  • Prometheus 와 항상 함께 연동되는 시각화 툴
• PromQL
  • Prometheus가 저장한 데이터 중 원하는 정보만 가져오기 위한 Query Language 제공

단점

• Scalability(확장성), High Availability(유효성)를 보장하기 어려움
  • Prometheus Sever가 Single node 로 운영되어야 하기 때문에 발생하는 문제
  • ⇒ Thanos 라는 오픈소스를 활용해 multi prometheus server 를 운영