MLOps란 무엇인가

다음 글은 구글의 MLOps에 관한 글을 번역하였다. 원문

구글에서 말하는 MLOps의 단계를 알아보고 현재 우리 회사는 어떤 단계이고, 어떤 것들을 추가해나가면 좋을 지 생각해보자.

MLOps는 머신러닝의 지속적 배포 및 자동화 파이프라인을 의미한다. ML 시스템을 위한 CI(Continuous Integration), CD(Continuous Deplyment), CT(Continuous Training) 를 구현하고 자동화하는 기술을 의미한다.

DevOps 원칙을 MLOps에 적용하는 것이다. MLOps는 ML 시스템 개발(Dev) 과 ML 시스템 운영(Operation)을 통합하는 것을 목표로 하는 ML 엔지니어링 문화 및 방식이다. MLOps 수행을 통해서 통합, 테스트, 출시, 배포, 인프라 관리를 비롯하여 ML 시스템 구성의 모든 단계에서 자동화 및 모니터링을 지원하도록 한다.

다음 다이어그램은 ML 시스템 중 ML code는 극히 일부일 뿐이라는 것을 보여준다. 발췌 논문

ML 시스템의 특성

• 팀 기술 : ML 프로젝트에서 팀은 일반적으로 탐색적 데이터 분석, 모델 개발, 실험에 중점을 두는 데이터 과학자 또는 ML 연구원을 포함한다. 이러한 구성원 중 프로덕션 수준의 서비스를 빌드 할 수 있는 엔지니어가 없을 수 있다.
• 개발 : ML은 기본적으로 실험적이다. 피처, 알고리즘, 모델링 기법, 매개변수 구성을 다양하게 시도하여 문제에 가장 적합한 것을 찾아내야 한다. 효과가 있었던 것을 추적하고, 코드 재사용성을 극대화하면서 재현성을 유지해야 한다.
• 테스트 : ML 시스템 테스트는 다른 시스템보다 더 복잡하다. 일반적인 단위 및 통합 테스트 외에도 데이터 검증, 학습된 모델 품질평가, 모델 검증이 필요하다.
• 배포 : ML 시스템에서 배포는 오프라인으로 학습된 ML 모델을 예측 서비스로 배포하는 것이 그리 간단하지 않다. ML 시스템을 사용하면 모델을 자동으로 재학습시키고 배포하기 위해 다단계 파이프라인을 배포할 수 있어야 한다. 그리고 배포 전에 데이터 과학자가 모델을 검증하는 과정을 수행해야 하는데 이 단계를 자동화해야 한다.
• 프로덕션 : ML 모델은 최적화되지 않은 코딩뿐만 아니라 지속적으로 진화하는 데이터 프로필로 인해 성능이 저하될 수 있다. 즉 모델은 기존 성능보다 저하될 수 있기 때문에 이를 고려해야 한다. 따라서 데이터의 요약 통계를 추적하고 모델의 온라인 성능을 모니터링하여 값이 기대치를 벗어나면 알림을 전송하거나 롤밸해야 한다.
• CI는 코드 및 구성요소만 테스트하고 검증하는 것이 아니라, 데이터, 데이터 스키마, 모델도 테스트하고 검증해야 한다.
• CD는 모델 예측 서비스를 자동으로 배포해야 하는 시스템(ML 학습 파이프라인)이다.
• CT는 ML 시스템에 고유한 새 속성으로, 모델을 자동으로 재학습시키고 제공하는데 사용된다.

ML을 위한 데이터 과학 업무과정

• 데이터 추출 : 다양한 소스에서 관련 데이터를 선택하고 통합한다.
• 데이터 분석 : 사용할 데이터를 이해하기 위해 탐사적 데이터 분석(EDA)를 수행한다. 이러한 과정을 통해 다음 결과과 발생한다.
  • 모델에서 예상하는 데이터 스키마 및 피처 이해
  • 모델에 필요한 데이터 준비 및 피처 추출 식별
