MLOps를 시작하는 5가지 방법

Published in

베슬에이아이 <VESSL AI>

15 min readApr 18, 2022

What’s MLOps?

MLOps는 “Machine Learning Operations”의 약자로, 지속가능한 머신러닝 개발과 운영을 아우르는 시스템과 프로세스를 의미합니다. 데이터 적재부터 모델 배포 · 모니터링까지, MLOps가 다루는 영역은 매우 넓습니다. 따라서, 소개하는 각자마다 서로 다른 범위와 내용으로 MLOps를 설명하곤 하는데, MLOps는 크게 세 개의 관점에서 정의할 수 있습니다.

MLOps의 시작

MLOps는 구글에서 2015년에 발표한 논문 “Hidden Technical Debt in Machine Learning System”에서 처음 다루어졌습니다. 이 논문에서 저자는 머신러닝 모델을 개발하는 일 외, 이를 지속해서 개발하고 운영할 수 있는 시스템을 설계하는 일을 강조하고 있습니다. 다음 그림에서 볼 수 있듯, 전체 머신러닝 시스템 중 ‘모델 코드’를 작성하는 일은 극히 일부분이며, 데이터부터 자원관리, 배포, 모니터링 등 다른 요소들이 더욱 신중하게 고려되어야 한다는 내용입니다.

“Hidden Technical Debt in Machine Learning System”, Google, NeurIPS 2015

ML + DevOps

MLOps를 ML + DevOps의 개념으로 정의하기도 합니다. 이는 개념적으로도 모델 개발 이후 CI/CD, 즉 지속적인 배포 및 운영이라는 측면에서, 그리고 기술적으로 머신러닝과 데브옵스의 기술을 결합한다는 점에서 적합한 설명입니다. 주로 다음과 같은 그림을 통해 설명됩니다.

그림에서 볼 수 있듯이, 개발과 운영에 필요한 워크플로우를 자동화하여 (1) 머신러닝 모델을 개발 및 배포하고, (2) 배포한 모델을 모니터링한 후, (3) 새롭게 수집한 데이터를 이용해 다시 모델을 업데이트하는 사이클을 만드는 것을 목표로 합니다.

DataOps + Model Ops

머신러닝 라이프사이클을 단계 별로 세분화하여, 데이터에 관련된 부분을 DataOps, 모델에 관련된 부분을 ModelOps라고도 합니다.

Why MLOps?

MLOps의 정의는 광범위하기 때문에, MLOps를 도입함으로써 기대하는 효과도 매우 다양합니다. 그동안 제가 현업에서 머신러닝 개발을 하면서 부딪혔던 문제들을 단순히 나열해봐도 다음과 같은 문제들이 있습니다.

새로운 데이터가 추가되었을 때, 데이터셋의 분포가 어떻게 달라졌을까?
데이터를 라벨링 한 후에 해당 데이터가 제대로 추가되었는지 어떻게 확인할 수 있을까?
로컬에서 학습한 모델을 온프레미스 클러스터나 클라우드에 옮겨서 빠르게 스케일업할 수 없을까?
로컬의 GPU 머신을 여러 명이 나눠 써야 하는데 어떻게 관리할 수 있을까?
1년 전에 만들어놓은 모델을 다시 재현하기 위해서는 어떻게 해야 하지?
모델을 배포한 후에 모델의 성능은 어떻게 모니터링할까?
깃업에 커밋이 되거나 데이터가 추가될 때 마다 자동으로 모델이 학습되는 CI 파이프라인을 구성할 수 없을까?
새로운 SOTA 모델이 공개되었는데, 나의 데이터를 사용해 해당 모델을 빠르게 재현해 보려면 어떻게 해야 할까?

대다수의 머신러닝 엔지니어들이 모델을 개발, 배포, 운영하는 과정에서 하루에도 몇번씩 이와 같은 문제들에 부딪히게 됩니다. MLOps는 머신러닝 라이프사이클의 각 단계별로 이를 해결할 수 있는 방법들을 제시합니다. ML-Ops.org에서 사례별로 해결할 수 있는 방법들을 정리해놓았으니, 더 구체적으로 확인하고 싶은 분들은 참고해 보시기 바랍니다.

5 steps to start MLOps

