-
MLOps 개론
-
모델 개발 프로세스 - Research
- 문제 정의
- EDA
- Feature Engineering
- Train
- Predict
- 해당 과정은 고정된 데이터를 사용해 학습
- 학습된 모델을 앱,웹 서비스에서 사용할 수 있도록 만드는 과정이 필요 이런 경우 Real World, Production 환경에서 모델을 배포한다고 표현
-
모델 개발 프로세스 - Production
- 앱, 웹 서비스에서 활용할 수 있게 만드는 과정
- "모델에게 데이터(Input)를 제공하면서, (Output) 예측해주세요"라고 요청
- 모델의 결과값이 이상한 경우가 존재
- 원인 파악 필요
- Research 할 땐 Outlier로 제외할 수 있지만, 실제 서비스에선 제외가 힘든 상황
- Input 데이터가 이상한 경우가 존재
- 모델의 성능이 계속 변경
- 새로운 모델이 더 안 좋다면?
- 머신러닝 모델링 코드는 머신러닝 시스템 중 일부에 불과함
- 앱, 웹 서비스에서 활용할 수 있게 만드는 과정
-
MLOps란?
- MLOps = ML (Machine Learning) + Ops (Operations)
- 머신러닝 모델을 운영하면서 반복적으로 필요한 업무를 자동화시키는 과정
- 머신러닝 엔지니어링 + 데이터 엔지니어링 + 클라우드 + 인프라
- 머신러닝 모델 개발(ML Dev)과 머신러닝 모델 운영(Ops)에서 사용되는 문제, 반복을 최소화하고 비즈니스 가치를 창출하는 것이 목표
- 모델링에 집중할 수 있도록 관련된 인프라를 만들고, 자동으로 운영되도록 만드는 일
- Production 환경에 배포하는 과정엔 Research의 모델이 재현 가능해야 함
- 현실의 Risk 있는 환경에서 잘 버틸 수 있어야 함
- MLOps의 목표는 빠른 시간 내에 가장 적은 위험을 부담하며 아이디어 단계부터 Production 단계까지 ML 프로젝트를 진행할 수 있도록 기술적 마찰을 줄이는 것
-
-
MLOps Component
-
Server Infra
- 집에서는 그냥 요리하면 되지만, 레스토랑을 위해선 "장소"가 필요합니다
고려해야할 부분
- 유동 인구 (= 예상 트래픽)
- 가게의 평수 (= 서버의 CPU, Memory 성능)
- 점포 확장 가능 여부 (= 스케일 업, 스케일 아웃 가능 여부)
- 직접 장소를 구입할지? 월세로 할지? (= 자체 서버 구축, 클라우드)
- 집에서는 그냥 요리하면 되지만, 레스토랑을 위해선 "장소"가 필요합니다
-
GPU Infra
-
Infra
- 클라우드 : AWS, GCP, Azure, NCP 등
- 온 프레미스 : 회사나 대학원의 전산실에 서버를 직접 설치
-
Serving
- Batch Serving
- Online Serving
- Serving Map
- Batch Serving
-
Experiment, Model Management
- 레시피를 기록해야 어떤 조합이 좋은지 알 수 있음(파라미터, 모델 구조 등)
- 여러 시행착오를 겪으며 요리함
- 제일 맛있었던(성능이 좋았던) 레시피를 레스토랑에 사용
- 만드는 과정에서 생기는 부산물 저장(= 모델 Artifact, 이미지 등)
- 타코(모델)는 다양한 종류가 있으므로 언제 만든 타코인지(=모델 생성일), 얼마나 맛있었는지(모델 성능), 유통기한 등(=모델 메타 정보)을 기록해둘 수 있음
-
Feature Store
- 요리별로 사용되는 재료들이 중복됨, 반죽이나 간 등을 미리 만들면 편함
- 이런 재료를 가공해서 냉장고에 저장(= 머신러닝 Feature를 집계한 Feature Store)
-
Data Validation
- 재료들이 예전에 요리할 때 사용한 재료와 비슷한지 확인할 필요가 있다(= Feature의 분포 확인)
- 재료들이 예전에 요리할 때 사용한 재료와 비슷한지 확인할 필요가 있다(= Feature의 분포 확인)
-
Continuous Training
-
Monitoring
-
AutoML
-
-
Product Serving
Model Serving
-
Serving
- Production(Real World) 환경에 모델을 사용할 수 있도록 배포
- 머신러닝 모델을 개발하고, 현실 세계(앱,웹)에서 사용할 수 있게 만드는 행위
- 서비스화라고 표현할 수 있음
- 머신러닝 모델을 회사 서비스 기능 중 하나로 활용
- Input이 제공되면 모델이 예측 값(Output)을 반환
- 크게 2가지 방식 존재
- Online Serving
- Batch Serving
- 용어 정리
- Serving : 모델을 웹/앱 서비스에 배포하는 과정, 모델을 활용하는 방식, 모델을 서비스화하는 관점
- Inference : 모델에 데이터가 제공되어 예측하는 경우, 사용하는 관점
- Serving : Inference 용어가 혼재되어 사용되는 경우도 존재
-
Web Server Basic
- Web Server는 Client의 다양한 요청을 처리해주는 역할(주문 받기, 신규 고객 응대 등)
- Machine Learning Server는 Client의 다양한 요청을 처리해주는 역할(데이터 전처리, 모델을 기반으로 예측 등)
- 웹 서버 : HTTP를 통해 웹 브라우저에서 요청하는 HTML 문서나 오브젝트를 전송해주는 서비스 프로그램, 요청(Request)을 받으면 요청한 내용을 보내주는(Response) 프로그램
- 머신러닝 모델 서버 : 어떤 데이터(Input)를 제공하며 예측해달라고 요청(Request)하면, 모델을 사용해 예측 값을 반환(Response)하는 서버
-
API
- 운영체제나 프로그램 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스
-
Online Serving Basic
- 요청이 올 때마다 실시간으로 예측
- 클라이언트(애플리케이션)에서 ML 모델 서버에 HTTP 요청(Request)하고, 머신러닝 모델 서버에서 예측한 후, 예측 값(응답)을 반환(Response)
- ML 모델 서버에 요청할 때, 필요시 ML 모델 서버에서 데이터 전처리를 해야할 수 있음 ( 혹은 분리를 위해 전처리 서버 / ML 모델 서버로 나눌 수도 있음)
- 서비스의 서버에 ML 서버를 포함하는 경우도 있고, ML 서버를 별도로 운영하는 경우도 존재
- 구현하는 방식
- 직접 API 웹 서버 개발 : Flask, FastAPI 등을 사용해 서버 구축
- 클라우드 서비스 활용 : AWS의 SageMaker, GCP의 Vertex AI 등
- Serving 라이브러리 활용 : Tensorflow Serving, Torch Serve, MLFlow, BentoML 등
- Online Serving에서 고려할 부분
- Serving 할 때 Python 버전, 패키지 버전 등 Dependency가 중요
- "재현 가능"하지 않은 코드는 Risk를 가지고 있는 코드
- 관련해서 Virtualenv, Poetry, Docker도 학습할 예정
- 실시간 예측을 하기 때문에 예측할 때 지연 시간(Latency)를 최소화해야 함
- 1) Input 데이터를 기반으로 Database에 있는 데이터를 추출해서 모델 예측해야 하는 경우
- 데이터를 추출하기 위해 쿼리를 실행하고, 결과를 받는 시간이 소요
- 2) 모델이 수행하는 연산
- 모델을 경량화하는 작업이 필요할 수 있다.
- 3) 결과 값에 대한 보정이 필요한 경우
- Example) 마이너스 값
- 이를 해결하기 위해 여러가지 방법이 존재
- 데이터 전처리 서버 분리(Feature Store)
- 모델 경량화
- 병렬처리
- 예측 결과 캐싱
- 1) Input 데이터를 기반으로 Database에 있는 데이터를 추출해서 모델 예측해야 하는 경우
Batch Serving
- Workflow Scheduler : 해당 Serving을 특정 기간 단위 등으로 실행
- Batch Serving은 주기적으로 학습을 하거나 예측을 하는 경우
- 30분에 1번씩 최근 데이터를 가지고 예측
- Batch 묶음(30분의 데이터)를 한번에 예측
- 모델의 활용 방식에 따라 30분 or 1주일 or 하루 단위일 수 있음
- 한번에 많은 예측을 실행
- 특정 시간에 반복해서 실행
- Batch는 데이터 엔지니어링에서 자주 활용되는 용어, 한꺼번에 배치 단위로 묶음(DataLoader의 Batch와 유사)
- Batch Serving 관련한 라이브러리는 따로 존재하지 않음
- 함수 단위를 "주기적"으로 실행함
- Batch Serving 예시
- 1시간 뒤 수요 예측
- 재고 및 입고 최적화를 위해 매일 매장별 제품 수요 예측
- 실시간이 필요 없는 대부분의 방식에서 활용 가능
- 장점
- Online Serving보다 구현이 수월하며, 간단함
- 한번에 많은 데이터를 처리하므로 Latency가 문제되지 않음
- 단점
- 실시간으로 활용할 수 없음
- Cold Start 문제 : 오늘 새로 생긴 컨텐츠는 추천할 수 없음
- Airflow
-
Online Servig vs Batch Serving
- 선택하는 기준
- Input 관점
- 데이터를 하나씩 요청하는 경우 : Online
- 여러가지 데이터가 한번에 처리되는 경우 : Batch
- Output 관점
- 인퍼런스 Output을 어떻게 활용하는지에 따라 다름
- API 형태로 바로 결과를 반환해야 하는 경우 : Online
- 서버와 통신이 필요한 경우 : Online
- 1시간에 1번씩 예측해도 괜찮은 경우 : Batch
- Input 관점
- 선택하는 기준
-
처음부터 Online Serving(API 형태) 만들어야 하는 것은 아니고, 실시간 모델 결과가 어떻게 활용되는지에 대한 생각이 필요(예측해도 활용이 되지 않는다면 Batch로 진행해도 무방)
-
Batch Serving 결과를 Database에 저장하고, 서버는 Database의 데이터를 쿼리해서 주기적으로 조회하는 방식으로 사용할 수 있음
-
우선 Batch Serving으로 모델을 운영하면서 점점 API 형태로 변환
-
Notebook 베이스 - Voila
-
모델을 개발한 후, 사람들과 테스트할 수 있는 프로토타입을 만들기
-
ipywidget과 같이 사용할 경우 간단한 대시보드를 구축할 수도 있음
-
실행할 때 저장된 Notebook 파일이 순차적으로 실행
-
Notebook에서 별도의 코드 추가 없이 실행할 수 있는 점이 Voila의 강점
-
ipywidget과 같이 사용하면 인터랙티브한 효과를 줄 수 있음
import ipywidgets as widgets from IPyhthon.display import display- Slider widget
- 그 외에도 FloatSlider, IntRangeSlider 등이 존재
>>> int_widget.value # 값이 보임 4 >>> int_widget.value = 8 # 값이 변경됨 -
Rules of Machine Learning : Best Practices for ML Engineering
- Basic Approach
- Make sure your pipeline is solid end to end
- Start with a reasonable objective
- Add common-sense features in a simple way
- Make sure that your pipeline stays solid
- Basic Approach
AI 새싹