MLOps 란 무엇일까?

 

출처: MLOps 란 무엇일까?. MLOps 의 등장 배경 | by Jongmin Kim | XBrain | Medium

MLOps 의 등장 배경

머신러닝은 복잡한 문제들을 효율적으로 풀어낼 수 있는 도구입니다. 이 도구를 활용하여 상품 추천 시스템, 이메일의 스팸 필터, 이상징후 예측으로 보안시스템 강화, 효율적인 고객지원을 위한 다양한 서비스를 만들 수 있습니다. 실제로 대다수 IT 기업들은 머신러닝의 가치를 이해하고 1회 이상 머신러닝을 적용하였고, 앞으로 확대 적용할 계획을 가지고 있습니다.

하지만 머신러닝을 운영하는 건 어렵습니다. 대부분(88%)의 머신러닝 프로젝트들은 POC 단계에서 가치는 검증되었지만, 운영상의 어려움으로 인해 서비스로 발전하지 못합니다. 왜 많은 기업이 머신러닝 시스템을 구축하고 운영하는 데 어려움을 겪을까요? 예를 들어 쇼핑몰에서 다음날의 수요를 예측하여 창고의 재고를 주문하는 시스템을 구축한다고 가정해보겠습니다.

모델의 서비스 적용의 어려움

데이터 과학자가 다양한 곳에 있는 데이터 속에서 학습 가능한 데이터로 정제하여 모델을 만들었습니다. 모델을 서비스에 적용하기 위해서는 매일 전날의 구매 이력을 사용해 다음 날의 수요량을 예측해야 합니다. 예측서비스를 운영하기 위해서는 API 서버, Batch job 과 같이 개발된 모델을 위한 endpoint가 제공되어야 합니다. 이런 endpoint 를 개발하기 위해서는, 소프트웨어 개발과 마찬가지로 Infrastructure 설계, 개발, CI/CD 와 같이 고려되어야 할 것들이 많이 있습니다. 하지만 데이터팀은 서비스 개발이 주 업무가 아니기 때문에, 서비스 개발에 능숙한 인력이 부족합니다. 그렇기 때문에 아무리 성능 좋은 모델을 만든다 한들, 서비스가 가능한 수준의 제품으로 만들어내는 일은 어렵습니다.

모델 성능 추적의 어려움

예측 모델 하나에 대하여 DevOps 팀에서 데이터를 받아 예측값을 전달하는 API를 만들어 주었고, 며칠간 수요예측모델을 운영했습니다. 하지만 쇼핑몰의 경우 외부 요인들에 따라 데이터는 변하게 됩니다. 예를 들면 코로나로 인해 생수와 같은 생필품 수요량이 많이 늘어날 수 있습니다. 이러한 데이터의 변화, 모델 성능의 변화를 인지하지 못한다면, 모델은 과거의 학습된 패턴으로 수요를 예측합니다. 모델의 성능이 떨어짐을 인지하지 못하면, 수요예측에 실패하고 상품이 품절되거나 재고가 쌓이는 상황이 발생합니다.

모델과 데이터 관리의 어려움

모델이 이상징후가 감지되면 학습에 사용된 데이터와 서빙된 데이터들이 어떤 차이가 있는지 꼼꼼히 비교해 보아야 합니다. 하지만 데이터는 계속해서 변해가고 데이터 변형과정과 모델학습 방법은 반복해서 업데이트가 이루어집니다. 과거 모델을 분석하기 위해선 학습된 데이터, 예측했던 데이터들이 필요합니다. 반복된 데이터 정제 코드의 수정과 모델 학습 코드의 변경으로 과거의 모델을 재현하고 분석하는 건 어렵습니다.

협업의 어려움

수요 예측이라는 문제 하나를 풀기 위해 실험환경을 구축하는 것부터, 모델 endpoint, 모니터링과 같은 기능은 DevOps 팀과의 협업이 필요합니다. 하지만 문제는 DevOps 엔지니어는 머신러닝 시스템을 이해하기 어렵고, 반대로 데이터 과학자는 인프라스트럭쳐 설계부터, 서비스 운영까지의 DevOps 과정을 이해하기 어렵습니다. DevOps, 데이터 과학자, 운영자들이 서로 잘 모르는 영역을 논의하고 R&R을 논의하는 것은 어렵습니다. 이렇게 힘겨운 과정을 새로운 모델을 개발할 때, 모델을 업데이트할 때마다 발생합니다.

머신러닝은 문제를 해결하는 정말 좋은 도구입니다. 하지만 머신러닝을 운영한다는 것은 위와 같이 실험만큼이나 혹은 그 이상으로 큰 노력이 필요합니다. 운영을 위한 시스템이 마련되지 않으면, 머신러닝은 더 좋은 서비스를 만드는 도구가 아니라 병목이 됩니다. 그렇기 때문에 많은 IT 회사들이 POC 단계에서 모델의 가치는 검증하지만, 실제 머신러닝을 운영까지 발전하지 못합니다.

