[MLOps] [번역] Continuous delivery and automation pipelines in machine learning (5) MLOps level 1: ML pipeline automation

안녕하세요! 선한 데이터 과학자를 꿈꾸는 헤일리입니다!🥰
어제는 올리지 못했지만, 오늘은 계속해서 Google에서 2019년에 MLOps Best Practice에 대해 작성한 MLOps: Continuous delivery and automation pipelines in machine learning 을 번역하도록 할게요.

제가 계속하여 강조하지만, 원문에서 언어 설정을 변경하시면 (또는 이미 언어 설정이 되어 있으시면) 한국어로 보이실 거에요! 따라서, 이 글은 제가 스스로 정리해보고자 하는 목적이 좀더 강한 번역글입니다! 약간의 의역이 있을 수 있으며, 말미에 저의 소감과 요약문을 첨부하니 궁금하시면 참고해주세요~:)

지난 시간에는...

ML을 도입하는 많은 기업들에 가장 흔하게 보이는 MLOps 수준 0에 대해서 알아보았는데요. ML 모델을 데이터 사이언티스트들이 주피터 노트북 등의 인터랙티브한 환경에서 개발하고, 학습된 모델 파일을 배포 담당자인 엔지니어에게 전달하면 엔지니어가 배포하는 방식입니다. 엔지니어가 배포를 위해 저지연 실시간으로 제공가능한 형태로 변수를 다시 만들기도 하여, 이로 인해 학습-서빙 간 불일치가 일어나기도 합니다. 수준 0은 모델을 업데이트 하는 주기가 빈번하지 않고, 모델 개수가 적을 때는 충분할 수도 있지만 모델을 새로운 데이터나 새로운 구현방법에 맞게 자주 업데이트 하기에는 적합하지 않습니다.

오늘은 "ML 파이프라인 배포"를 통해 자동화된 모델 재학습이 가능하게 한, 그래서 데이터가 업데이트 됨에 따른 모델 재학습을 빠르게 할 수 있도록 한, MLOps 수준 1에 대해서 번역하려고 합니다! 시작해볼게요~ 😊

---

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

수준 1의 목표는 ML 파이프라인을 자동화 함으로써 모델의 continuous training (지속적 학습)을 하고자 함입니다; 이를 통해 모델 예측 서비스의 continuous delivery(지속적 배포)가 가능해지지요. 운영 환경에서 새로운 데이터를 가지고 모델을 재학습하는 과정을 자동화 하기 위해서는 파이프라인 트리거와 메타 데이터 관리와 더불어, 파이프라인에 자동화된 데이터와 모델 검증 단계가 도입되어야 합니다.
아래 그림은 CT를 위해 자동화된 ML 파이프라인을 스키마 형태로 나타내었습니다.

그림 3. CT를 위한 ML 파이프라인 자동화

특징

아래 리스트는 그림 3에 보이는 MLOps 수준 1 설정의 특징들을 설명합니다.

• 빠른 실험: ML 실험을 위한 단계들이 조율(orchestrate)되어 있습니다. 단계 간의 전환이 자동화 되어 있어서, 실험을 빠르게 반복할 수 있고 전체 파이프라인을 운영에 옮길 준비를 더 잘 할 수 있게 합니다.
• 운영 환경에 배포된 모델의 CT: 실시간 파이프라인 트리거에 기반하여 운영 환경의 배포 모델이 신규 데이터로 자동으로 학습됩니다. 실시간 파이프라인 트리거는 다음 섹션에서 이야기합니다.
• 실험-운영 일치: 개발 또는 실험 환경에서 쓰이는 파이프라인 구현체가 사전 운영(pre production)과 운영 환경에 쓰입니다. 이것은 Dev와 Ops를 통합하는데 주요한 MLOps 프랙티스의 측면입니다.
• 컴포넌트들과 파이프라인을 위한 모듈화된 코드: ML 파이프라인을 만들기 위해, 컴포넌트들은 재사용 가능해야 하고, 구성 가능해야 하며, 가능하면 ML 파이프라인 전반에서 공유 가능해야 합니다. 그렇기에, EDA (탐색적 데이터 분석) 코드 정도는 노트북에 있어도 괜찮을 수 있지만, 컴포넌트들을 위한 소스코드는 모듈화 되어야 합니다. 또한, 이상적으로는 컴포넌트들이 컨테이너화 되어야 하며, 그 이유는 다음 때문입니다:
  - 실행 환경과 커스텀 코드 런타임을 분리하기 위해서
  • 코드가 개발과 운영 환경 모두에서 재현가능하게 하기 위해서
  • 파이프라인의 각 컴포넌트들을 독립적으로 분리하기 위해서. 컴포넌트들은 그들 각자의 런타임 환경 버전을 가질 수 있으며, 다른 언어와 라이브러리를 사용할 수 있다.
