삼성전자 빅데이터 센터에서는 고객에게 최고의 제품과 서비스를 제공하기 위해 다양한 데이터 분석 서비스를 개발하고 운영합니다. 초창기의 통계적 데이터 분석을 넘어 현재에는 다양한 데이터 분석 AI를 개발하며 적용하고 있습니다. 이러한 가운데, 다수의 AI 모델을 빠르게 개발하고 신뢰성 있게 유지해야 하는 요건에 직면하여 MLOps 도입을 적극 진행하고 있습니다. 여기서는 저희의 경험을 바탕으로 MLOps의 개념과 구축 방법을 간단한 예제 코드와 함께 설명해드리겠습니다.

MLOps(Machine Learning Operations)는 AI를 개발하고 배포하여 운영하는 일련의 과정을 효율적이고 신뢰성 있게 만드는 방법론(또는 패러다임)을 의미합니다. 간단히 말하자면 AI를 고객에게 서비스로 제공하기 위한 모든 과정을 체계화하고 자동화하는 것입니다. ‘MLOps가 굳이 필요할까?’라는 의문이 들 수 있습니다. 물론 MLOps를 적용하지 않더라도 AI를 만들어 고객에게 제공할 수 있습니다. 하지만 이렇게 만든 AI는 금방 도태될 가능성이 높습니다. 그 이유 중 하나는 AI 자체가 연역적인 방법론보다는 데이터 학습에 따른 귀납적인 방법론에 더 의존하기 때문입니다.   현대 사회에서는 대량의 데이터가 빠르게 생성되는 동시에 급격히 변화합니다. 이 같은 데이터 변화에 맞춰 AI 서비스를 정상적으로 유지하려면 AI를 지속적으로 개선하거나 새롭게 개발하여 빠르게 서비스에 배포해야 합니다. 이런 고민의 산물이 바로 MLOps입니다. 결국 MLOps는 AI를 개발해서 지속적으로 서비스하려는 조직에게 필수 불가결한 요소라고 볼 수 있습니다.

MLOps는 복잡하고 광범위한 개념입니다. AI 자체가 복잡한 측면도 있고 AI의 발전이 클라우드 같은 여러 가지 기술의 발전에 기대어 왔기 때문이기도 합니다. 그래서인지 MLOps를 구축하는 방법은 다양하고 관련 솔루션도 많습니다. 이처럼 다양하고 복잡한 AI 생태계에서 길을 잃지 않으려면 MLOps에 필수적인 요소를 우선 고려하는 것이 중요합니다. 여기에서는 MLOps에 필수적인 요소를 Training, Monitoring, Serving(Inferencing)으로 규정했습니다. 다음으로 각 요소를 설명해 드리겠습니다.

그림 1. MLOps 구성 요소 

MLOps에서 Training은 학습을 통해 AI 모델을 성장시키는 과정을 의미합니다. 완벽한 모델이란 없기 때문에 모델의 학습은 지속되어야 합니다. 이를 나타내는 용어가 Continuous Training(CT)입니다. Training Pipeline은 일반적으로 아래와 같은 요소로 이루어집니다.

그림 2. Training Pipeline

Training은 우선 데이터를 추출하는 Data extraction 과정을 수행합니다. 모델의 학습을 위한 데이터를 다양한 저장소에서 가져와 학습용 Dataset을 구성합니다. 이렇게 수집된 데이터는 Data validation을 거치게 됩니다. 이 과정에서 데이터의 Schema를 확인하고 데이터에 대한 기본적인 통계 분석을 수행합니다. 이를 바탕으로 모델의 학습에 적합하게 데이터의 형태를 변환(Transformation)하는 과정을 수행합니다. Category 데이터를 one hot encoding으로 변경하거나 Text Data를 tokenize하는 등의 데이터 전처리가 포함됩니다.

Model training은 Hyperparameter 튜닝을 비롯한 모델의 실질적인 학습 과정을 담고 있는 핵심 Component입니다. 모델은 주어진 데이터를 바탕으로 최적의 결과를 도출하는 방법을 학습하게 됩니다. 이렇게 학습이 완료된 모델은 Model registry에 저장되고 추후 Monitoring 또는 Serving 과정에서 활용됩니다. 

