[AITech][Product Serving] 20220516 - Product Serving 개론

본 포스팅은 SOCAR의 ‘변성윤’ 마스터 님의 강의를 바탕으로 작성되었습니다.

Product Serving 개론

MLOps 개론

MLOps가 필요한 이유가 뭘까?

모델 개발을 하는 경우는 크게 두가지 상황으로 나눌 수 있다.

• Research
• Production

Research에서는 고정된 데이터, 환경 하에서 모델의 퍼포먼스를 올리는데 집중을 한다.

이렇게 개발된 모델을 real world에 배포할 때는, 여러 변수가 생긴다.

• 모델 결과값이 이상한 경우
• 모델 성능이 크게 변하는 경우
• 데이터가 잘못된 경우
• 실제 사용하기에 부적절한(속도, 용량 등) 경우

그래서 Production 시의 모델 개발에서는 아래와 같이 Deploy 과정이 추가된다.

MLOps의 목표는 빠른 시간 내에 가장 적은 위험을 부담하여 아이디어 단계부터 Production 단계까지 ML 프로젝트를 진행할 수 있도록 기술적 마찰을 줄이는 것이다.

아래는 Research ML과 Production ML의 일반적인 차이이다.

MLOps의 각 Component에 대해 이해하기

MLOps는 몇 개의 component로 구성된다.

• Infra (Server, GPU)
  • 모델을 어디에 관리할 것인가? 로컬? 회사 내 서버? 클라우드?
  • CPU와 GPU 성능은 어느정도 필요할 것인가?
• Serving
  • 사용자/소비자에게 어떤 식으로 모델을 제공할 것인가?
  • Batch serving(정기적으로), Online serving(요청 시)
• Experiment, Model Management
  • 실험이나 환경, 하이퍼파라미터 등 기록
• Feature Store
  • Feature 전처리
  • 모델 가중치, 구조 등 기록 및 저장
• Data Validation (Data Management)
  • 데이터 저장 및 파이프라인 제공
• Continuous Training
  • 모델 재학습 -> 언제 재학습 시킬것인가?
  • 새로운 데이터가 생긴 경우, 정기적으로, 성능이 나빠진 경우, 요청 시
• Monitoring
  • 모델의 성능 등을 logging하고 확인
• AutoML
  • 요즘엔 데이터만 넣어주면 자동으로 모델 구조를 만들어준다?!?

각 Component를 위한 tool 들은 매우매우 많아서, 각각을 완벽히 익히는 것보다는 왜 이것이 필요하고, 언제 사용할 수 있을지에 대해 이해햐는 것이 중요하다. 더욱이 MLOps를 위한 tool 들은 아직 통합되거나, 대세를 이룬다고 할 만한 것들이 명확히 없다.

그렇기 때문에 항상 위 요소들이 모두 사용될 필요는 없다. 하지만 내가 어떤 부분이 필요하다고 인지했을 때 무엇을 사용할 수 있을지 정도는 떠올릴 수 있는 것이 좋을 것이다.

MLOps Component들 중 내가 매력적으로 생각하는 TOP3?

진짜 다 중요해보여서 3개만 고르기가 너무 어렵다… 그렇기 때문에 각 component가 존재하는 것이겠죠.

그래도 현재 공부하는 입장에서 가장 와닿는 부분들을 위주로 골라본다!

• Infra
  • 어떤 환경에서 모델을 학습시키고, 서비스를 제공하는지는 너무 중요해서 두 말하면 잔소리인 것 같다. 이로부터 개발 프로세스가 어떤 식으로 진행될 지 정해야 하니 말이다.
  • 현재 가용한 Infra를 토대로 정해야 하는 부분들이 많다고 생각해서, 가장 중요한 것 같다.
• Experiment, Model Management
  • 실험/모델 관리 또한 너무너무 중요하다. 효율적으로 분업을 하고, 겹치지 않는 일을 하여 최단시간에 최고의 효율을 뽑아내기 위해서는 실험/모델 관리가 매우매우 중요하다.
  • 이러한 실험/모델 관리 툴이 잘 갖춰져 있다면 프로덕트 서빙 과정에 있어서 효율이 크게 오를 것이다.
