MLOps 개론

주저리주저리 많이 적으니깐 강의가 감당이 안된다.
하지만 확실히 기억에 오래 남을거 같다. 
그래도 다음 강의부턴 정리를 줄인다. 

이 글은 네이버 부스트캠프 ai tech 변성윤 강사님의 강의를 참고하여 작성한 글입니다.
문제가 있거나 틀린점이 있다면 말씀해주세요 :)

모델 개발 프로세스 - Research 

1. 문제정의
2. EDA
3. Feature Engineering
4. Train
5. Predict요

고정된 데이터를 사용하여 학습,

학습된 모델을 앱,웹서비스에서 사용할 수 있도록 만드느 과정이 필요하다.
이런 경우 Real World, Production 환경에 모델을 배포한다고 표현 !

---

모델 개발 프로세스 - Production

1. 문제정의
2. EDA
3. Feature Engineering
4. Train
5. Predict
6. Deploy

웹, 앱 서비스에서 활용할 수 있게 만드는 과정
모델에게 데이터(Input)을 제공하면서, 예측(Output)을 요청.

모델이 배포되었다고 가정하자.

1. 모델의 결과값이 이상한 경우가 발생했다

• 원인 파악 필요
• Input데이터가 이상한 경우가 존재(x값이 0~100 이내여야하는데 Input으로 200이 들어오는 경우
• Research 할 땐 outlier로 제외할 수 있지만, 실제 서비스에선 제외가 힘든 상황 (별도 처리 필요)

2. 모델의 성능이 계속 변경

• 모델의 성능은 어떻게 확인할 수 있을까?
• 예측값과 실제 레이블을 알아야 함
• 정형(Tabular)데이터에서는 정확히 알 수 있지만, 비정형 데이터(이미지 등)은 잘 모를 수 있음.

3. 새로운 모델이 더 안좋다면?

• 과거의 모델을 다시 사용해야 함
• Research 환경에선 성능이 더 좋았던 모델이 production환경에선 더 좋지 않을 수 있음
• 이전 모델을 다시 사용하기 위한 작업이 필요

4. 그 외에도 다양한 이슈가 존재...

머신러닝 모델링 코드는 머신러닝 시스템 중 일부에 불과하다.

Hidden Technical Debt in Machine Learning Systems, NEURIPS, 2015

https://zzsza.github.io/data/2018/01/28/hidden-technical-debt-in-maching-learning-systems/

MLOps란?

MLOps = ML + Ops(Operations)
머신러닝 모델을 운영하면서 반복적으로 필요한 업무를 자동화시키는 과정
머신러닝 엔지니어링 + 데이터 엔지니어링 + 클라우드 + 인프라

머신러닝 모델 개발(ML Dev)과 머신러닝 모델 운영(Ops)에서 사용되는 문제, 반복을 최소화하고
비즈니스 가치를 창출하는 것이 목표

모델링에 집중할 수 있도록 관련된 인프라를 만들고, 자동으로 운영되도록 만드는 일

변성윤 마스터님의 설명이다.
반복을 최소화하고, 모델링에 집중할 수 있도록 관련된 인프라를 만들고, 자동으로 운영되도록 만드는 일 
너무 멋지다..

최근엔 비즈니스 문제에 머신러닝/딥러닝을 적용하는 Case가 많아짐.
Production 환경에 배포하는 과정엔 Research의 모델이 재현 가능해야 함.

• 현실의 Risk 있는 환경에서 잘 버틸 수 있어야 함

MLOps의 목표는 빠른 시간내에 가장 적은 위험을 부담하며 아이디어 단계부터 Production단계까지
ML프로젝트를 진행할 수 있도록 기술적 마찰을 줄이는 것

Reserch와 Production의 차이

	Reserch ML	Production ML
데이터	고정(Static)	계속 변함 (Dynamic-Shifting)
중요 요소	모델 성능(Accurach,RMSE 등)	모델 성능, 빠른 Inference속도, 해석가능함.
도전과제	더 좋은 성능을 내는 모델(SOTA), 새로운 구조의 모델	안정적인 운영, 전체 시스템 구조
학습	(데이터는 고정) 모델 구조, 파라미터 기반 재학습	시간의 흐름에 따라 데이터가 변경되어 재학습
목적	논문 출판	서비스에서 문제해결
표현	Offline	Online

데이터

• res : e.g)5000장가지고 train, validation 나눠서 학습.
• pro : 계속 변함. 새로운 데이터는 계속 유입된다. 그렇다면 validation은 고정될까?

유입되는 데이터에서 틀린 이미지를 새로 학습하고 함께 유입된 유사한 이미지를 validation 데이터로 추가할 것 같다. 

중요 요소

• Inference속도는 styleGAN 프로젝트에서 너무나도 큰 문제점으로 다가왔었다. 실제 서비스 된다면 그걸 기다리는 소비자는 몹시 적을것이다.