Model evaluation은 Test Data를 대상으로 한 Model의 평가 과정을 의미합니다. Accuracy, F1 score, MSE(Mean Squared Error) 등과 같은 모델 성능 평가 값(Evaluation metrics)이 결과 값으로 도출되며 Training 과정이 종료됩니다.

Training 과정에는 다양한 라이브러리와 컴퓨팅 리소스가 사용됩니다. 상황에 따라 XGBoost 나 Light GBM과 같은 Machine Learning 라이브러리가 필요할 수도 있고 TensorFlow 나 PyTorch와 같은 DNN(Deep Neural Network)   프레임워크가 필요할 수도 있습니다. 또한 다수의 GPU나 고용량 메모리가 필요할 수 있습니다. Kubernetes 기반으로 만든 Kubeflow는 확장성과 범용성 측면에서 이런 요구 사항을 해결하는데 적합한 솔루션 중 하나입니다. Training 과정을 통해 생성된 모델은 서비스에 사용될 때도 학습된 과정과 최대한 동일하게 서비스되어야 합니다. 그렇지 않으면 사용자가 실제로 사용하는 모델의 성능이 Training 때와는 많이 달라집니다. 따라서 학습에 사용하는 코드가 Serving에서도 재사용 가능하게 작성되어야 하며, 버전 관리도 필수적으로 이뤄져야 합니다. 코드가 동작하는 환경 역시 컨테이너화하여 학습과 동일한 환경이 되도록 해야 합니다. 이 부분은 DevOps와 거의 유사하다고 볼 수 있습니다.  

MLOps에서는 코드와 환경에 더해, Artifact라는 요소를 추가로 고려해야 합니다. Artifact는 Pipeline의 각 Component가 생성한 결과물을 의미합니다. 학습에 사용하기 위한 Dataset, 학습된 모델, 모델의 Evaluation metrics 등이 여기에 포함됩니다. MLOps에서 Dataset은 어떤 과정을 거쳐서 만들어졌으며 어떤 모델의 학습에 사용되었는지 등의 메타데이터를 함께 포함해야 합니다. 이는 다른 Artifact 역시 마찬가지입니다. 결국 Artifact는 단순한 저장을 넘어 모델의 유지/개선을 위한 추적 관리 대상이 됩니다. ML Metadata(MLMD)나 MLflow와 같은 프로그램은 이 기능을 제공하도록 개발되었습니다.

Monitoring은 모델의 성능을 유지하고 발전시키기 위해 꼭 필요한 과정입니다. Training과 유사하지만 Training 과정에서 생성된 artifact와 비교 분석을 해야 한다는 점에서 차이가 있습니다. 다음은 Monitoring Pipeline을 나타낸 그림입니다.

그림 3. Monitoring Pipeline

Data validation은 학습에 사용한 데이터와 현재 데이터 간에 차이가 있는지를 확인하는 과정입니다. 데이터 타입 등의 스키마뿐만 아니라 학습 시점에 사용한 데이터에서 drift가 발생하지 않았는지도 확인해야 합니다. Data Drift는 모델의 성능 저하를 야기할 정도로 데이터 분포가 크게 변화하는 것을 의미합니다. Kullback–Leibler divergence나 Jensen-Shannon divergence와 같은 통계적인 방법으로 이를 탐지할 수 있습니다.1) 이 기능은 자체적으로 개발해서 활용할 수도 있지만 Tensorflow Data Validation이나 Great Expectations, Evidently 같은 라이브러리를 활용하는 것도 좋습니다. 이런 라이브러리는 데이터를 비교 분석하고 간단한 보고서를 자동으로 만들어주기 때문에 Monitoring에 유용합니다.

Monitoring에서 Model evaluation은 학습 시점 대비 어느 정도로 모델의 성능이 저하되었는지를 파악하는 과정입니다. 성능을 결정하는 요소로는 정확도도 있겠지만 추론 속도, 사용 자원량과 같은 항목도 있습니다. MLflow에서 제공하는 Tracking은 모델의 성능뿐만 아니라 다양한 요소에 대한 Tracking을 지원합니다. 이를 통해 모델의 성능이 지속적으로 유지되고 있는지를 추적해서 관리할 수 있습니다.

