호돌찌의 AI 연구소
article thumbnail

서빙 이후에 Inference가 잘 진행이 되고 있는지, Test data가 가정한 분포에 맞게 잘 들어오고 있는지 등등을 점검하는 부분인 모델 모니터링에 대해 알아보겠습니다.

 

1. Motivation

model을 품은 서버를 잘 배포했다고 가정을 했을 때 또 다른 벽을 마주하게 됩니다. 모델이 떠있는 inference 서버, 그 서버가 떠있는 Kubernetes 클러스터가 24시간 동안 100% 잘 돌아간다고 생각을 할 수 있을까요? 

굉장히 ideal한 예시로 비트코인 예측 모델을 구축을 했다고 가정하겠습니다. 이 모델을 flask로 감싸서, minikube cluster에 배포를 했다고 가정하겠습니다. 그리고 가진 재산을 넣고 수행한다고 가정하겠습니다. 

다음과 같은 이슈를 한번 생긴다고 가정해보겠습니다. 

 

- 수행하고 있는 inference 서버 다운

- 바이낸스 거래소 서버 다운

- 갑자기 분위기 전쟁 발발

- 파월 아저씨의 말도 안 되는 매파적 발언

 

등등 시장에 크게 영향을 미치는 이벤트가 발발해서 불안정한 서비스를 제공한다고 하면 일상생활을 하기 힘들다고 생각할 수 있습니다. (과거 비트코인 캐시 사태처럼, 포지션이 잡혀 있는데 거래소 이슈로 인해 물리는 것을 상상만 해도 끔찍합니다.) 따라서 모니터링의 목표는 안정적인 서비스를 제공하며, 지속적으로 성능을 개선하여 챔피언 모델을 배포를 하여야합니다. 

 

2. Monitoring의 수요

State of MLOps 2021 내용의 글을 소개하고자합니다. 제목 그대로 작년 mlops의 트렌드를 알 수 있습니다. 

https://valohai.com/state-of-mlops/

 

The State of MLOps 2021 Report

Where is the industry with MLOps today? The State of MLOps 2021 report details what teams are focusing on and what areas they've adopted tooling for.

valohai.com

당신의 업무를 가장 잘 설명하는 문장이 무엇이냐고 했을 때, 2020년만 해도 모델을 우선시 한다는 응답비율이 있었지만, 2021년에는 인프라를 더 우선적으로 개발한다는 응답이 있었습니다. 

 

최근에 사용한 툴은 어떤 분야냐고 물어봤을 때, 모델 모니터링에 대한 관심도가 늘어나고 있고, 이미 존재하는 것을 쓰는 것보다 더 좋은 것을 찾고 위해 노력을 하고 있다는 응답을 볼 수 있습니다. 

 

다음 3달 동안 어떤 분야에 집중할 것이냐고 물어봤을 때, 재학습과 제품화된 모델을 모니터링하는 응답도 상당히 증가했음을 알 수 있습니다. 

 

 

 

 

 

 

 

3. ML 모델 모니터링 점검 요소

2017년에 구글에서 낸 "The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction" paper입니다. 

https://static.googleusercontent.com/media/research.google.com/ko//pubs/archive/aad9f93b86b7addfea4c419b9100c6cdd26cacea.pdf

 

bold 체로 나타낸 내용을 취합하면 다음과 같습니다. 

이 부분을 ML 관련된 부분과 Ops 관련된 부분으로 나눌 수 있습니다. 표로 정리하면 아래와 같습니다. 

ML 관련 Ops 관련
Input Data 분포가 일정한가? Request Latency
Feature Distribution 분포가 일정한가? Request Error Rate
Output Data 분포가 일정한가? CPU, Memory Utilization
Performance(Eval) 기준을 충족하는 가? Disk I/O
모델 안정성 수치값이 일정한가? Network Traffic

 

4. ML 서비스가 모니터링이 어려운 이유?

시스템 관점에서는 소프트웨어 개발 관점에서는 늘 비슷합니다. (위의 표 Ops 관련) 하지만 ML 부분에 있어서는 기본적으로 성능평가를 위한 정량적인 Metric을 정의하기가 상당히 어렵습니다. (특히 추천 시스템 영역은 정말 정확한 Metric을 정의하기가 상당히 어렵습니다. CTR과 같은 Metric이 만능은 아니기 때문에) 평가 데이터도 잘 만들어야 하고, 지속적인 성능 평가를 잘해야 하는 부분이 있습니다.

또한 "특정 사이트 페이지 접속이 원활하지 않은 상황" 보다 "특정 사이트 고객 맞춤 추천 제품의 판매량 하락" 과 같은 문제가 더 이유를 명확하게 찾아내기가 어렵습니다.

또한 여러 통계분석, 도메인과 비즈니스 요소 등 다양한 지식들을 결합하여 의사결정 하는 것도 어렵습니다. 

 

 

5. 마치며

이런 여러 어려움을 딛고 이겨낼 모니터링을 위한 오픈소스 Prometheus, Grafana 에 대해 다음 글에서 다룰 예정입니다. 대략적인 구조와 사용방법만 작성할 예정입니다. 이 Tool들은 자유도가 높기에 잘 익혀둔다면 마주할 문제에 대해 Metric 모니터링 및 시각화가 가능할 것입니다. 

 


https://bit.ly/37BpXiC

 

패스트캠퍼스 [직장인 실무교육]

프로그래밍, 영상편집, UX/UI, 마케팅, 데이터 분석, 엑셀강의, The RED, 국비지원, 기업교육, 서비스 제공.

fastcampus.co.kr

 

* 본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

 

 

 

 

 


profile

호돌찌의 AI 연구소

@hotorch's AI Labs

포스팅이 도움이 되셨다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!