DEVOCEAN

출처 : MLOps정의와 다양한 도구들-1

안녕하세요? 래블업 DevRel 유우영입니다.

저희 래블업에서 운영하는 블로그에 Backend.AI(백엔드닷에이아이) 및 회사 관련한 다양한 정보를 포스팅하고 있는데요, 그 중 기계학습의 라이프 사이클을 관리하는 기술인 MLOps 관련 연재중 첫 번째 글을 공유합니다.. 

MLOps란

기계 학습 및 딥 러닝 분야가 IT의 큰 기술 트렌드가 되면서 다양한 연구가 진행되고 확산되고 있습니다. 좋은 연구 성과들이 빛을 내면서 이제는 연구 성과를 사람들의 실생활에 적용하기 위한 많은 노력들이 진행 중입니다. The OverFlow에 따르면 기계 학습 프로젝트 87% 가[^1], Redapt에 따르면 90%의 기계학습 프로젝트가 최종 서비스까지 완성되지 않는다고 합니다.[^2] 기계학습 개발과 서비스로 이어지는 흐름은 우선 데이터 사이언티스트가 데이터를 분석해서 나온 특징이나 모델의 결과를 서비스 제품에 올려, 온라인 예측이나 배치 예측을 가동하는 식으로 이어집니다. 이를 위해 데이터 분석 외에도 재현성, 출시된 모델 버전 관리, 데이터 버전 관리, 데이터 및 학습/예측 코드 및 모델 버전 구성 관리, 데이터 드리프트 모니터링 등, 모델 성과를 계속해서 고객에게 전달하기 위한 대응이 필요합니다.

MLOps는 Machine Learning Operations의 약자로, 데이터 전처리, 모델 개발, 배포, 운영 등을 포함한 기계 학습의 라이프 사이클을 관리하는 기술 및 도구를 말합니다. 기존 소프트웨어 개발 방법인 “DevOps” 개념에 “데이터”와 “훈련 모델”이 추가되었고, 전체를 아우르는 기계 학습의 라이프 사이클 관리가 더해집니다. MLOps의 기본 도구에는 DevOps의 CI(continuous integration)/CD(continuous delivery)에 CT(Continuous Training)가 추가되었습니다.

DevOps와 MLOps

• MLOps와 DevOps의 차이

  CI (Continuous Integration)는 코드 및 구성 요소 테스트에 더하여 데이터 형식 및 모델 테스트 및 검증이 중요한 요소입니다. CD (Continuous Delivery)는 단일 소프트웨어 패키지 및 서비스 배포뿐만 아니라 ML 훈련 파이프라인을 포함합니다. CT(Continuous Training)는 ML 시스템 특유의 새로운 항목입니다. 모델을 자동으로 재훈련하고(시스템에 배포함으로써) 추론 서비스를 제공하는 것을 목적으로 합니다. CE (Continuous Evaluation; 지속적인 평가)는 실행 중인 추론 모델의 정확성을 실시간으로 모니터링하는 메커니즘입니다. CE를 통해 기계 학습 시스템의 품질 저하를 감지할 수 있습니다. 이러한 품질 저하는 서비스 환경의 역학 변화로 인해 종종 발생합니다.