흔히 MLOps라 하면, 데이터 취합부터 모델 학습 및 배포를 자동화 하는 파이프라인을 떠올리는 경우가 많습니다. 하지만 이와 같은 end-to-end 파이프라인을 구성하기 위해서는 먼저 데이터, 실험, 모델 등에 대한 정보를 정확하게 기록하는 것이 우선입니다. 만약 MLOps 도입을 고민하고 있다면 다음의 순서로 시작해 보는 것을 추천합니다.

1. Experiment Tracking

대부분의 머신러닝 개발자분들은, Tensorboard나 Weights & Biases를 사용하여 머신러닝 실험(학습)을 기록하고 비교 · 분석해보신 경험이 있을 것입니다. MLOps의 시작은 머신러닝 실험과 하이퍼파라미터 및 모델링 과정을 정확하게 기록하는 것에서 출발합니다. 이때 다음을 주의하여 실험을 기록하는 것이 좋습니다.

하이퍼파라미터뿐만 아니라 개발환경, 커맨드, 로그, 메트릭 등 실험과 관련된 모든 정보를 기록합니다.
기록된 정보로 모델을 정확히 재현할 수 있는지 확인합니다. 특히, 데이터셋이 수시로 바뀌는 경우, 실험을 실행할 때마다 데이터셋의 버전을 기록하지 않으면 모델이 재현되지 않을 수 있습니다.
기록된 정보를 쉽게 찾아볼 수 있도록 중앙화된 저장소에 구조화하여 저장합니다. 시간이 지나도 해당 정보를 쉽게 찾아볼 수 있도록 엑셀이나 로컬환경에 저장하지 않고, 팀원과 상시 공유되는 중앙화된 저장소에 저장하는 것이 좋습니다.

VESSL Experiments을 비롯해 Tensorboard, MLflow, Weights & Biases, Neptune.ai 등을 사용하여 시작할 수 있습니다.

2. Model Registry

실험을 기록한 이후에는 여러 학습을 통해 만들어진 모델을 중화된 저장소에 저장합니다. 이때 파라미터, 체크포인트 등 학습된 모델의 결과물, evaluation metric 등 모델의 성능을 나타내는 지표, 그리고 모델이 만들어지는 과정을 모두 저장하면 모델을 비교하고 분석할 때 용이하게 사용할 수 있습니다.

이처럼 모델과 모델의 ‘artifact’를 저장하는 저장소를 모델 레지스트리라고 하며 이곳에 저장된 모델을 이후 API를 통한 배포 및 서빙(serving)이나 재학습, fine-tuning을 통한 최적화를 할 때 활용할 수 있습니다.

모델 레지스트리를 사용할 때는 다음을 주의해야 합니다.

모델 파일 뿐만 아니라, 서빙 또는 fine-tuning 할 때 필요한 데이터 전처리 관련 통계 및 설정 값 또한 저장해야 합니다.
이후에 쉽게 찾아볼 수 있도록 중앙화된 저장소에 구조화하여 저장합니다.
지속적인 모델 업데이트를 위해 파이프라인과 연계하여 사용하는 것이 좋습니다.

VESSL Model Registry와 MLflow, Amazon Sagemaker를 이용해 구축할 수 있습니다.

3. Job Orchestration

모델을 중앙화된 저장소에 잘 저장하였다면 다음 단계는 모델 학습을 포함한 다양한 형태의 작업을 하나의 ‘job’ 형태로 구성하여 실행하는 것입니다. 로컬 환경의 주피터 노트북을 하나의 실행 가능한 job으로 정의해야 하므로 job orchestration은 처음 MLOps를 시작하는 엔지니어가 가장 어려워하는 부분 중 하나입니다. 별도의 MLOps 툴을 사용하지 않는다면 모델을 컨테이너화하는 과정에서 도커나 쿠버네티스를 익혀야 하기도 합니다.

먼저 모델의 학습이 진행되는 환경(Docker image), 컴퓨팅 리소스 스펙, 파라미터, 커맨드 등을 다음과 같이 명시하고, 이를 ‘scale out’ 하여 실행하거나 자동화된 CI/CD, testing에서 활용합니다.

Job scheduling의 경우 도커, 쿠버네티스에 대한 이해가 필요하며 가장 많은 시간을 필요로 합니다. 동작하는 job을 구성하기 위해 반복적으로 job을 재정의 하는 업을 진행하기도 합니다. Job을 정의한 후에는 쿠버네티스 등의 orchestration 툴을 이용하여 job을 실행합니다. 이 과정에서 다음과 같은 팁이 유용할 수 있습니다.

