[일일리포트] Day 81 (ProductServing_1/ FinalProject_1)

해당 일일리포트에서는 네이버 커넥트에서 진행하는 '부스트캠프 AI Tech 3기'에서 배운 내용을 다루고 있습니다. 저작권 이슈 때문에 관련 자료를 올릴 수는 없기에 핵심 이론과 코드를 요약해서 올리고 있기에 내용이 부족할 수 있습니다.
또한, Furthur Question의 경우 다른 포스팅을 통해서 다루겠습니다.

▶ Today I Learned (핵심 요약 정리)

Product Serving 개론

MLOps는 Machine Learning과 Oprations가 합쳐진 말로 머신러닝 모델을 운영하면서 반복적으로 필요한 업무를 자동화시키는 과정이다. 머신러닝 모델 개발과 머신러닝 모델 운영에서 사용되는 문제, 반복을 최소화하고 비즈니스 가치를 창출하는 것이 목표이다.
따라서 MLOps의 목표는 빠른 시간 내에 가장 적은 위험을 부담하며 아이디어 단계부터 Production 단계까지 ML 프로젝트를 진행할 수 있도록 기술적 마찰을 줄일 수 있어야 한다. 그리고 Production ML 단계에서는 모델 성능 뿐만 아니라 빠른 Inference 속도와 해석 가능여부가 중요하며 안정적인 운영과 전체 시스템 구조에 대한 이해가 필요하다.
요즘 MLOps는 정말 다양한 라이브러리들이 있기 때문에 라이브러리나 Tool을 익히는 것보다 각 MLOps Componet에서 해결하고자 하는 문제는 무엇이고, 어떤 방식으로 해결하고 있는지를 중심으로 학습하는 것이 좋다.

MLOps Component

Research에서만 진행하던 것을 Production으로 옮기는 과정이 MLOps의 가장 큰 Task라고 할 수 있다. 이때는 트래픽, CPU, 메모리 성능, 스케일 업과 스케일 아웃이 가능한가, 자체 서버를 구축할 지 클라우드를 사용할 지 등을 고려할 수 있다. MLOps의 Component에 대해 간단하게 적어보고자 한다.

Infra: 클라우드의 AWS, GCP, Azure, NCP등이 있다. 온 프레미스라는 회사나 대학원의 전산실에 서버를 직접 설치하는 방식이 있다.

Serving: Batch Serving과 Online Serving이 있다.

• Batch Serving은 많은 데이터를 일정 주기로 한꺼번에 예측하는 경우에 사용한다.
• Oneline Serving은 실시간으로 예측해서 동시에 여러 요청이 들어와도 병목이 없어야 하고, 확장이 가능하게 해야 한다.

Experiment / Model Management
모델 실험 Setting과 모델 Artifact를 저장해야 한다. 또한, 해당 모델에 대한 생성일이나 성능, 메타 정보들을 기록해둘 수 있다. (Hyperparams, Schemas, Statistics, Models, Evaluation metrics, Profiling logs, Other) 대표적인 라이브러리로 MLflow가 있고, 해당 기록이 점점 더 쉬워지고 있다.

Feature Store
머신러닝 Feature를 집계한 Feature Store가 있어, 모델을 만들 때마다 Feature에서 추출해올 수 있다. DL보다 정형 데이터에서 이러한 부분이 많이 사용된다. 그리고 Research와 Production에서 동일한 Feature를 사용할 수 있게 하면 더 실험과 배포가 더 쉬워질 수 있다. 대표적인 라이브러리로 FEAST가 있어, Featurestore를 간단히 정의해 사용할 수 있다.

Data Validation
Feature의 분포를 확인할 필요가 있다. 데이터가 이전 데이터와 serving이후의 데이터를 확인해야 한다. 이와 관련된 용어로 Data Drift가 있다. 대표적인 라이브러리로 TFDV(Tensorflow Data Validation)가 있지만 TF에서만 사용이 가능하다는 단점이 있다. AWS Deequ가 있어, 데이터에 대한 단위 Test와 Data Quality를 측정할 수 있다.

Continuous Training
모델을 배포한 이후 모델을 재학습해야하는 경우가 있다. 재학습은 새로운 데이터가 들어오거나, 일정 기간으로 하거나, 갑자기 Metric이 낮아진 경우에 할 수 있고, 이 외에도 요청이 있을 때 할 수도 있다. 라이브러리가 있지는 않고, Devops에서 활용하는 CI/CD개념과 연관되어 있다.

Monitoring
Serving을 진행하면서 모델의 지표, 인프라의 성능 지표 등을 잘 기록해 확인하는 것을 의미한다.

AutoML
시대가 좋아져서 데이터만 넣어주면 자동으로 서비스를 제공해줄 수 있게 됐고, 대표적인 라이브러리로 AutoML이 있다.

