머신러닝 오퍼레이션 자동화, MLOps

in MLOps on Basic


  • MLOps 춘추 전국 시대 정리 자료를 정리한 글입니다
    • 최초 작성했던 글을 2021년 6월에 모두 수정했습니다
    • 키워드 : MLOps, MLOps란, MLOps 정의, MLOps 플랫폼, MLOps 엔지니어, MLOps 뜻, MLOps pipeline, MLOps framework


머신러닝 프로세스(Research)

  • 연구, 테스트 단계를 Research로 정의함
  • 머신러닝의 큰 프로세스
    • 문제 정의
      • 어떤 문제를 풀 것인지 정의
      • 어떤 데이터가 필요한지?
      • 어떤 방식으로 문제를 풀 수 있는지? 여러 방법 중 어떤 방법을 우선적으로 사용할 수 있는지?
    • EDA
      • 데이터에 어떤 컬럼이 있는지
      • 컬럼의 분포는 어떠한지
      • Target Value와 어떤 관계가 있는지 등
    • Feature 생성
    • 모델 학습
    • 예측
  • 특징
    • 보통 자신의 컴퓨터(로컬이라고 표현) 또는 서버에서 실행
    • 고정된(Static, Fixed) 데이터를 사용해 학습


머신러닝 프로세스(Production)

  • 머신러닝 모델을 실제 서비스화하는 과정을 Production으로 정의함
  • 실제 환경 : Production, Real World
    • 실제 환경의 예시 : 모바일 앱 서비스 또는 웹 서비스에서 모델을 사용해 예측하는 경우
  • Research에서 만든 모델을 실제 환경에 서비스화하면서 생각해야 하는 부분이 많이 존재함
    • 우선 현실 세계는 매우 Risk가 있는 환경이므로, 데이터가 안정적으로 들어온다는 생각을 하면 안됨
    • 모델을 API 형태 등으로 배포해야 함(쉽게 배포하고, 롤백도 가능해야 함
    • Input Data가 학습할 당시와 동일한 범위 안에 있는지, 동일한 타입으로 들어오는지 확인해야 함
    • 새로 배포한 모델의 성능을 지속적으로 확인해야 함(Research 단계와 다를 수 있으므로)
    • Research 단계에선 좋았던 모델이 Production 환경에서 더 안좋을 수 있음
    • Research 단계에서 만든 Feature가 사실상 실제 서비스할 경우엔 사용할 수 없을 수 있음
  • 이런 상황은 머신러닝의 전체 프로세스가 머신러닝 모델 개발(Model Development)과 머신러닝 모델 운영(Model Operation)로 나뉘기 때문
    • 머신러닝 모델 운영시 고려할 부분이 매우 많기 때문
    • 앱 서비스를 만드는 과정과 유사함. 앱에서 새로운 기능을 개발하는 것과 이미 저번 주에 출시된 기능의 버그를 찾고 계속 운영하는 일이 발생함 => 이 작업을 1명이 한다면 매우 할 일이 많을텐데, 머신러닝 프로세스도 동일함
  • 구글의 논문인 “Hidden Technical Debt in Machine Learning Systems”(번역 글)에도 나온 것처럼 머신러닝 코드는 머신러닝 시스템 중 정말 작은 일부분에 불과함

  • 이런 상황을 해결하기 위해 MLOps라는 분야가 생겼고, 계속 발전하고 있음


MLOps

  • ML + Ops = MLOps

  • 머신러닝 모델 개발과 머신러닝 운영 Workflow의 간극을 줄이기 위한 분야

  • Model Development와 Model Prediction으로 나누는 관점으로도 볼 수 있음

  • 만약 머신러닝 팀이 작을 경우
    • 소수의 모델을 운영함(팀 인원이 직접 운영할 수 있는 2~3개의 모델)
    • 소수의 모델이므로 데이터 과학자들 모델에 대해 기억할 수 있음
    • 각자의 모델을 자신만의 방법으로 진행 상황 추적, 성능 확인을 하곤 함
  • 팀이 점점 성장하면 생기는 이슈들
    • 1) 데이터의 복잡도 증가
      • 데이터를 가공하는(전처리) workflow가 많음
      • 데이터가 중앙에서 표준화되게 관리되지 않고, 갑자기 수정될 수 있음(기록은 없고)
      • 이런 Flow의 복잡성을 관리하는게 점점 힘들어짐
    • 2) 사람마다 선호하는 프레임워크가 다름
      • Tensorflow, R, Spark, Keras, PyTorch, MXNet 등
    • 3) 모델을 배포하는 Serving은 점점 어려워짐
      • 환경마다 실행이 달라지고, 라이브러리나 파이썬 버전 등에 민감함
      • 모델을 배포한 후, 만약 좋지 않으면 과거 버전으로 롤백하는 과정도 복잡할 수 있음
    • 4) 무엇이 잘못되었는지 추적하기 힘듬
      • 데이터 과학자들은 파이프라인 버그라고 말할 수 있고(데이터의 이슈다)
      • 데이터 엔지니어는 모델의 문제라고 함(예측 결과의 이상함)
  • MLOps의 목표
    • 머신러닝 모델 개발(ML Dev)과 머신러닝 모델 운영(Ops)에서 사용되는 문제의 반복을 최소화하면서 비즈니스 가치를 창출하는 것
    • 모델링에 집중할 수 있도록 안정된 인프라를 만들고 자동으로 운영하는 것
    • 빠른 시간에 적은 Risk로 프러덕션까지 진행할 수 있도록 기술적 마찰을 줄이는 것
  • MLOps의 중요한 원칙
    • Reproducibiltiy(재현성)
      • Research 단계에서 만든 모델이 Production 환경에도 재현되어야 함
      • 데이터도 유사한 분포를 가져야 함
    • Orchestration(오케스트레이션)
      • 서비스의 자동화된 설정, 관리, 조정 등
      • 만약 예측하려는 요청이 많은 경우 내부적으로 서버를 증설해야 함
  • 데이터 직군들의 Task
    • Data Scientist
      • 모델 개발
    • Data Engineer
      • 데이터 파이프라인 개발
    • MLOps Engineer
      • 모델, 데이터 파이프라인 및 Production 부분 담당