• 데이터 준비 : 데이터 정리 및 데이터를 학습, 검증, 테스트 세트로 분할한다.
• 모델 학습 : 데이터 과학자는 다양한 알고리즘으로 모델을 학습시킨다. 결과는 학습된 모델 파일이다.
• 모델 평가 : 모델 품질을 평가하기 위해 홀드아웃 테스트 세트에서 모델을 평가한다. 결과는 평가 측정항목 집합
• 모델 검증 : 예측 성능이 특정 기준보다 우수하면 모델이 배포에 적합한 것으로 확인된다.
• 모델 제공 : 검증된 모델을 예측 서비스 환경에 배포된다. 이 배포는 다음 중 하나일 수 있다.
  • 온라인 예측을 제공하기 위해 REST API가 포함된 마이크로서비스
  • 에지 또는 휴대기기에 삽입된 모델
  • 일괄 예측 시스템의 일부
• 모델 모니터링 : 모델 예측 성능이 모니터링되어 ML 프로세스에서 새로운 반복을 호출 할 수 있다. (예를들면 모델 성능이 떨어지는 경우 알람을 통해 데이터 과학자에게 알리고 데이터를 추가하여 더 나은 모델을 학습시켜 배포하는 형태가 될 수 있다.)

이러한 일련의 과정의 자동화 정도가 ML 시스템의 성숙도를 나타낸다. 다음은 MLOps의 성숙도를 단계별로 알아보자.

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

이 단계는 ML 모델을 빌드하고 배포하는 과정은 완전히 수동으로 이루어지는 단계이다. 다음 다이어그램은 이러한 수동 프로세스의 워크 플로우를 보여준다.

0단계의 특성을 살펴보자.

• 수동, 스크립트기반, 대화형 프로세스 : 데이터 분석, 데이터 준비, 모델 학습, 모델 검증을 포함한 모든 단계가 수동이다. 각 단계를 수동으로 실행하며, 다음 단계도 수동으로 전환해야 한다. 이 프로세스는 작업자가 작성하고 실행하는 실험코드에 의해 이루어진다.
• ML과 운영 간 분리 : 모델을 만드는 데이터 과학자와 모델을 예측 서비스로 제공하는 엔지니어를 분리한다. 데이터 과학자는 엔지니어링 팀에 학습된 모델을 전달하여 API 인프라에 배포한다. 이 전달은 모델을 스토리지 위치에 배치하거나, 코드 저장소에 확인하거나, 레지스트리에 업로드 하는 작업이 포함된다. 엔지니어는 짧은 지연 시간을 제공하기 위해 필요한 기능을 프로덕션 단계에서 사용할 수 있도록 해야한다. 이것으로 인해 training-serving skew 가 발생할 수 있다.
• 간헐적인 출시 반복 : 잦은 배포가 일어나지 않고, 1년에 두 어번만 배포된다.
• CI,CD 없음 : 구현 변경사항이 거의 없으므로 CI가 무시되고, 배포도 자주 되지 않으므로 CD가 없음
• 예측 서비스를 의미하는 배포 : 이 프로세스는 전체 ML 시스템을 배포하는 대신 예측 서비스(예: REST API가 포함된 마이크로 서비스)로 학습된 모델을 배포하는 것과 관련이 있다.
• Active 성능 모니터링 부족 : 프로세스가 모델 성능 저하 및 기타 모델 동작 드리프트를 감지하는 데 필요한 모델 예측 및 작업을 추적하거나 로깅하지 않는다.

엔지니어링 팀은 보안, 회귀, 부하 및 카나리아 테스트를 비롯하여 API 구성, 테스트, 배포를 위한 자체적인 복잡한 설정을 가질 수 있다. 또한 일반적으로 새로운 ML 모델 버전의 프로덕션 배포는 일반적으로 A/B 테스트 또는 온라인 실험을 거친 후 배포된다.

도전과제

MLOps 0 단계는 ML을 적용하기 시작하는 많은 비즈니에서 일반적이다. 모델이 거의 변경되지 않거나 학습되지 않는 경우에는 이러한 데이터 과학자 기반 프로세스로도 충분할 수 있다. 하지만 실제 환경에 모델이 배포될 때 손상되는 경우가 많다. 그리고 모델 환경의 동적인 변화와 데이터의 변화에 적응하지 못한다. 자세한 내용은 아래 링크를 참고하자. Why Machine Learning Models Crash and Burn in Production