MLOps의 모든 Component를 한 번에 적용시키기에는 무리가 있다. 따라서 처음엔 작은 MVP(minimum viable product)로 시작해서 점점 운영 리소스가 많이 소요될 때 하나씩 구축하는 방식을 활용해야 한다

Model Serving

Serving은 Production 환경에서 모델을 사용할 수 있도록 배포하는 방법이다. 이는 다시 말해 머신러닝 모델을 개발하고, 현실 세계에서 사용할 수 있게 만드는 행위이다. 크게 Batch Serving과 Online Searving2가지로 구분할 수 있다.
Model Serving에 들어가기 전에 Serving과 Inference용어가 혼재되어 사용되는 경우가 있기 때문에 이에 대해서 구분을 하고 갈 필요가 있다.

• Serving: 모델을 웹/앱 서비스에 배포하는 과정, 모델을 활용하는 방식, 모델을 서비스화하는 관점이다.
• Inference: 모델에 데이터가 제공되어 예측하는 경우이며, 모델을 사용하는 관점이다.

Online Serving

Online Serving에 대해 이해하기 전에 Web Server에 대해 이해할 필요가 있다. Web server가 동작하는 과정은 식당의 종업원과 고객이 주문을 주고받는 과정을 생각하면 쉽다. 고객(Client)은 종업원(Server)에게 주문(Request)을 하고, 종업원(Server)은 주방에 주문을 전달하고, 종업원(Server)은 고객이 주문한 것을 고객에게 전달한다(Response).
Oneline Serving 과정에서 머신러닝 서버의 역할도 웹 서버와 크게 다르지 않고 Client의 다양한 요청을 처리해주는 역할을 한다. 머신러닝 모델 서버는 "어떤 데이터를 제공하며 예측해달라고 요쳥하면, 모델을 사용해 예측값을 반환하는 서버"이다.
추가적으로 API의 개념에 대해 이해할 필요가 있다. API는 'Application Programming Interface'라는 의미로 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만드는 인터페이스이다. 인터페이스는 기계와 인간의 소통창구라고 할 수 있는데, 특정 서비스에서 해당 기능을 사용할 수 있도록 외부에 노출한 API(기상청 API, 지도 API)일 수 있다. 또한, Pandas나 Pytorch와 같은 라이브러의 함수도 API라고 볼 수 있다. 이처럼 서버에서도 여러 API가 존재한다.

이제 Online Serving에 대해 다뤄보겠다. Online Serving은 요청이 올 때마다 실시간으로 예측을 진행한다. 클라이언트에서 ML 모델 서버에 HTTP요청을 하고 머신러닝 모델 서버에서 예측한 후, 예측 값을 반환하는 과정이다. 단일 데이터를 받아 실시간으로 예측하는 경우도 이에 해당한다. 그리고 ML모델 서버에서 데이터 전처리를 할 수도 있는 방법도 있고, 분리를 위해 전처리 서버와 ML 모델 서버로 나누는 경우도 있다. 이는 회사에 따라서 다르게 구성될 수 있다.
온라인 서비스를 구현하는 방식은 직접 API 웹 서버를 개발하는 방법, 클라우드 서비스를 활용하는 방법, Serving 라이브러리를 활용하는 방법이 있다.

• 직접 API 웹 서버 개발: Flask, FastAPI 등을 사용해 서버 구축
• 클라우드 서비스: 직접 구축해야 하는 MLOps의 다양한 부분이 쉽게 만들어진다. 또한, 사용자 관점에선 Pytorch사용하듯 학습 코드만 제공하면 API 서버가 만들어진기 때문에 직접 개발보다 쉽다. 하지만 클라우드 서비스가 익숙해야 잘 활용할 수 있고, 비용문제가 있다. (AWS의 SageMaker, GCP의 Vertex AI 등)
• Serving 라이브러리 활용: 다양한 방식으로 개발할 수 있지만, 추상화된 패턴을 잘 제공하는 오픈소스를 활용할 수 있다. 그리고 BentoML처럼 간단히 사용할 수 있는 오픈소스가 많이 증가하고 있다. (Tensorflow Serving, Torch Serve, MLFlow, BentoML 등)

Online Serving에서는 여러가지 고려해야 할 부분이 있다. 우선 실시간 예측을 하기 때문에 예측할 때 지연 시간(Latency)을 최소화해야 함을 고려해야 한다. [Latency: 하나의 예측을 요청하고 반환값을 받는데까지 걸리는 시간] 그 외에 다음과 같은 고려할 사항들이 존재한다.