Research ML과 Production ML의 비교

  • Research, Production의 차이점을 느끼면 좋음
    • 여기 작성된 부분이 100% 진리는 아니고, 글쓴이의 개인적 견해


MLOps Component

  • 쉬운 설명을 위해 요리하는 과정을 예시로 사용함
  • 집에서 요리를 하다보면, 가끔 자신의 요리에 자신감을 가질 수 있음
    • 이런 경우 자신이 좋아하는 요리를 만드는 레스토랑을 만들 수 있음

  • 집, 레스토랑의 요리를 나눠서 설명함
    • 집 : Research
      • 요리를 연습하는 환경
      • 요리하고 꼭 모든 요리가 레스토랑에서 판매되는 것은 아님. 요리하다 보면 실패도 경험함
    • 레스토랑 : Production
      • 만든 요리를 판매하는 환경
    • 식재료 : Data, Feature
    • 음식 : Machine Learning Model
    • 요리하는 행위 : Train
  • 대표적인 MLOps Component
    • Serving
    • Experiment, Model Management
    • Feature Store
    • Data Validation
    • Continuous Training
    • Monitoring
    • GPU Infra Management
    • AutoML


Serving

  • 레스토랑에서 음식을 만들었으면, 이제 손님에게 “서빙”해야 함
    • 음식 서빙과 동일하게 모델도 서빙한다고 생각하면 됨
  • Serving의 방식
    • Batch Serving
    • Online Serving
    • Edge Serving(Mobile)
  • Serving에서 신경써야 하는 부분
    • 의존성 관리 : 라이브러리, 파이썬 버전, OS 등
    • Docker나 Kubernetes를 많이 사용함
  • Batch Serving
    • 음식을 정기 배송하는 것처럼, 특정 시간에 서빙받길 원하는 경우가 있음
    • 이런 경우를 Batch로 많은 양을 한꺼번에 처리한다고 해서 Batch Serving이라 표현함
    • 방식
      • 라이브러리가 존재하진 않고, Airflow나 Cronjob 등으로 특정 시간에 학습하고(예를 들어 1주일 단위) 특정 시간마다 예측(예를 들어 1시간 단위)
      • 가장 처음에 접근하기 쉬운 방식
      • Batch로 예측한 결과를 DB Table에 저장하고, 서버에서 이 값을 활용하는 방식으로 협업 가능
  • Online Serving
    • API Serving이라 부를 수도 있음
    • 주문하고 바로 음식을 만들어 서빙하는 경우
      • 한번에 음식을 하나씩 포장해서 배송
    • Online 상황처럼 실시간으로 Request가 올 경우 Response를 반환함
    • 동시에 여러 주문이 들어올 경우(=Request가 동시에 많이 올 경우) 확장 가능한 대책이 필요함
    • 진행해야 하는 예측이 Batch 불가능하고, 실시간으로 빠르게 처리해야 하는 경우 선택하는 방식
    • 방식
      • Flask / FastAPI를 사용해서 API 서버를 직접 개발하는 방식(그 후 Docker 등에 올림)
      • Serving 라이브러리 사용
    • Serving 라이브러리

  • 도표
    • 모델을 개발한 후, 패키지화해서 Serving

