[MLOps] ML Pipeline

해당 스터디 자료는 AWS 기반 데이터 과학을 기반으로 진행되었습니다.

 

1. 왜 Pipeline인가?
2. Pipeline이 도대체 무엇인가?
3. 효율적이고 이상적인 Pipeline란?
4. ML Pipeline 플랫폼은 무엇이 있는가?

 

---

 

Why Pipeline?

Machine Learning 또한 하나의 어플리케이션 개발과 유사하게 모델을 개발하는 작업이라 볼 수 있다. 또한 ML 모델도 한 번 개발하면 끝이 나는 것이 아니라 계속해서 유지보수가 필요하다. 유지보수가 왜 필요하냐고? 크게 아래와 같이 정리할 수 있을 것 같다.

모델 성능 하락/고도화 필요성
시간이 지남에 따라 들어오는 ML 학습에 활용되는 데이터의 추이가 바뀌거나, 삭제되어 모델의 성능이 낮아질 수 있다. 혹은 학습할 수 있는 데이터가 추가되면서 모델 성능을 좀 더 높일 수 있게 되는 경우가 생긴다. 이럴 경우 더 나은 모델을 서비스하기 위해 유지보수가 필요하다.

비즈니스 니즈 변경
모델이 라이브에 서비스하다 보면 모델 개발 초기와는 다른 비즈니스 니즈가 생길 수 있다. 가령 binary classification에서 multi-class classification을 요구하거나, 단순히 0,1로만 결과값을 반환하던 모델에 점수 형식으로 결과값을 받아보길 원할 수 있다. 이는 ML 모델의 결과를 기반으로 다른 프로젝트가 같이 연관될 경우 발생할 수 있다.

 

체감상 데이터 변경에 따른 모델 성능 하락 때문에 유지보수가 많이 일어나는 것 같다. 그렇다면 ML 모델 개발자들은 자신들이 개발한 수많은 ML 모델들의 성능을 어떻게 다 모니터링할 수 있을까? 모니터링이 가능하다면, 모델 성능 하락 발생 시 그 원인을 어떻게 찾아낼 수 있을까? 이 방법을 찾기 위해 고안해 낸 것이 바로 MLOps이자, Pipeline이라 볼 수 있다.

 

 

What is Pipeline?

Jenkins와 같은 CI/CD 자동화 툴처럼 ML 모델 개발자들도 자신의 모델 개발의 사이클을 자동화하고 추적할 수 있는 플랫폼의 필요성이 점점 더 강해졌다. (아마 다양한 기업에서 여러 ML 모델이 개발됨에 따라 관리의 필요성도 기하급수적으로 늘었을 것이다.)

그러면 Machine Learning의 사이클은 어떻게 정리할 수 있을까? 각 MLops 플랫폼마다 정의하는 바는 다르지만, 대체로 아래와 같이 볼 수 있다. 

 

https://valohai.com/machine-learning-pipeline/

위 그림을 기반으로 아래와 같이 순서를 요약해서 볼 수 있다. 그리고 각 단계를 대부분의 MLOps pipeline 플랫폼에서는 component라고 칭한다.

1. 데이터 수집 및 버전 관리(Data Ingestion and Versioning)
2. 데이터 분석 및 검증 (Data Anaylsis and Validation)
3. 피쳐 선택 및 엔지니어링 (Feature Selection and Engineering)
4. 모델 학습 및 튜닝 (Model Training and Tuning)
5. 모델 평가 (Model Evaluation)
6. 모델 배포 및 버전 관리 (Model Deployment and Versioning)
7. 모델 모니터링 (Model Monitoring - Model Feedback and skew detection)

 

 

How to make Efficient/Ideal Pipeline

※ 글자 많음 주의 ※

 

파이프라인이 모델 유지보수 측면에서 꼭 필요하고, 전체적인 ML의 흐름을 pipeline으로 정리해서 볼 수 있다는 점은 이해했다. 그렇다면 어떻게 해야 보다 효율적으로 pipeline을 구축할 수 있을까? 정확히는 위에서 본 pipeline의 component는 각각 어떤 것을 주목적으로 삼아 구축해야지 가장 이상적인 pipeline이라고 할 수 있을까?

 

데이터 수집 및 버전 관리

