MLOps의 구성 요소는?

이전 MLOps 글을 작성한 지 벌써 1년이나 지났는데... 변명을 해보자면 MLOps를 계속해서 공부를 하고는 있었지만, 직장 생활을 하면서 글을 작성한다는 게 쉽지는 않다는 것을 깨달았고 Dart & Flutter 등 다른 언어들을 공부하느라 소홀했습니다...ㅎ (Dart & Flutter는 공부하면서 꽤나 재밌었기 때문에 조만간 글을 작성할 계획입니다.)

 

아무튼 이제 개인적인 시간도 많아졌고 해서 다시 한번 꾸준히 글을 작성해 볼 생각입니다.

1년 전 MLOps 관련 글은 MLOps가 등장하게 된 배경, MLOps가 DevOps와 다른 점에 대해서 알아보았습니다.

 

이번에는 MLOps의 구성 요소에 대해서 정리해 볼까 합니다.

시작하기 전에,

MLOps가 DevOps를 참고해서 만든 만큼 구성 요소도 꽤 나 비슷하게 이루어져 있습니다. 구글에 MLOps 구성 요소를 검색하면 많은 글에서 잘 설명해주고 있지만 이 글에서는 필자가 처음 MLOps를 접하고, 공부하면서 정리했었던 내용들을 조금 더 간단하게 다뤄보려고 합니다. (이 글은 비기너 레벨이라고 생각해 주시면 좋을 것 같습니다. 🙏)

MLOps의 구성 요소

ML(Machine(Deep) Learning)에서 가장 중요한 것은 'Data'입니다. MLOps = ML + DevOps 글에서도 설명드린 것처럼 Data의 유무 때문에 기존 DevOps의 요소들을 그대로 반영할 수 없는 것처럼 MLOps의 구성 요소도 ML에 맞게 설정되었습니다.

MLOps의 구성 요소는 크게 3가지(Data, Model, Serving)로 나눌 수 있고 Data를 수집하고 Model을 만들고 서버에 Serving 하는 단계를 조금 더 세부적으로 정리해 보았습니다.

 

여러분께서 이미 하셨거나 구상 중인 프로젝트를 생각하시면서 글을 읽으신다면 도움이 되지 않을까 생각합니다.

1. Data

첫 번째는 Data입니다. ML&DL Model을 개발할 때 가장 먼저 하는 일이기도 하고, Model 성능에 영향을 많이 주는 중요한 요소입니다.

근데 그냥 Data라고 끝내기에는 이해하기 어려우니 조금 더 세분화해서 살펴보면 아래와 같습니다. (필자가 사용해 본 툴은 초록색 글씨로 해두었습니다.)

 

1-1. 데이터 수집 파이프라인 (사용하는 툴 : Kafka, Flink, Spark 등)

 

대부분의 경우 Model 학습에 필요한 데이터는 사용자가 직접 수집해야 하는 경우가 많습니다. (AI 허브나 공공 데이터 포털을 통해서 데이터 수집을 할 수 있지만 업데이트가 자주 이루어지지 않는다는 점, 사용자가 원하는 데이터가 없을 수도 있다는 점 때문에 지속적으로 데이터를 수집하고 Model을 학습시키기 위한 MLOps와는 맞지 않습니다.)

 

하지만 무조건 Kafka, Spark 등의 툴로 데이터 수집 파이프라인을 만들어야 한다고 물어보신다면 그것은 아닙니다. 왜냐하면 Kafka, Spark 등의 툴들은 빅데이터(대략 1GB 이상)를 다룰 때 활용하는 것이 더 효과적입니다. 만약 매일, 매주 수집해야 하는 데이터의 양이 10MB ~ 20MB라면 굳이 복잡하고 어려운 툴보다는 스크레이핑, 크롤링과 스케쥴링을 결합하는 방법이 더 효과적일 수 있습니다.

 

