MLOps 이란?

Intro

 ML 프로젝트 진행 중에 지속적으로 나왔던 MLOps 이론에 대하여 정리의 필요성을 느끼고 내용을 한번 공부하고 정리하는 차원에서 글을 작성을 하겠다.

 

 먼저 MLOps 라는 개념이 언급되었던 이유는 ML 분야에서 데이터를 정제하고 모델을 학습시키고 그리고 그 모델을 평가, 배포하는 이런 일련의 과정이 생각보다 많은 분야이 사람들과 그리고 시간, 인력 등 많은 작업들을 필요로 한다. 그래서 이런 과정들을 하나의 파이프라인을 구조화하여 빠르고 단순하게 ML을 구현이 가능할까? 하는 물음에서 이 개념이 언급이 되었다.

MLOps란

 이전에 미리 존재하는 DevOps(Software Devdlopment and IT Operation)이론과 비슷한 개념으로 MLOps(Machine Learning Operations)는 머신러닝 개발과 관리를 한 번에 하는 작업을 하는 개념이다.

 

  여기서는 단순이 ML에서 머신러닝 모델을 학습하고 배포하는 작업만 포함하는 게 아니라 데이터를 수집하고 분석하는 단계, 그리고 모델을 학습하고 배포하는 단계까지 모든 ML 프로세스의 전 과정을 담고 있다. 어떻게 보면 데이터 분석, 모델 학습, 평가, 전처리, 모니터링을 한 번에 수행을 자동으로 한다고 이해하면 편하다.

 

MLOps에서 이런 과정들을 하나하나 용어로 칭하여 지정을 하였다.

-머신러닝(ML: Machine Learning)
-시스템관리(CI: Continuous Integration)
-지속적 배포(CD: Continuous Delivery)
-지속적 학습(CT: Continuous Training)

이런 과정들을 자동화 시키는게 MLOps의 목적이라고 할 수 있다.

MLOps 0단계 프로세스: 수동 프로세스

출처: https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

위의 사진처럼 이런 과정들을 ML, Data 분야의 사람이 수동으로 학습과 분석을 진행하고 완전히 수동으로 배포를 진행을 한다.

특성

-수동, 스크립트 기반, 양방향 프로세스: 데이터 분석, 데이터 준비, 모델 학습, 모델 검증을 포함한 모든 단계가 수동이다.. 각 단계를 수동으로 실행하고, 한 단계에서 다른 단계로 수동 전환해야 한다. 이 프로세스는 일반적으로 작업 가능한 모델이 생성될 때까지 데이터 과학자가 노트북에서 작성하고 실행하는 실험 코드에 의해 이루어진다.

 

-ML과 작업 간 연결 해제: 이 프로세스는 모델을 만드는 데이터 과학자와 모델을 예측 서비스로 제공하는 엔지니어를 분리한다. 데이터 과학자는 엔지니어링팀에 학습된 모델을 아티팩트로 전달하여 API 인프라에 배포한다. 이 전달에는 학습된 모델을 스토리지 위치에 배치하거나, 모델 객체를 코드 저장소에 확인하거나, 모델 레지스트리에 업로드하는 작업이 포함될 수 있다. 그런 다음 모델을 배포하는 엔지니어는 짧은 지연 시간을 제공하기 위해 필요한 기능을 프로덕션 단계에서 사용할 수 있도록 해야 한다. 이를 통해 학습-제공 편향이 발생할 수 있다.

 

-간헐적인 출시 반복: 데이터 프로세스는 데이터 과학팀이 모델 구현을 변경하거나 새 데이터로 모델을 재학습 시키는 등 자주 변경되지 않는 몇 가지 모델을 관리한다고 가정한다. 새 모델 버전은 1년에 두어 번만 배포된다.

 

-CI 없음: 구현 변경사항이 거의 없으므로 CI가 무시된다. 일반적으로 코드 테스트는 메모장 또는 스크립트 실행의 일부이다. 실험 단계를 구현하는 스크립트와 메모장은 소스로 제어되며 학습된 모델, 평가 측정항목, 시각화와 같은 아티팩트를 생성한다.

 

-CD 없음: 모델 버전이 자주 배포되지 않으므로 CD는 고려되지 않는다.

 

-예측 서비스를 의미하는 배포: 이 프로세스는 전체 ML 시스템을 배포하는 대신 예측 서비스(예: REST API가 포함된 마이크로 서비스)로 학습된 모델을 배포하는 것과 관련이 있다.

 

-활성 성능 모니터링 부족: 프로세스가 모델 성능 저하 및 기타 모델 동작 드리프트를 감지하는 데 필요한 모델 예측 및 작업을 추적하거나 로깅하지 않는다.

도전과제

