• Google Cloud Platform의 MLOps: Continuous delivery and automation pipelines in machine learning을 번역한 글입니다
  • 키워드 : CI/CD in Machine Learning, Continuous delivery and automation pipelines in machine learning, Continuous integration in Machine Learning, 머신러닝의 지속적인 배포와 지속적 통합, 자동화된 파이프라인

---

MLOps: Continuous delivery and automation pipelines in machine learning

이 문서는 머신러닝 시스템을 위한 Continuous Integration(CI), Continuous Delivery(CD), Continuous Training(CT)를 구현하고 자동화하는 기술에 대해 설명한다.

데이터 사이언스 및 ML은 복잡한 현실의 문제를 해결하고, 산업에 적용하며 모든 도메인에서 가치를 제공하는 핵심 능력이 되고 있다. 현재 효과적인 ML을 적용하기 위해 사용할 수 있는 재료들은 다음과 같다.

• 거대한 데이터세트
• 저렴한 on-demand 컴퓨팅 리소스
• 다양한 클라우드 플랫폼의 ML을 위한 전용 도구
• 다양한 ML 연구 분야의 빠른 발전
  • 컴퓨터 비전, 자연어 이해, 추천 시스템 등

따라서 많은 비즈니스가 데이터 사이언스 팀 및 ML 능력에 투자해 고객에게 비즈니스 가치를 제공할 수 있는 예측 모델을 개발하고 있다.

이 문서는 DevOps 원칙을 ML 시스템(MLOps)에 적용하려는 데이터 과학자 및 ML 엔지니어를 위한 문서다. MLOps는 ML 시스템 개발(Dev) 및 ML 시스템 운영(Ops)을 통합하는 것을 목표로 하는 ML 엔지니어링 문화와 관행이다. MLOps를 한다는 것은 통합, 테스트, 릴리즈, 배포 및 인프라 관리를 포함한 ML 시스템 구축의 모든 단계에서 자동화 및 모니터링을 해야한다는 것을 의미한다.

데이터 과학자는 사용 사례와 관련된 학습 데이터를 받아 오프라인 홀드아웃 데이터 세트에서 예측 성능을 갖춘 ML 모델을 구현하고 학습할 수 있다. 그러나 문제는 ML 모델을 만드는 것이 아니라 통합 ML 시스템을 구축해 프러덕션 환경에서 지속적으로 운영하는 것이다. Google의 오랜 프러덕션 ML 서비스 히스토리를 통해, 프러덕션에서 ML 기반 시스템을 운영하는데 많은 함정이 있을 수 있는 것을 알게되었다. 이러한 함정 중 일부는 Machine Learning: The hihg-interest credit card of technical debt에 요약되어 있다.

다음 다이어그램에서 볼 수 있듯, 실제 ML 시스템은 일부만 ML 코드로 구성된다. 필요한 요소는 매우 많고 복잡하다.

그림 1. ML 시스템의 요소. Hidden Technical Debt in Machine Learning Systems에서 가져왔다

역자 : Hidden Technical Debt in Machine Learning Systems 번역본은 역자의 블로그 Hidden Technical Debt in Machine Learning Systems 리뷰에서 확인할 수 있다

이 다이어그램에서 머신러닝 코드를 제외한 나머지 시스템은 설정(config), 자동화, 데이터 수집, 데이터 검증, 테스트 및 디버깅, 리소스 관리, 모델 분석, 프로세스 및 메타 데이터 관리, 인프라 제공 및 모니터링으로 구성된다.

이런 복잡한 시스템을 개발하고 운영하기 위해 MLOps(ML 시스템)에 DevOps 원칙을 적용할 수 있다. 이 문서는 ML의 CI, CD, CT와 같은 데이터 사이언스 실무를 위해 MLOps 환경을 설정할 때 고려해야 할 개념을 다룬다.

다음 주제를 다룬다.

• DevOps vs MLOps
• ML 모델을 개발하는 단계
• MLOps 성숙도

DevOps vs MLOps

DevOps는 대규모 소프트웨어 시스템을 개발하고 운영하는데 널리 사용된다. 이 방법은 개발주기 단축, 배포 속도 향상 및 신뢰할 수 있는 릴리즈와 같은 이점을 제공한다. 이런 이점을 달성하기 위해 소프트웨어 시스템 개발에서 두 가지 개념을 소개한다.