학습된 모델을 실서비스에 적용하는 방법은 상황에 따라 다를 수 있습니다. 모델을 Batch processing의 일부로 배포하여 특정 주기에 따라 지속적으로 동작하게 할 수도 있고, 서버에 배포하여 사용자의 요청에 따라 실시간으로 응답하게 할 수도 있습니다. AI 모델의 Serving은 대개 후자에 해당됩니다. 후자의 경우 Training과 달리 소량의 데이터를 빈번하게 동시 처리한다는 점을 추가로 고려해야 합니다. 또한 Training과 동일한 코드와 환경으로 Serving을 구축해야 하는 점도 놓치지 않아야 합니다. 아래는 Serving의 프로세스를 간단히 도식화한 그림입니다.

그림 4. Serving Pipeline

Data validation과 transformation에서는 앞서 Training에 사용된 component를 재사용합니다. Inferencing은 메모리에 올려져 있는 학습된 모델을 사용해 결과를 추론하는 과정입니다. 사용자에게 전달되는 Output은 단순히 모델의 예측치 혹은 생성 데이터(Generative AI의 경우)일 수도 있지만 모델이 왜 그런 결과를 도출했는지에 대한 설명도 포함될 수 있습니다.

AI와 사용자의 접점이기 때문에 Serving 영역은 좀더 신경 써야 하는 부분이기도 합니다. Serving을 지원하기 위한 다양한 상용 혹은 오픈소스 솔루션이 존재합니다. Seldon Core나 KServe가 대표적인 플랫폼입니다.

지금까지 MLOps의 필수적인 요소를 살펴봤습니다. 이제 저희가 MLOps 인프라를 어떻게 구축했는지를 설명드리려고 합니다. 아래 그림은 클라우드 환경에서 Kubeflow Pipelines(KFP)와 MLflow를 활용해 MLOps를 구축한 사례를 간단히 도식화한 것입니다.

그림 5. MLOps 환경 구축 사례

기본적으로 KFP는 Kubernetes 클러스터에 설치합니다. MLflow는 동일한 k8s 클러스터에 설치하거나 별도의 인스턴스에 설치할 수 있습니다. 주로 관리용 데이터를 저장하는 Metadata store는 MySQL과 같은 전통적인 RDB를 활용합니다. 모델과 같은 파일을 저장하는 Artifact store로는 object storage(AWS S3나 GCP의 GCS 혹은 MinIo)를 사용합니다. 이렇게 저장소로 사용하는 Metadata store와 Artifact store는 되도록 별도의 클러스터나 인스턴스에 설치하는 것이 추후 KFP나 MLflow의 버전 업그레이드를 위해 좋습니다. 

다음으로, 설치된 KFP와 MLflow가 실질적으로 MLOps에서 각각 어떤 역할을 수행하는지를 간단한 예제 코드와 함께 설명해드리겠습니다.

Kubeflow는 Kubernetes를 기반으로 하는 AI 플랫폼으로, Dashboard, Pipelines, Notebooks, KServe 등 다양한 AI 개발 관련 툴을 제공합니다. 저희는 이 중 Kubeflow Pipelines(KFP)만을 사용했습니다. Kubeflow의 다른 툴은 MLOps에 필수적이지 않거나 아직 Alpha  버전이라서 이번 MLOps 구축에서 활용하지 않았습니다. KFP는 Kubernetes 환경에서 Pipeline(Workflow)을 작동시키고 관리하는 플랫폼입니다. 앞서 설명한 Training과 Monitoring pipeline을 KFP를 통해 개발하고 원하는 주기 혹은 시점에 실행할 수 있습니다.

KFP는 Kubernetes가 구축된 환경에서 쉽게 설치할 수 있습니다. 또한 AWS, GCP와 같은 다양한 클라우드 환경에서 동작합니다. KFP에서 제공하는 Python SDK를 통해 개발자가 직접 Pipeline을 개발할 수 있습니다. 다음은 Iris dataset에 대한 분류 모델을 학습시키는 Component를 KFP SDK를 활용해 개발한 예시입니다.

그림 6. 학습 Component 작성 사례

코드 상단에는 Python 3.11을 container 이미지로 정의한 것을 볼 수 있습니다. Component는 기본적으로 container 단위로 동작하기 때문에 Component 단위로 다양한 라이브러리를 자유롭게 사용할 수 있습니다. 이를 통해 복잡한 라이브러리 의존성을 최소화할 수 있습니다. 마찬가지로 CPU, GPU와 같은 컴퓨팅 리소스도 Component 단위로 할당할 수 있습니다. 다음은 이렇게 작성된 Component를 묶어서 Pipeline을 작성한 예시입니다.