예를 들어, 10평의 논 밭에서 쌀을 수확할 때 기계를 이용하는 것보다 사람이 직접 수확하는 것이 더 효과적이고 10000평의 논 밭에서는 사람보다는 기계를 이용해서 수확해야 효과적인 것처럼 최소 비용에서 최대 비율을 낼 수 있는 방법들을 고민해보아야 합니다.

 

1-2. 데이터 저장 (사용하는 툴 : MySQL, Hadoop, Amazon S3 등)

 

수확한 농산물을 상하지 않게 저장해두어야 하는 것처럼 수집한 데이터도 저장해두어야 합니다. 주로 RDB나 NoSQL에 저장하는 경우가 많지만 빅데이터나 24시간 서비스가 돌아가야 하는 경우라면 AWS, GCP 등 클라우드 서비스도 이용할 수도 있습니다. 이 때도 사용자의 판단에 따라 달라질 수 있습니다.

 

1-3. 데이터 관리 (사용하는 툴 : Feast, DVC 등)

 

데이터 관리라고 했을 때, '데이터를 저장까지만 하면 이제 Model 학습할 수 있는 거 아닌가요?'라는 생각이 들 수 있다. 물론 저장한 데이터로 Model을 학습시켜서 결과를 볼 수 있습니다. 하지만 데이터가 주기적인 업데이트가 이루어지고 업데이트된 데이터로 새로 Model을 학습시켜야 하고 업데이트된 데이터를 학습한 Model이 이전보다 성능이 떨어질 수도 있기 때문에 섣불리 이전 데이터를 삭제하기에도 위험부담이 있습니다. 이로 인해 Data Version Control(DVC)가 필요합니다.

 

그리고 하나의 Model이 아닌 여러 개의 Model을 하나의 데이터 셋에서 학습시킬 때 다음과 같은 상황이 벌어질 수도 있습니다.

A Model은 1 ~ 4번 Feature를 사용하고, B Model은 3 ~ 7번 Feature를 사용한다고 할 때 각각 Model에 맞춰서 데이터를 저장하기에는 같은 데이터 셋을 중복해서 저장하는 것이기 때문에 비효율적이다. 이 때, Feature Engineering을 할 수 있는 Feast를 활용한다면 하나의 데이터 셋에서 Model 별로 필요한 Feature들만 추출해서 사용하는 것이 가능합니다.

 

데이터 관리를 이 글에서 전부 설명하기에는 너무 길어질 수도 있으니 나중에 Feast나 DVC 툴을 직접 다루면서 설명하는 것으로 하고 자세한 설명은 하지 않겠습니다.

 

여기서는 간단하게 데이터 관리가 어떤 것인지에 대해서만 감을 잡으시면 좋을 것 같습니다.

2. Model

두 번째는 Model입니다. 앞에서 데이터를 수집하고 저장하고 관리하는 길고 긴 과정을 거치고 나면 드디어 Model을 학습하는 단계에 도달할 수 있습니다.

Model도 Data와 비슷하게 3단계 정도로 나눌 수 있습니다.

 

2-1. Model 개발(사용하는 툴 : Tensorflow, Pytorch, Jupyter Notebook 등)

 

데이터 수집을 진행했으니 이제 Tensorflow나 Pytorch를 사용해서 학습 시킬 Model을 제작하는 단계입니다.

구글에서 제공되는 Colab이나 Jupyter Notebook 등의 환경을 사용할 수 있습니다.

 

2-2. Model 버전 관리(사용하는 툴 : Git, MLflow, Jenkins 등)

 

Model 버전 관리도 앞서 설명했던 DVC와 비슷하게 생각하시면 좋습니다. 데이터를 관리해주는 이유와 비슷하게 새로운 Model이 기존 Model 보다 성능이 낮을 수도 있기 때문에 Model들을 버전 별로 관리해서 서비스되는 Model이 항상 가장 높은 성능을 유지하기 위함입니다.

 

2-3. Model 학습 & 스케줄링 관리(사용하는 툴 : Kubernetes 등)

 