• MLOps가 없는 세계

  데이터 관리: 모든 데이터는 사내 서버에 저장되며 분석에 사용되는 데이터는 한 번 하드 디스크로 옮겨 개발 팀에 전달됩니다. 모든 데이터는 클라우드에 저장되며 분석 중에 필요한 하위 집합을 SQL로 검색합니다.

  하이퍼 파라미터 튜닝: 하이퍼 파라미터나 데이터의 조합을 수동으로 재기록하면서, ML 모델을 훈련 평가합니다. 실험 관리 도구를 사용하여 모델을 개발합니다. 하이퍼 파라미터 검색에는 수리 최적화가 사용됩니다.

  ML 프로세스 분석: 연구자는 매개 변수를 변경할 때마다 jupyter notebook에 설명된 전처리, 학습 및 평가의 일련의 ML 테스트를 순차적으로 수행합니다. ML 프로세스는 통합되고 자동화되어 학습 및 테스트 반복이 빠르게 수행됩니다.

  배포용 추론 모델을 구현: 훈련에 사용되는 노트북과 requirements.txt를 구현 담당자에게 전달하고 구현 담당자는 추론 코드를 추출한 후 Flask 등을 사용하여 추론 웹 API 서버를 구성합니다. 추론 웹 API 서버에 대한 배포는 CI / CD 도구를 통해 자동화되며 GCP의 AI Platform prediction을 사용하여 추론 엔드 포인트를 생성하기 때문에 모델러는 기계 학습 모델을 만드는 데 집중할 수 있습니다. 지속적인 훈련 모델 개발에는 월 단위의 시간이 걸리므로 모델을 재교육하는 경우는 거의 없습니다. 항상 발생하는 환경 변화에 대응하기 위해 정기적으로 최신 데이터를 사용하여 재 훈련을 수행합니다.

  CI / CD 모델의 업데이트는 거의 없으므로 CI 및 CD는 고려하지 않습니다. 새로운 데이터로 훈련된 모델은 자동으로 정밀도 검증, 테스트 및 배포 대상이 됩니다. 감시 모델의 성능 저하 등을 검출하기 위한 모니터링은 실시하지 않기 때문에 환경의 역학 변화에 취약합니다. 라이브 데이터를 기반으로 모델 성능에 대한 통계 정보를 수집합니다. 성능이 일정 수준을 충족하지 못하면 재훈련 파이프라인이 자동으로 실행됩니다.

ML 파이프라인

MLOps는 데이터 및 모델을 중심으로 다양한 기능을 하는 ML 파이프라인(ML pipeline) 을 구성합니다. ML 파이프라인은 7단계로 구성할 수 있습니다.

1. Data ingestion
2. Data validation
3. Data processing
4. Model training
5. Model validation and tuning
6. Model deploy
7. Monitoring performance and capturing new data

ML 파이프라인은 다양한 장점을 제공합니다. 기존 모델의 유지 보수와 함께 새로운 모델 개발이 연속적으로 이루어지기 때문에 ML 서비스에서 사용 중인 모델의 성능을 추적하여 서비스 결과를 버전 별로 알 수 있으며, 이를 데이터 과학자, 개발자, 서비스 운영진에 자동으로 공유할 수 있습니다. ML 파이프라인을 구성하는 구성 요소는 컨테이너 기술을 사용하여 개발 환경에서 서비스 운용 환경까지 쉽게 재현하고 서비스를 확장할 수 있습니다.

기계학습 워크 플로우와 MLOps

Google은 기계 학습 프로젝트의 워크플로우의 단계를 자동화된 도구의 수준으로 규정하였습니다.

1. MLOps level 0: Manual process 자동화를 포함하지 않음
2. MLOps level 1: ML pipeline automation ML 파이프라인 자동화
3. MLOps level 2: CI/CD pipeline automation ML 파이프라인 및 CI/CD/CT 파이프라인 자동화

기계학습 워크플로우를 따라서 각 태스크가 잘 실행되면 좋겠지만, 그렇지 않은 것들도 있겠지요.

예를 들면 다음과 같은 것들입니다.

i) 훈련에 사용할 연산 리소스가 부족하여 더 이상 학습이나 실험을 진행할 수 없습니다.

• 기계 학습 환경을 빠르게 늘리는(Scale up/out) 기능이 필요합니다.
• 예시로 (어제까지 데이터를 분석하고 있어, GPU 노드는 쉬게 했지만 지금 모델 훈련이나 실험을 여러 개 돌리고 싶지만, GPU는 기본적으로 하나의 프로세스 밖에 돌릴 수 없기 때문에 병렬화를 할 수 없고, 공동의 GPU 자원은 관리자의 승인이나 사용자간 간섭에 자유롭지 못하여 사용하기 어렵습니다.
• GPU 자원을 동시에 여러 프로세스가 사용할 수 있거나, 사용자간 간섭을 방지하며 자동화된 자원을 관리하며 빠르게 모델 훈련 환경 스케일 업/아웃을 도와주는 MLOps 도구가 필요합니다.

ii) 훈련한 모델을 추론 모델로 만들기 어렵습니다.

• 훈련 혹은 실험에서 좋은 결과가 나왔지만, 이것을 서비스로 제공(ML Serving) 하기까지 여러 단계를 걸친 서비스 최적화 작업과 서빙 모델을 동작하기 위한 프레임워크에 맞게 변환하고, 서비스를 모니터링하는 과정이 어렵습니다.
• ML 서비스에 적용하기까지 일련의 복잡한 과정을 자동화하도록 프레임워크나 플랫폼 지원이 필요합니다. (참고. Using MLOps to Bring ML to Production/The Promise of MLOps)