• 모델의 지속적 배포 (Continuous delivery): 운영환경에 있는 ML 파이프라인은 새로운 데이터에 학습된 새로운 모델을 예측 서비스에 지속적으로 배포합니다. 학습되고 검증된 모델을 실시간 예측을 위해 예측 서비스로 전달하는 모델 배포 단계가 자동화 됩니다.
• 파이프라인 배포: 수준 0 에서는 운영환경에 학습된 모델을 예측 서비스로써 배포합니다. 수준 1에서는, 전체 학습 파이프라인을 배포하며, 이 파이프라인이 학습된 모델을 예측 서비스로 서빙하기 위해서 자동적이고 반복적으로 작동합니다.

추가적인 컴포넌트들

이 섹션은 ML 의 지속적 학습(CT)를 가능하게 하기 위해 아키텍쳐에 추가해야 하는 컴포넌트들에 대해서 다룹니다.

데이터 및 모델 검증

ML 파이프라인을 운영으로 배포할 때, 아래 나올 ML 파이프라인 트리거 섹션에서 이야기되는 하나 이상의 트리거가 자동으로 파이프라인을 실행한다. 이 파이프라인은 새로운, 실제 데이터가 들어오면 이를 가지고 학습된 새로운 모델 버전이 만들어 질 것이라고 예상한다. 그러므로 자동화된 데이터 검증과 모델 검증 단계가 운영에 배포될 파이프라인에 필요한데, 이는 파이프라인이 다음과 같이 예상대로 작동하게 하기 위함이다:

• 데이터 검증: 이 단계는 모델을 학습 하기 전에 모델을 재학습 해야 할지 또는 파이프라인의 실행을 멈춰야 할지를 결정하기 위해 필요합니다. 이 결정은 파이프라인이 다음을 식별할 경우에 자동적으로 이뤄집니다:
  - 데이터 스키마 왜곡: 이러한 왜곡은 입력 데이터에 이상치가 있음을 말하고, 이것은 입력데이터를 받아 진행되는 데이터 전처리나 모델 학습과 같은 이어질 파이프라인 단계들이 예상되는 스키마에 맞지 않는 데이터를 받게 된다는 것을 의미합니다. 이 경우, 파이프라인을 멈춰서 데이터 사이언스 팀이 조사할 수 있도록 해야 합니다. 이 데이터 사이언스 팀은 스키마에 있는 이러한 변화들을 다루기 위해서 파이프라인 수정이나 업데이트를 릴리즈 할 수도 있습니다. 스키마 왜곡의 예시에는 예상치 못한 변수를 받거나, 예상한 변수 중에 빠진 변수가 있거나, 변수 값이 예상 범위를 벗어나는 경우가 있습니다.
  • 데이터 값 왜곡: 이러한 왜곡은 데이터의 통계적인 특징에 유의미한 변화가 있는 경우입니다. 이는 데이터 패턴이 변화하고 있다는 것을 의미하고, 이러한 변화들을 모델에 반영하기 위해 모델 재학습을 트리거 해야 합니다.
• 모델 검증: 이 단계는 새로운 데이터가 주어져서 모델을 성공적으로 학습한 이후에 이뤄집니다. 모델이 운영 환경에 배포되도록 격사오디기 전에 모델을 평가하고 검증해야 합니다. 이 오프라인 모델 검증 단계는 다음으로 구성되어 있습니다.
  - 모델의 예측 품질을 가늠하기 위하여 테스트 데이터셋에 학습된 모델을 이용해서 평가 지표 값을 만듭니다.
  • 새롭게 생성된 학습모델의 평가 지표를 현재 모델, 예를 들면 현재 운영 환경에 배포된 모델, 베이스라인 모델, 또는 다른 비즈니스 요구사항 모델의 평가지표와 비교합니다. 새롭게 학습된 모델을 운영 환경 배포용으로 격상 시키기 전에, 새 모델이 현재 모델보다 좋은 성능을 낸다는 것을 확인합니다.
  • 모델의 성능이 데이터의 다양한 세그먼트에 일관되는지를 확인합니다. 예를 들면, 새롭게 학습한 소비자 이탈 모델이 이전 모델에 비해 전반적인 예측 정확도는 더 높을 수 있지만, 소비자의 지역별 정확도의 분산은 더 클 수 있습니다.
  • 인프라와의 호환성과 예측 서비스 API 와의 일관성 등 모델이 배포 가능한지 꼭 테스트합니다.