그림 7. Pipeline 작성 사례

load_data는 데이터를 추출한 후 학습에 사용할 Dataset을 Artifact로 저장하는 Component입니다. 바로 아랫줄의 train은 이렇게 저장된 Artifact를 활용해 모델을 학습시키는 Component입니다. 이런 component가 모여서 pipeline을 구성하게 됩니다. 이렇게 만든 Pipeline은 Kubernetes의 CRD(Custom Resource Definitions)   형태로 컴파일해서 yaml 파일로 저장합니다(KFP python SDK를 사용해 컴파일 가능). 이 파일을 KFP 서버에 제출해서 다음과 같이 웹 UI를 통해 Pipeline 단위로 관리하고 실행할 수 있습니다.

그림 8. Kubeflow Pipelines(KFP)에 제출되어 실행된 pipeline

Pipeline은 일회성으로 실행되거나 특정 시간에 맞춰 주기적으로 실행되게 할 수 있습니다. 이를 통해 앞서 설명한 Training과 Monitoring Pipeline을 운영할 수 있습니다.

MLflow는 Machine Learning Lifecycle 관리에 초점을 맞춘 플랫폼입니다. 모델을 관리하거나 Artifact를 시각화하고 비교하는 측면에서 장점이 있습니다. 대신 MLflow에는 KFP와 같이 workflow를 실질적으로 동작시키고 관리하는 기능은 없습니다. 앞서 언급한 대로 MLflow는 Model Registry와 ML에 대한 tracking을 담당합니다. 다음은 KFP의 Component 안에서 MLflow를 연동해 artifact를 기록하고 모델을 저장하는 부분을 작성한 예시입니다.

그림 9. MLflow 연동 코드

이처럼 비교적 간단한 코드로 모델의 성능에 대한 metrics를 로깅하고 모델을 Registry에 등록할 수 있습니다. 모델이 Registry에 등록될 때 모델에 필요한 의존성 라이브러리와 컨테이너 이미지 정보까지 함께 자동으로 저장됩니다. 이를 통해 모델을 실서비스에 배포할 때 환경 차이로 발생하는 문제를 미연에 방지할 수 있습니다. 위와 같이 작성된 코드를 통해 간단히 다음과 같은 성능 비교가 가능합니다.

 그림 10. 모델의 버전별 train loss 비교

Epoch별로 train loss가 수렴하는 과정을 모델의 서로 다른 버전 간에 비교한 모습입니다. MLflow는 이와 같이 artifact를 저장하고 시각화해서 모델의 관리를 용이하게 해줍니다. 따라서 지속적으로 개발된 모델을 쉽게 모니터링할 수 있습니다.

지금까지 MLOps의 개념과 MLOps에 필수적인 요소인 Training, Monitoring, Serving에 대해 간단히 설명하고 Kubeflow Pipelines(KFP)와 MLflow를 통한 MLOps 시스템 구축을 살펴봤습니다. 그런데 여기서 언급하지 않은 MLOps 관련 요소와 솔루션도 많습니다. Feature store에서 Model mesh에 이르는 다양한 개념과 툴이 존재합니다. 추후에 이런 내용에 대해 설명드릴 기회가 있으면 좋을 것 같습니다.

AI는 지속적으로 발전하고 있으며 AI 자체의 개발은 대단히 중요합니다. 하지만 개발된 AI를 어떻게 “지속적으로 학습시키고 배포해서 운영할지”에 대한 심도 깊은 고려 없이 성급하게 사용자에게 서비스할 경우 금세 문제에 직면할 가능성이 높습니다. 결국 이런 문제들은 거대한 기술 부채(Technical Debt)가 되어 서비스 자체를 어렵게 만들 뿐만 아니라 깊이 있는 발전을 가로막습니다. 궁극적으로 MLOps는 기술 부채를 없애려는 노력의 산물이자 AI를 지탱하는 기술이라 할 수 있습니다. 아무쪼록 이 글이 MLOps를 구축하는 분들에게 일말의 도움이 되었기를 기대합니다. 부족한 글을 끝까지 읽어주셔서 감사드립니다.