[Serving] Model Serving

Model Serving

• product serving 의 핵심이 되는 부분이다. 대표적으로 많은 양을 일정 주기로 한꺼번에 서빙하는 Batch Serving 과 한번에 하나씩 실시간으로 서빙하는 Online Serving 이 있다.
• Serving 은 Production(real world) 환경에 모델을 사용할 수 있도록 배포하는 것을 뜻한다.
• 머신러닝 모델을 개발하고, 현실 세계(앱, 웹)에서 사용할 수 있게 만드는 행위로 서비스화라고 표현할 수도 있다.
• 추천시스템과 같이 머신러닝 모델을 회사 서비스의 기능 중 하나로 활용하고, input 이 제공되면 모델이 예측 값(output)을 반환한다.
• Online, Batch 서빙 외에 클라이언트(모바일 기기, IoT device 등)에 대한 Edge Serving 도 존재한다.
• Serving 과 Inference 용어가 혼재되어 사용되는 경우도 존재한다.
  • Serving : 모델을 웹/앱 서비스에 배포하는 과정, 모델을 활용하는 방식, 모델을 서비스화하는 관점
  • Inference : 모델에 데이터가 제공되어 예측하는 경우, 사용하는 관점

Web Server

• 웹 서버는 HTTP 를 통해 웹 브라우저에서 요청하는 HTML 문서나 오브젝트를 전송해주는 서비스 프로그램이다. 즉 요청(Request)을 받으면 요청한 내용을 보내주는(Response) 프로그램이다.
• 음식점에서 Serving 해주는 사람이 Server, 손님은 Client 라고 부르듯, Client 가 서버에게 요청(request)하게 되면 서버가 요청을 듣고 Client 에게 응답(response)을 보내는 방식이다.
• 이처럼 Web Server 는 Client 의 다양한 요청을 처리해주는 역할을 한다. 마찬가지로 Machine Learning Server 도 Client 의 데이터 전처리, 모델을 기반으로 예측 등의 요청을 처리해주는 역할을 한다.

• 모든 웹 서버는 request 와 response 로 나뉜다.

  

• 머신러닝 모델 서버는 어떤 데이터(input)를 제공하며 예측해달라고 요청(request)하면, 모델을 사용해서 예측값을 반환(response)하는 서버다.
• API 란?
  • Application Programming Interface 의 준말로, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스다.
  • 사용자들이 프로그램이나 어플리케이션을 사용할 수 있도록 여러 기능이 존재한다. 인터페이스는 기계와 인간의 소통 창구라고 생각할 수 있다.
  • 특정 서비스에서 해당 기능을 사용할 수 있도록 외부에 노출된다. 예를 들어 기상청 API, 지도 API 등이 있다.
  • Pandas, Tensorflow, PyTorch 라이브러리의 함수 또한 API 다. 실제로 라이브러리(ex. PyTorch)의 공식문서에 가보면 API Document 가 있다. 이처럼 라이브러리에서 함수가 API 라고 볼 수 있다.
  • 카카오, 구글, 네이버, AWS, 구글 등에서 API 를 제공한다.

Online Serving

• Online Serving 은 요청(request)이 올 때마다 실시간으로 예측한다.

  

• inference 관점에서 보면, 먼저 input data 를 들고 서버에 예측을 해달라고 요청한다. REST API 는 뒤에서 모델을 로드하여 그 모델에 예측을 시키고 output data 를 반환한다.
• 즉 클라이언트(애플리케이션)에서 ML 모델 서버에 HTTP 요청을 하고, 머신러닝 모델 서버에서 예측한 후, 예측 값(응답)을 반환하는 것이다.
• 단일 데이터를 받아서 실시간으로 예측하는 예제에는 기계 고장 예측 모델, 음식 배달 소요 시간 예측 등이 있다.
• ML 모델 서버에 요청할 때, 필요시 ML 모델 서버에서 데이터 전처리를 해야할 수 있다. 혹은 전처리 서버와 ML 모델 서버로 서버를 둘로 나눌 수도 있다. 이렇게 되면 전처리 서버에서 완료된 것을 ML 모델 서버로 요청해야 한다.
• 서비스에서 서버에 ML 서버를 포함하는 경우도 있고, ML 서버를 별도로 운영하는 경우도 존재한다. 마이크로서비스 아키텍처(MSA)라는 개념이 그렇다.
• 회사에서 개발 조직과 데이터 조직의 협업하는 방식에 따라 다르게 개발할 수 있다. 결국 개발은 똑같이 하고 어떤 서버에 배포하냐에 대한 차이다.

Online Serving 구현 방식

• 직접 API 웹 서버를 개발한다. Flask, FastAPI 등을 사용해서 서버를 구축할 수 있다.