이러한 문제를 해결하고 프로덕션 단계에서 모델의 정확성을 유지하려면 다음을 수행해야 한다.

• 프로덕션 단계에서 적극적으로 모델 품질을 모니터링 : 품질을 모니터링하면서 성능 저하 및 모델 비활성을 감지할 수 있다. 이는 새로운 실험이과 재학습의 필요성을 제기하는 역할을 한다.
• 프로덕션 모델 자주 재학습 : 진화하고 새로운 패턴을 포착하려면 최신 데이터로 모델을 재학습시켜야 한다.
• 모델을 생성하기 위한 새로운 구현을 지속적으로 실험 : 최신 아이디어와 기술의 발전을 활용하려면 피처 추출, 모델 아키텍처, 하이퍼파라미터 등의 새로운 구현을 시도해야 한다.

이러한 수동 프로세스의 도전 과제를 해결하려면 CI/CD 및 CT용 MLOps 방식이 도움이 된다. ML 학습 파이프라인을 배포하여 CT를 사용 설정할 수 있으며 CI/CD 시스템을 설정하여 ML 파이프라인의 새로운 구현을 빠르게 테스트, 빌드, 배포 할 수 있다.

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

수준 1 단계의 목표는 ML 파이프라인을 자동화하여 모델을 지속적으로 학습시키는 것이다. 이를 통해 모델 예측 서비스를 지속적으로 제공할 수 있다. 새 데이터를 사용하여 프로덕션 단계에서 모델을 재학습시키는 프로세스를 자동화하려면 파이프라인 트리거 및 메타데이터 관리 뿐만 아니라 자동화된 데이터 및 모델 검증 단계를 파이프라인에 도입해야 한다. 다음 그림은 CT용 자동화된 ML 파이프라인을 도식화하여 보여준다.

1단계의 특성을 살펴보자.

데이터 및 모델 검증

ML 파이프라인을 프로덕션에 배포할 때는 ML 파이프라인 트리거 섹션에서 설명한 트리거 중 하나 이상이 자동으로 파이프라인을 실행한다. 파이프라인은 실시간 데이터로 학습된 새 모델 버전을 생성할 것으로 예상할 수 있다. 따라서 다음 예상되는 동작을 보장하기 위해 프로덕션 파이프라인은 자동화된 데이터 검증 및 모델 검증 단계가 필요하다.

• 데이터 검증 : 이 단계는 모델 학습 전에 모델을 재학습할 지 또는 파이프라인 실행을 중지할 지 결정하는 데 필요하다. 이 결정은 파이프라인에서 다음을 식별하면 자동으로 수행된다.
  • 데이터 스키마 편향 : 이러한 편향은 입력 데이터의 이상으로 간주된다. 즉, 데이터 처리 및 모델 학습을 포함한 다운스트림 파이프라인 단계가 예상 스키마를 준수하지 않는 데이터를 수신한다. 이 경우 데이터 과학팀이 조사할 수 있도록 파이프라인을 중지해야 한다. 팀은 이러한 변경사항을 스키마에서 처리하기 위해 파이프라인에 대한 수정 또는 업데이트를 할 수 있다. 스키마 편향에는 예기치 않은 특성을 수신하거나, 예상되는 모든 특성을 수신하지 않거나, 예기치 않은 값을 포함하는 특성을 수신하는 경우가 포함된다.
  • 데이터 값 편향 : 이러한 편향은 데이터의 통계적 속성에 큰 변화를 주어 데이터 패턴이 변경되고 있음을 의미한다. 모델의 재학습을 트리거하여 이러한 변경사항을 포착해야 한다.
