MLOps - 2. Model Serving

출처 : 변성윤님 블로그.
출처 : 부스트캠프 AI Tech.

1. Model Serving

1.1 Serving Basic

• Production(Real World) 환경에 모델을 사용할 수 있도록 배포
• 머신러닝 모델을 개발하고, 현실 세계(앱, 웹)에서 사용할 수 있게 만드는 행위 - 서비스화라고 표현할 수도 있음
• 머신러닝 모델을 회사 서비스의 기능 중 하나로 활용
• 예 : 추천 시스템의 추천 알고리즘
• Input이 제공되면 모델이 예측 값(Output)을 반환
• 크게 Online Serving, Batch Serving 이 존재하며, 클라이언트(모바일기기, IoT Device) 에서 Edge Serving 도 존재

1.2 Serving 용어

• Serving : 모델을 웹/앱 서비스에 배포하는 과정, 모델을 활용하는 방식, 모델을 서비스화하는 관점
• Inference : 모델에 데이터가 제공되어 예측하는 경우, 사용하는 관점
• Serving - Inference 용어가 혼재되어 사용되는 경우도 존재 (Online Serving / Online Inference) // Batch Serving(+Inference)

---

2. Web Server Basics

2-1. Wikipedia Definition.

• HTTP를 통해 웹 브라우저에서 요청하는 HTML 문서나 오브젝트를 전송해주는 서비스 프로그램
• 요청(Request)을 받으면 요청한 내용을 보내주는(Response) 프로그램

2-2. Slides - 변성윤님 블로그

---

3. API

• Application Programming Interface
• 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스
• 특정 서비스에서 해당 기능을 사용할 수 있도록 외부에 노출 : 기상청 API, 지도 API
• 라이브러리의 함수 : Pandas, Tensorflow, PyTorch

---

4. Online Serving

• 요청(Request)이 올 때마다 실시간으로 예측
• 클라이언트(애플리케이션)에서 ML 모델 서버에 HTTP 요청(Request)하고, 머신러닝 모델 서버에서 예측한 후, 예측 값(응답)을 반환(Response)

4.1 Online Serving을 구현하는 방식

• 직접 API 웹 서버 개발 : Flask, FastAPI 등을 사용해 서버 구축
• 클라우드 서비스 활용 : AWS의 SageMaker, GCP의 Vertex AI 등
• Serving 라이브러리 활용 : Tensorflow Serving, Torch Serve, MLFlow, BentoML 등

4.2 Online Serving을 선택 가이드 (회사 에서 - 효율적)

• (만약 회사에서 클라우드 비용에 대해 괜찮을 경우) 프로토타입 모델을 클라우드 서비스를 활용해 배포
• 직접 FastAPI 등을 활용해 서버 개발
• Serving 라이브러리를 활용해 개발

4.3 이런 Flow로 체험하는 것을 추천 (개인 입장 - 개인 성장 측면)

• 프로토타입 개발
• Fast API로 서버 개발
• Serving 라이브러리로 개발
• 개인적으로 Fast API로 개발하면 후에 다른 Serving Library들을 다루는데 문제가 없을 것이라고 생각함
• Serving 라이브러리, 클라우드 서비스 활용 하면 효율적이겠지만 해당 플랫폼이나 라이브러리에 종속되거나 비용적, 이관 문제 발생가능

4.4 Online Serving 시 고려해야될 부분

• 환경 setting
  • Serving 할 때 Python 버전, 패키지 버전 등 Dependency가 굉장히 중요
  • “재현 가능"하지 않은 코드는 Risk를 가지고 있는 코드 = "Reproducibility" 매우 중요
  • Virtualenv, Poetry, Docker
• Latency
  • 이 값은 짧을 수록 좋으며, Latency가 길다는 것은 Loading이 긴 것과 유사한 상황
• Input 데이터를 기반으로 Database에 있는 데이터를 추출해서 모델 예측해야 하는 경우
  • 데이터는 다양한 공간(Database, AWS S3)에 저장되어 있을 수 있음
  • 데이터를 추출하기 위해 쿼리를 실행하고, 결과를 받는 시간이 소요
• 모델이 수행하는 연산
  • RNN, LSTM 등은 회귀 분석보다 많은 연산을 요구하고, 더 오래 걸림
  • 이를 위해 모델을 경량화하는 작업이 필요할 수 있으며, 복잡한 모델보다 간단한 모델을 사용하는 경우도 존재
• 결과 값에 대한 보정이 필요한 경우
  • 머신러닝 알고리즘에서 유효하지 않은 예측값이 반환될 수 있음
  • 예를 들어 집 값을 예측하는데, 0 이하의 마이너스 값이 나올 수 있음 - 이런 경우 결과를 보정하는 코드가 필요할 수 있음
  • 예 : 집 값이 마이너스가 나오면 0으로 표시한다 등

---

5. Batch Serving

 

5.1 Batch Serving은 주기적으로 학습을 하거나 예측을 하는 경우

• 30분에 1번씩 최근 데이터를 가지고 예측
• Batch 묶음(30분의 데이터)를 한번에 예측
• 모델의 활용 방식에 따라 30분일 수도 있고, 1주일, 하루 단위일 수 있음 - 한번에 많은 예측을 실행
• 특정 시간에 반복해서 실행
• Batch는 데이터 엔지니어링에서 자주 활용되는 용어. 한꺼번에 배치 단위로 묶음(DataLoader의 Batch와 유사)

5.2 Batch Serving 예시

• 추천 시스템 : 1일 전에 생성된 컨텐츠에 대한 추천 리스트 예측
• 1시간 뒤 수요 예측
• 재고 및 입고 최적화를 위해 매일 매장별 제품 수요 예측
• 실시간이 필요 없는 대부분의 방식에서 활용 가능

5.3 Batch Serving 장점

• Jupyter Notebook에 작성한 코드를 함수화한 후, 주기적으로 실행하는 간단한 구조!
• Online Serving보다 구현이 수월하며, 간단함
• 한번에 많은 데이터를 처리하므로 Latency가 문제되지 않음

5.4 Batch Serving 단점

• 실시간으로 활용할 수 없음
• Cold Start 문제 : 오늘 새로 생긴 컨텐츠는 추천할 수 없음

---

6. Online Serving vs Batch Serving

• Online vs Batch를 선택하는 기준
  • Input 관점 데이터 하나씩 요청하는 경우 : Online
  • 여러가지 데이터가 한꺼번에 처리되는 경우 : Batch
• Online vs Batch를 선택하는 기준 - Output 관점
  • 인퍼런스 Output을 어떻게 활용하는지에 따라 다름
    • API 형태로 바로 결과를 반환해야 하는 경우 : Online - 서버와 통신이 필요한 경우 : Online
    • 1시간에 1번씩 예측해도 괜찮은 경우 : Batch