카나리 배포나 A/B 테스팅 셋업의 경우에, 새롭게 배포된 모델은 실시간 트래픽에 완전히 배포 되기 전에 오프라인 모델 검증 뿐 아니라 온라인 모델 검증도 거칩니다.

피처 저장소

수준 1 ML 파이프라인 자동화에 옵셔널한 추가적인 컴포넌트는 피처(변수) 저장소 입니다. 피처 저장소란 학습과 서빙을 위해 피처들의 정의, 저장, 접근을 표준화한 중앙 저장소 입니다. 피처 스토어는 피처 값들을 처리량이 많은 배치 서빙과 저지연 실시간 서빙을 모두 할 수 있는 API 를 제공해야 하며, 학습과 서빙 부하를 모두 지원할 수 있어야 합니다.
피처 스토어는 데이터 사이언티스트들이 다음의 것들을 할 수 있게 돕습니다:

• 동일하거나 비슷한 피처를 만들지 않고 가용한 피처 셋을 확인하고 재사용할 수 있습니다.
• 피처 및 그들에 대한 메타데이터를 관리함으로써 다른 정의를 가진 비슷한 피처를 사용하는 것을 피할 수 있습니다.
• 최신화된 피처 값들을 제공할 수 있습니다.
• 피처 저장소를 실험, 지속적 학습(continuous training), 실시간 서빙의 데이터 원천으로 사용함으로써 학습-서빙 불균형을 피할 수 있습니다. 이 접근은 학습에 사용된 피처들이 서빙에 사용되는 피처들과 동일한 것들임을 확실시 할 수 있습니다:
  - 실험을 위해서, 데이터 사이언티스트들은 피처 저장소로부터 피처를 파일로 추출하여 실험을 진행합니다.
  • 지속적 학습을 위해서, 자동화된 ML 학습 파이프라인은 학습 업무에 사용되는 데이터의 최신화된 피처 값 배치를 가져올 수 있습니다.
  • 실시간 예측을 위해서, 예측 서비스는 요청된 엔티티 예를 들면 소비자 인구통계학적 변수, 제품 변수, 또는 현재 세션 종합 변수 등과 관련된 피처 값들의 배치를 가져올 수 있습니다.

메타데이터 관리

ML 파이프라인의 각 실행에 대한 정보는 기록되며, 이는 데이터 및 아티팩트(파이프라인 결과물. 예를 들면 모델) 계보, 결과 재현, 비교를 쉽게 하기 위함이다. 파이프라인 실행을 기록하는 것은 에러와 이상을 디버깅하는데도 도움이 된다. 파이프라인을 구동할 때마다, ML 메타데이터 저장소는 아래와 같은 메타 데이터를 기록한다:

• 실행된 파이프라인과 컴포넌트 버전들
• 실행 시작 및 종료 일시와 파이프라인이 각 단계를 실행하는데 얼마나 시간이 걸렸는지
• 파이프라인의 실행 주체
• 파이프라인에 전달된 파라미터 값
• 파이프라인 각 단계에 생성된 아티팩트에 대한 경로나 정보, 예를 들면 준비된 데이터의 위치, 검증 시의 이상, 계산된 통계량, 범주형 변수에서 추출된 vocabulary (발생한 모든 범주 리스트). 이러한 중간 결과물을 추적하면, 파이프라인이 특정 단계에서의 실패 때문에 멈췄을 경우에 이미 완료된 단계들을 재수행 할 필요 없이 가장 최근의 단계부터 이어서 파이프라인을 실행할 수 있도록 합니다.
• 이전의 학습 모델에 대한 경로나 정보. 이는 이전 모델 버전으로 롤백을 해야 하거나, 파이프라인에 모델 검증 단계에서 새로운 테스트 데이터가 주어졌을 때 이전 모델 버전에 대한 평가 지표를 계산해야 할 때 쓰입니다.
• 학습과 테스트 셋에 대해서 모델 평가 단계에서 계산한 모델 평가 지표들. 이 평가 지표들은 모델 검증 단계에서 새롭게 학습된 모델의 성능과 이전에 학습한 모델에 대해 기록된 성능을 비교할 수 있게 합니다.

ML 파이프라인 트리거

아래 유스케이스마다 적합한 방식으로 ML 운영 파이프라인이 새로운 데이터로 모델을 재학습 하도록 자동화 할 수 있습니다.

