[MLOps 해제(解題) 1] MLOps workflow에 대한 기본 이해
해당 책은 아래와 같은 구성으로 이뤄져 있다. 해당 포스팅은 Section 1을 다룬다.
| 3 | |
| 27 | |
| 51 | |
| 79 | |
| 103 | |
|
Deploying Machine Learning Models at Scale
|
133 |
|
Key Principles for Deploying Your ML System
|
135 |
|
Building Robust CICD Pipelines
|
165 |
| APIs and Microservice Management | 191 |
|
Testing and Securing Your ML Solution
|
213 |
|
Essentials of Production Release
|
229 |
|
Monitoring Machine Learning Models in Production
|
253 |
|
Key Principles for Monitoring Your ML System
|
255 |
|
Model Serving and Monitoring
|
275 |
|
Governing the ML System for Continual Learning
|
311 |
|
About Packt
|
339 |
|
Other Books You May Enjoy
|
340 |
|
Index
|
343 |
Fundamentals of an MLOps workflow
전통적인 소프트웨어 개발방식과 MLOps와의 차이: 데이터와 코드를 둘다 다뤄야하는 ML문제
ML을 이용한 서비스가 점차적으로 확대될 것이라는 것에 이 챕터의 내용이 강조되고 있다. 여태까지 소프트웨어의 발전은 보통 "개발업무(development)"라는 것으로 취급되어서, Waterfall 방식, Agile 방식, DevOps방식으로 쭉 진행되어왔다. 소프트웨어의 개발이 더 큰 개념이기 때문에, 열거한 3가지 방식중에 최근 방식인 Agile/DevOps로 해결하면 되는것이 아닌가? 생각을 하게된다. 하지만, 현업에서는 많은 실패사례들이 존재한다. 왜 그럴까? 이 책에서는 ML을 이용한 서비스가 실패하는 이유를 말하는데, 전통적인 소프트웨어 개발과의 차이점을 강조한다.
Machine Learning = data + code
DevOps라고하면, 지속적으로 코드를 개발하고, 업데이트하고, 사용자가 일부 개발과정을 포함해서 지속적으로 개발/도입/운영할 수 있는 개발방식으로 여겨지는데, MLOps도 이와 같이 했을 경우는 코드는 업데이트되지만, 데이터는 업데이트 안된다는 것에 단점이 있다. 따라서, 데이터와 코드가 지속적으로 함께 관리되어야함을 강조한다. 예) 모델은 최신모델인데 과거데이터를 쓰거나, 현재 데이터만을 이용해서 향후에 서비스 방식이 바뀌면 재도입이 어려운 것들에 대한 문제가 이해 해당된다. 이러한 단점을 줄이기 위해서 MLOps은 체계적인 방식으로 "data"와 "code(model)"을 같이 운영하는 것을 목표로한다. 이를 위해서, 모델의 개발, 도입(depolyment), 모니터링등알 함께 지속적인 방식으로 도입하는 것을 의미한다.
MLOps의 워크플로우: 어떤방식으로 진행이되나?
Figure 2은 MLOps의 워크플로우의 개념도이다. 두 형태로 나뉘는데, 상위(Build, Delopy, Monitor)은 주로 MLOps pipeline이라고 불린다.한편 하위는 Driver(드라이버)라고 불린다.
- MLOps pipeline: 모델 개발, 적용, 적용후 모니터링에 대한 업무의 개요에 해당된다.
- Driver: MLOps pipeline을 하기위해서 실제로 행해야하는 하위 테스크, 구성되어야하는 인프라 등을 일컫는다.
MLOps업무를 해본사람이면 대부분 이해할 수 있는 개념이다. 참고로, model packaging, model registering, application testing 에 관한 내용만 추가로 아래와 같이 기술해 놓았다.
- Model packaging: 모델을 직렬화하고, 독립적인 소프트웨어로 작동할 수 있게끔 컨테이너화하는 단계를 의미한다. 주로 ONNX file로 모델을 직렬화한다. ML모델을 Training/Testing으로 나누고 실제 잘 개발되었다고하자. 더 이상 이 모델은 현시점에서 바뀔일이 없다. 따라서, Pickling을 하든, ONNX로 변경하든 직렬화해놓고, 메모리에 로드하여 바로 쓸 수 있는 단계로 만드는 일에 해당된다. 그리고, 이 직렬화한 모델을 독립적인 소프트웨어로 쓸 수 있도록, Docker등으로 필요한 데이터, 종속코드 등을 하나로 묶어 만들어놓는 것을 의미한다.
- Model registering: 모델레지스터링은 직렬화+패키징된 모델을 DB등과 같은 레지스트리에 등록/저장해놓는 것을 의미한다. 이렇게 해놓으면, 언제든지 해당 모델이 필요할 때, 다운로드 받아서 쓸 수 있다.
- Application testing: 동의어로 Pre-production testing이라고 생각하면된다. 모델을 개발해놓고, 실제 운영에 쓰기전에 진짜 쓸만한것인지를 Extra validation하는 것과 같다. API나 쿠버네티스, 컨테이너로 띄워놓고 훈련용이 아닌, 추가적인 테스트용도로 데이터를 보내보고, 모델이 기대하는 것과 잘 동작하는지를 의미한다. Application testing의 결과는 도메인 전문가가 직접 결과를 분석하기도 한다(실제로 잘되었는지 확인해야하니까..), 도메인 전문가가 쓸만하다라고 판단해준 이후에나 실제 개발환경에 넣고, 추론할 수 있는 대기상태로 만들어두는 것이다.
MLOps 파이프라인의 예시: 희귀질환 환자의 유전변이추천시스템을 개발했다고 하자.
- 이 개발할 때 썼던 데이터는 2021년 이전의 데이터였다. 그렇게 만들어낸 Top 5 recall이 96.3%였다. 여기까지가 Model build이다.
- 이 모델을 바로 쓸 수 있도록, ONNX으로 직렬화하고 docker image로 만들어 내었다(model packaging).
- 이렇게 모델패키지한 것을 도커 이미지 리포지토리에 올려놓았다(model registering, 완벽한의미의 regstering은 아님).
- 그리고 나서, 임상유전학자들이 판독에 쓰기직전에 추가적으로 2022년 이후의 데이터를 모아놓고, 추천시스템 API을 띄워놓은 상태에서 모아놓은 데이터를 추론해보았다. 2022년 이후의 데이터를 추론했을 때의 결과가 20개중에, top 3가 95%이상이었다. 이 결과를 임상유전학자에게 다시 보냈다(Application testing).
- 그 후에 model production에 쓸 수 있도록 운영 서버로부터 데이터수 있도록 Restful API을 오픈했다.