0 단계 프로세스에서 반드시 해결해야하고 그리고 한계점은 모델의 거의 변경되지 않거나 학습되지 않는 경우에는 이 수동적인 방식이 적절할 수 있지만 실제 환경에서 모델을 적용시키면 항상 일정한 상황만 존재하는 게 아니다. 그래서 모델의 배포 단계에서 모델이 정상적으로 작동하지 않을 수 있다.

 

그렇다면 이런 단계에서 정확성을 유지하기 위해서는 해야하는 과정은 3가지 정도가 있다.

 

-프로덕션 단계에서 적극적으로 모델 품질 모니터링: 품질을 모니터링하면 성능 저하 및 모델 비활성을 감지할 수 있다. 이는 새로운 실험 반복 및 새 데이터에 대한 모델 재학습(수동)의 단서 역할을 한다.

 

-프로덕션 모델 자주 재학습: 진화하고 새로운 패턴을 포착하려면 최신 데이터로 모델을 재학습 시켜야 한다. 예를 들어 앱에서 ML을 사용하여 패션 제품을 추천하는 경우 추천은 최신 트렌드와 제품에 맞게 조정되어야 한다.

 

-모델을 생성하기 위한 새로운 구현을 지속적으로 실험: 최신 아이디어와 기술의 발전을 활용하려면 특성 추출, 모델 아키텍처, 초매개변수 등의 새로운 구현을 시도해야 한다. 예를 들어 얼굴 인식에 컴퓨터 비전을 사용하는 경우 얼굴 패턴은 고정되지만, 더 나은 새로운 기술을 사용하여 감지 정확도를 향상할 수 있다.

MLOps 1단계 프로세스: ML 파이프라인 자동화

1단계 프로세스의 목적은 ML 파이프라인을 자동화하여 모델을 지속적으로 학습시키는 것이다. 이를 통해 모델 예측하는 서비스를 지속적으로 제공하면 변하는 상황에서 모델을 학습시켜 환경에 다른 상황에서 모델을 학습을 시키는게 가능하다. 여기 단계에서 이제 모델을 새 데이터를 가지고 재학습 시키는 프로세스와 이밖에 파이프라인 트리거 및 메타데이터 관리뿐만 아니라 자동화된 데이터 및 모델 검증 단계를 파이프라인에 도입을 해야 한다.

출처: https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

위의 그림은 CT용 자동화된 ML 파이프라인을 보여준다.

특성

-빠른 실험: ML 실험 단계가 조정됩니다. 단계 간 전환은 자동으로 이루어지므로 실험을 빠르게 반복하고, 전체 파이프라인을 프로덕션으로 더 빠르게 이동할 수 있다.

 

-프로덕션 단계에서 모델의 CT: 다음 섹션에서 설명하는 실시간 파이프라인 트리거를 기반으로 하는 새로운 데이터를 사용하여 모델이 프로덕션 단계에서 자동으로 학습된다.

 

-실험-운영 균형: 개발 또는 실험 환경에서 사용되는 파이프라인 구현은 사전 프로덕션 및 프로덕션 환경에서 사용되며, 이는 DevOps 통합을 위한 MLOps 방식에 있어 핵심적인 요소이다.

 

-구성요소 및 파이프라인의 모듈화 된 코드:  ML 파이프라인을 구성하려면 ML 파이프라인 전체에서 구성요소를 재사용, 구성, 공유할 수                                                                      있어야 한다. 따라서 EDA 코드는 여전히 메모장에 있을 수 있지만 구성요소의 소스 코드는 모                                                                     듈화 되어야 합니다. 또한 구성요소를 컨테이너 화하여 다음을 수행하는 것이 좋다.

 

-모델의 지속적 배포: 프로덕션 단계의 ML 파이프라인은 새 데이터로 학습된 새 모델에 예측 서비스를 지속적으로 배포한다. 학습 및 검증된 모델을 온라인 예측용 예측 서비스로 제공하는 모델 배포 단계가 자동화된다.

 

-파이프라인 배포: 수준 0에서는 학습된 모델을 프로덕션에 예측 서비스로 배포한다. 수준 1의 경우, 학습된 모델을 예측 서비스로 제공하기 위해 자동으로 반복 실행되는 전체 학습 파이프라인을 배포한다.

추가 구성요소

1단계 프로세스에서 중요하게 새로 생기는 구성요소에 대하여 설명을 하겠다.

 

1.데이터 및 모델 유효성 검사

이 단계에서 ML 파이프라인 트리거 중 하나 이상이 자동으로 파이프라인을 실행을 해야 한다. 여기서 실시간으로 데이터를 받아서 새로운 모델을 학습시켜 새로운 버전의 모델을 생성되어야 한다. 이런 단계를 평가하기 위해서 파이프라인은 자동화된 데이터 검증 및 모델을 검증을 해야한다.

