Rules of Machine Learning: Best Practices for ML Engineering
Model Serving
Serving Basic
-
Production(real world)환경에 모델을 사용할 수 있도록 배포
-
머신러닝 모델을 개발하고 현실 세계(앱, 웹)에서 사용할 수 있게 만드는 행위
-
서비스화라고 표현할 수도 있다.
-
Input이 제공되면 모델이 Output(예측)을 반환
-
크게 Online, Batch, Edge(모바일 기기, IoT)가 존재한다.
Serving : 모델을 웹/앱 서비스에 배포하는 과정, 모델을 서비화하는 관점
Inference : 모델에 데이터가 제공되어 예측하는 경우, 사용하는 관점
Serving-Inference가 혼재되어 사용하는 경우도 존재함
Batch Serving(+Inference)
Online serving/online inference
Online Serving
Web Server Basic
-
HTTP를 통해 웹 브라우저에서 요청하는 HTML문서나 오브젝트를 전송해주는 서비스 프로그램
-
Client(브라우져)가 web server에 특정 요청(request)를 보내면 그에 반응 요청을 처리하여 응답(response)를 하게 된다.
-
Machine Learning Server는 Client의 다양한 요청(데이터 전처리, 모델 기반 예측 등)을 처리해주게 된다.
API(Application Programming Interface)
운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스
인터페이스란 기계와 인간의 소통 창구로 이해할 수 있다. 예를들어 우리와 TV사이를 리모컨이라는 인터페이스가 소통을 담당하는 인터페이스로 이해할 수 있다.
API는 특정 서비스에 해당 기능을 사용할 수 있도록 외부에 노출시키는 경우(기상청 API, 지도 API)와 라이브러리 함수(Pandas, Tensorflow, Pytorch)와 같은 경우가 있다.
Online Serving basic
-
요청(request)가 올 때마다 실시간으로 예측
-
클라이언트(애플리케이션)에서 ML모델 서버에 HTTP 요청을하고 모델 서버에서 예측을 한 후, 예측 값(응답)을 반환한다.
-
Online Serving / Online Inference
-
단일 데이터를 받아 실시간으로 예측을 하는 예제
Online Serving을 구현하는 방식
-
직접 API 웹 서버 개발 : Flask, FastAPI 등을 이용
-
클라우드 서비스 활용 : AWS의 SageMaker, GCP의 Vertex AI 등
-
Serving 라이브러리 활용 : Tensorflow Serving, Torch Serve, MLFlow, BentoML 등
-
학습을 목적으로 할때는 serving라이브러리 사용은 나중에 공부하는 것을 추천(새로운 오픈소스가 언제든 나올 수 있으며 라이브러리에 종속되었다가는 Low level의 이해도가 부족해질 수 있다.)
Online Serving에서 고려할 부분
Serving할 때 Python 버전, 패키지 버전 등 Dependency가 굉장히 중요하며 재현 가능하지 않는 코드는 큰 Risk를 가지고 있는 코드이므로 버전 관리의 용이한 Virtualenv, Poetry, Docker도 중요한 요소이다.
실시간 예측을 하기 때문에 지연 시간(Latency)를 최소화 해야 한다.
- DB에 쿼리로 조회를 할 경우
- 모델이 수행하는 연산이 길 경우 (모델 경량화)
- 결과 값에 대한 보정이 필요한 경우 (후처리)
등 문제 상황에 맞는 해결 방법(데이터 전처리 서버 분리, 모델 경량화, 병렬처리, 예측 결과 캐싱)이 존재한다.
Batch Serving
주기적으로 학습을 하거나 예측을 하는 경우
- 30분에 1번씩 최근 데이터를 가지고 예측
- Batch 묶음(30분의 데이터)를 한번에 예측
- 모델의 활용 방식에 따라 주기는 달라지며 한번에 많은 예측을 실행한다.
- Airflow, Cron Job 등으로 스케쥴링 작업(Work Scheduler)
- 학습/예측을 별도의 작업으로 설정할 수도 있다.(학습 1주일, 예측 1시간)
example
실시간이 필요 없는 대부분의 방식에서 활용 가능하다.
재고 및 입고 최적화를 위해 매일 매장별 제품 수요 예측
장점
- Online Serving보다 구현이 수월하고 간단함
- 한번에 많은 데이터를 처리하므로 Latency가 문제가 되지 않음
단점
- 실시간으로 이용할 수 없기 때문에 아래와 같은 문제가 생긴다.
- Cold Start 문제 : 오늘 새로 생긴 컨텐츠는 추천할 수 없는 현상
Workflow Scheduler
-
데이터 엔지니어링에서 자주 활용 되는 Airflow
-
Linux의 Cron job
Online Serving vs. Batch Serving
-
Input 관점 : 데이터 하나씩 요청하는 경우(Online), 여러개 (Batch)
-
Output 관점 : API 형태로 결과를 바로 반환해야 한다(Online). 일정 주기로 예측해도 된다(Batch).
-
실시간 모델 결과가 어떻게 활용되는지에 대한 생각을 해보고 예측결과를 바로 활용하지 않는다면 Batch로 진행해도 무방하며 Batch Serving의 결과를 DB에 저장하고 서버는 DB의 데이터를 주기적으로 조회하는 방식으로도 사용할 수 있다.