(구글 클라우드의 Practitioners Guide to MLOps)


Experiment, Model Management

  • 집에서 음식 만들 때, 레시피를 기록해두어야 함
    • 어떤 재료를 사용하고 몇 분동안 데우고, 맛이 어떠했는지 등
    • 머신러닝 모델링에서도 여러 파라미터, 어떤 모델 구조 등으로 여러 실험을 진행함
    • 캐글에서 많은 실험을 어떻게 기록하는지와 관련됨
    • 이 중에서 제일 맛있었던(=성능이 좋았던) 모델을 레스토랑으로 옮김(=Production)
  • 음식 만드는 과정에서 생기는 부산물(최종 음식, 사용한 재료 등)을 모두 저장해둠
    • 머신러닝 모델 파일, Feature importance 등
    • Artifact라는 단어가 자주 사용됨
  • 정리하면 머신러닝 모델 학습하는 과정에서 생기는 설정, 데이터, Artifact 등을 모두 저장함
    • 기록은 쉽고, 모니터링할 수 있는 대시보드가 필요함
    • 특정 메트릭 기준으로 좋은 것을 선택하는 Choice 기능도 필요함
  • SaaS가 매우 많으며, Weight and Bias, Neptune 등이 존재함
  • 오픈소스는 MLflow가 제일 활발하게 개발됨
    • MLflow 관련 내용은 전시흠님의 블로그에 라이브러리 리뷰쪽에 보면 MLflow의 모든 기능을 자세히 다루니 추천!
  • Experiment에서 만든 모델을 관리하는 것도 필요한데, 프러덕션에 어떤 모델이 올라갔고 어떤 성능을 보이고 있는지 알 수 있어야 하기 때문
    • 여러 실험의 결과로 Production 환경으로 감
  • Research에서 Model Management와 Production의 Model Management를 분리해서 MLflow 운영하면 좋음
  • 모델을 선택하는 예시는 Uber의 A Machine Learning Model Management System at Uber 참고

  • 도표
    • ML metadata, artifact repository
    • Repository라는 표현도 자주 사용됨. 저장소


Feature Store

  • 하나의 음식이 아닌 여러 음식을 준비하는 경우(부리또, 타코 등) 중복되는 요리 재료가 존재함
    • 음식을 요리할 때, 재료 손질부터 요리까지 A to Z 하는 것보다, 이미 손질되어 있는 재료를 활용해 요리에만 집중할 수 있음
    • 다양한 음식에서 중복해서 사용되는 경우엔 특히 더 효과를 볼 수 있음
    • 머신러닝으로 설명하면 점점 더 많은 모델이 개발되고, 그 모델에서 사용하는 Feature들이 중복되는 경우 => Feature Store를 구축할 수 있음
      • 이러면 요리할 때마다 재료 손질을 할 필요가 없고(전처리되어서 저장된 Feature Store를 사용하기 때문) 손질 시간을 단축할 수 있음

  • 집과 레스토랑에서 같은 재료(데이터)를 사용할 수 있도록 Research / Production 환경에서 같이 사용할 수 있는 Feature Store 구축하는 것도 매우 의미있음
    • 이를 위해선 실시간 데이터 파이프라인이 사전에 필요함
  • Feature를 재사용할 수 있게 됨
  • 방식
    • Batch 단위로(예 : 5분 단위) 쿼리를 실행해서 특정 DB Table에 저장하고, 그 Table을 사용하는 방식으로 구성할 수 있음
    • 오픈소스는 Feast, Hopsworks 등이 있고 아직 개발되고 있음
    • 클라우드는 SageMaker Feature Store, Vertex AI 등이 있음
  • 도표