• Monitoring
  • Production 관점에서 핵심적인 것이 성능 monitoring이라고 생각한다. 우리의 목적은 만들어서 주는 것이 아닌, 지속적인 서비스의 제공이기 때문에 monitoring 과정은 너무나 중요하다. 이는 어찌보면 책임감과도 연관될 수 있다고 생각한다.
  • 제공중인 서비스를 모니터링하고, 이를 기반으로 어떤게 개선할 것인지를 결정하는 것은 서비스 과정의 핵심이라고 생각한다.

MLOps 관련 자료, 논문

• https://github.com/EthicalML/awesome-production-machine-learning
• https://github.com/visenger/awesome-mlops
• Uber의 MLOps 논문, 기술 블로그
• 구글 클라우드의 ‘Practitioners Guide to MLOps’
• Superb AI의 ‘실리콘밸리의 MLOps’

Model Serving

용어 정리

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

Online Serving

Online serving은 웹 서버 통신을 생각하면 됩니다. 여기에 머신러닝 모델을 포함한 것이 머신러닝 모델 서버라고 보면 되고요.

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

그리고 이와 같은 Online serving을 할 때에는 API를 사용하여 서버를 구축해야 합니다. 이때 대략적인 파이프라인은 아래와 같이 구성됩니다.

즉, online serving은 요청에 따라 단일 데이터를 받아 실시간으로 예측 후 결과를 반환해주는 서빙 방식입니다.

API를 사용하여 Online serving을 구현할 때에는 3가지 방식을 사용할 수 있습니다.

1. 직접 API 웹 서버 개발

   • Flask, FastAPI 등을 사용해 서버 구축
   • localhost(예를 들면 www.naver.com/) 웹 서버 예시

   

2. 클라우드 서비스 활용

   • AWS의 SageMaker, GCP의 Vertex AI 등
   • 장점
     • 직접 구축해야 하는 MLOps의 다양한 부분(API 서버 만들기)이 만들어짐
     • 사용자 관점에선 PyTorch 사용하듯 학습 코드만 제공하면 API 서버가 만들어짐
   • 단점
     • 클라우드 서비스가 익숙해야 잘 활용할 수 있음
     • 비용 문제: 직접 만드는 것보다 더 많은 비용이 필요할 수 있음
   • 클라우드 서비스에서는 어떤 방식으로 AI 제품을 만들었는지 확인할 수 있어서 사용해보는 것도 좋음

3. Serving 라이브러리 활용

   • Tensorflow Serving, Torch Serve, MLFlow, BentoML 등

   • Fast API 등을 활용할 수 있지만, 처음에 서버에 대한 이해가 충분하지 않으면 어려울 수 있음

   • 다양한 방식으로 개발할 수 있지만, 매번 추상화된 패턴을 가질 수 있음

   • 추상화된 패턴을 잘 제공하는 오픈소스를 활용하는 방식

   • BentoML 예시

     

이 중 어떤 방식을 쓰느냐는 주어진 환경(회사에서 주어진 일정, 인력, 예산, 요구 성능 등)에 따라 다릅니다.

[추천 방식]

1. 프로토타입 모델을 클라우드 서비스를 활용해 배포 (클라우드 비용이 괜찮을 경우)
2. 직접 Fast API 등을 활용해 서버 개발
3. Serving 라이브러리를 활용해 개발

[신경 써야 할 부분]

추가적으로, Online serving에서는 Python 버전, 패키지 버전 등 Dependency가 굉장히 중요합니다. (Virtualenv, Poetry, Docker 등)

또한 실시간 예측을 하기 때문에 지연 시간(Latency)을 최소화해야 합니다.

이외에 다음과 같은 요소들을 고려해야 합니다.

• Input 데이터를 기반으로 Database에 있는 데이터를 추출해서 모델 예측해야 하는 경우 (데이터 통신 시간)
• 모델이 수행하는 연산 (모델 경량화)
• 결과값에 대한 보정(후처리)이 필요한 경우

이와 같은 문제들을 해결하기 위해 여러가지 방법들이 존재하며, 이후 강의에서 다뤄집니다.

• 데이터 전처리 혹은 서버 분리(혹은 Feature를 미리 가공 -> Feature Store)
• 모델 경량화
• 병렬처리(Ray)
• 예측 결과 캐싱

Batch Serving

Batch Serving은 여러 input data들에 대한 예측 output을 특정 기간 단위(하루, 1시간 등)로 내야하는 경우에 사용합니다.

여기에는 이전 하루 동안의 데이터를 이용하여 다음 날 추천 리스트를 예측하는 등의 task를 들 수 있습니다.