학습

• 시간의 흐름에 따라 데이터가 변경되어 재학습이 가능해야 하는데 dataset에도 버전이 존재한다 !

MLOps Component

변성윤 마스터님의 타코집 예시 ! 
나는 가끔.. 집에서 타코를 만든다..
내가 만든 타코가 너무 맛있어서 가끔 고민에 빠진다. -> 레시피를 공유할까? 장사할까?

타코레스토랑 창업 ! 
집(research) <-> 레스토랑(production) : 
집 : 마트에서 재료를 산다.
레스토랑 : 재료 납품, 업소용 소스를 사용, 비슷하지만 살짝 다른 내용 !
타코 : Model
재료,소스 등 : Data/ Feature

장소 선정시 고려할 부분
- 유동 인구가 얼마나 있는가? (= 예상되는 트래픽이 얼마나 되는가?)
- 가게의 평수 (= 서버의 GPU, Memory 성능은 어느정도 할 것인가?)
- 점포 확장이 가능한가 (= 스케일업, 스케일 아웃이 가능한가?)
- 직접 장소를 구입할지? 월세로 사용할지?(=자체 서버 구축, 클라우드) 
+ 특정 회사는 클라우드를 사용할 수 없다. (= 금융권)
- 레스토랑에서 비싼 식기를 사는것은 아까울 수 있어서 임대하는 경우 (= 클라우드 GPU)


클라우드 : AWS, GCP, Azure, NCP 등
온 프레미스 : 회사나 대학원의 전산실에 서버를 직접 설치 -> NVIDIA(DGX), 조립식컴퓨터 등등

Batch Serving은 많은 양(=많은 데이터)을 일정 주기(1일 1주 1달 등)로 한꺼번에 음식을 서빙(=예측)

Jupyter NoteBook에서 실행하는 방식은 대부분 Batch Serving으로 쉽게 변경 가능(Dataframe의 데이터를 한번에 예측)

Online Serving은 한번에 하나씩(=실시간)포장해서 배송(=예측) 동시에 여러 주문이 들어올 경우 병목이 없어야하고, 확장 가능하도록 준비해야함

Experiment, Model Management

집에서 요리 만들때, 레시피를 기록해야 어떤 조합이 좋은지 알 수 있음(파라미터,모델 구조 등)
"소금 대충 넣고 케찹 쫌 뿌리니깐 맛있다 ?!" -> 재현 불가능. 
집(Research)에서 Best 레시피를 만들었다면 레스토랑(Product)에서 사용하게 됨.

요리 만드는 과정에서 생기는 부산물 저장! (= 모델 Artifact, 이미지 등 eg: pickle파일,...,)

타코(모델)는 다양한 종류가 있으므로 
언제만든 타코인지(모델 생성일), 얼마나 맛있었는지(모델 성능), 유통기한 등(모델 메타 정보)를 기록해둘 수 있음. 

MLFlow
mlflow.sklearn.autolog()만 작성해도 실험한 내용을 저장해준다.. 좋은 협업툴이 될 수도 있음 (like WandB)

요리별로 사용되는 재료들이 중복됨. 반죽이나 간 등을 미리 만들면 편함.
이런 재료를 가공해서 냉장고에 저장(=머신러닝 Feature를 집계한 Feature Store) 
=> 정형데이터에서 많이 나옴.
요리별로 필요한 재료를 바로 사용, 요리 만들 때 재료 만드는 시간이 소요되지 않아 편함.

집과 레스토랑에서 같은 재료를 사용하도록 냉장고를 구축해놓으면 장사할때 편리함. => Feature Store
라이브러리가 적음.
from feast import FeatureStore !! 
라이브러리 사용보다는 직접 개발하는 경우가 더 많음

재료들이 예전에 요리할 때 사용한 재료와 비슷한지 확인할 필요가 있다. (=Feature의 분포 확인)
재료가 변하면 음식이 달라지므로 잘 신경쓰자 ! (=> Feature의 분포를 잘 확인해보자!)

train과 serving했을때의 분포 차이를 맞춰줘야 함.
Keyword : 
-	Performance decay: Concept drift, model drift, data drift
library를 쓰면 좋을지 모르겠지만 존재함. 
TFDV(Tensorflow Data validation)
AWS Deequ : Unit Test for data, Data Quality 측정
import com.amazon.deequ.VerificationSuite
우리가 의미하는 데이터만 들어오는지 확인해야함.

Continuous Training
만들었던 요리를 언제부터 고객분들이 좋아하지 않는다. 신선한 재료로 다시 만들어야한다. (Retrain)
다시 요리하는 경우
1. 신선한 재료가 도착한 경우(=새로운 데이터)
2. 일정 기간(매일 매시간)
3. 갑자기 매출이 줄어들 경우(Metric 기반)
4. 요청시 