• 온디맨드: 필요할 때 Ad-hoc 방식으로 수동으로 실행
• 스케쥴에 따라: 새로운, 라벨링이 완료된 데이터가 ML 시스템에 매일, 매주, 또는 매달 체계적으로 전달됩니다. 재학습 빈도는 데이터의 패턴이 얼마 자주 바뀌는지 또 모델을 재학습하는 것이 얼마나 비용이 드는지에 따라 결정됩니다.
• 새로운 학습 데이터가 있을 때: 새로운 데이터는 ML 시스템에 규칙적으로 제공되지 않고, 새로운 데이터가 수집되고 원천 데이터베이스에 쌓일 때 ad-hoc 방식으로 제공됩니다.
• 모델 성능 하락에 따라: 모델은 눈에 띄는 성능 하락이 있을 때 재학습 됩니다.
• 데이터 분포에 유의미한 변화가 있을 떄: 실시간 모델의 성능을 완전히 가늠하기는 어렵지만, 예측을 하기 위해 쓰이는 변수들의 데이터 분포에 유의미한 변화가 있는지는 알아 차리게 됩니다. 이러한 변화들은 모델이 이제 더이상 데이터에 맞지 않음을 의미하고, 최신 데이터로 재학습 되어야 함을 의미합니다.

도전적인 부분들

파이프라인에 대한 새로운 구현체가 자주 배포되지 않는다고 가정을 하고, 파이프라인을 몇개만 관리한다고 가정하면, 파이프라인과 그 컴포넌트들을 보통 수동으로 테스트 합니다. 또한, 새로운 파이프라인 구현체를 수동으로 배포합니다. 또한 테스트가 완료된 소스코드를 IT 팀에 제출하여 원하는 환경으로 배포되도록 합니다. 이러한 셋업은 새로운 데이터가 들어왔기 때문에 모델을 업데이트 하는 경우에는 적합하지만, 새로운 ML 아이디어가 있어서 업데이트 하는 경우에는 맞지 않습니다.
그러나, 새로운 ML 아이디어들을 시도해보고 ML 컴포넌트들을 새롭게 구현해서 빠르게 배포하는 것이 필요합니다. 많은 ML 파이프라인을 운영환경에서 관리한다면, ML 파이프라인들의 빌드, 테스트, 배포를 자동화하기 위해서 CI/CD 셋업이 필요합니다.

---

요약

모델에 대한 배포 뿐 아니라, 모델을 학습하는 ML 파이프라인 자체를 배포한다면 MLOps 수준0에서 1이 된 것이다. 이 단계에서 주된 용례는 데이터가 변화하여서 새로운 데이터로 ML 파이프라인을 재실행해서 모델을 재학습, 배포하는 경우이다. (ML 모델을 바꿔서 코드가 바뀌어야 하는 경우는 수준2에서 다룬다.) 데이터에 의해 자동으로 트리거되어 파이프라인이 실행되어야 하며, 파이프라인에서 받아오는 데이터에 대한 정합성(변수가 모두 있는지, 새로운 변수가 추가됐는지, 변수 값이 달라졌는지) 체크와 저장된 모델에 대한 정합성 체크 (모델 전반적 성능, 세그먼트별 성능, 현재모델과의 성능 비교, 배포가능한 상태인지 체크)를 자동화해야 한다. 또한, 옵셔널하게는 피처 저장소도 도입해서, 학습/운영 환경 모두에서 같은 피처 저장소에서 변수 데이터를 가져오게 할 수 있고 또한 필수적으로 메타 데이터 저장소를 만들어서 파이프라인 실행결과 (버전, 파라미터, 수행시간, 중간 결과물 경로, 학습 모델 경로, 학습 모델 성능 지표)를 저장해놓아 결과 재현, 원천 추적, 디버깅, 오류 시 최근 컴포넌트부터 재수행, 롤백 등을 쉽게 할 수 있다.

소감

요즘 Fast campus에서 MLOps 강의를 듣고 있는데, 많은 오픈소스들을 다루지만 그 요소들이 어디에 쓰이고 왜 배워야 하는지에 대해서 잘 이해하지 못하고 파편적으로만 오픈소스들을 배워오고 있었는데요. 오늘 글을 읽으면서 퍼즐이 좀 맞춰지는 느낌이었습니다. 현재까지 들은 진도에서는 Data and Model Management, Model Serving, Model Monitoring 까지를 다뤘는데 이후에 Feature Store에 대해서도 다루게 된다고 들었고, Kubeflow도 곧 다룰 것같아 파이프라인의 "구현체"라는 것이 어떤 모습인지 지금은 굉장히 추상적인지 좀더 감이 올 것 같습니다. (순서가 지정된 Kubernetes Pods?) 오늘은 좀 급하게 번역했는데 ㅠㅠ 다시 돌아와서 찬찬히 번역한 것들 살펴보며 되새겨야 할거같아요! 다음시간에 Level2로 돌아올게요!

감사합니다! :) 다음시간에 만나요~