• 모델 검증 : 이 단계는 새 데이터로 모델을 학습시킨 후 발생한다. 모델을 프로덕션으로 배포하기 전에 사용자가 모델을 평가하고 검증한다. 이 오프라인 모델 검증 단계는 다음으로 구성된다.
  • 모델의 예측 품질을 평가하기 위해 테스트 데이터로 평가 측정항목 값을 생성한다.
  • 새 모델의 평가 측정항목과 기존 모델의 측정항목을 비교한다. (예 프로덕션 모델, 기준 모델, 비즈니스 요구사항 모델) 새 모델이 프로덕션으로 배포되기 전에 현재 모델보다 우수한 성능을 제공하는 지 확인한다.
  • 모델의 성능이 다양한 세그먼트에서 일관성이 있는지 확인한다. 예를들어 새로 학습 된 모델은 고객 이탈 모델에서는 예측 정확도가 높을 수 있지만, 고객 리전당 정확도 값은 차이가 날 수도 있다.
  • 예측 서비스 API 와의 인프라 호환성 및 일관성을 포함하여 모델의 배포를 테스트해야 한다.

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

Feature Store

수준 1단계의 ML 파이프라인 자동화를 위한 추가적인 요소는 피처 스토어이다. 피처 스토어는 중앙집중식 저장소이고, 학습과 서빙을 위해 피처 값에 대한 정의, 스토리지, 엑세스를 표준화한다. 피처 스토어는 피처 값에 대한 높은 일괄(batch) 처리 및 짧은 지연 시간으로써의 실시간 제공을 위한 API를 제공해야 하며, 학습 및 서빙 워크로드를 모두 지원해야 한다.

피처 스토어는 데이터 과학자가 다음을 수행하는데 도움을 준다.

• 동일하거나 유사한 피처 세트를 다시 만들지 않고 항목에 사용 가능한 피처 세트 탐색 및 재사용
• 피처 및 관련 메타데이터를 유지하여 정의가 다른 유사한 피처 사용 방지
• 피처 스토어에 최신 피처 값 제공
• 지속적 학습, 온라인 제공을 위해 피처 스토어를 데이터 소스로 사용하여 training-serving skew 방지
  • 실험의 경우 데이터 과학자는 피처 스토어에서 오프라인 추출을 통해 가져와 실험을 실행할 수 있다.
  • 지속적 학습의 경우 자동화된 ML 학습 파이프라인은 학습 태스크에 사용되는 데이터 세트의 최선 피처 값의 배치를 가져올 수 있다.
  • 온라인 예측의 경우 예측 서비스는 고객 인구통계 피처, 제품 피처, 현재 세션 집계 피처 등의 요청된 항목과 관련된 피처 값의 배치를 가져올 수 있다.

메타데이터 관리

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

• 실행된 파이프라인 및 구성요소 버전
• 시작 및 종료 날짜, 시간, 파이프라인 각 단계를 완료하는 데 걸린 시간
• 파이프라인의 실행자
• 파이프라인에 전달된 매개변수 인수
• 준비된 데이터의 위치, 검증 이상, 계산된 통계, 카테고리형 피처에서 추출된 어휘와 같은 파이프라인의 각 단계에서 생성된 아티팩트 대한 포인터. 이러한 중간 출력을 추적하면, 이미 완료된 단계를 다시 실행하지 않고도, 파이프라인이 도중에 중단된 경우 실패한 단계에서 파이프라인을 재개할 수 있다.
• 이전에 학습된 모델에 대한 포인터(이전 모델 버전으로 롤밸해야 하는 경우 또는 모델 검증 단계에서 파이프라인에 새 테스트 데이터가 제공될 때 이전 모델 버전에 대한 평가 측정항목을 생성해야 하는 경우)
• 학습 및 테스트 세트 모두에 대한 모델 평가 단계에서 생성된 모델 평가 측정항목. 이 측정항목은 모델 검증 단계에서 새로 학습된 모델의 성능과 이전 모델의 기록된 성능을 비교하는데 도움이 된다.

ML 파이프라인 트리거

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