데이터 중심 작업 중 하나. 수집된 raw 데이터와 학습을 위해 전처리한 데이터 각각 버전 관리를 진행한다. 이는 문제가 발생할 경우 전처리 과정에서 발생한 문제인지 원본 데이터에 의도하지 않은 값이 들어온 건지 추적하기 위함이다. 각 버전 관리는 데이터가 수집된 날짜나 크게 데이터 schema가 변경된 시점 등을 기준으로 관리할 수 있다.

 

데이터 분석 및 검증

데이터 중심 작업 중 하나. 수집 및 전처리된 데이터의 품질과 편향을 분석하여 추후 모델 성능 하락 시 추적 가능하도록 한다. 또한 데이터에 불순물은 없는지, 데이터 타입에 불일치는 없는지 등 실제로 모델이 학습할 수 있는 데이터인지 검증을 진행한다.

 

피쳐 선택 및 엔지니어링

모델 학습을 진행하기 전의 최종 데이터 전처리 작업이다. 데이터 셋의 균형을 맞추거나, Train/Valid/Test set으로 나누는 등의 작업을 진행한다. 추가로 훈련 및 추측에 사용할 feature를 별도의 feature store에 관리 및 공유할 경우 해당 stage에서 진행한다. 

 

모델 학습 및 튜닝

앞서 전처리된 데이터셋을 활용해 모델을 학습한다. 해당 단계에서 각각 다른 알고리즘으로 개발된 모델에 맞춰 파이프라인을 개별로 구축해 두면, A/B테스트를 동시에 진행할 수도 있다. 또한 하나의 알고리즘에 대해서도 각각 하이퍼파라미터에 대해 튜닝 과정을 진행할 수 있다. 

 

모델 평가

피쳐 선택 및 엔지니어링 단계에서 미리 분류해 둔 Test set을 이용해 각 모델을 평가한다. 모델 평가 지표는 유저가 직접 설정 및 추가할 수 있다. 각 평가 지표를 통해 모델 편향을 자동으로 검증하고, 재훈련 및 튜닝을 다시 진행할 수 있다.

 

모델 배포 및 버전 관리

모델의 하이퍼파라미터 및 Train/Valid/Test set을 하나로 묶어 버전 관리를 진행한다. 이렇게 버전 관리 시, 추후 실험 결과 재생산(다시 모델 돌릴 경우에도 동일한 결과 보장)이 가능하고, 역추적이 가능해진다.

ML의 경우 실험의 느낌이 강해 단순히 모델의 하이퍼파라미터로만 버전관리할 경우 나중에 해당 모델의 성능이 왜 저렇게 나왔는지 역추적이 어려울 때가 많이 발생한다. 데이터에 따라 모델 성능이 크게 차이가 나는 경우가 있기 때문에 같이 버전 관리해야 할 필요가 있다.

 

모델 모니터링

비즈니스 지표(ex. 매출 증가량, 사기 탐지 성공률 등)에 대한 모델 성능을 분석한다. 목표치에 비해 성능이 떨어질 경우 데이터에 왜곡 여부를 앞 컴포넌트에서 확인하여 모델 재훈련 및 개선 작업이 필요한 시점을 보다 자동으로 알 수 있도록 만든다. 여러 플랫폼에서 해당 단계에 모델 성능 및 예측 결과를 시각화해 보여주기도 한다.

 

 

파이프라인 구축 시 각 단계별로 어떤 것에 중점을 둘지 살펴보았다. 각 단계를 목표에 맞춰 잘 구현했다면 가장 이상적인 pipeline의 마지막 단계는 자동화일 것이다. 즉, 한 번 pipeline을 구축한 후, 우리가 원하는 시점에 알아서 모델이 학습하고 이를 알람을 준다면 ML 모델 개발자 입장에서도 공수가 덜 들고, 해당 모델 관련 프로젝트 담당자들도 좀 더 쉽게 모델의 추이를 확인할 수 있을 것이다.

자동으로 학습하는 조건은 각 단계(컨포넌트)의 코드 중 일부 코드가 변경되었을 때, 데이터가 추가되었을 때, 특정 주기마다를 의미할 수도 있으며, 모델 성능 지표나, 학습 데이터의 추이가 변경되었을 때도 가능하다!! 이 얼마나 편리하고 똑똑한 pipeline인가!

 

 

ML Pipeline Platform