Data Validation

  • 집에서 사용한 재료와 레스토랑에서 사용한 재료가 비슷해야 요리가 유사하게 나타날 수 있음
    • 머신러닝으로 설명하면 Research에서 학습한 데이터의 Feature 분포와 Production의 Feature 분포를 모니터링해서 얼마나 차이가 나는지 확인해야 함
  • 키워드 : Data drift, Model drift, Concept drift
  • Tensorflow Data Validation 등을 확인하면 학습한 당시의 Feature 분포를 저장해서 확인할 수 있음


Continuous Training

  • MLOps에선 CI/CD/CT 3가지를 고려함
  • 음식을 어느 시점에 다시 만들 것인가?에 대한 문제
    • 머신러닝 모델을 재학습하는 주기와 관련됨
  • 다시 학습하는 경우
    • 새로운 데이터가 들어온 경우
    • Metric이 떨어진 경우
    • 주기적으로(1주일마다)
    • 코드가 변경된 경우
    • 요청하는 경우(수동 프로세스)
  • Metric 기반 Deployment 예시(Uber)

  • 도표


GPU Infra Management

  • 집, 레스토랑의 요리 인프라를 주기적으로 관리해야 함
    • 필요한 경우, 많은 요리할 수 있는 구조 등
  • 로컬 GPU가 있는 경우엔, 이 환경과 Production 환경을 잘 유지시킬 필요가 있고, 리소스 분배도 필요함


Monitoring

  • Serving 환경에서 나오는 결과 데이터를 모두 저장하고, 모니터링해야 함
  • 인프라의 지표와 모델의 로그를 구분해서 관리해야 함
    • 인프라의 지표 모니터링은 Grafana 등을 사용
    • 모델의 예측 결과 등은 BI 오픈소스인 Superset, Redash, Metabase 등을 사용하거나 직접 웹을 구축하는 방법 등 다양함
  • 예측 값과 실제 값의 차이를 주기적으로 확인할 수 있고, 그 값을 통해 Alert를 보내주는 시스템이 필요함


AutoML

  • 에어프라이어처럼 재료만 넣으면 자동으로 음식을 만들 수도 있음
    • Research 관점에서 하이퍼파라미터를 자동으로 뽑아주거나, 네트워크의 구조도 뽑아줄 수 있음
  • 라이브러리


MLOps 파이프라인 예시

  • 머신러닝이냐 딥러닝이냐에 따라 생각을 다르게 해보는 과정도 필요함


MLOps Level

  • Level 1 : ML 파이프라인 자동화

  • Level 2 : CI/CD 파이프라인 자동화


MLOps 학습 컨텐츠


다양한 MLOps 오픈소스

BentoML

# iris_classifier.py
import pandas as pd
	
from bentoml import env, artifacts, api, BentoService
from bentoml.adapters import DataframeInput
from bentoml.frameworks.sklearn import SklearnModelArtifact
	
@env(infer_pip_packages=True)
@artifacts([SklearnModelArtifact('model')])
class IrisClassifier(BentoService):
  """
  A minimum prediction service exposing a Scikit-learn model
  """
	
  @api(input=DataframeInput(), batch=True)
  def predict(self, df: pd.DataFrame):
      """
      An inference API named `predict` with Dataframe input adapter, which codifies
      how HTTP requests or CSV files are converted to a pandas Dataframe object as the
      inference API function input
      """
      return self.artifacts.model.predict(df)  



# main.py
from sklearn import svm
from sklearn import datasets
	
# Load training data
iris = datasets.load_iris()
X, y = iris.data, iris.target
	