• Continuous Integration (CI)
• Continuous Delivery (CD)

ML 시스템은 소프트웨어 시스템이므로 ML 시스템을 안정적으로 구축하고 운영할 수 있도록 유사한 관행이 적용된다.

그러나, ML 시스템은 다음 이유로 다른 소프트웨어 시스템과 다르다.

• Team Skills
  • ML 프로젝트에서, 팀에는 일반적으로 EDA, 모델 개발 및 실험에 중점을 둔 데이터 과학자 또는 ML researcher로 구성된다. 이 멤버는 프로덕션급 서비스를 구축할 수 있는 숙련된 소프트웨어 엔지니어가 아닐 수도 있다.
• Development
  • ML은 본질적으로 실험이다. 다른 feature, 알고리즘, 모델링 기술 및 파라미터 구성을 시도해 가능한 빨리 문제점에 가장 적합한 것을 찾는다. 무엇이 효과가 있었는지, 무엇이 그렇지 않은지를 추적하고, 코드 재사용을 극대화하면서 재현성을 유지하는 것이 과제다.
• Testing
  • ML 시스템 테스트는 다른 소프트웨어 시스템 테스트보다 더 복잡하다. 일반적인 단위 및 통합 테스트 외에도 데이터 검증, 훈련된 모델 품질 평가 및 모델 검증이 필요하다.
• Deployment
  • ML 시스템에서, 배포는 오프라인에서 훈련된 ML 모델을 구축하는 것만큼 간단하지 않다. ML 시스템은 자동으로 모델을 재학습하고 배포하기 위해 다단계 파이프라인을 구축이 필요할 수 있다. 이 파이프라인은 복잡성을 가중시키고 새로운 모델을 학습 및 검증하기 위해 데이터 과학자가 배포하기 전에 수동으로 수행하는 단계를 자동화해야 한다.
• Proudction
  • ML 모델은 코딩뿐만 아니라 지속적으로 발전하는 데이터 프로파일 때문에 성능이 저하될 수 있다. 즉, 모델은 기존 소프트웨어 시스템보다 더 많은 방식으로 붕괴될 수 있으므, 이런 저하를 고려해야 할 필요가 있다. 따라서 데이터의 요약 통계치를 추적하고 모델의 온라인 성능을 모니터링해 값을 예상치를 벗어날 때 알림을 보내거나 롤백해야 한다.

ML 및 다른 소프트웨어 시스템은 소스 제어, 단위 테스트, 통합 테스트 의 continuous integration과 소프트웨어 모듈 또는 패키지의 continuous delivery에서 유사하다. 그러나 ML에서는 몇 가지 주목할 차이가 있다.

• CI는 더 이상 코드와 구성 요소를 테스트하고 검증하는 데 그치지 않고 데이터, 데이터 스키마 및 모델 테스트와 검증 역할도 한다.
• CD는 더 이상 단일 소프트웨어 패키지나 서비스가 아니라 다른 서비스(모델 예측 서비스)를 자동으로 배포해야 하는 시스템(ML 학습 파이프라인)에 관한 것이다.
• CT는 ML 시스템에 고유한 새로운 속성으로, 모델을 자동으로 재학습하고 서빙하는 것과 관련이 있다.

다음 섹션에서는 예측 서비스로 사용하기 위해 ML 모델을 학습하고 평가하는 일반적인 단계에 대해 설명한다.

---

Data science steps for ML

모든 ML 프로젝트에서 비즈니스 사용 사례를 정의하고 성공 기준을 설정한 후 ML 모델을 프러덕션에 전달하는 과정은 다음 단계를 포함한다. 이런 단계는 수동으로 완료하거나 자동 파이프라인을 통해 완료할 수 있다.

1. 데이터 추출 : ML Task에 대한 다양한 데이터 소스에서 관련 데이터를 선택하고 통합한다.
2. 데이터 분석 : ML 모델 구축에 사용 가능한 데이터를 이해하기 위해 탐색적 데이터 분석(EDA)을 수행한다. 이 과정은 다음과 같다.
   • 모델에서 기대하는 데이터 스키마 및 특성 이해
   • 모델에 필요한 데이터 준비 및 feature engineering 식별