ML Pipeline을 쓰기 편리하게 구현한 여러 플랫폼이 이미 존재한다! 하지만 MLOps란 개념이 이제야 빛을 보고 있기 때문에 해당 플랫폼들이 아무리 잘 구현되어 있다고 해도 여전히 미숙한 부분이나 아쉬운 부분들이 많고, document들도 상대적으로 적다. (선조들의 지혜 창고, 스택오버플로에 아직 많은 삽질이 더 올라와야 할 것 같다) 현재 ML모델 서비스 중인 플랫폼과 모델 크기, 비즈니스 목표등을 고려해 가장 적합한 플랫폼을 사용하는 것을 추천한다.

 

AWS SageMaker

 

각 Pipeline에 맞춰 단계별로 스크립트를 구축 및 코드 관리를 해두면, 해당 스크립트를 SageMaker를 활용해 불러오고 실행시킬 수 있다. 각 스크립트의 인풋 선언 및 아웃풋 관리 또한 SageMaker에서 지정할 수 있다. 

전처리된 데이터 및 모델과 같은 각 단계 별 output은 대체로 AWS S3를 활용하여 진행하는 편이다. (같은 VPC 기준으로는 업로드/다운로드 과금이 없으며 단순 보관 비용만 발생) 따라서 AWS에 많은 인프라가 구축되어 있다면 SageMaker도 사용할 법하다. (그래서 상대적으로 많이 사용을 해보는 편인 것 같기도 하다)

좀 더 코드 레벨로 확인하고 싶다면 해당 링크에 대략 어떤 식으로 Pipeline을 구축(혹은 활용)하는지 확인할 수 있다.

 

AWS Step Function

ML 전용 기능은 아니나 AWS에서 지원하는 workflow 플랫폼이다. 해당 플랫폼을 위의 compenent에 맞춰 개발한다면 ML Pipeline구축이 가능하다. (근데 SageMaker가 있는데 굳이...? 가격이나 접근성 측면의 문제로 선택하게 되는 걸까?) 

 

Kubeflow

쿠버네티스(Kubernetics) 환경을 기준으로 만들어진 MLOps이다. AWS에서도 Kubeflow를 지원하고 있기 때문에 EKS환경에서 보다 쉽게 구축이 가능하다. Kubeflow는 기본적으로 작은 컴퓨팅 시스템을 여러 개 사용하여 보다 효율적이고 빠르게 작업을 동시에 진행하는 것을 목표로 하고 있으며, 그 기반이 쿠버네티스이다. 다만 ML 모델 개발자나 Data Scientist 입장에서는 쿠버네티스를 이해해야 한다는 점이 다른 서비스에 비해 큰 디메리트로 작용할 수 있다. 다만 각 쿠버네티스의 인스턴스나 클러스터 관리의 측면에서 본다면 MLOps 엔지니어 입장에선 확장이 용이하고 관련 도큐먼트를 쉽게 더 많이 찾아볼 수 있다는 장점도 가지고 있다. 

 

 

Apache Airflow

Airflow의 경우 job scheduling 플랫폼으로, ML 측면으론 주로 데이터 엔지니어링이나 분석 작업을 위한 ETL 작업에 자주 사용된다고 한다. 결국 하나의 pipeline을 dag(airflow의 하나의 스케줄 단위라고 이해하면 편함)로 생성하고, 각 단계(component)를 dag 하위의 job으로 구현하면 우리가 생각하는 pipeline을 만들 수 있다. 또한 각 순서를 병렬 처리 및 순차처리가 동시에 진행되도록 설정할 수도 있으며, job 기준으로 해당 job만 재실행하거나 그 이후를 전체 재실행하는 등의 작업이 가능하다. 

 

 

---

Machine Learning을 진행하다 보면 다양한 문제에 부딪치게 된다. 그중에 많은 이들이 공감할 대용량 데이터 처리, 모델 유지보수의 측면에서 MLOps의 중요도가 높아지고 더불어 Pipeline이란 개념이 결국 AI 분야에 녹아들게 된 것 같다. 

본문에서는 Pipeline이 왜 필요하고, 도대체 무엇이며, 그래서 이상적인 pipeline 구축을 위해 고려해야 할 점이 무엇인지를 살펴보았다. 마지막엔 어떤 플랫폼들이 대표적으로 있으며 활용할 수 있는지도 간략히 정리해 보았다.

필자 또한 여전히 동일한 문제를 겪고 있어 Airflow와 Kubeflow를 사용하고 있는데, 단순히 사용자의 입장이라 좀 더 자세히 적지 못해 아쉬울 따름이었다. 추후 상세히 정리하는 시간을 갖으며 이상적인 Pipeline 구축을 위해 좀 더 고민해봐야 할 것 같다.