Serving

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

크게 2가지 방식이 존재한다.

• Online Serving

• Batch Serving
  그 외에 클라이언트(모바일 기기, IoT Device 등)에서 Edge Serving도 존재

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

Online Serving

• 웹 서버(Wikipedia)

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

• 머신러닝 모델 서버

  • 어떤 데이터(Input)를 제공하며 예측해달라고 요청(Request)하면, 모델을 사용해 예측 값을 반환(Response)하는 서버

• API(Application Programming Interface)
  

  • 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스

• Online serving basic
  

• 요청(Request)이 올 때마다 실시간으로 예측

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

• ML 모델 서버에 요청할 때, 필요시 ML 모델 서버에서 데이터 전처리를 해야할 수 있다 (혹은 분리를 위해 전처리 서버 / ML 모델 서버로 나눌 수도 있음)

• 서비스의 서버에 ML 서버를 포함하는 경우도 있고, ML 서버를 별도로 운영하는 경우도 존재한다.

• 회사에서 개발 조직과 데이터 조직의 협업하는 방식에 따라 다르게 개발할 수 있다

• Online Serving을 구현하는 방식

  • 1) 직접 API 웹 서버 개발
  • 2) 클라우드 서비스 활용
  • 3) Serving 라이브러리 활용

• Online Serving을 구현하는 방식

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

• cloud 사용

• AWS의 SageMaker, GCP의 Vertex AI 등

  • 장점
    • 직접 구축해야 하는 MLOps의 다양한 부분(API 서버 만들기)이 만들어짐
    • 사용자 관점에선 PyTorch 사용하듯 학습 코드만 제공하면 API 서버가 만들어짐
  • 아쉬운 점
    • 클라우드 서비스가 익숙해야 잘 활용할 수 있음
    • 비용 문제 : 직접 만드는 것보단 더 많은 비용이 나갈 수 있음

• 회사의 상황에 따라 클라우드 서비스를 활용하는 것이 좋은 시기도 존재하고, 소수의 인원만 존재하며, 소수의 인원이 많은 업무를 해야하는 경우 클라우드의 내부 실행 구조를 잘 알아야 문제 상황이 발견되었을 때 잘 해결할 수 있다.

• 클라우드 서비스에선 어떤 방식으로 AI 제품을 만들었는지 확인할 수도 있어서 사용해보는 것도 좋다.

• Online Serving에서 고려할 부분

  • Serving 할 때 Python 버전, 패키지 버전 등 Dependency가 굉장히 중요하다. 더 나아가, 실제 서비스할 때, 재현이 불가능하면 안된다.
    관련해서 Virtualenv, Poetry, Docker가 존재한다.
  • 실시간 예측을 하기 때문에 예측할 때 지연 시간(Latency)를 최소화해야 한다.
    • 1) Input 데이터를 기반으로 Database에 있는 데이터를 추출해서 모델 예측해야 하는 경우
      • 데이터는 다양한 공간(Database, AWS S3)에 저장되어 있을 수 있다. 이런 경우에는 데이터를 추출하기 위해 쿼리를 실행하고, 결과를 받는 시간이 소요
    • 2) 모델이 수행하는 연산
      • RNN, LSTM 등은 회귀 분석보다 많은 연산을 요구하고, 더 오래 걸리기 때문에 모델을 경량화하는 작업이 필요할 수 있으며, 복잡한 모델보다 간단한 모델을 사용하는 경우도 존재한다.
    • 3) 결과 값에 대한 보정이 필요한 경우(후처리)
      • 예를 들어 집 값을 예측하는데, 0 이하의 마이너스 값이 나올 때 결과를 보정하는 코드가 필요할 수 있다.
  • 위의 문제를 해결하기 위해 Feature store, 경량화, 병렬처리, 예측 결과 캐싱 등의 해결방법이 존재한다.

Batch Serving

함수 단위를 “주기적"으로 실행한다. Airflow, Cron Job 등으로 스케쥴링 작업(Workflow Scheduler)을 수행한다.

• 추천 시스템 : 1일 전에 생성된 컨텐츠에 대한 추천 리스트 예측

• 1시간 뒤 수요 예측

• 재고 및 입고 최적화를 위해 매일 매장별 제품 수요 예측

• 실시간이 필요 없는 대부분의 방식에서 활용 가능

• 장점

  • Online Serving보다 구현이 수월하며, 간단함 한번에 많은 데이터를 처리하므로 Latency가 문제되지 않음

• 단점

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

• Workflow Scheduler

  • 데이터 엔지니어링에서 자주 활용되는 Airflow
  • Linux의 Cron Job

머신러닝을 하기 위한 규칙 : https://developers.google.com/machine-learning/guides/rules-of-ml