3. 데이터 준비 : 데이터는 ML Task를 위해 준비된다. 이 준비는 데이터 정리가 포함되며 데이터를 학습, 검증, 테스트 세트로 분할한다. 또한 해당 task를 해결하기 위해 데이터 변환 및 feature engineering을 적용한다. 이 단계의 결과는 준비된 형식으로 데이터가 분할되는 것이다.
4. 모델 학습 : 데이터 과학자는 준비된 데이터로 다양한 알고리즘을 구현해 다양한 ML 모델을 학습한다. 또한 구현된 알고리즘을 하이퍼 파라미터 튜닝해서 최상의 성능을 갖는 ML 모델을 얻는다. 이 단계의 결과는 훈련된 모델이다.
5. 모델 평가 : 모델은 모델 품질을 평가하기 위해 홀드 아웃 테스트 세트에서 평가된다. 이 단계의 결과는 모델의 품질을 평가하기 위한 metric이다.
6. 모델 유효성 검사 : 모델이 배포에 적합한 것으로 확인되었으며, 예측 성능이 특정 베이스라인보다 우수하다.
7. 모델 serving : 검증된 모델은 예측을 제공하기 위해 대상 환경에 배포된다. 이 배포는 다음 중 하나일 수 있다.
   • 온라인 예측을 제공하기 위한 REST API가 포함된 마이크로 서비스
   • 엣지 또는 모바일 장치에 내장된 모델
   • 배치 예측 시스템의 일부
8. 모델 모니터링 : ML 프로세스에서 새로운 이터레이션을 잠재적으로 실행하기 위해 모델 예측 성능을 모니터링한다.

이런 단계들의 자동화 수준은 ML 프로세스의 성숙도를 정의하며, 이는 새로운 데이터를 제공하거나 새로운 모델을 학습하는 속도를 반영한다. 다음 섹션에서는 자동화를 수반하지 않는 가장 일반적인 레벨에서 시작해 ML 및 CI/CD 파이프라인을 모두 자동화하는 3가지 MLOps 레벨에 대해 설명한다.

---

MLOps 레벨 0 : 수동 프로세스

많은 팀들이 최첨단 모델을 만들 수 있는 데이터 과학자와 ML 연구자들을 보유하고 있지만, ML 모델을 만들고 배치하는 과정은 전적으로 수동적이다. 이것은 성숙도의 기본 수준, 즉 레벨 0으로 간주된다. 다음 다이어그램은 이 단계의 워크플로우를 보여준다.

그림 2. 모델을 예측 서비스로 제공하기 위한 수동 ML 단계

특성

다음 목록은 그림 2와 같이 MLOps 레벨 0단계의 특성들이다:

• 수동, 스크립트 중심, 대화식(interactive) 프로세스
  • 데이터 분석, 데이터 준비, 모델 교육 및 검증을 포함한 모든 단계는 수동이다. 각 단계를 수동으로 실행하고, 한 단계에서 다른 단계로 수동 전환해야 한다. 이 과정은 대개 실행 가능한 모델이 생산될 때까지 데이터 과학자가 대화식으로 노트북에 기록하고 실행하는 실험 코드에 의해 구동된다.
• ML과 운영의 분리
  • 이 프로세스는 모델을 만드는 데이터 과학자와 예측 서비스에 모델을 서빙하는 엔지니어를 구분한다. 데이터 과학자들은 훈련된 모델을 그들의 API 인프라에 배치하기 위해 엔지니어링 팀에 아티팩트로 넘겨준다. 이 핸드오프에는 훈련된 모델을 저장 위치에 저장하거나, 모델 개체를 코드 저장소로 확인하거나, 모델 레지스트리에 업로드하는 작업이 포함될 수 있다. 그런 다음 모델을 구현하는 엔지니어는 지연 시간이 짧은 서비스를 위해 필요한 기능을 프로덕션에서 사용할 수 있도록 해야 하며, 이로 인해 training-serving skew가 발생할 수 있다.
• 드문 릴리즈 반복
  • 이 프로세스는 데이터 과학 팀이 모델 구현을 변경하거나 새 데이터로 모델을 재학습하는 등 자주 변경되지 않는 몇 가지 모델을 관리한다고 가정한다. 새 모델 버전은 1년에 2~3번만 배포된다.