• 요청 시 : 파으프라인의 임시 수동 실행이다.
• 일정 기준 : 라벨이 지정된 새 데이터는 매일, 매주 또는 매월 ML 시스템에서 사용할 수 있다. 재학습의 빈도는 데이터 패턴의 변경 빈도와 모델 재학습 비용에 따라 달라진다.
• 새 학습 데이터의 가용성 기준 : 새 데이터는 시스템적으로 ML 시스템에서 사용할 수 없으며, 대신 새 데이터가 수집되어 소스 데이터베이스에서 사용할 수 있게 된 경우 임시로 사용할 수 있다.
• 모델 성능 저하 시 : 성능 저하가 눈에 띄는 경우 모델이 재학습 된다.
• 데이터 분포의 중요한 변화 시(concept drift) 온라인 모델의 전체 성능을 평가하기는 어렵지만, 예측을 수행하는 데 사용되는 피처의 데이터 분포에 큰 변화가 있다. 이러한 변경사항은 모델이 오래되어 새로운 데이터로 재학습 되어야 함을 나타낸다.

도전과제

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

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

MLOps 수준 2단계 : CI/CD 파이프라인 자동화

프로덕션 단계에서 파이프라인을 빠르고 안정적이게 업데이트하려면 강력한 자동화된 CI/CD 시스템이 필요하다. 이 자동화된 CI/CD 시스템을 사용하면 데이터 과학자가 피처 추출, 모델 아키텍처, 하이퍼파라미터에 대한 새로운 아이디어를 빠르게 살펴볼 수 있다. 데이터 과학자는 이러한 아이디어를 구현하고 새 파이프라인 구성요소를 대상 환경에 자동으로 빌드, 테스트, 배포할 수 있다. 다음 다이어그램은 자동화된 ML 파이프라인 설정과 자동화 된 CI/CD 루틴의 특성을 가진 CI/CD를 사용하여 ML 파이프라인을 구현하는 방법을 보여준다.

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

• 소스 제어
• 서비스 테스트 및 빌드
• 배포 서비스
• 모델 레지스트리
• 피처 스토어
• ML 메타데이터 스토어
• ML 파이프라인 오케스트레이터

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

• 개발 및 실험 : 새 ML 알고리즘과 실험 단계가 조정되는 새 모델링을 반복적으로 시도합니다. 이 단계의 출력은 ML 파이프라인 단계의 소스 코드이며, 소스 코드는 소스 저장소로 푸시됩니다.

• 파이프라인 지속적 통합 : 소스 코드를 빌드하고 다양한 테스트를 실행합니다. 이 단계의 출력은 이후 단계에서 배포될 파이프라인 구성요소(패키지, 실행 파일, 아티팩트)이다.
• 파이프라인 지속적 배포 : CI 단계에서 생성된 아티팩트를 대상 환경에 배포한다. 이 단계의 출력은 모델의 새 구현이 포함되는 배포된 파이프라인이다.
• 자동화된 트리거 : 파이프라인은 일정 또는 트리거에 대한 응답에 따라 프로덕션 단계에서 자동으로 실행된다. 이 단계의 출력은 모델 레지스트리로 푸시되는 학습된 모델이다.
• 모델 지속적 배포 : 학습된 모델을 예측 서비스로 서빙한다. 이 단계의 출력은 예측 서비스에 배포된 형태이다.
• 모니터링 : 실시간 데이터를 기반으로 모델 성능의 통계를 수집한다. 이 단계의 출력은 파이프라인을 실행하거나 새 실험 주기를 실행하는 트리거이다.

지속적 통합

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

• 피처 추출 로직을 단위 테스트 한다.
• 모델에 구현된 다양한 메서드를 단위 테스트 한다. 예를들어 범주형 데이터 열을 허용하는 함수가 있다면 이 함수를 원-핫 피처로 인코딩한다.
• 모델 학습이 수렴하는지 테스트 한다. (손실이 계속 줄어드는지 오버피팅하는지)
• 모델 학습에서 0으로 나누거나 작은 값 또는 큰 값을 조작하여 NaN 값을 생성하지 않는지 테스트 한다.
• 파이프라인의 각 구성요소가 예상 아티팩트를 생성하는지 테스트 한다.
• 파이프라인 구성요소 간의 통합을 테스트 한다.

지속적인 배포

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

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

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