1) Input 데이터를 기반으로 Database에 있는 데이터를 추출해서 모델 예측해야 하는 경우: 데이터를 추출하기 위해 쿼리를 실행하고, 결과를 받는 시간 소요
2) 모델이 수행하는 연산: RNN, LSTM 등은 회귀 분석보다 많은 연산을 요구하고 오래 걸린다. 따라서 모델을 경량화하는 작업이나 복잡한 모델보다 간단한 모델을 사용하는 경우도 존재
3) 결과 값에 대한 보정이 필요한 경우: 머신러닝 알고리즘에서 유효하지 않은 예측값이 반환될 수 있기 때문에 후처리 Logic이 필요할 수 있다.

Batch Serving

BatchServing은 Workflow Scheduler라는 것을 사용해 작업을 특정기간 단위로 주기적으로 실행(학습, 예측)하는 것을 의미한다. 한꺼번에 배치 단위로 묶어서 특정 시간에 반복해서 실행한다. Batch Serving 관련한 라이브러리는 따로 존재하지 않고, 함수 단위를 "주기적"으로 실행한다. Workflow Scheduler로 데이터 엔지니어링에서 자주 활용되는 Airflow와 Linux의 CronJob이 있다.
Online Serving보다 구현이 수월하며 간단하다. 또한, 한번에 많은 데이터를 처리하므로 Latency가 문제되지 않는다. 하지만 실시간으로 활용할 수 없기 때문에, Cold Start 문제가 존재하는 등의 단점이 있다.

Online Serving vs Batch Serving

Online vs Batch를 선택하는 기준은 Input관점과 Output관점에서 구분해서 볼 수 있다.
Input관점

• 데이터 하나씩 요청하는 경우: Online
• 여러가지 데이터가 한꺼번에 처리되는 경우: Batch

Ouput관점: 인퍼런스 Output을 어떻게 활용하는지에 따라 다르다.

• API 형태로 바로 결과를 반환해야 하는 경우나 서버와 통신이 필요한 경우: Online
• 1시간에 1번씩 예측해도 괜찮은 경우: Batch

우선 Batch Serving으로 모델을 운영하면서 점점 API형태로 변환할 수 있다. 하지만, 실시간으로 모델 결과를 활용해야 한다면 Online Serving이 필요하다.

▶ Review (생각)

2주 전부터 생각했던 주제가 좌절되면서 코어타임 시간에는 거의 최종 프로젝트 관련해서 주제 선정 자료조사를 하고, 주제를 정리하는데 집중했다. 하지만 아직까지도 주제에 대한 의견이 모이고 있지 않아 어려움을 겪고 있어, 오늘만해도 이전 멘토님과 새로운 멘토님 두 분께 멘토링을 받았다. 이전 멘토님께 받은 피드백을 통해 새로운 주제를 선정했고, 새로운 멘토님께 보여드렸다. 그리고 새로운 멘토님의 멘토링을 통해 우리 팀이 너무 어렵게 생각하고 있었다는 것을 깨닫게 되었다. 생활의 문제에서 출발하는 주제가 됐으면 했기 때문에 주제를 어렵게 만들고 있었고, 그러다보니 정작 중요한 팀의 흥미나 재미적인 부분을 고려하지 못했었다. 사업이 아닌 사이드 프로젝트였기 때문에 이 부분도 중요하게 다뤘어야 하는데, 제대로 된 프로젝트를 하고 싶다는 생각에 이러한 부분을 고려하지 못했던 것 같다. 그리고 무엇보다 중요한 것은 기술적인 Stack이나 뛰어난 아이디어가 아닌 한 번의 프로젝트를 돌려보면서 인사이트를 얻는게 더 중요하다는 것도 어느 순간 놓치고 있었다. 따라서 내일 오전 중으로는 지금까지 나왔던 주제들 중 멘토님께서 괜찮다고 하셨던 주제를 선정해서 빠르게 진행하는게 좋을 것 같다. 그리고 해당 주제에 대해서 더 발전 및 변화시킬 수 있는 부분을 프로젝트를 진행하며 추가하는 부분에 대해서 팀원들에게 얘기해봐야겠다.
그리고 오늘 Product Serving 강의를 시작하게 됐는데, 매우 흥미로운 강의였고 제대로 공부하고 싶다는 생각이 드는 강의였다. 저번에 마스터님께서 강의에서 나오는 Further Question에 대해서 블로그에 정리하면 좋을 것 같다고 말씀하셨는데, 강의를 정리하는 것만으로도 양이 꽤 많다. 따라서 이 부분에 대해서는 별도의 글로 작성하면서, 마스터님께서 말씀해주셨던 공부한 내용을 정리하는 것뿐만이 아닌 '글'을 써보려고 한다. 그리고 오늘은 이론적인 부분을 다룬 강의였기 때문에 기록하면 좋을 것 같아 정리했지만, Part2, Part3부터는 Further Question 부분만 따로 글을 작성하는 것도 좋아보일 것 같다. 그리고 남는 시간은 최종 프로젝트와 관련된 부분을 다루고자 한다.