• CI 없음
  • 구현물 변경이 거의 가정되지 않기 때문에 CI는 무시된다. 일반적으로 코드 테스트는 노트북 또는 스크립트 실행의 일부분이다. 실험 단계를 구현하는 스크립트와 노트북은 소스 제어되며, 훈련된 모델, 평가 메트릭, 시각화 등의 아티팩트를 생성한다.
• CD 없음
  • 모델 버전 배포가 빈번하지 않기 때문에, CD는 고려되지 않는다.
• 배포는 예측 서비스를 의미한다
  • 이 프로세스는 훈련된 모델을 전체 ML 시스템에 배포하는 것이 아니라 예측 서비스(예 : REST API를 사용하는 마이크로 서비스)에 배포하는 것만 관련이 있다.
• Active 성능 모니터링 부족
  • 이 프로세스는 모델 성능 저하 및 기타 모델 행동 변화를 감지하기 위해 필요한 모델 예측 및 작업을 추적하거나 기록하지 않는다.

엔지니어링 팀은 보안, regression, 로드 및 카나리 테스트를 포함해 API 구성, 테스트 및 배포를 위한 자체적인 복잡한 설정을 가질 수 있다. 또한 새로운 버전의 ML 모델의 프러덕션 배포는 모든 예측 요청 트래픽을 서비스하기 위해 모델이 모두 배포되기 전에 A/B 테스트나 온라인 실험을 거친다.

도전 과제

MLOps 레벨 0은 ML을 사용 사례에 적용하기 시작하는 많은 기업에서 흔히 볼 수 있다. 모델이 거의 변경되거나 학습되지 않을 경우, 이런 수동 데이터 과학 기반 방법이 충분할 수 있다. 실제로 모델들은 실제 세계에 배치될 때 깨지는 경우가 많다. 모델은 환경의 변화나 데이터의 변화에 적응하지 못한다. 자세한 내용은 머신러닝 모델이 프로덕션에서 작동 중단 및 불타는 이유를 참조하자.

이런 문제를 해결하고 프러덕션 환경에서 모델의 정확성을 유지하려면 다음을 수행해야합니다.

• 프로덕션 환경에서 모델의 품질을 적극적으로 모니터링한다
  • 모니터링을 통해 성능 저하 및 모델 지속성을 감지할 수 있다. 그것은 새로운 실험 반복과 (수동) 새로운 데이터에 대한 모델 재학습의 신호로 작용한다.
• 프러덕션 모델을 자주 재학습
  • 진화하는 패턴을 포착하려면 최신 데이터를 사용해 모델을 재학습 해야한다. 예를 들어 앱이 ML을 사용해 패션 제품을 추천하는 경우 해당 추천은 최신 트렌드 및 제품에 맞게 조정되어야 한다.
• 모델을 제작하기 위한 새로운 구현을 지속적으로 실험
  • 최신 아이디어와 기술의 진보를 활용하려면 피쳐 엔지니어링, 모델 아키텍처 및 하이퍼 파라미터와 같은 새로운 구현을 시도해야 한다. 예를 들어, 얼굴 탐지에 컴퓨터 비전을 사용할 수 있지만, 더 나은 새로운 기법은 탐지의 정확도를 향상시킬 수 있다.

이 수동 방법의 문제를 해결하기 위해서는 CI/CD 및 CT에 대한 MLOps 사례가 도움이 된다. ML 교육용 파이프라인을 배포해서 CT를 활성화할 수 있으며, ML 파이프라인의 새로운 구현을 신속하게 테스트, 구축 및 배포할 수 있도록 CI/CD 시스템을 설정할 수 있다. 이런 특징들은 다음 섹션에서 더 자세히 설명된다.

---

MLOps 레벨 1 : ML 파이프라인 자동화

레벨 1의 목표는 ML 파이프라인을 자동화해서 모델의 지속적인 학습을 하는 것이다. 이를 통해 모델 예측 서비스를 지속적으로 서빙할 수 있다. 새로운 데이터를 사용해 운영 중인 모델을 재학습하는 프로세스를 자동화하려면 파이프라인에 자동화된 데이터 및 모델 검증 단계를 도입하고 파이프라인 트리거 및 메타데이터 관리를 도입해야 한다.