• 아래는 localhost 에서의 웹 서버 예시다.

  

• 클라우드 서비스를 활용할 수 있다. 대표적으로 AWS 의 SageMaker, GCP 의 Vertex AI 등이 있다.

  

• 클라우드 서비스의 장점은 직접 구축해야 하는 MLOps 의 다양한 부분(API 서버 구현)이 만들어져 있다. 즉 사용자 관점에서는 PyTorch 를 사용하듯 학습 코드만 제공하면 API 서버가 만들어진다.
• 반면에 아쉬운 점은 클라우드 서비스가 익숙해야 잘 활용할 수 있다는 점이다. 또한 직접 만드는 것보다 더 많은 비용이 나갈 수 있다는 비용 문제가 있다.
• 회사의 상황에 따라 클라우드 서비스를 활용하는 것이 좋은 시기도 존재한다. 예를 들어 소수의 인원만 존재하며, 소수의 인원이 많은 업무를 해야 하는 경우다.
• 이 때 클라우드 내부 실행 구조를 잘 알아야 문제 상황이 발견되었을 때 잘 해결할 수 있다.
• 클라우드 서비스에서는 어떤 방식으로 AI 제품을 만들었는지 확인할 수도 있어서 사용해보는 것이 좋다.

Serving 라이브러리 활용

• 대표적인 Serving 라이브러리로 Tensorflow Serving, Torch Serve, MLFlow, BentoML 등이 있다.
• FastAPI 등을 활용할 수 있지만, 처음에 서버에 대한 이해가 충분하지 않으면 어려울 수 있다.
• 이러한 라이브러리들을 활용하면 다양한 방식으로 개발하면서 매번 추상화된 패턴을 가질 수 있다. 따라서 추상화된 패턴을 잘 제공하는 오픈소스를 활용해보자.

• BentoML 에서는 아래 코드를 실행하여 학습한 후 CLI 에서 bentoml serve IrisClassifier:latest 명령어를 입력하면 배포가 끝난다.

  

• 이처럼 굉장히 간단하게 모델을 배포할 수 있다.
• Serving 방법을 선택할 때는, 주어진 환경(회사에서 주어진 일정, 인력, 예산, 요구 성능 등)에 따라 다르다. 만약 회사에서 클라우드 비용에 대해 감당 가능하다면 아래와 같은 방식을 따를 수 있다.
  • 프로토타입 모델을 클라우드 서비스를 활용해서 배포한다.
  • 직접 FastAPI 등을 활용해 서버를 개발한다.
  • Serving 라이브러리르 활용해 개발한다.
• 주의해야 할 점은 언제든 새로운 오픈소스가 나올 수 있기 때문에 라이브러리에 종속되지 말아야 한다.
• 또한 서버 프로그래밍은 필수적으로 경험해야 하기 때문에, 먼저 서버 프로그래밍을 해보고 Serving 라이브러리를 학습하자.
• Serving 할 때 제일 중요한 것이 파이썬 버전, 패키지 버전 등의 dependency 다. 재현 가능하지 않은 코드는 risk 를 가지고 있는 코드로 배포할 수 없다. 따라서 Virtualenv, Poetry, Docker 등을 이용하자.

Latency 와 Online Serving

• 실시간 예측을 하기 때문에 예측할 때 지연 시간(Latency)을 최소화해야 한다.
• Latency 는 하나의 예측을 요청하고 반환값을 받는데까지 걸리는 시간이다. 이 값은 짧을 수록 좋다. latency 가 길다는 것은 로딩이 긴 것과 유사한 상황이다.
• input data 를 기반으로 database 에 있는 데이터를 추출해서 모델 예측을 해야 하는 경우, 데이터는 다양한 공간 (database, AWS S3 등) 에 저장되어 있을 수 있다. 이 때 데이터를 추출하기 위해 쿼리를 실행하고, 결과를 받는 시간이 소요된다. 이러한 경우에 latency 가 길어진다.
• 또한 모델이 수행하는 연산에 따라 latency 가 생긴다. RNN, LSTM 등은 회귀 분석보다 많은 연산을 요구하고 오래 걸린다. 이를 해결하기 위해 모델을 경량화하는 작업이 필요할 수 있으며, 복잡한 모델보다 간단한 모델을 사용하는 경우도 존재한다.
• 마지막으로 결과값에 대한 보정(후처리)이 필요한 경우가 있다. 머신러닝 알고리즘은 유효하지 않은 예측값이 반환될 가능성이 언제나 존재한다. 예를 들어 집 값을 예측하는데 0 이하의 마이너스 값이 나올 수 있다. 이런 경우 결과를 보정하는 후처리 코드가 필요할 수 있다. 즉 전처리 뿐 아니라 후처리도 필요할 수 있다는 것이다.
• Latency 를 완화하기 위한 다양한 방법이 존재한다.
  • 데이터 전처리 서버 분리 혹은 Feature 를 미리 가공해두는 Feature Store 사용
  • 모델 경량화
  • 병렬처리(Ray)
  • 예측 결과 캐싱 등