레스토랑의 매출, 손님 수, 대기열 등(=모델의 지표, 인프라의 성능 지표 등)을 잘 기록해야함.
집에서 만든 요리법이 레스토링에서 얼마나 많이 팔리는지 확인해서 추가로 아이디어 얻을 수 있음.
- 얼마나 판매되었는지?
- 어느 시간대에 주문이 몰리는지?

AutoML
시대가 좋아져서 자동으로 음식을 만들 수도 있음 => 에어프라이어(AutoML)에 넣기만 하면 집, 레스토랑에서 모두 활용 가능.

MLOps Component - 정리

1. 인프라(서버,GPU)
2. Serving
3. Experiment, Model Management
4. Feature Store
5. Data Validation(Data Management)
6. Continuous Training
7. Monitoring
8. AutoML

집에서 요리하던 사람이 레스토랑을 운영하면서 신경써야 하는 부분
= 머신러닝 모델을 직접 운영하면서 신경써야 하는 부분 
밀키트? => pretrain model을 밀키트와 비교할 수 있지 않을까?

MLOps는 회사의 비즈니스 상황과 모델 운영 상황에 따라 우선순위가 달라짐
앞선 모든 요소가 항상 존재해야 하는 것은 아님을 꼭 인지하기

MLOps를 처음부터 진행하는 것이 오히려 비효율적일 수 있음

처음엔 작은 단위의 MVP(Minimal Value Product)로 시작해서
점점 운영 리소스가 많이 소요될 때 하나씩 구축하는 방식을 활용 

! 핵심 과제!
1. MLOps가 필요한 이유 이해하기
2. MLOps의 각 Component에 대해 이해하기(왜 이런 Component가 생겼는가?)
3. MLOps 관련된 자료, 논문 읽어보며 강의 내용 외에 어떤 부분이 있는지 파악해보기 
4. MLOps Component 중 내가 매력적으로 생각하는 TOP3을 정해보고 왜 그렇게 생각했는지 작성해보기

MLOps 개론

변성윤 선생님의 후반부 멘트가 기억에 남는다.

"MLOps를 처음부터 진행하는 것이 오히려 비효율적일 수 있으니, 처음엔 작은 단위의 MVP부터 시작해서
2번 3번 반복하게 되면 그때 필요한것들을 구축하는 것도 좋은 방법이다."

MLOps의 경우 나에게는 자동화라는 느낌이 강하게 다가오는데 자동으로 처리할 일이 생긴다면, 고려해야할 일, 예외처리가 몹시 많을 것이다. 코딩테스트와 유사하다고 생각하는데 최대한 많은 것을 고려해서 만들어놔도 예외는(코딩테스트의 Hidden test case) 항상 발생할 것이고, 이에대한 실수를 줄이고 필요한 것을 잘 파악하려면 2~3번은 직접 흐름을 따라가보며 만들어보고 그 과정에서 꼭 필요한 것들, 예외들을 발견하는것이 중요해보인다.

1. MLOps가 필요한 이유 이해하기

개론강의를 들은 나의 생각은 다음과 같다.

모델 잘만들어놓은거로 돈벌자 !
잘갖춰진 인프라로 놓은거로 적게 일하고 많이 벌 수 있도록 하자 !
많은 사람들이 활용할 수 있도록 하자 !

ㅋㅋ..면접이나 이력서 그런게 아니라 정리하는 글이여서 말 할 수 있는 가감없이 든 생각이다.
정말 좋은 모델을 만들어놨다면 어떻게 시장에 내놓을지, 관리할지, 문제점(연구에서 사용된 데이터의 분포와 실제 데이터의 분포 차이, 예측하지 못한 인풋 데이터 등.), 리스크를 다루는 것이 필수적이다. MLOps가 이러한 역할을 한다고 생각되기에 필수적이라고 생각한다.

이루다도 MLOps가 조금 더 발전되었다면 살아남을 수 있었을까??

2. MLOps의 각 Component에 대해 이해하기(왜 이런 Component가 생겼는가?)

1. 인프라(서버,GPU)
2. Serving
3. Experiment, Model Management
4. Feature Store
5. Data Validation(Data Management)
6. Continuous Training
7. Monitoring
8. AutoML

타코가 아닌 옷으로 설명해보자!
작년에 무슨 옷을 입고 다녔는지 이번 겨울엔 입을 옷이 없다. 심지어 작년 겨울에 옷도 많이 산 거 같은데,,
안부족하려면 한트럭을 갖다놔야하나? 직접 만들자! 만든 옷으로 장사를 하면서 내 옷도 챙기자! (엄청난 스토리텔링 보고있슴니까 마스터님?)