다음 그림은 CT용 자동 ML 파이프라인의 개략도를 나타낸 것이다.

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

특성

다음 목록은 그림 3과 같이 MLOps 레벨 1 설정의 특성을 강조한다:

• 빠른 실험
  • ML 실험 단계가 시작된다. 단계 간 전환이 자동화되어 실험이 빠르게 반복되고 전체 파이프라인을 프러덕션 환경으로 빠르게 옮길 수 있다.
• 프로덕션 모델의 CT
  • 이 모델은 다음 섹션에서 설명하는 라이브 파이프라인 트리거를 기반으로 최신 데이터를 사용해 프로덕션 환경에서 자동으로 학습된다.
• 실험 운영 환경의 조화
  • 개발 또는 실험 환경에서 사용되는 파이프라인 구현은 사전 프로덕션(preproduction) 및 프로덕션 환경에서 사용되며 이는 MLOps 실무에 DevOps를 통합하는 핵심 부분이다.
• 구성 요소 및 파이프라인을 위한 모듈화된 코드
  • ML 파이프라인을 구성하려면 ML 파이프라인에서 구성 요소를 재사용, 구성 및 공유할 수 있어야 한다. 따라서 EDA 코드는 여전히 노트북에 있을 수 있지만, 구성 요소의 소스 코드는 모듈화가 되야한다. 또한 구성 요소는 이상적으론 다음 내용을 컨테이너화 해야 한다.
    • 커스텀 코드 런타임에서 실행 환경을 분리하기.
    • 개발(development) 환경과 프로덕션 환경간에 코드를 재현할 수 있다.
    • 파이프라인에서 각 구성 요소를 분리하기. 구성 요소는 자체 런타임 환경 버전을 가질 수 있으며 다른 언어 및 라이브러리를 가질 수 있다.
• 지속적인 모델 제공
  • 프러덕션의 ML 파이프라인은 새로운 데이터에 대해 훈련된 새로운 모델에 예측 서비스를 지속적으로 제공한다. 온라인 예측을 위한 예측 서비스로 학습되고 검증된 모델을 제공하는 모델 배포 단계가 자동화된다.
• 파이프라인 배포
  • 레벨 0에서는 학습된 모델을 프로덕션에 예측 서비스로 배포한다. 레벨 1의 경우 학습된 모델을 예측 서비스로 제공하기 위해 자동 및 반복적으로 실행되는 전체 학습 파이프라인을 배포한다.

추가 구성 요소

이 섹션에서는 ML continuous training을 사용하기 위해 아키텍처에 추가해야 하는 구성 요소에 대해 설명한다.

역자 : 총 4개 요소를 설명한다. 한번 정리하면

1) Data and model validation

2) Feature store

3) Metadata management

4) ML pipeline triggers

1) Data and model validation

ML 파이프라인을 프로덕션에 배포하면 Triggering the ML pipeline 섹션에서 논의된 하나 이상의 트리거가 파이프라인을 자동으로 실행한다. 파이프라인은 새로운 라이브 데이터가 새로운 데이터에 대해 학습된 새로운 모델 버전을 생성할 것으로 예상한다 (그림 3 참조). 따라서 프로덕션 파이프라인에서 예상되는 동작을 보장하려면 자동화된 데이터 검증 및 모델 검증 단계가 필요하다.

• 데이터 검증
  • 이 단계는 모델 학습 전에 파이프라인 실행을 중지해야하는지 또는 모델을 학습해야 하는지 결정하기 위해 필요하다. 파이프라인에서 다음을 식별하면 이 결정이 자동으로 이루어진다.
    • Data schema skews
      • 이 skews는 입력 데이터에서 이상치로 간주되므로, 다음 단계인 데이터 처리, 모델 학습 단계에서 예상되는 스키마와 다른 데이터를 받는 것을 의미한다. 이 경우 파이프라인을 중단시켜 데이터 과학팀이 조사할 수 있도록 해야 한다. 팀은 스키마의 이런 변경 사항을 처리하기 위해 파이프라인 수정사항 또는 업데이트를 릴리즈할 수 있다. 스키마 스큐에는 예상치 못한 feature, feature에서 예상하지 못한 값 등이 있는 경우 등에서 발생한다.
    • Data values skews
      • 이 비대칭은 데이터의 통계 속성이 크게 변경되어 데이터 패턴이 변경되고 있음을 의미하므로 이런 변경 사항을 따라가려면 모델을 다시 학습해야 한다.
