[MLOps] Google이 말하는 MLOps 수준

MLOps를 구현하는 것은 예측용 API로 모델을 배포하는 것 뿐만 아니라, 모델의 재학습 및 배포를 자동화할 수 있는 ML 파이프라인 배포를 포함합니다. CI/CD 시스템을 세팅해서 새로운 파이프라인 구현을 통해 자동으로 테스트하고 배포할 수 있습니다. 이런 시스템을 사용하면 데이터와 비즈니스 환경에서 일어나는 빠른 변화에 대처하기 쉬워질 것입니다.

 

Google에서는 자동화가 필요하지 않은 가장 일반적인 수준 부터 ML 및 CI/CD 파이프라인 모두를 자동화하는 세 가지 MLOPs 수준을 설명합니다. 이 중   ML 및 CI/CD 파이프라인 자동화에 대해 살펴보겠습니다.

 

ML Ops 1단계 : ML 파이프라인 자동화

---

데이터 추출부터 모델 학습 및 배포하기 까지의 작업을 ML  파이프라인으로 배포하여 자동화할 수 있습니다.  따라서, CT(Continuous traing, 지속적 학습)이 가능해집니다.

ML 파이프라인이 자동화됨에 따라 모델 예측 서비스를 지속적으로 제공할 수 있습니다. (예측 서비스에 대한 CD, Continuous delivery, 지속적 배포)

CT를 위해 파이프라인 트리거, 메타 데이터 관리, 데이터와 모델 검증 자동화를 도입하기도 합니다.

 

1단계 수준에서는 파이프라인과 컴포넌트를 수동 테스트하고 수동 배포합니다. 그러므로 파이프라인의 코드가 바뀔 경우 배포가 어렵습니다. 또한 파이프라인의 개수가 많아져도 관리가 어렵다는 한계가 있습니다. 따라서 새로운 ML 아이디어를빨리 시도해보고 이를 코드에 반영하려고 하거나, ML 파이프라인의 수가 많다면 ML 파으프라인에 대한 CI/CD가 필요합니다. (빌드, 테스트, 배포 자동화)

.

ML Ops 수준1 : ML 파이프라인 자동화

 

• 빠른 실험 : ML 실험(모델 탐색, 하이퍼파라미터 튜닝 등)을 위한 단계들이 모듈화 및 순차적으로 연결되어 있습니다. 단계 간의 전환이 자동화 되어 있어서, 실험을 빠르게 반복할 수 있고 전체 파이프라인을 운영에 옮기기 쉽습니다.
• 운영 모델의 CT(Continuous Training) : 실시간 파이프라인 트리거를 기반으로 하는 신규 데이터를 사용하여 모델이 Production 단계에서 자동으로 재학습하여 운영에 배포됩니다.
• 실험-운영 균형 : 개발, 실험 환경(pre production), 운영 환경에 배포되는 파이프라인이 동일하여, 실험과 운영에서의 Skew가 없어집니다.
• 컴포넌트들과 파이프라인을 위한 모듈화된 코드 : ML 파이프라인을 만들기 위해 컴포넌트들은 재사용 가능하고, Configure가 가능해야 하며, ML 파이프라인 전반에서 공유 가능해야 합니다. 따라서 EDA 코드 정도를 제외한 그외 컴포넌트는 모듈화 되어야 합니다. (주피터 노트북 형태는 안됨) 또한 이상적으로는 컴포넌트들이 컨테이너화 되는 것이 좋습니다.
  그 이유는 다음과 같습니다.
  • 개발과 운영 환경 모두에서 코드를 재현가능하게 하기 위해서입니다. (도커  컨테이너는 재현성이 높음)
  • 파이프라인의 각 컴포넌트들을 독립적으로 분리하기 위해 컴포넌트들은 각자의 런타임 환경 버전을 가질 수 있으며, 다양한 언어와 라이브러리를 사용할 수 있기 때문입니다.

• 모델의 지속적 배포(Continuous deliver) : Production 환경에 있는 ML 파이프라인은 새로운 데이터가 들어오면 모델을 새로 학습하여 예측 서비스에 지속적으로 배포합니다. 따라서 모델을 예측 서비스로 배포하는 단계가 자동화됩니다.(CD)
• 파이프라인 배포 : 학습된 모델을 예측서비스로 제공하기 위해 자동으로 반복 실행되는 전체 파이프라인을 배포합니다.

 

ML Ops 2단계 : CI/CD 파이프라인 자동화

---

프로덕션 단계에서 파이프라인을 빠르고 안정적으로 업데이트하기 위해 Robust(강건)하고 자동화된 CI/CD 시스템이 필요합니다. 이 자동화된 CI/CD 시스템은 데이터 사이언티스들이 Feature Engineering(파생변수 생성), 모델 아키텍처, 하이퍼 파라미터에 대한 새로운 아이디어를 빠르게 살펴볼 수 있습니다. 그들이 이러한 아이디어를 구현하고 나면, 새롭게 구현된 파이프라인 구성요소를 자동으로 빌드, 테스트, 배포할 수 있습니다.

ML Ops 수준2 : CI/CD 파이프라인 자동화

MLOps 설정에는 다음 구성요소가 포함됩니다.

• Source control
• Test and build services
• Deployment services
• Model registry
• Feature store
• ML metadata store
• ML pipeline orchestrator

 

파이프라인은 다음 단계로 구성됩니다.