# Model Training
clf = svm.SVC(gamma='scale')
clf.fit(X, y)

# import the IrisClassifier class defined above
from iris_classifier import IrisClassifier
	
# Create a iris classifier service instance
iris_classifier_service = IrisClassifier()
	
# Pack the newly trained model artifact
iris_classifier_service.pack('model', clf)
	
# Save the prediction service to disk for model serving
saved_path = iris_classifier_service.save()

python3 main.py
  • 다음과 같은 파일이 자동으로 생성됨


PMML

  • sklearn2pmml Github
  • Storage 및 serialisation을 위한 기계학습 모델 파이프라인을 표현하는 방법
  • 여러 시스템이 이 방법으로 플랫폼간 모델 전송
from sklearn import datasets, tree
iris = datasets.load_iris()
clf = tree.DecisionTreeClassifier()
clf = clf.fit(iris.data, iris.target)

from sklearn_pandas import DataFrameMapper
default_mapper = DataFrameMapper(
    [(i, None) for i in iris.feature_names + ['Species']])

from sklearn2pmml import sklearn2pmml
sklearn2pmml(estimator=clf,
             mapper=default_mapper,
             pmml="D:/workspace/IrisClassificationTree.pmml")


DATA VERSION CONTROL(DVC)

  • link
  • 데이터 과학 프로젝트를 위한 버전 컨트롤 시스템
  • iterative.ai에 의해 빌드된 git fork는 데이터, config, 코드를 그룹화할 수 있음
# add your data
dvc add images.zip

# connect data input, model output and code
dvc run -d images.zip -o modl.p ./cnn.py

# add repository location (s3)
dvc remote add myrepo s3://mybucket

# push to the location specified
dvc push


ModelDB

  • Github
  • 함수 자체를 확장해 라이브러리 수준에서 input, output, config를 추적하는 암묵적인 방법
  • 사용된 모든 단계와 모델 결과, prediction을 저장
  • 저장된 모델을 사용 가능
def fit_and_predict(data):
    model.fit_sync(data)
    preprocessor.transform_sync(data)
    model.predict_sync(data)

PACHYDERM

  • Github
  • 재현 가능한 파이프라인 정의를 허용하는 End to End 모델 버전 관리 프레임워크
# create a repo
$ pachctl create-repo training
$ pachctl list-repo
NAME                CREATED             SIZE
training            2 minutes ago       0 B

# commit data (with -c flag) into the repo
$ pachctl put-file training master -c -f data/iris.csv

# Build
# pytrain.py

...import dependencies

cols = [ "Sepal_Length", "Sepal_Width", "Petal_Length", "Petal_Width", "Species" ]
features = [ "Sepal_Length", "Sepal_Width", "Petal_Length", "Petal_Width" ]

# Load training data
irisDF = pd.read_csv(os.path.join("/pfs/training", 
    "iris.csv"), names=cols)

svc = svm.SVC(kernel='linear', C=1.0).fit(
    irisDF[features], irisDF["Species"])

# Save model to pachyderm /pfs/out
joblib.dump(svc, os.path.join("/pfs/out", 'model.pkl'))

# dockerfile
FROM ubuntu:14.04

...install dependencies 

# Add our own code.
WORKDIR /code
ADD pytrain.py /code/pytrain.py

# computational pipeline 정의
{
  "pipeline": {
    "name": "model"
  },
  "transform": {
    "image": "pachyderm/iris-train:python-svm",
    "cmd": ["python3", "/code/pytrain.py",]
  },
  "input": {
    "atom": {
      "repo": "training",
      "glob": "/"
    }
  }
}


Orchestration을 위한 도구

Seldon-core


카일스쿨 유튜브 채널을 만들었습니다. 데이터 분석, 커리어에 대한 내용을 공유드릴 예정입니다.

PM을 위한 데이터 리터러시 강의를 만들었습니다. 문제 정의, 지표, 실험 설계, 문화 만들기, 로그 설계, 회고 등을 담은 강의입니다

이 글이 도움이 되셨거나 의견이 있으시면 댓글 남겨주셔요.

Buy me a coffeeBuy me a coffee



© 2017. by Seongyun Byeon

Powered by zzsza