• 장점
  • Jupyter Notebook에 작성한 코드를 함수화한 후, 주기적으로 실행하는 간단한 구조
  • Online Serving보다 구현이 수월하며, 간단함
  • 한번에 많은 데이터를 처리하므로 Latency가 문제되지 않음(보통의 경우)
• 단점
  • 실시간으로 활용할 수 없음
  • Cold Start 문제: 오늘 새로 생긴 컨텐츠는 추천할 수 없음

Batch Serving에서 이용하는 Workflow Scheduler로는 다음과 같은 것들이 있습니다.

• 데이터 엔지니어링에서 자주 활용되는 Airflow
• Linux의 Cron Job
• 참고: Awesome Workflow Engines Github

Online Serving vs Batch Serving

Input 관점

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

Output 관점

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

더 읽어보면 좋은 자료

• [Rules of Machine Learning:

  ML Universal Guides

  Google Developers](https://developers.google.com/machine-learning/guides/rules-of-ml)

• Online Serving / Batch Serving 기업들의 Use Case 찾아서 정리하기

머신러닝 프로젝트 라이프 사이클

문제 정의의 중요성

문제를 잘 풀기 위해서는 문제를 잘 정의하는 것이 중요하며, 이 때의 문제 정의란 ‘왜 이 문제를 풀어야 하는지, 이 문제를 풀면 어디어 어떻게 도움이 되는지’와 같은 Why에 집중하는 것을 말합니다.

프로젝트 Flow

프로젝트 Flow는 현상 파악 -> 구체적인 문제 정의 -> 프로젝트 설계 -> Action -> 추가 원인 분석으로 이어집니다.

현상 파악

어떤 현상이 발생하였는지 현재 상황을 파악합니다.

• 어떤 일이 발생하고 있는가?
• 해당 일에서 어려움은 무엇인가?
• 해당 일에서 해결하면 좋은 것은 무엇인가?
• 추가적으로 무엇을 해볼 수 있을까?
• 어떤 가설을 만들어 볼 수 있을까?
• 어떤 데이터가 있을까?

구체적인 문제 정의

그리고 앞선 현상을 조금 더 구체적이고 명확한 용어로써 정리해봅니다.

이 과정에서 현상 속의 어떤 부분 때문에 지금 현상이 발생하는 것인지(원인) 파악하고 구체화합니다.

문제를 일으키는 원인을 구체화하고 나면, 문제를 어떻게 해결할 수 있을 지 How에 집중하여 해결 방안들을 만듭니다. 이 때 주의할 것은, 무조건 머신러닝을 사용한 방법이 최상의 솔루션을 아닐 수 있다는 것입니다. 즉, Rule-based 방법과 같이 간단한 방법부터 점진적으로 접근하는 것이 좋고, 머신러닝 알고리즘적 방법을 사용하려면 적절한 패턴과 데이터가 있어야 함을 명심해야 합니다.

문제 정의는 결국 현상을 계속 쪼개서 각각을 어떻게 해결할 수 있을지 생각하는 것입니다.

프로젝트 설계

이 강의를 진행하신 마스터 분은 실제로 아래와 같은 프로젝트 설계 과정을 거치셨다고 합니다.

• 문제 정의
• 최적화할 Metric 선택
• 데이터 수집, 레이블 확인
• 모델 개발
• 모델 에측 결과를 바탕으로 Error Analysis. 잘못된 예측이 왜 생기는지 분석
• 다시 모델 학습.
• 성능이 나오지 않아 더 많은 데이터 수집
• 다시 모델 학습
• 2달 전 테스트 데이터에서는 성능이 좋았지만 오늘 데이터에는 성능이 좋지 않음
• 모델을 다시 학습
• 모델 배포
• 최적화할 Metric이 실제로 잘 동작하지 않아 Metric을 수정
• 다시 시작…

이와 같이, 실제로 배포할 AI 모델을 설계하는 일에는 많은 일들이 포함되어 있고, 당연히 생각대로 흘러가지 않습니다. 그래서 여기서 강조하는 것은, 문제 정의 후 프로젝트의 설계를 최대한 구체적으로 하는 것이 좋다는 것입니다.

여기서 프로젝트의 설계를 구체적으로 한다는 것은 실제 설계 과정에서 들어가기 전에 대비할 수 있는 것들은 다 대비하고 시작하자는 것입니다. 그리고 다음과 같은 예시들이 있습니다.

머신러닝 문제 타당성 확인

머신러닝 문제를 고려할 때는 얼마나 흥미로운지가 아니라, 제품/회사의 비즈니스에서 어떤 가치를 가져다 줄 수 있는지를 고려해야 합니다.

머신러닝을 이용해 문제를 풀면 좋은 경우는 다음과 같습니다.

• 패턴: 학습할 수 있는 패턴이 있는가?
  • ex) 로또 번호와 같이 생성되는 방식에 패턴이 없다면 학습할 수 없다