1. 개발 및 실험 : 반복적으로 새로운  ML 알고리즘과 새로운 모델링을 실험 단계가 실험해보는데, 이 때 실험 단계의 출력은 ML 파이프라인 각 단계들의 소스 코드이며, 소스 코드는 source repository로 푸시됩니다.
2. 파이프라인 지속적 통합(CI) : 소스 코드를 빌드하고 다양한 테스트를 수행합니다. 이 단계의 결과물은 다음 단계에서 배포될 파이프라인 구성요소(패키지, 실행 파일, artifacts-모델 등의 파이프라인 실행으로 생성된 객체들)입니다.
3. 파이프라인 지속적 배포(CD) : CI 단계에서 생성된 artifacts를 타겟 환경에 배포합니다. 이 단계의 결과물은 모델의 새로운 구현 방법이 반영된 파이프라인으로 이 파이프라인이 배포되는 것입니다.
4. 자동화된 트리거 : 파이프라인은 스케쥴 또는 트리거에 의해 프로덕션 단계에서 자동으로 실행됩니다. 이 단계의 결과물은 Model registry에 푸시되는 학습된 모델입니다. 
5. 모델 지속적 배포 : 학습된 모델을 예측하기 위해 예측 서비스로 서빙합니다. 이 단계의 결과물은 배포된 모델 예측 서비스입니다.
6. 모니터링 : 실시간 데이터를 기반으로 모델 성능에 대한 통계를 수집합니다. 이 단계의 결과물은 파이프라인을 재실행하거나 새로운 실험 사이클을 실행하는 트리거입니다.

데이터 분석 단계는 여전히 수작업으로 이뤄지며 데이터 사이언티스트들이 실허믕ㄹ 새롭게 반복 하기하기 전에 수행하는 작업입니다. 

 

⬛ 지속적 통합 (CI, Continuous integration)

이 셋업에서 파이프라인과 파이프라인의 구성요소는 새로운 코드가 커밋되거나 소스 코드 저장소로 푸시될 때 자동으로 빌드, 테스트, 패키화 됩니다.

CI 프로세스에는 패키지, 컨테이너 이미지, 실행 파일을 빌드하는 것 외에 다음과 같은 테스트가 포함될 수 있습니다.

• Feature Engineering 로직을 단위 테스트합니다.
• 모델에 구현된 다양한 메소드를 단위 테스트합니다.
  (예를 들어 범주형 데이터  컬럼을 받고 원핫 인코딩하는 함수가 있을 수 있습니다.)
• 모델 학습이 수렴하는지 테스트합니다(즉, 모델의 Loss가 학습 Iterations을 거쳐 낮아지고 몇 가지 샘플 데이터를 과적합하는지) 테스트합니다.
• 모델 학습에서 0으로 나누거나 작거나 큰 값을 다루다가 NaN값 을 생성하지 않는지 테스트합니다.
• 파이프라인의 각 구성요소가 예상된 artifacts를 생성하는지 테스트합니다.
• 파이프라인 구성요소 간의 통합을 테스트합니다.

⬛ 지속적 배포 (CD, Continuous delivery)

MLOps 2단계에서 ML 시스템은 새fhdns  파이프라인 구현을 타겟 환경에 지속적으로 배포하여 새롭게 학습된 모델을 이용하는 예측 서비스를 배포합니다. 파이프라인 및 모델의 빠르고 안정적인 지속적 배포를 위해서 다음 사항을 고려해야 합니다.

• 모델을 배포하기 전에 모델과 타겟 인프라의 호환성을 검증해야 합니다.
  (예를 들어 서빙 환경에 모델에 필요한 패키지가 설치되어 있는지, 그리고 메모리, 컴퓨팅, 가속기 리소스가 사용 가능한지 확인해야 합니다.)
• 예상되는 인풋으로 서비스 API를 호출하고 예상되는 응답이 반환되는지 확인함으로써 예측 서비스를 테스트합니다. 이 테스트는 보통 모델 버전을 업데이트하여 인풋데이터의 형태가 바뀔 떄 발생할 수 있는 문제를 잡아냅니다.  해당 버전이 다른 입력을 예상할 때 발생할 수 있는 문제를 포착합니다.
• 예측 서비스 퍼포먼스 테스트를 합니다. 이는 서비스에서 로드 데이터를 해서 초당 쿼리 수(QPS) 및 모델 지연 시간과 같은 측정합니다.
• 재학습이나 배치 예측을 위한 데이터 정합성을 검증합니다.
• 모델이 배포되기 전에 예측 성능 목표를 달성하는지 확인합니다.
• 테스트 환경으로의 자동화된 배포를 고려해야 합니다.
  (예를 들어, 개발 브랜치에 코드를 푸시되었을 때 트리거되는 배포를 의미합니다)
• Pre-Production 환경에 대한 반 자동화된 배포를 고려합니다.
  (예를 들어, 리뷰어들이 변경사항을 승인한 후 코드를 메인 브랜치로 머지함에 따라 트리거된 배포를 의미합니다.)
• Pre-Production 환경에서 파이프라인이 여러 번 성공적으로 동작함을 확인한 후에 프로덕션 환경에 수동으로 배포하는 것을 고려합니다.

 

 

참고자료 :
1) https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

MLOps: 머신러닝의 지속적 배포 및 자동화 파이프라인  |  클라우드 아키텍처 센터  |  Google Cloud