1. 옷은 넓은 공간을 필요로 하지않는다. 많은 옷을 잘 배치해놓는다면 적은 공간에 많은 옷을 보여줄 수 있고 사람이 오래 머무르지 않는다. 하지만 너무 좁다면 사람들이 원하는 옷을 찾기 힘들것이다.

(가벼운 모델이며, 적당한 크기(?)의 인프라 필요)

2. 옷은 내가 직접 만들수도, 공장에서 떼올수도 있다. 공장에서 떼올경우 말그대로 찍어내는 옷을 대량으로 도매가에 구매하여 판매하면 이익을 남길 수 있을것이다. 하지만 바로 옆 옷가게도 같은 공장, 브랜드를 사용한다면?! 내가 만든 옷에 집중하거나 다른 공장을 찾거나 좀 더 커스터마이징하거나 가게의 접근성을 높히고, 이쁘게 꾸미고, 확장하고, 홍보하면 된다. - 그래도 사람이 옆가게로 간다면 조금 더 큰 손해를 입겠지만 ;-;

내가 만든 옷 -> Research! 다른공장이라 하면,, github밖에 생각되지 않습니다,, 
예를 들어 다른팀에서도 BabyGAN을 github에서 클론하여 사용했다면?! 
우리팀은 BabyGAN을 커스터마이징하고, 최적화하고, inference time동안 흥미를 끌만한 요소를 보여주고, 
내부에서 사용되는 Resnet모델을 미리 서버에 올려놓고,, -> 옷가게 안에 공장 직원이?!

3. -4-6(?). 옷의 경우 유행을 많이 탄다. 아직까지 노x페이스700 패딩을 올려놓고 팔리길 기도한다면 패션은 돌고 돈다지만 옷가게에서 차지하는 패딩 부피에 대한 자리값은 노스x이스에 청구할것도 아니고,, 끊임없이 유행을 쫓아야된다. 조금 더 짧은 주기로 보면 계절마다 파는 옷의 종류가 바뀔 것이다. 하지만 계절은 조금 더 빠른 속도로 돌고 돈다. 작년 여름에 너무 잘팔려서 이번 여름에도 사람들이 입고 다닌다면?! 이번년도에도 잘팔릴 확률이 크지않을까? 비슷한게 또 유행하지 않을까?

4. 내가 판 옷에 대한 불량품 문의 및 환불이 많이 들어오기 시작했다. 옷이 변색되고, 줄고, 늘어나는 등 다양한 문제가 생겼는데 이러한 문제가 제기되는 옷들의 원단은 비슷하다는걸 알게 됐다 ! 문제가 되는 해당 원단은 적당한 원단으로 교체해야한다.

5. 내가 만든 옷들이 잘팔리기 시작했다. 겨울이라 보온성이 강해서 잘팔리는줄도 모르고 여름에도 가게의 많은 자리를 차지하며 진열해놨고, 날이 따듯해지자 안팔리는걸 확인했다. 옷의 원단을 통풍이 잘되는거로 바꿔야 할 필요가 있다.

6. 알바가 들어왔다. 원단만 가져다주면 옷도 만들어주는데 나보다 더 잘만든다. 기가 막히다. 알바가 좀만더 잘알게되면 원단도 알아서 구해달라해야겠다...

위의 component에 대해 비교하며 생각해봤다.
장사가 안그래도 이렇게 힘든데 코로나라니.. 22년엔 코로나 끝났으면~

4. MLOps Component 중 내가 매력적으로 생각하는 TOP3을 정해보고 왜 그렇게 생각했는지 작성해보기

1. 인프라(서버,GPU)
2. Serving
3. Experiment, Model Management
4. Feature Store
5. Data Validation(Data Management)
6. Continuous Training
7. Monitoring
8. AutoML

나는 2,3,5,6,8(인기상)을 선택하겠다 !
Feature Store, Infra, Monitoring은 잘 몰라서 매력적이게 느껴지지않는다. 모든 강의 내용을 정리하고 어느정도 알게 된다면.. 그때 다시 적어보는것도 좋을거 같다.

Serving의 경우 만들어진 인공지능을 유용하고 쉽게 사용하도록 해준다. 얼마나 매력적인가..

Experiment, Model Management 실험은 언제나 흥미롭고 그 모델을 애지중지 관리하는것.. 멋있다.

Data Validation(Data Management) 산학공동프로젝트에서 손에 대한 영상을 촬영하고 하나하나 라벨링하다가,, 자동화,, 뭐 반 자동화 정도,,사람이 직접 검사해야하는 과정이 있었지만 아무튼 반자동화 했는데 삶의 질이 달라졌다. 더 편해질 수 있었는데 부캠 빨리 들을걸..

---

model serving 강의를 한바퀴 다 돌고 다시 읽으며 순위를 고르자면... 못고르겠다. 전부 중요하고, 매력적인 Component들이다. 갈길이 멀군요 :)