어떤 분들은 2-2. Model 버전 관리에서 이미 Model 학습은 끝났는데 2-3에서 다시 학습하는 것에 대해 의문이 있을 수도 있습니다. 물론 개발이나 버전 관리 단계에서도 Model 학습이 이루어지지만 여기서 말하는 학습은 재학습에 가깝습니다. 만약, 데이터가 지속적으로 업데이트가 되는 서비스라면 그 때마다 Model은 업데이트된 데이터를 다시 학습을 해야 합니다.

 

이 때, 재학습해야 하는 Model이 10개, 20개 또는 그 이상이라면 수동으로 하나하나 재학습을 시켜주는 것이 효율적일까요? 당연하게도 아닌 경우가 더욱 많을 것입니다. 그렇기 때문에 Model을 일괄적으로 학습시켜줄 수 있는 시스템이 이런 상황에서는 상당히 유용할 수 있습니다.

 

예를 들어, 일주일 주기로 데이터가 새롭게 업데이트 되는 서비스가 있고 일주일마다 Model을 재학습시켜주어야 한다면 스케줄링을 통해서 일요일 10시에 일괄적으로 재학습을 시켜줄 수도 있습니다.

3. Serving

마지막 세 번째는 Serving입니다. 지금까지 데이터를 수집하고 Model을 만들었으니 이제 서비스를 시작하기 위한 단계입니다.

 

Serving 단계에는 서버에 학습된 Model을 올리기 위한 모델 패키징 단계, 서버나 Model의 상태를 확인할 수 있는 서빙 모니터링, Data, Model, 서빙 단계를 모두 관리하기 위한 파이프라인 매니징으로 이루어져 있습니다.

 

3-1. 모델 패키징(사용하는 툴 : Docker, Flask, FastAPI, BentoML, TFServing)

 

모델 패키징은 서버에서 Model을 사용할 수 있게 하는 단계입니다. 여러분이 만든 모델을 패키징을 거치지 않고 그대로 서버에 올리게 되면 사용자가 모델을 사용할 때 마다 여러분이 Model을 학습시키고 결과를 보았던 긴 과정을 사용자도 경험할 수 있습니다.

 

예를 들어, 패키징된 Model은 계산기이고 패키징을 하지 않은 Model은 수학자라고 생각할 때 1+1을 계산기에게 물어보는 것과 수학자에게 물어보는 것은 너무 다르죠? 이런 느낌이라고 생각하시면 됩니다.

 

3-2. 서빙 모니터링(사용하는 툴 : Prometheus, Grafana, Thanos)

 

서빙 모니터링은 서버를 모니터링하는 것을 말합니다. 사용자들이 서버에 접속했을 때 안정성이나 Model이 사용자들에게 어떤 퍼포먼스를 보이는지 등 서비스를 구성하고 있는 전반적인 상황을 확인하는 단계입니다.

 

또한, 서버의 과부하 또는 Model의 성능 하락 등 특정 상황에 맞는 알람 기능을 통해서 안정적인 서비스를 운영하는데 도움을 받을 수도 있습니다.

 

3-3. 파이프라인 패키징(사용하는 툴 : Kubeflow, Airflow)

 

서비스를 운영하기 전 여러분께서 지금까지 봐왔던 단계들을 하나의 파이프라인으로 제작하시게 된다면 여러 가지 이점을 가질 수 있습니다.

 

예를 들어, 새로운 데이터를 Model이 재학습하고, 재학습된 Model을 다시 서버에 올리는 과정을 거치는 것보다는 파이프라인으로 구성되어 있다면 A Model 말고 B Model로 재학습하고 서버에 올리는 과정을 한 번에 수행할 수도 있습니다.

**필자도 이 단계는 아직 실제로 다뤄본 적이 없기 때문에 여러 글과 강의를 접한 후에 내용들을 정리한 것입니다.**

---

처음에는 간단하게 정리하려고 했는데 작성하다 보니 점점 길어졌네요...MLOps에 관심이 있거나 처음 접하시는 분들에게 도움이 되었으면 좋겠습니다.

 

긴 글 읽어주셔서 감사합니다!