• 데이터 검증 : 모델 학습 전에 모델을 재학습할지 또는 파이프라인 실행을 중지할지 결정하는 데 필요
• 데이터 스키마 편향: 데이터 처리 및 모델 학습을 포함한 다운스트림 파이프라인 단계가 예상 스키마를 준수하지 않는 데이터를 수신한다. 이 경우 데이터 과학팀이 조사할 수 있도록 파이프라인을 중지해야 한다. - 데이터 값 편향 : 입력 데이터의 이상을 편향성으로 간주. 파이프라인을 중지시킨다. 또한 이런 사항을 파이프라인에 대한 수정 또는 업 데이트를 해야 한다.
• 모델 검증: 새 데이터가 제동 된 모델을 학습시킨 후에 발생하는 단계로 모델을 평가한다.

2.특성 저장소

 

특성 저장소에서는 최신 특성 값을 제공하며 그리고 메타데이터를 유지하는 역할을 한다. 이런 특성을 가지고 있어서 새로운 학습을 할 때 필요한 데이터를 유지하고 관리하는 구성요소인 특성 저장소가 반드시 필요하다.

 

3.메타 데이터 관리

 

ML 파이프라인의 각 실행에 대한 정보는 데이터 및 아티팩트 계보, 재현성, 비교를 돕기 위해 기록되며, 오류와 이상을 디버깅하는 데도 도움이 된다. 파이프라인을 실행할 때마다 ML 메타데이터 저장소는 다음과 같은 메타데이터를 기록한다.

 

 

4.ML 파이프라인 트리거

사용자의 사용 사례에 따라 ML 프로덕션 파이프라인을 자동화하여 새로운 데이터로 모델을 재학습 시킬 수 있다.

-요청 시: 파이프라인의 임시 수동 실행된다.

 

-일정 기준: 라벨이 지정된 새 데이터는 매일, 매주 또는 매월 ML 시스템에 시스템적으로 사용할 수 있다. 재학습 빈도는 데이터 패턴의 변경 빈도와 모델 재학습 비용에 따라 달라진다.

 

-새 학습 데이터의 가용성 기준: 새 데이터는 시스템적으로 ML 시스템에서 사용할 수 없으며 대신 새 데이터가 수집되어 소스 데이터베이스에서 사용할 수 있게 된 경우 임시로 사용할 수 있다.

 

-모델 성능 저하 시: 성능 저하가 눈에 띄는 경우 모델이 재학습 된다.

 

-데이터 분포의 중요한 변화 시(개념 드리프트). 온라인 모델의 전체 성능을 평가하기는 어렵지만 예측을 수행하는 데 사용되는 특성의 데이터 분포에 큰 변화가 있다. 이러한 변경사항은 모델이 오래되어 새로운 데이터로 재학습 되어야 함을 나타낸다.

도전과제

 파이프라인의 새 구현이 자주 배포되지 않고 몇 개의 파이프라인만 관리한다고 가정한다. 이 경우 일반적으로 파이프라인과 구성요소를 수동으로 테스트한다. 또한 새 파이프라인 구현을 수동으로 배포하며, 파이프라인을 대상 환경에 배포하기 위해 파이프라인의 테스트된 소스 코드를 IT팀에 제출한다. 이 설정은 새 ML 아이디어가 아닌 새 데이터 기반의 새 모델을 배포할 때 적합하다.

 

 하지만 새 ML 아이디어를 시도해야 하고 ML 구성요소의 새 구현을 빠르게 배포해야 한다. 프로덕션 단계에서 여러 ML 파이프라인을 관리하는 경우 ML 파이프라인의 빌드, 테스트, 배포를 자동화하기 위한 CI/CD 설정이 필요하다.

MLOps 2단계 프로세스: CI/CD 파이프라인 자동화

출처 : https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

마지막으로 2단계 단계에서는 CI, CD 단계를 자동화하는 단계이다 이는 빠르고 안정적인 업데이트를 하기 위해서는 반드시 필요하다. 위의 사진이 자동화된 ML 파이프라인과 자동화된 CI/CD 루틴의 특성을 가진 방식을 나타낸다.

특성

 

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