• 모델 검증
  • 이 단계는 새 데이터로 모델을 성공적으로 학습한 후에 발생한다. 프러덕션 단계로 가기 전에 모델을 평가하고 검증한다. 이 오프라인 모델 검증 단계는 다음으로 구성된다.
    • 모델의 예측 품질을 평가하기 위해 테스트 데이터 세트에서 학습된 모델을 사용해 평가 지표(metric) 값을 구한다.
    • 새로 학습된 모델에서 생성한 평가 지표 값을 현재 모델(예 : 현재 프러덕션에 올라간 모델, 베이스라인 모델 또는 기타 비즈니스 요구 사항 모델)과 비교한다. 프로덕션으로 승격시키기 전에 새 모델이 현재 모델보다 더 나은 성능을 제공하는지 확인하자.
    • 모델의 성능이 다양한 데이터 세그먼트에서 일관되는지 확인한다. 예를 들어, 새로 학습된 고객 이탈 예측 모델은 이전 모델에 비해 전체적으로 더 나은 예측 정확도를 가질 수 있지만 고객의 지역당 정확도 값은 큰 차이가 있을 수 있다.
    • 인프라 호환성 및 예측 서비스 API와 일관성 등을 배포할 모델에 테스트해야 한다.

오프라인 모델 검증 외에도, 새로 배포된 모델은 온라인 트래픽예측을 제공하기 전에 카나리 배포 또는 A/B 테스트에서 온라인 모델 검증을 거친다.

2) Feature Store

레벨 1 ML 파이프라인 자동화를 위한 선택적인 추가 구성 요소는 feature store다. feature store는 학습 및 서비스를 위한 feature의 정의, 저장 및 액세스를 표준화하는 중앙 집중식 저장소다. feature store는 feature 값에 대한 처리량이 많은 배치 처리 서비스와 지연 시간이 짧은 실시간 서비스를 제공하고 학습 및 서비스 작업 부하를 모두 지원하는 API를 제공해야 한다.

Feature store는 다음 역할을 수행하며 데이터 과학자를 도와준다

• 동일하거나 유사한 feature를 재생성하지 않고, 사용 가능한 feature set를 발견하거나 재사용한다.
• feature와 관련된 메타 데이터를 유지해서 정의가 다른 feature를 사용하지 않는다.
• feature store에서 최신 feature 값을 제공한다.
• feature store를 실험, 지속적인 학습 및 온라인 서빙을 위한 데이터 소스로 사용해 학습 서비스 왜곡을 피한다. 이 방법을 사용하면 학습에 사용되는 feature가 서빙 중 사용되는 feature와 동일해진다.
  • 실험을 위해, 데이터 과학자는 feature store에서 오프라인으로 데이터를 추출해 실험할 수 있다.
  • 지속적인 학습을 위해, 자동 ML 학습 파이프라인은 학습에 사용되는 데이터 집합의 최신 feature 값을 일괄적으로 가져올 수 있다.
  • 온라인 예측의 경우, 예측 서비스는 고객 인구 통계적 feature, 제품 feature, 현재 세션 집계 feature와 같이 요청된 엔티티와 관련된 feature를 일괄적으로 가져올 수 있다.

역자 : Machine Learning의 Feature Store란? 글을 참고해도 좋을듯!

3) Metadata management

ML 파이프라인의 각 실행 정보는 데이터 및 artifact lineage, 재현성 및 비교를 돕기 위해 기록된다. 또한 오류 및 이상치를 디버깅하는데 도움이 된다. 파이프라인을 실행할 때마다 ML 메타 데이터 저장소는 다음 메타 데이터를 기록한다.