DevOps가 주목받은 이유가 서비스를 빠르게 전달하여, 고객을 더 잘 지원하고 경쟁력을 갖춘다는 것이었습니다. 마찬가지로 MLOps는 머신러닝 시스템을 사용자에게 빠르게 전달하는 것을 목표로 합니다. 이제부터 MLOps 에 대해 조금 더 상세하게 알아보겠습니다.

 

MLOps 의 상세 개념

MLOps의 목표는 DevOps의 목표와 마찬가지로 사용자에게 서비스를 빠르게 전달하는 개발 문화입니다. DevOps에서는 “코드 통합, 테스트, 배포, 테스트, 모니터링” 의 파이프라인을 자동화하여 이 목표를 달성합니다. 하지만 MLOps의 파이프라인은 DevOps의 파이프라인과 의미가 상당히 다릅니다.

코드 통합

머신러닝은 기본적으로 실험이 개발입니다. 머신러닝 개발은 데이터 더미에서 유의미한 학습 데이터 만들기, 알고리즘 구현, 하이퍼 파라미터 최적화와 같은 일입니다. 이 과정에서는 원활한 실험을 위해 샘플링된 데이터를 사용하기도 하며, 최적화를 위한 다양한 시도들이 코드로 작성됩니다. 말 그대로 실험과 검증을 위한 코드가 개발됩니다. DevOps 와 달리 실험용 코드는 운영 가능한 형태가 아닙니다. 운영을 위해선 프로덕션 데이터의 ETL, 분산처리, 불필요한 로직 제거, 예측 추론 시간을 서비스 수준에 맞게 학습 단계 단순화와 같이 운영 수준의 변형과정이 필요합니다.

일반적인 머신러닝 파이프라인

MLOps 의 통합은 실험환경에서 결정된 데이터 변형, 학습, 평가, 재학습 주기, 모니터링 지표 설정 등 실제 서비스 운영환경으로 통합되는 것을 의미합니다.

테스트

예측 모델을 단순하게 생각하면 output = model.predict(inputData) 입니다. 일반적인 소프트웨어 개발이라면 predict() 의 내부 동작을 알기 때문에, 다양한 시나리오를 만들어 테스트할 수 있습니다. 하지만 모델의 경우 내부 동작 방식을 이해할 수 없는 경우가 대부분입니다. 그렇기 때문에 output 에 대한 검증을 하기 어렵습니다. 그렇기 때문에 일반적인 소프트웨어의 유닛테스트와 같이 assert output == 0.5 와 같이 나온다고 모델이 정상이라고 판단할 수 없습니다. 모델을 테스트하기 위해선 Accuracy, Precision/Recall curve, Confusion matrix 와 같은 다양한 지표들을 활용해야 합니다.

모니터링

일반적인 소프트웨어의 경우 서버의 리소스 상태, 응답시간과 같이 명확하게 정상과 비정상을 구분할 수 있는 지표들이 있습니다. 하지만 테스트단계와 마찬가지로 모델의 성능을 판단하는 방법은 다양하고 복잡합니다. 예를 들면 모델 endpoint 에 요청된 데이터와 예측했던 값들을 수집하고, 이것들이 학습된 데이터와 Statistical distance 를 계산하는 것입니다. 프로젝트의 목적, 알고리즘, 데이터의 특성에 따라 판단 방법은 달라질 수 있기 때문에, 어떤 방법을 사용할지 결정하는 것도 중요합니다.

배포

모델을 배포하는 건 단순히 예측 모델을 API에서 제공하는 것이 아닙니다. MLOps 의 배포는 코드 통합, 새로운 데이터의 학습, 서비스로 모델 전달, 모니터링 방식 적용까지의 파이프라인의 배포입니다. 이 파이프라인이 배포되면 Raw data에서 모델이 서비스 전달되고 모니터링되는 과정이 동작하게 됩니다. 중요한 점은 MLOps 의 파이프라인은 일회용 아니라는 것입니다. 배포 이후 다시 모델 개발 단계로 신속하게 전환이 되어야 합니다. 이전 모델과 운영된 데이터의 분석 후 다시 통합, 학습, 전달, 모니터링이 이루어져야 합니다.

ML 개발, 통합, 테스트, 배포, 모니터링

MLOps를 도입한다는 것을 요약하자면 아래와 같이 정리할 수 있습니다.

• 개발, 통합, 테스트, 운영, 모니터링 파이프라인을 운영 Infrastructure 적용
• 위 파이프라인의 Continuous Integration, Continuous Training, Continuous Delivery
• 학습 데이터와 모델, 운영 데이터의 통합적인 관리