iii) 모델 훈련 실험 결과를 재현하기 어렵습니다.

• 소프트웨어 개발자, 데이터 과학자가 원하지 않는 ML 학습, 실험 결과를 발견했을 때, 수정하기 위해서 훈련과 실험 과정을 쉽게 재현하기 어렵습니다.
• 훈련 과정이나 실험에서 문제가 발생하는 것을 재현하기 어렵고, ML 서비스 제공 시점에서도 또한 재현이 어렵다면 ML 서비스에 대한 품질 보증은 더 어렵게 됩니다.
• 이를 개선하기 위해서는 모델 훈련이나 실험에 사용된 데이터, 학습 코드, 하이퍼 파라미터, 훈련 모델, 실험 결과의 일관된 버전 관리 및 재현성 담보가 필요합니다.

iv) 모델을 개발할 때는 충분한 정확도가 있었지만, ML 서비스에서는 처리 속도가 느리거나 서비스 확장을 하기 어렵습니다.

• 기계 학습 모델이 정교할수록 GPU/CPU 등의 연산 자원을 더 많이 필요로 하게 되지만, ML 서비스에서 모델의 정확도를 유지하면서 서비스에 필요한 연산 자원을 늘리는 데는 한계가 있고, 이를 자동으로 확장하는 것은 또 다른 어려움이 됩니다.
• ML 서비스를 효과적으로 제공하기 위해서는 처리 속도와, 정확도의 트레이드오프를 조정하여 최적화할 필요가 있으며, 이 과정을 자동화하거나 어느 정도 추천한 값을 제공하는 도구가 필요합니다.

MLOps 도구들

MLOps의 여러 문제를 해결하기 위해서 다양한 단계별 도구들이 있으며, 이러한 것들을 묶어서 플랫폼 서비스로 제공하려는 여러 프로젝트들이 있습니다.

• 모델 서빙을 위한 도구들

  • Flask, FastAPI, TensorFlow Serving, TorchServe, Triton Inference Server, OpenVINO, KFServing, BentoML, AI Platform Prediction, Sagemaker 등등

• 기계 학습 플랫폼: 관리형 ML, CI/CD 파이프라인 제공

  • AWS Sagemaker, GCP AI Platform, Azure Machine Learning, Kubeflow, Backend.AI 등등

• 실험 관리 도구

  • MLFlow, Trains, comet, neptune, 등등

• 파이프라인 관리 도구

  • Apache Airflow, digdag, Metaflow, Kedro, Pipeline X 등등

• 분석 및 모델링 툴

  • Jupyter, JupyterLab

• 하이퍼 파라미터 최적화

  • Scikit-Optimize, Optuna

• 데이터 수집 및 관리

  • AWS, GCP, Azure 등 클라우드 서비스에서 공급하는 여러 도구들

맺음말

MLOps는 “기계 학습 프로젝트를 원활하게 진행하기 위한 도구” 입니다. 기계 학습 제품 서비스를 제공하기 위한 필요한 도구들이 활발하게 개발 및 공개되고 있습니다. 하지만 MLOps에 필요한 단계마다 정말 많은 도구들이 있어서 이것들을 조합하여 기계학습 서비스로 만들기 위해서는 각 도구들의 특성과 적용 범위를 이해하여야 하며, 각 기계 학습 프로젝트에 맞추어 어떻게 조합하고, 사용하는지를 생각해야 합니다. 이 과정이 어렵기 때문에, 많은 시행착오를 거치며 다양한 문제를 해결해야만 합니다. 본 글을 시작으로 MLOps에서 사용하는 여러 가지 도구의 특성과 적용 범위 및 사용법을 정리하여 여러분께 공유하도록 하겠습니다.

Reference

• The DevOps HandBook : (Author), John Willis (Author), Jez Humble (Author)
• Key requirements for an MLOps foundation : Craig Wiley (Google Cloud)
• The 2021 Accelrate State of DevOps: Elite performance, productivity and scaling : Nicole Forsgren (Research and Strategy, DORA)

[^1]: How to put machine learning models into production

[^2]: Why 90% of Machine Learning Models Never Make it to Production