• 실행된 파이프라인 및 구성 요소 버전
• 파이프라인의 시작 및 종료 날짜, 시간 그리고 파이프라인이 각 단계를 완료하는데 걸린 시간
• 파이프라인의 실행기(executor)
• 파이프라인에 전달된 파라미터
• 준비된 데이터의 위치, 이상치 검증 결과, 계산된 통계, 범주형 feature에서 추출된 어휘 등. 파이프라인의 각 단계에서 생성된 아티팩트. 이런 중간 출력을 추적하면 이미 완료된 단계를 다시 실행할 필요없이, 실패된 파이프라인부터 실행할 수 있다.
• 모델 검증 단계에서 파이프라인에 새 테스트 데이터가 제공 될 때 이전 모델 버전으로 롤백해야 하거나 이전 모델 버전에 대한 평가 지표를 생성해야하는 경우를 위해 이전에 학습된 모델을 기록한다.
• 학습 및 테스트 세트 모두에 대해 모델 평가 단계에서 생성 된 모델 평가 지표. 이런 메트릭을 사용하면 모델 검증 단계에서 새로 훈련된 모델의 성능과 이전 모델의 성능을 비교할 수 있다.

4) ML pipeline triggers

ML 프러덕션 파이프라인을 자동화해서 사용 사례에 따라 새 데이터로 모델을 재학습할 수 있다.

• On demand(필요할 때마다)
  • 파이프라인을 수동 실행한다.
• On a schedule(주기적인 일정)
  • ML 시스템에 대해 매일, 매주 또는 매월 새로운 레이블이 있는 데이터를 사용할 수 있다. 재학습 빈도는 데이터 패턴이 얼마나 자주 변경되고 모델을 재학습하는데 얼마나 비싸 느냐에 달려있다.
• On availability of new training data(새로운 학습 데이터의 가용성에 따라)
  • ML 시스템에 새로운 데이터를 사용할 수 없고 대신 소스 데이터베이스에서 새 데이터를 수집해 사용할 수ㅍ있을 때 임시로 사용할 수 있다.
• On model performance degradation(모델 성능 저하시)
  • 성능 저하가 눈에 띄면 모델이 재학습된다.
• On significant changes in the data distributions(concept drift, 데이터 분포의 큰 변화가 있는 경우)
  • 온라인 모델의 전체 성능을 평가하기는 어렵지만 예측을 수행하는데 사용되는 feature의 데이터 분포에 큰 변화를 모니터링할 수 있다. 이런 분포의 변화로 인해 최신 데이터를 따라가지 못하고, 모델이 오래되었기 때문에 새로운 데이터를 다시 학습해야한다.

도전 과제

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

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

---

MLOps 레벨 2 : CI / CD 파이프라인 자동화

프러덕션에서 파이프라인을 빠르고 안정적으로 업데이트하려면 자동화된 CI/CD 시스템이 필요하다. 이 자동화된 CI/CD 시스템을 통해 데이터 과학자는 feature engineering, 모델 아키텍처 및 하이퍼 파라미터에 대한 새로운 아이디어를 신속하게 탐색할 수 있다. 이런 아이디어를 구현하고 새로운 파이프라인 구성 요소를 대상 환경에 자동으로 빌드, 테스트, 배포 할 수 있다.

다음 다이어그램은 자동화된 ML 파이프라인 설정과 자동화된 CI/CD 루틴의 특성을 갖는 ML 파이프라인의 구현을 보여준다.

그림 4. CI/CD 및 자동화된 ML 파이프라인

이 MLOps 설정은 다음 구성 요소가 포함된다.

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

특성

다음 다이어그램은 ML CI/CD 자동화 파이프라인의 단계를 보여준다.

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

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

데이터 분석 단계는 여전히 파이프라인이 새로운 반복이 시작하기 전에 데이터 과학자가 수동으로 실행해야 한다. 모델 분석 단계도 수동으로 진행한다.

---

Continuous integration(지속적인 통합)

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

• Feature engineering 로직을 단위 테스트한다.
• 모델에 구현된 다양한 방법을 단위 테스트한다. 예를 들어, 범주형 데이터 컬럼을 허용하는 함수가 있으며 이 함수를 one-hot feature로 인코딩하는 방법을 테스트한다.
• 모델 학습이 수렴되는지 테스트한다(즉, 모델의 loss가 이터레이션에 의해 감소하고 일부 샘플 레코드에 오버피팅됨).
• 모델 학습에서 0으로 나누거나 작거나 큰 값을 조작해 NaN 값을 생성하지 않는지 테스트한다.
• 파이프라인의 각 구성 요소를 테스트해 예상 아티팩트가 생성되는지 확인한다.
• 파이프라인 구성 요소 간의 통합 테스트