• 목적 함수: 학습을 위한 목적 함수를 만들 수 있는가?
• 복잡성: 패턴이 충분히 복잡한가?
  • 패턴이 복잡하지 않을 경우 머신러닝 방법을 사용할 필요가 없다
  • 비슷한 task를 머신러닝을 이용해 해결한 선례가 있는가?
    • 있다면, 머신러닝 문제로서 타당하다
    • 없다면, 이 문제는 혁신적인 문제이거나 머신러닝을 이용하기 적합하지 않은 문제이다
• 데이터 존재 여부: 적절한 데이터가 존재하거나, 수집/제작할 수 있는가?
  • 적절한 데이터가 없다면, 학습할 데이터를 어떻게 만들지부터 결정해야 함
• 반복: 반복적인 task인가?
  • 어떤 task가 반복적이라는 것은 패턴이 있다는 것이다

반면 머신러닝을 사용하면 좋지 않은 경우들도 있습니다.

• 비윤리적인 문제
• 간단히 해결할 수 있는 경우
• 좋은 데이터를 얻기 어려운 경우
• 한 번의 에측 오류가 치명적인 결과를 발생시킬 경우
• 시스템이 내리는 모든 결정이 설명 가능해야 할 경우
• 비용 효율적이지 않은 경우

목표 설정, 지표 결정

프로젝트의 목표에는 Goal과 Objectives가 있습니다.

• Goal: 프로젝트의 일반적인 목적, 큰 목적
• Objectives: 목적을 달성하기 위한 세부 단계의 목표

Goal과 Objective도 마찬가지로 프로젝트 설계 과정에서 계속해서 구체화됩니다.

지표의 경우, 모델의 성능을 평가할 핑가 지표가 필요합니다. 보통 objective마다 하나의 loss function을 정의하며, 그 loss function들을 결합하여 전체 모델의 cost function을 정의합니다. Cost function을 정의하는 방법으로 다음의 2가지 방법이 주로 사용됩니다.

• 방법 1

  • 단일 모델 사용
  • 두 loss를 하나의 loss로 결합하고, 해당 loss를 최소화하기 위해 모델을 학습

  

• 방법 2

  • 2개 이상의 모델 사용
  • 각각의 모델을 상정하고, 각각의 loss를 최소화

  

  • 여러 개의 모델을 사용할 경우, 전체 모델을 재학습하지 않아도 조정할 수 있음

정리하면, Objective가 여러 개인 경우 분리하는 것이 좋고, 전체 모델을 재학습하지 않도록 모델을 분리하는 것이 좋습니다. Objective는 수정해야 하는 유지보수 일정이 모두 다를 수 있기 때문에, 각각을 나누는 것이 이런 점에서도 좋습니다.

제약 조건

프로젝트 설계 과정에서의 제약 조건에는 다음의 사항들이 있습니다.

• 일정: 프로젝트에 사용할 수 있는 시간
• 예산: 사용할 수 있는 최대 예산
• 관련된 사람: 이 프로젝트로 인해 영향을 받는 사람
• Privacy: Storage, 외부 솔루션, 클라우드 서비스 등에 대한 개인정보 보호 요구
• 기술적 제약: 기술을 적용하는 환경에서의 기술적 제약
• 윤리적 이슈: 윤리적으로 어긋난 결과
• 성능
  • Baseline : 새로 만든 모델을 무엇과 비교할 것인가? 기존에 사람이 진행하던 성능 or 간단한 회귀
  • Threshold : 확률값이 0.5 이상일 경우 강아지라고 할 것인지, 0.7 이상일 경우 강아지라고 할 것인지?
  • Performance Trade-off : 속도가 빠른데 Acc 0.93 vs 속도는 조금 더 느린데 Acc 0.95
  • 해석 가능 여부 : 결과가 왜 발생했는지 해석이 필요할까? 해석이 필요한 사람은?
  • Confidence Measurement : False Negative가 있어도 괜찮은지? 오탐이 있으면 안되는지?

