Model Serving
Serving Basic
Serving
- Production 환경에 모델을 사용할 수 있도록 배포하는 것이다.
- 머신러닝 모델을 개발하고, 현실 세계(앱, 웹)에서 사용할 수 있게 만드는 행위이다.
- 서비스화라고 표현할 수도 있다.
- 머신러닝 모델을 회사 서비스의 기능 중 하나로도 활용 가능하다. (e.g. 추천 시스템의 추천 알고리즘)
- Input이 제공되면 모델이 예측값(output)을 반환한다.
- 크게 2가지 방식이 존재한다.
- Online Serving
- Batch Serving
용어 정리
- Serving: 모델을 웹/앱 서비스에 배포하는 과정, 모델을 활용하는 방식, 모델을 서비스화하는 큰 관점
- Inference: 모델에 데이터가 제공되어 예측하는 경우, 사용하는 관점
Serving과 Inference 용어가 혼재되어 사용되는 경우가 있다.
Online Serving과 Online Inference는 보통 구분할 수 있지만, Batch Serving는 serving 안에 inference 개념이 포함되기도 한다.
Online Serving
Web Server Basic
웹 서버
- HTTP를 통해 웹 브라우저에서 요청하는 HTML 문서나 오브젝트를 전송해주는 서비스 프로그램이다.
- 요청(Request)을 받으면 요청한 내용을 보내주는(Response) 프로그램이다.
- Machine Learning Server는 Client의 다양한 요청을 처리해주는 역할이다.
- 데이터 전처리, 모델을 기반으로 예측 등
크롬에서 유튜브에 접근하는 경우, 해당 페이지를 보여달라고 요청(Request)한다. 유튜브 서버는 유튜브 메인 페이지를 반환(Response)한다.
쇼핑몰 예시
머신러닝 모델 서버
- 어떤 데이터(Input)를 제공하며 예측해달라고 요청(Request)하면, 모델을 사용해 예측값을 반환(Response)하는 서버
API(Application Programming Interface)
- API: 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스
- 인터페이스: 기계와 인간의 소통 창구라고 할 수 있다.
- API 종류
- 특정 서비스에서 해당 기능을 사용할 수 있도록 외부에 노출: 기상청 API, 지도 API
- 라이브러리의 함수: Pandas, Tensorflow, PyTorch
Online Serving Inference 관점
- 요청(Request)이 올 때마다 실시간으로 예측한다.
- 클라이언트(어플레이케이션)에서 ML 모델 서버에 HTTP 요청(Request)한다.
- 머신러닝 모델 서버에서는 예측한 후, 예측값(응답)을 반환(Response)한다.
Serving Input - Single Data Point
- 단일 데이터를 받아 실시간으로 예측을 하는 예제
- 기계 고장 예측 모델: 센서의 실시간 데이터가 제공되면 특정 기계 부품이 앞으로 N분 안에 고장날지 아닐지를 예측
- 음식 배달 소요 시간 예측: 해당 지역의 과거 평균 배달 시간, 실시간 교통 정보, 음식 데이터 등을 기반으로 음식 배달 소요 시간 예측
Online Serving Basic
- ML 모델 서버에 요청할 때, 필요시 ML 모델 서버에서 데이터 전처리를 해야할 수 있다. (혹은 분리를 위해 전처리 서버 / ML 모델 서버로 나눌 수도 있다)
- 서비스의 서버에 ML 서버를 포함하는 경우도 있고, ML 서버를 별도로 운영하는 경우도 존재한다.
- 회사에서 개발 조직과 데이터 조직의 협업하는 방식에 따라 다르게 개발할 수 있다.
Online Serving을 구현하는 방식
- 직접 API 웹 서버 개발: Flask, FastAPI 등을 사용해 서버 구축
- 클라우드 서비스 활용: AWS의 SageMaker, GCP의 Vertex AI 등
- Serving 라이브러리 활용: Tensorflow Serving, Torch Serve, MLFlow, BentoML 등
직접 API 웹 서버 개발
클라우드 서비스 활용
클라우드 서비스의 장점
- 직접 구축해야 하는 MLOps의 다양한 부분(API 서버 만들기)이 만들어진다.
- 사용자 관점에선 PyTorch 사용하듯 학습 코드만 제공하면 API 서버가 만들어진다.
클라우드 서비스의 아쉬운 점
- 클라우드 서비스가 익숙해야 잘 활용할 수 있다.
- 비용 문제: 직접 만드는 것보단 더 많은 비용이 나갈 수 있다.
회사의 상황에 따라 클라우드 서비스를 활용하는 것이 좋은 시기도 존재한다.
- 소수의 인원만 존재하며 소수의 인원이 많은 업무를 해야하는 경우
- 클라우드의 내부 실행 구조를 잘 알아야 문제 상황이 발견되었을 때 잘 해결할 수 있다.
- 클라우드 서비스에선 어떤 방식으로 AI 제품을 만들었는지 확인할 수도 있어서 사용해보는 것도 좋다.
Serving 라이브러리 활용
- Fast API 등을 활용할 수 있지만, 처음에 서버에 대한 이해가 충분하지 않으면 어려울 수 있다.
- 다양한 방식으로 개발할 수 있지만, 매번 추상화된 패턴을 가질 수 있다.
- 추상화된 패턴을 잘 제공하는 오픈소를 활용하는 방식이다.
BentoML 예시
다양한 Serving 방법을 선택하는 가이드
주어진 환경(회사에서 주어진 일정, 인력, 예산, 요구 성능 등)에 따라 다르다.
만약 클라우드 비용에 대해 괜찮을 경우, 추천 방식 순서
1. 프로토타입 모델을 클라우드 서비스를 활용해 배포
2. 직접 FastAPI 등을 활용해 서버 개발
3. Serving 라이브러리를 활용해 개발
바로 Serving 라이브러리를 학습하지 않는 이유
- 사용하기에는 편하지만, 점진적으로 문제를 해결하기 위해
- 오픈소스는 계속 개발되고 있기 때문에 언제든 새로운 오픈소스가 나올 수 있다. (라이브러리에 종속되지 않기)
- High Level 오픈소스를 먼저 사용할 경우, Low Level의 이해도가 부족할 수 있다.
- 서버 프로그래밍은 필수적으로 경험해야 하기 때문에 먼저 서버 프로그래밍을 해보고 Serving 라이브러리를 학습
Online Serving에서 고려할 부분
- Serving할 때 Python 버전, 패키지 버전 등 Dependency가 굉장히 중요하다.
- "재현 가능"하지 않은 코드는 Risk를 가지고 있는 코드이다.
- Virtualenv, Poetry, Docker
- 실시간 예측을 하기 때문에, 예측할 때 지연 시간(Latency)를 최소화해야 한다.
- Latency: 하나의 예측을 요청하고 반환값을 받는데까지 걸리는 시간
- Latency가 길다는 것은 Loading이 긴 것과 유사한 상황이기 때문에, latency는 짧을수록 좋다.
- 배달 음식 앱에서 음식 추천을 받기 위해 1분을 기다려야 한다면? 1초 안에 나오면 더 좋을 것이다.
- Input 데이터를 기반으로 Database에 있는 데이터를 추출해서 모델을 예측해야 하는 경우
- 데이터는 다양한 공간(Database, AWS S3)에 저장되어 있을 수 있다.
- 데이터를 추출하기 위해 쿼리를 실행하고, 결과를 받는 시간이 소요된다.
- 모델이 수행하는 연산
- RNN, LSTM 등은 회귀 분석보다 많은 연산을 요구하고, 더 오래 걸린다.
- 이를 위해 모델을 경량화하는 작업이 필요할 수 있고, 복잡한 모델보다 간단한 모델을 사용하는 경우도 존재한다.
- 결과값에 대한 보정이 필요한 경우
- 머신러닝 알고리즘에서 유효하지 않은 예측값이 반환될 수 있다.
- 집 값을 예측하는데, 마이너스 값이 나온 경우.
- 이런 경우 결과를 보정하는 코드가 필요할 수 있다.
- 집 값이 마이너스가 나오면 0으로 표시한다 등
앞의 문제를 해결하기 위해 여러가지 방법이 존재한다. 문제 상황에 맞는 행결 방법을 사용.
- 데이터 전처리 서버 분리 (혹은 Feature를 미리 가공하는 Feature Store 만들기)
- 모델 경량화
- 병렬처리(Ray)
- 예측 결과 캐싱
Batch Serving
Batch Serving Basic
Batch Serving은 주기적으로 학습을 하거나 예측을 하는 경우이다.
- 30분에 1번씩 최근 데이터를 가지고 예측
- Batch 묶음(30분의 데이터)를 한 번에 예측
- 한 번에 많은 예측을 실행
- 특정 시간에 반복해서 실행
Batch 관련한 라이브러리는 따로 존재하지 않는다.
함수 단위를 "주기적"으로 실행한다.
예시
아침 10시에 python main.py 실행
아침 11시에 python main.py 실행
Airflow, Cron Job 등으로 스케쥴링 작업(Workflow Scheduler)이 가능하다.
학습/예측을 별도의 작업으로 설정
- 학습 : 1주일에 1번
- 예측 : 10분, 30분, 1시간에 1번씩
실시간이 필요 없는 대부분의 방식에서 활용 가능하다.
- 재고 및 입고 최적화를 위해 매일 매장별 제품 수요 예측
- 1시간 뒤 수요 예측
- 1일 전에 생성된 컨텐츠에 대한 추천 리스트 예측
스포티파이의 예측 알고리즘 - Discover Weekly
How Spotify’s Thriving Recommendation System is Becoming A New Advertising Platform
Batch Serving 장점
- Jupyter Notebook에 작성한 코드를 함수화한 후, 주기적으로 실행하는 간단한 구조
- Online Serving보다 구현이 수월하며, 간단하다.
- 한 번에 많은 데이터를 처리하므로 Latency가 문제되지 않는다.
Batch Serving 단점
- 실시간으로 활용할 수 없다.
- Cold Start 문제: 오늘 새로 생긴 컨텐츠는 추천할 수 없다.
Workflow Scheduler
- Apache Airflow: 데이터 엔지니어링에서 자주 활용된다.
- Task 단위로 이루어져 있다.
- Linux의 Cron Job
Online Serving vs Batch Serving
Online vs Batch를 선택하는 기준
Input 관점
- 데이터 하나씩 요청하는 경우: Online(Fast API와 같은 웹 서버 구성)
- 여러가지 데이터가 한꺼번에 처리되는 경우: Batch
Output 관점
- Inference output을 어떻게 활용하는지에 따라 다르다.
- API 형태로 바로 결과를 반환해야 하는 경우: Online
- 서버와 통신이 필요한 경우: Online
- 1시간에 1번씩 예측해도 괜찮은 경우: Batch
실시간 모델 결과가 어떻게 활용되는지에 대한 생각이 필요하다. 예측해도 활용이 되지 않는다면 Batch로 진행해도 무관하다.
Batch Serving의 결과를 Database에 저장하고, 서버는 Database의 데이터를 쿼리해서 주기적으로 조회하는 방식으로 사용할 수 있다.
우선 Batch Serving으로 모델을 운영하면서 점점 Online Serving(API 형태)로 변환해도 괜찮다.