---

Continuous delivery(지속적인 전달)

레벨 2에서 시스템은 대상 환경에 새로운 파이프라인 구현을 지속적으로 배포하고 새로 학습된 모델의 예측 서비스를 제공한다. 파이프라인 및 모델을 빠르고 안정적이고 지속적으로 제공하려면 다음을 고려해야한다.

• 모델을 배포하기 전에 대상 인프라와 모델의 호환성 확인
  • 예를 들어, 모델에 필요한 패키지가 서빙 환경에 설치되어 있고 사용 가능한 메모리, 컴퓨팅 및 가속기 자원이 있는지 확인해야한다.
• 예상 input으로 서비스 API를 호출해 예상 서비스를 테스트하고 예상되는 응답을 얻는다.
  • 이 테스트는 일반적으로 모델 버전을 업데이트할 때 발생할 수 있는 문제를 캡처하며 다른 input을 기대한다.
• 예측 서비스 성능 테스트
  • 서비스를 로드 테스트해서 초당 쿼리 (QPS) 및 모델 대기 시간과 같은 메트릭을 파악한다.
• 재학습 또는 배치 예측을 위한 데이터 검증
• 모델이 배포되기 전에 예측 성능 목표를 충족하는지 확인
• 테스트 환경에 대한 자동 배포(예 : development 브랜치에 코드를 푸시하여 트리거되는 배포)
• 사전 프로덕션 환경에 대한 반자동 배포(예 : 리뷰어가 변경 사항을 승인한 후 코드를 마스터 브랜치에 merge해서 트리거되는 배포)
• 사전 프로덕션 환경에서 파이프라인을 여러 번 성공적으로 실행한 후 프로덕션 환경에 수동 배포

요약하면 프로덕션 환경에서 ML을 구현하는 것은 모델을 예측 용 API로 배포하는 것만 의미하지 않는다. 오히려 새로운 모델의 재학습 및 배포를 자동화할 수 있는 ML 파이프라인 배포를 의미한다. CI/CD 시스템을 구축하면 새로운 파이프라인 구현을 자동으로 테스트하고 배포할 수 있다. 이 시스템을 사용하면 데이터 및 비즈니스 환경의 빠른 변화에 대처할 수 있다. 모든 프로세스를 한 레벨에서 다른 레벨로 즉시 이동할 필요는 없다. ML 시스템 개발 및 생산의 자동화를 개선하기 위해 이러한 관행을 점차 구현할 수 있다.

---

다음에 읽을 자료

• Kubeflow 및 Cloud Build를 사용한 CI/CD ML 파이프라인 아키텍처에 대해 자세히 알아보자.
• Cloud Build를 통한 GitOps 스타일 continuous delivery에 대해 자세히 알아보자.
• 데이터 처리 워크 플로우를 위한 CI/CD 파이프라인 설정에 대해 자세히 알아보자.
• YouTube의 Google Cloud(Cloud Next ‘19)의 MLOps 모범 사례를 시청하자.
• 다른 Google 클라우드 기능을 직접 사용해보자. 튜토리얼를 살펴보자 .

---

번역 후기

• MLOps를 단계별로 정의해서, 현재 조직이 어떤 단계인지 파악해줄 수 있는 좋은 글이라 생각합니다
• MLOps의 전반적인 아키텍쳐에 대해 잘 설명한 글이고, CI/CD의 필요성을 느끼게 해준 글입니다

카일스쿨 유튜브 채널을 만들었습니다. 데이터 사이언스, 성장, 리더십, BigQuery 등을 이야기할 예정이니, 관심 있으시면 구독 부탁드립니다 :)

PM을 위한 데이터 리터러시 강의를 만들었습니다. 문제 정의, 지표, 실험 설계, 문화 만들기, 로그 설계, 회고 등을 담은 강의입니다

이 글이 도움이 되셨거나 다양한 의견이 있다면 댓글 부탁드립니다 :)