머신러닝 프로젝트에서 필요한 라이브러리와 환경을 개발 단계에서 requirements.txt 등을 작성하여 미리 저장하고, 이후 job을 만들 수 있도록 준비합니다. 필요할 경우 도커 이미지를 직접 어서 활용할 수도 있습니다.
클라우드 환경이나 온프레미스 서버에서 job을 실행할 경우 데이셋 마운트 및 다운로드가 필요할 수 있습니다. 이를 위해 사전에 cloud NFS storage 구축, NAS storage 사용 등 인프라단에서 준비가 필요할 수 있습니다. 또한, 네트워크 퍼포먼스가 병목이 되는 경우가 종종 있으니 네트워크 망이 지원하는 최대 throughput 등을 확인합니다.
데이터와 모델을 중앙화된 저장소에 정리하고 필요할 경우 마운트 하여 사용할 수 있도록 저장소를 구축합니다.
Job에서 생하는 로그나 상태 등을 experiment tracking과 연계하여 모니터링 하거나 클러스터 모니터링 툴을 구축하여 job의 실행 정볼르 파악해야 합니다.
Job을 정의하고 난 후에는 스크립트를 작성해서 수십, 수백 개의 학습을 자동화 하거나, GitHub Hook 등과 연계하여 기초적인 CI/CD 파이프라인 생성이 가능합니다.

VESSL Managed Experiments와 vessl run을 이용하거나 KubeFlow TFJob, MLflow Project를 이용해 시작할 수 있습니다.

4. Model Serving

이후에는 모델을 라이브 상태의 API 서비스로 배포하거나 패키징하여 배포할 수 있습니다. 직접 인퍼런스 코드를 구현할 수도 있으나, BentoML과 같은 머신러닝 프레임워크를 사용하면 코드 몇줄만으로 간편하게 API 서비스화하거나 웹 애플리케이션 형태로 제작할 수 있습니다.