Batch Serving

• 모델이 있고 입력 데이터가 있으면, 한번에 많은 양의 데이터가 예측을 요청하고 한번에 결과를 내는 방식이다.

  

• Batch Serving 은 별도의 웹 서버로 API 통신하고 이런 것이 아니라 workflow scheduler 를 이용해서 특정 기간 단위로 실행한다.
• 주기적으로 학습하거나 예측하는 경우 Batch Serving 이라 볼 수 있다.
  • 30 분에 1 번씩 최근 데이터를 가지고 예측한다. 모델의 활용 방식에 따라 30 분일 수도 있고, 1주일, 하루 단위일 수 있다.
  • Batch 묶음을 한번에 예측한다.
  • 한번에 많은 예측을 실행한다.
  • 특정 시간에 반복해서 실행한다.
  • Batch 는 데이터 엔지니어링에서 활용되는 용어다. 단위 묶음이라고 생각할 수 있다.
  • 관련 라이브러리는 따로 존재하지 않는다.
  • 함수 단위를 “주기적”으로 실행하는 것이 핵심이다. 이 때 Airflow, Cron Job 등으로 스케쥴링 작업(Workflow Scheduler)을 실시한다.
  • 학습, 예측을 별도의 작업으로 설정할 수 있다. 또한 분리해서 serving 할 수도 있다.
• 즉 실시간이 필요 없는 대부분의 방식에서 활용 가능하다. 아래는 Batch Serving 에 대한 예시다.
  • 추천시스템 : 1 일 전에 생성된 컨텐츠에 대한 추천 리스트 예측
  • 1시간 뒤 수요 예측
  • 재고 및 입고 최적화를 위해 매일 매장별 제품 수요 예측
• Batch Serving 의 장점은 주피터 노트북 등에서 작성한 코드를 함수화한 후, 주기적으로 실행하는 간단한 구조라는 점이다.
• 따라서 파이썬 패키지의 dependency 만 잘 체크하면 된다.
• Online Serving 보다 구현이 수월하며 간단하다. 또한 한번에 많은 데이터를 처리하므로 Latency 가 문제되지 않는다.
• 그러나 단점으로는 실시간으로 활용할 수 없다는 점이다. 이와 관련하여 Cold Start 문제가 있다. 즉 오늘 새로 생긴 콘텐츠는 추천할 수 없다.

• 그럼에도 불구하고 문제상황에 따라 Batch 로 알고리즘이 도는 것이 충분히 좋은 방법일 수 있다. 스포티파이 예측 알고리즘이 Batch Serving 방식을 사용한다.

  

• Workflow Scheduler 는 데이터 엔지니어링에서 자주 활용되는 Apache Airflow 나 Linux 의 Cron Job 을 자주 사용한다.

Online Serving vs. Batch Serving

• 두 Serving 방식에 대한 선택 기준은 Input 관점이다.
  • 데이터를 하나씩 요청하는 경우(실시간)는 Online Serving 방식을 이용한다. Fast API 웹 서버 등을 이용해서 구현해야 한다.
  • 여러 데이터가 한꺼번에 처리되는 경우에는 Batch Serving 방식을 이용한다.
• 또한 output 관점으로도 생각해볼 수 있다.
  • API 형태로 바로 결과를 반환해서 고객에게 노출해야 하는 경우 Online Serving 방식을 이용한다.
  • 서버와 통신이 필요한 경우에도 Online Serving 방식이 좋다.
  • 1 시간에 1 번씩 예측해도 괜찮은 경우에는 Batch Serving 을 이용한다.
  • 만약 서버가 Database 를 1 시간에 한번씩 가져가는 경우에도 Batch Serving 을 이용한다.
• 중요한 것은 처음부터 Online Serving(API 형태)을 만들어야 하는 것은 아니고, 실시간 모델 결과가 어떻게 활용되는지에 대한 생각이 필요하다. 실시간으로 예측을 하더라도 활용이 되지 않는다면 Batch Serving 으로 진행해도 무방하다.
• Batch Serving 의 결과를 Database 에 저장하고, 서버는 Database 의 데이터를 쿼리해서 주기적으로 조회하는 방식으로도 사용할 수 있다.
• 우선 Batch Serving 으로 모델을 운영하면서 점점 API 형태로 변환하는 방법도 취할 수 있다.
• 중요한 것은 언제나 문제 상황에 따라 다르다는 점이다.

맨 위로 이동 ↑