MLOps는 XBrain에서 주장하는 개념이 아닙니다. GCP, Netflix, Uber와 같은 세계적인 IT 기업에서도 MLOps를 도입하고, 이에 대하여 많은 연구조사를 하고 있습니다. 많은 사례가 있지만, 그 중 Uber에서 공개한 UberEATS의 배달 소요 시간 예측 모델 운영에 대해 알아보겠습니다.

사례 분석

Uber 의 배달 소요 시간 예측

Uber의 음식 배달 서비스 Uber Eats

배달 소요 시간을 예측하는 건 상당히 어렵습니다. 식당이 얼마나 바쁜지, 음식이 완료되어도 이 배달 기사님이 식당에 언제 도착하는지, 도착까지 어떤 경로로 이동하는지에 대한 정보가 필요합니다. 모델학습을 위해 날씨, 시간, 지역, 지난 7일간 음식이 준비된 시간과 같이 복잡한 학습데이터가 필요합니다. 그리고 이 데이터의 양은 상당히 많습니다.

MLOps를 위해 Uber 에서는 미켈란젤로라는 내부적인 MLOps시스템을 구축했습니다. 이 시스템의 주요 기능은 아래와 같습니다.

1. 데이터 관리 Uber의 문제에서 데이터는 크게 스트리밍 데이터와 Data Lake 두 가지 형태로 데이터가 존재합니다. Data Lake의 방대한 양을 처리하기 위해 Spark와 같은 분산처리시스템을 사용하며, 스트리밍 데이터를 정제하기 위해 Kafka, Samza와 같은 스트리밍 엔진을 사용합니다. 이렇게 정제된 데이터를 관리하기 위해 Cassandra를 “Feature Store”로 사용합니다. ( Feature Store라는 개념은 MLOps 에서 중요한 개념입니다. Feature Store에 대한 설명은 추후 별도의 포스팅에서 다룰 예정입니다)
2. 모델 학습 및 평가 정제과정을 거친 데이터는 Feature Store 에 저장이 되고, 이 데이터들은 주기적으로 학습됩니다. 이 역시 대용량의 데이터이기 때문에 Spark MLLib, XGBoost, TensorFlow 와 같은 도구를 활용합니다. 이렇게 학습된 모델은 평가 후 “Model Repository” 에 저장됩니다. ( Feature Store 와 마찬가지로 Model Repository 역시 추후 별도의 포스팅에서 다룰 예정입니다. )
3. 모델 배포 및 서비스 적용 기존의 모델이 아니라 앞의 학습 과정에서 생성된 모델을 사용하도록 운영환경에 모델이 전달됩니다. 이 모델은 사용자에게 예측 시간을 실시간으로 알려주는 서비스와 주기적으로 식당의 배달 소요 시간을 계산하는 데 사용됩니다. 여기서 모델이 요청받은 데이터와 예측한 값들은 “1. 데이터 관리” 기능에 의해 Feature Store와 같은 저장소에 저장됩니다.
4. 예측결과 모니터링 앞에서 강조했듯이 모델의 성능을 평가하는 중요합니다. Uber 의 경우 요청 양이 워낙 많기 때문에 샘플링하여 요청 데이터와 예측값을 저장합니다. 이 데이터를 사용해 모델의 성능을 모니터링합니다.

미켈란젤로 시스템

글을 마치며…

머신러닝 시스템을 운영하기 위해선 넘어야 할 장애물이 많이 있습니다. 대부분의 장애물은 데이터 과학자는 DevOps 과정을 이해하기 어렵고, DevOps 는 데이터와 머신러닝의 복잡도를 이해하기 어려운 것에서 시작됩니다. 머신러닝과 DevOps 의 간극을 최대한 줄이는 것이 중요합니다.

XBrain 은 MLOps 를 쉽게 도입할 수 있도록 도와드립니다. 크게 ”데이터와 모델의 관리 방법”과 “예측 모델 서비스와 모니터링” 두 가지 기능에 집중하고 있습니다.

“데이터와 모델의 관리” 를 위해 고객들의 환경에 맞는 데이터베이스, 분산처리 엔진구축, 체계적인 관리 방법을 제공합니다.

“예측 모델 서비스와 모니터링” 을 위해 다양한 ML Framework ( sklearn, Tensorflow ) 를 이해하고 이것들의 운영시스템을 제공합니다. 그리고 kubernetes, jenkins 와 같이 원활한 모델의 배포를 위한 다양한 기술들의 사용 방법을 제공합니다. (제품의 자세한 소개는 여기를 클릭해 주세요)

XBrain 의 MLOps 엔지니어는 고객들의 어려워하는 부분을 이해하고, DevOps 와 머신러닝 이 둘의 간극을 줄여드립니다. 이러한 어려움을 겪는 고객의 소리에 귀 기울이고, 이를 기술적으로 해결하는 것에 관심이 있는 분들은 아래 링크로 들어와 주세요.