BentoML은 TensorFlow, PyTorch 등으로 만들어진 모델을 쉽게 API 서비스화할 수 있는 머신러닝 서빙 라이브러리입니다. 다음처럼 [bentoml.sklearn.save](<http://bentoml.sklearn.save>) 와 같은 형태로 모델을 저장하고, bentoml.Service 와 같은 형태로 모델 ‘service’를 정의합니다.

import bentomlfrom sklearn import svm
from sklearn import datasets# Load predefined training set to build an example model
iris = datasets.load_iris()
X, y = iris.data, iris.target# Model training
clf = svm.SVC(gamma='scale')
clf.fit(X, y)# Call to bentoml.<FRAMEWORK>.save(<MODEL_NAME>, model)
# In order to save to BentoML's standard format in a model store
bentoml.sklearn.save("iris_clf", clf)

모델을 서빙할 땐 다음 사항을 고민해보면 좋습니다.

모니터링할 지표를 사전에 정의하여 배포 후 수집할 수 있도록 구현합니다.
머신러닝 모델의 성능은 데이터 변동 등에 따라 필연적으로 떨어지므로 주기적인 업데이트가 필요합니다.
Inference 전후로 필요한 작업(data processing, prediction mapping 등)을 Serving API에서 수행할지, 혹은 backend code 단에서 수행할지 정의해야 합니다. 나아가 상황에 따라 각 작업을 수행하는 microservice를 구현해야할 수도 있습니다.

모델 서빙은 VESSL Model Serving과 BentoML, Streamlit, Amazon Sagemaker에서 이용할 수 있습니다.

5. CI/CD Pipeline

파이프라인은 앞서 다룬 job orchestration, serving 등을 포함한 개발 및 배포 과정을 하나의 파이프라인 형태로 구축하는 것을 말합니다. 인프라 설계부터 모든 과정이 자동화 되어야 하기 때문에, training, serving, monitoring 등 각각의 과정이 자동화된 후 시작하는 것이 좋습니다.

VESSL Pipeline, KubeFlow Pipeline, AirFlow, Kedro를 이용해 구축할 수 있습니다.

Other components

Model Monitoring — 모델을 배포한 후 모델의 성능과 인퍼런스 결과 등을 모니터링 하는 작업입니다. (Neptune AI, Evidently AI)
Dataset Versioning — 데이터가 지속해서 업데이트 되는 환경에서 각 파일을 git 처럼 시점에 따라 저장하고 복원할 수 있도록 버전관리 합니다. (Git LFS, DVC, VESSL Dataset)
Hyperparameter Optimization — AutoML의 일종으로, 머신러닝 모델에서 필요한 하이퍼파라미터를 자동으로 찾아주는 기술입니다. 데이터와 코드를 유지한채 더욱 정교한 모델을 찾고 싶을때 활용할 수 있습니다. (VESSL Sweep, Weights & Biases Sweep, Katib, Ray Tune)

VESSL — 실험관리부터 모델 서빙까지 한곳에서 빠르게

End-to-end MLOps를 위해 여러 개발툴을 익히고 자체적인 플랫폼을 구축하는 것은 많은 시간과 비용이 필요합니다. VESSL을 사용하면 하나의 플랫폼에서 가장 쉽게 MLOps의 각 기능을 사용하면서, 머신러닝 모델 개발 그 자체에만 집중할 수 있습니다. AWS, GCP, on-premise 등 여러 환경에서 동일하게 사용 가능하며 MLOps 도입 시 주의가 필요한 요소를 VESSL이 모두 해결해 줍니다.

Experiment Tracking

Tensorboard, Weights & Biases와 같이 실험을 기록, 관리할 수 있는 대시보드를 제공합니다.

Dataset & Model Registry

AWS, GCP, 로컬 환경 등에 저장된 데이터를 등록하고 데이터셋의 간단한 통계를 제공하며 버전과 권한 등을 관리할 수 있습니다. 또한, 개발된 모델을 저장하고, 각 모델이 만들어진 과정과 결과를 비교하고 조회할 수 있습니다.

ML Job Orchestration

로컬에서 진행한 작업을 vessl run 커맨드 하나로 클라우드나 온프레미스 환경에서 실행할 수 있습니다. 도커나 쿠버네티스 이해 없이 수십-수백개의 학습을 순차적으로 혹은 온디맨드로 scale-out하여 실행합니다.

Cluster Management

AWS, GCP, 온프레미스 클러스터를 등록하고, 각 클러스터의 상태와 GPU 사용 현황 등을 모니터링할 수 있습니다.

Model Serving & Pipeline

레지스트리에 저장된 모델을 API 서비스 형태로 배포할 수 있습니다. 또한, VESSL의 Python SDK나 Airflow 등을 활용하여 CI/CD 파이프라인을 구축할 수 있습니다.

Advanced Features

Dataset Versioning — 데이터셋의 파일들을 버전관리할 수 있는 Git-LFS 와 같은 스토리지를 제공합니다.
Hyperparameter Optimization — VESSL Sweep을 용하여 코드 변경 없이 모델을 최적화할 수 있습니다.
Hybrid Clusters — 온프레미스, 클라우드 클러스터를 자유자재로 등록하고 필요할때마다 클러스터를 변경해가면서 사용할 수 있습니다. 예로, 평소에는 보유하고 있는 온프레미스 머신을 활용하다 리소스가 부족한 경우 필요한 만큼만의 AWS, GCP 인스턴스를 활용할 수 있습니다. 프로젝트 중 GCP의 TPU가 필요하거나 한 경우 별도의 설정 없이 클릭 한번만으로 TPU 활용이 가능합니다.

마치며

지금까지 MLOps에 대한 정의와, 가장 쉽게 시작하는 5가지 방법에 대해 알아보았습니다. MLOps를 처음 시작하시는 분들께 조금이나마 이정표가 될 수 있었으면 좋겠습니다. 각 단계에 대한 더 자세한 내용은 이후 글에서 다시 한번 다루겠습니다. 다음과 같은 고민이 있다면, VESSL에 연락을 주시거나 도입을 검토해보세요!

공개되어 있는 유명한 모델을 쉽게 재현해 보고 싶은 경우
가장 저렴하고 효율적으로 GPU 머신을 활용하고 싶다.
물리 서버, 클라우드 등 GPU 서버들의 상태를 실시간으로 모니터링하고 사용 현황을 조회하고 싶다.
머신러닝 프로젝트 가시성을 확보하고 협업을 통해 모델을 더 효과으로 개발하고 싶은 경우
여러 종류의 프로젝트가 진행되고 있거나, 지속적으로 모델 개발이 필요한 경우
어떤 과정을 통해 모델이 개발되었는지 트래킹하고, 어떤 머신러닝 모델을 배포해야 할지 관리하고 싶은 경우