머신러닝 오퍼레이션 자동화, 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


카일스쿨 유튜브 채널을 만들었습니다. 데이터 사이언스, 성장, 리더십, BigQuery 등을 이야기할 예정이니, 관심 있으시면 구독 부탁드립니다 :)

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

이 글이 도움이 되셨거나 다양한 의견이 있다면 댓글 부탁드립니다 :)

Buy me a coffeeBuy me a coffee



© 2017. by Seongyun Byeon

Powered by zzsza