1. 개발 및 실험: 새 ML 알고리즘과 실험 단계가 조정되는 새 모델링을 반복적으로 시도한다. 이 단계의 출력은 ML 파이프라인 단계의 소스 코드이며, 소스 코드는 소스 저장소로 푸시된다.
2. 파이프라인 지속적 통합: 소스 코드를 빌드하고 다양한 테스트를 실행한다. 이 단계의 출력은 이후 단계에서 배포될 파이프라인 구성요소(패키지, 실행 파일, 아티팩트)이다.
3. 파이프라인 지속적 배포: CI 단계에서 생성된 아티팩트를 대상 환경에 배포한다. 이 단계의 출력은 모델의 새 구현이 포함되는, 배포된 파이프라인이다.
4. 자동화된 트리거: 파이프라인은 일정 또는 트리거에 대한 응답에 따라 프로덕션 단계에서 자동으로 실행된다. 이 단계의 출력은 모델 레지스트리로 푸시되는 학습된 모델이다.
5. 모델 지속적 배포: 학습된 모델을 예측의 예측 서비스로 제공한다. 이 단계의 출력은 배포된 모델 예측 서비스이다.
6. 모니터링: 실시간 데이터를 기반으로 모델 성능의 통계를 수집한다. 이 단계의 출력은 파이프라인을 실행하거나 새 실험 주기를 실행하는 트리거이다.

데이터 분석 단계는 파이프라인이 새 반복의 실험을 시작하기 전에 데이터 과학자가 수행하는 수동 프로세스이다. 모델 분석 단계 또한 수동 프로세스이다.

지속적 통합

이 설정에서 파이프라인과 구성요소는 새 코드가 커밋되거나 소스 코드 저장소로 푸시될 때 빌드, 테스트, 패키징 된다. CI 프로세스에는 패키지, 컨테이너 이미지, 실행 파일을 빌드하는 것 외에 다음과 같은 테스트가 포함될 수 있다.

• 특성 추출 로직을 단위 테스트한다.
• 모델에 구현된 다양한 메서드를 단위 테스트한다. 예를 들어 범주형 데이터 열을 허용하는 함수가 있다면 이 함수를 원-핫 특성으로 인코딩한다.
• 모델 학습이 수렴하는지 테스트한다(즉, 모델의 손실이 반복으로 인해 중단되고 몇 가지 샘플 레코드를 과적합함).
• 모델 학습에서 0으로 나누거나 작은 값 또는 큰 값을 조작하여 NaN 값을 생성하지 않는지 테스트한다.
• 파이프라인의 각 구성요소가 예상 아티팩트를 생성하는지 테스트한다.
• 파이프라인 구성요소 간의 통합을 테스트한다.

지속적 배포

이 수준에서 시스템은 새 파이프라인 구현을 대상 환경에 지속적으로 배포하여 새로 학습된 모델의 예측 서비스를 전달한다. 파이프라인 및 모델의 빠르고 안정적인 지속적 배포를 위해서 다음 사항을 고려해야 한다.

• 모델을 배포하기 전에 모델과 대상 인프라의 호환성을 확인한다. 예를 들어 모델에 필요한 패키지가 제공하는 환경에 설치되어 있는지, 그리고 메모리, 컴퓨팅, 가속기 리소스가 사용 가능한지 확인해야 한다.
• 예상되는 입력으로 서비스 API를 호출하고 응답이 예상하는 응답을 가져오도록 하여 예측 서비스를 테스트한다. 이 테스트는 일반적으로 모델 버전을 업데이트하고 해당 버전이 다른 입력을 예상할 때 발생할 수 있는 문제를 포착한다.
• 초당 쿼리 수(QPS). 및 모델 지연 시간과 같은 측정항목을 포착하기 위한 서비스 부하 테스트가 포함된 예측 서비스 성능 테스트
• 재학습 또는 일괄 예측을 위한 데이터 유효성 검사
• 모델이 배포되기 전에 예측 성능 목표를 충족하는지 확인
• 테스트 환경에 대한 자동 배포(예: 개발 분기에 코드를 푸시하여 트리거 된 배포)
• 사전 프로덕션 환경에 대한 반자동 배포(예: 검토자가 변경사항을 승인한 후 기본 분기에 코드를 병합하여 트리거된 배포)
• 사전 프로덕션 환경에서 여러 번의 성공적인 파이프라인 실행 후에 프로덕션 환경에 대한 수동 배포

요약하자면 프로덕션 환경에서 ML을 구현한다고 해서 모델이 예측용 API로 배포되는 것은 아니다. 대신 새 모델의 재학습 및 배포를 자동화할 수 있는 ML 파이프라인 배포를 의미한다. CI/CD 시스템을 설정하면 새로운 파이프라인 구현을 자동으로 테스트하고 배포할 수 있으며, 이 시스템을 사용하면 데이터 및 비즈니스 환경의 빠른 변화에 대처할 수 있다. 모든 프로세스를 한 수준에서 다른 수준으로 즉시 이동할 필요는 없다. 이러한 방식을 점진적으로 구현하여 ML 시스템 개발 및 프로덕션의 자동화를 개선할 수 있다.