베이스라인, 프로토타입

모델이 더 좋아졌다고 판단할 수 있는 베이스 라인이 필요합니다. 설계를 시작할 때는 가장 간단한 모델부터 시작하는데요, 이유는 다음과 같습니다.

• 어떻게든 모델의 위험을 낮추는 것이 목표가 되어야 함
• 가장 좋은 방법은 최악의 성능을 알기 위해 허수아비 모델로 시작하는 것
• 초기에는 아주 단순한 알고리즘으로 동작하는 모델을 사용

유사한 문제를 해결하고 있는 SOTA 논문을 파악하여 우리의 문제에는 어떤 시도를 해볼 수 있을지 고민하는 것도 아주 중요합니다.

베이스라인 이후에 간단한 모델을 만들면 피드백을 들어보는 것이 좋고, 이 때 모델을 사용할 수 있는 환경을 미리 준비해놓아야 합니다. 이를 프로토 타입이라 합니다.

• Input을 입력하면 Output을 반환하는 모델 형태
• 디자인보다는, 모델의 동작에 집중하는 것이 필요

평가 방법 설계

앞서서 Objectives를 구해 모델의 성능 지표는 확인할 수 있었습니다. 여기서 말하는 평가 방법이란, 비즈니스 차원의 목표에 영향을 미치는 정도를 파악하는 용도입니다.

앞선 문제를 해결할 경우 어떤 지표가 좋아질 지 고민하는 것이 중요하며, 지표를 잘 정의해야 우리의 Action이 기존보다 더 성과를 냈는지 아닌지를 파악할 수 있습니다.

평가 방법 설계 과정에서 할 수 있는 고민으로는 다음의 것들이 있습니다.

• 개발 및 배포 중에 시스템의 성능은 어떻게 판단할 수 있을까?
• 정답 레이블이 필요한 경우 사용자 반응에서 어떻게 레이블을 추론할 수 있을까?
• 모델 성능을 비즈니스 Goal과 Objectives를 어떻게 연결할 수 있을까?

Action (모델 개발 후 배포&모니터링)

프로젝트 설계를 마치고 나면, 이를 실제 서비스로 배포하고 지속적으로 모니터링해야 합니다. 이 때 앞서 정의한 지표가 어떻게 변하는지를 파악합니다.

• 현재 만든 모델이 어떤 결과를 내고 있는가?
• 잘못 예측하고 있다면 어떤 부분이 문제일까?
• 어떤 부분을 기반으로 예측하고 있을까?
• Feature의 어떤 값을 사용할 때 특히 잘못 예측하고 있는가?

추가 원인 분석

Action 후에는 새롭게 발견한 상황을 파악해 어떤 방식으로 문제를 해결할 지 모색하고, 그 과정에서 앞서 진행한 과정을 반복합니다.

비즈니스 모델

비즈니스란 회사에서 중요하게 생각하는 것이며, 비즈니스에 대한 이해도가 높을수록 문제 정의를 잘 할 수 있습니다.

• 회사의 비즈니스 파악하기
• 데이터를 활용할 수 있는 부분은 어디인가? (Input)
  • 데이터가 존재한다면 어떤 데이터가 존재하는가?
  • 데이터로 무엇을 할 수 있을까?
  • 해당 데이터는 신뢰할만한가? 데이터 정합성은 맞는가? 레이블이 잘 되어있는가? 계속 받을 수 있는가?
  • 다양한 팀에 있는 분들과 직접 인터뷰하는 것도 좋은 방법
• 모델을 활용한다고 하면 예측의 결과가 어떻게 활용되는가? (Output)
  • 고객에게 바로 노출(추천, 얼굴 필터 등) => 더 좋은 가치 제공 / 매출 증대
  • 내부 인원이 수동으로 진행해야 하는 업무를 자동화할 수 있음

이 과정에서 누군가 산업에 대해 정리해둔 Paper가 있는지 찾아보는 것이 큰 도움이 됩니다. awesome - 분야명(기술명) - github와 같이 입력하면 해당 분야에서 사용하는 기술들에 대해 찾아볼 수 있습니다.

참고 자료

• Uber 비즈니스 모델
• https://github.com/zzsza/Awesome-Mobility-Machine-Learning-Contents

참고 자료