Azure Machine Learning을 사용하여 기계 학습 수명 주기를 업스케일링하는 MLOps(machine learning operations) 프레임워크

Azure Data Factory
Azure Machine Learning

이 클라이언트 프로젝트는 포춘지 선정 500대 식품 회사가 수요 예측을 개선하는 데 도움이 되었습니다. 이 회사는 제품을 여러 소매점으로 직접 배송합니다. 이러한 개선을 통해 미국 여러 지역의 여러 매장에서 제품 재고를 최적화할 수 있었습니다. 이를 달성하기 위해 Microsoft의 CSE(상업 소프트웨어 엔지니어링) 팀은 파일럿 연구를 수행하는 고객의 데이터 과학자와 협력하여 선택한 지역에 대한 사용자 지정된 기계 학습 모델을 개발했습니다. 이러한 모델은 다음 사항을 고려합니다.

  • 쇼핑객 인구 통계
  • 과거 및 예측 날씨
  • 과거 배송
  • 제품 반품
  • 특별 이벤트

재고를 최적화한다는 목적은 프로젝트의 주요 구성 요소를 대표했으며 클라이언트는 초기 현장 시험에서 상당한 매출 증대를 실현했습니다. 또한 팀은 과거 평균 기준 모델과 비교할 때 MAPE(평균 절대 백분율 오차) 예측에서 40% 감소를 확인했습니다.

프로젝트의 핵심 부분은 파일럿 연구에서 프로덕션 수준으로 데이터 과학 워크플로를 스케일 업하는 방법을 파악하는 것이었습니다. 이 프로덕션 수준 워크플로에서 CSE 팀은 다음을 수행해야 합니다.

  • 많은 지역에 대한 모델을 개발합니다.
  • 모델의 성능을 지속적으로 업데이트하고 모니터링합니다.
  • 데이터와 엔지니어링 팀 간의 공동 작업을 촉진합니다.

오늘날 일반적인 데이터 과학 워크플로는 프로덕션 워크플로보다 일회성 랩 환경에 더 가깝습니다. 데이터 과학자를 위한 환경은 다음 작업을 수행하는 데 적합해야 합니다.

  • 데이터를 준비합니다.
  • 다양한 모델을 실험합니다.
  • 하이퍼 매개 변수를 조정합니다.
  • 빌드-테스트-평가-수정 주기를 만듭니다.

이러한 작업에 사용되는 대부분의 도구는 특정 목적이 있으며 자동화에 적합하지 않습니다. 프로덕션 수준의 기계 학습 작업에서는 애플리케이션 수명 주기 관리 및 DevOps를 더 많이 고려해야 합니다.

CSE 팀은 고객이 운영을 프로덕션 수준으로 스케일 업하도록 도왔습니다. CI/CD(지속적인 통합 및 지속적인 업데이트) 기능의 다양한 측면을 구현하고 관찰 가능성, Azure 기능과의 통합과 같은 문제를 해결했습니다. 구현하는 동안 팀은 기존 MLOps 지침에 격차가 있음을 발견했습니다. MLOps를 더 잘 이해하고 대규모로 적용할 수 있도록 이러한 격차를 더욱 개선해야 했습니다.

MLOps 사례를 이해하면 조직에서 시스템이 생성하는 기계 학습 모델이 비즈니스 성과를 개선하는 프로덕션 품질 모델이 되도록 보장하는 데 도움이 됩니다. MLOps를 구현하면 조직은 더 이상 프로덕션 수준 운영을 위한 기계 학습 모델을 개발하고 실행하는 데 필요한 인프라 및 엔지니어링 작업과 관련된 하위 수준 세부 정보에 대부분의 시간을 투자할 필요가 없습니다. 또한 MLOps를 구현하면 데이터 과학 및 소프트웨어 엔지니어링 커뮤니티가 함께 작업하여 프로덕션 준비 시스템을 제공하는 방법을 배울 수 있습니다.

CSE 팀은 이 프로젝트를 사용하여 MLOps 완성도 모델 개발과 같은 문제를 해결하여 기계 학습 커뮤니티 요구 사항을 해결했습니다. 이러한 노력은 MLOps 프로세스에서 주요 참여자가 직면한 일반적인 문제를 이해하여 MLOps 채택을 개선하는 것을 목표로 했습니다.

사용자 참여 및 기술 시나리오

사용자 참여 시나리오에서는 CSE 팀이 해결해야 하는 실제 과제에 대해 설명합니다. 기술 시나리오는 잘 설정된 DevOps 수명 주기만큼 안정적인 MLOps 수명 주기를 만들기 위한 요구 사항을 정의합니다.

사용자 참여 시나리오

클라이언트는 정기적인 일정에 따라 소매 시장 아울렛에 직접 제품을 배송합니다. 각 소매점은 제품 사용 패턴이 다르기 때문에 제품 재고는 매주 배송될 때마다 달라야 합니다. 판매를 최대화하고 제품 반품 및 판매 기회 상실을 최소화하는 것이 고객이 사용하는 수요 예측 방법론의 목표입니다. 이 프로젝트는 기계 학습을 사용하여 예측을 개선하는 데 중점을 두었습니다.

CSE 팀은 프로젝트를 두 단계로 나눴습니다. 1단계에서는 선택한 판매 지역에서 기계 학습 예측의 효율성에 대한 현장 기반 파일럿 연구를 지원하기 위해 기계 학습 모델을 개발하는 데 중점을 두었습니다. 1단계의 성공은 2단계로 이어졌으며, 여기서 팀은 단일 지리적 지역을 지원하는 최소 모델 그룹에서 모든 클라이언트의 판매 지역에 대한 지속 가능한 프로덕션 수준 모델 세트로 초기 파일럿 연구를 스케일 업했습니다. 스케일 업된 솔루션에 대한 주요 고려 사항은 많은 수의 지리적 지역과 해당 지역 소매점을 수용해야 한다는 것이었습니다. 팀은 각 지역의 크고 작은 소매점 모두에 기계 학습 모델을 제공했습니다.

1단계 파일럿 연구에서는 한 지역의 소매점 전용 모델이 지역 판매 내역, 지역 인구 통계, 날씨 및 특별 이벤트를 사용하여 해당 지역의 판매점에 대한 수요 예측을 최적화할 수 있다고 결정했습니다. 4개의 앙상블 기계 학습 예측 모델이 단일 지역의 시장 판매점에 서비스를 제공했습니다. 모델은 매주 일괄 처리로 데이터를 처리했습니다. 또한 팀은 비교를 위해 과거 데이터를 사용하여 두 가지 기준 모델을 개발했습니다.

스케일 업된 2단계 솔루션의 최초 버전에서 CSE 팀은 크고 작은 시장을 포함하여 14개의 지리적 지역을 참여하기 위해 선택했습니다. 50개 이상의 기계 학습 예측 모델을 사용했습니다. 팀은 추가 컴퓨터 성장과 기계 학습 모델의 지속적인 개선을 기대했습니다. 팀이 기계 학습 환경에 대한 DevOps의 모범 사례 원칙을 기반으로 하는 경우에만 이 광범위한 기계 학습 솔루션이 지속 가능하다는 것이 빠르게 분명해졌습니다.

Environment 시장 지역 서식 모델 모델 세분화 모델 설명
개발 환경 각 지리적 시장/지역(예: 북부 텍사스) 대규모 매장(슈퍼마켓, 대형 상점 등) 앙상블 모델 두 개 느리게 움직이는 제품 느리게 및 빠르게 움직이는 제품은 각각 LASSO(Least Absolute Shrinkage and Selection Operator) 선형 회귀 모델의 앙상블과 범주 포함이 있는 인공신경망을 가집니다.
빠르게 움직이는 제품 느리게 및 빠르게 움직이는 제품은 각각 LASSO 선형 회귀 모델의 앙상블과 범주 포함이 있는 인공신경망이 있습니다.
앙상블 모델 한 개 해당 없음 기록 평균
소규모 매장(약국, 편의점 등) 앙상블 모델 두 개 느리게 움직이는 제품 느리게 및 빠르게 움직이는 제품은 각각 LASSO 선형 회귀 모델의 앙상블과 범주 포함이 있는 인공신경망이 있습니다.
빠르게 움직이는 제품 느리게 움직이는 제품은 각각 LASSO 선형 회귀 모델의 앙상블과 범주 포함이 있는 인공신경망이 있습니다.
앙상블 모델 한 개 해당 없음 기록 평균
추가 13개 지역에 대해 위와 동일
프로덕션 환경의 경우 위와 동일

MLOps 프로세스는 기계 학습 모델의 전체 수명 주기를 처리하는 스케일 업된 시스템에 대한 프레임워크를 제공합니다. 프레임워크에는 개발, 테스트, 배포, 작업 및 모니터링이 포함됩니다. 클래식 CI/CD 프로세스의 요구 사항을 충족합니다. 그러나 DevOps에 비해 상대적으로 미성숙하기 때문에 기존 MLOps 지침에는 격차가 있음이 분명해졌습니다. 프로젝트 팀은 이러한 격차를 메우기 위해 노력했습니다. 스케일 업된 기계 학습 솔루션의 실행 가능성을 보장하는 기능적 프로세스 모델을 제공하기를 원했습니다.

이 프로젝트에서 개발된 MLOps 프로세스는 MLOps를 더 높은 수준의 완성도와 실행 가능성으로 옮기는 중요한 실제 단계를 만들었습니다. 새로운 프로세스는 다른 기계 학습 프로젝트에 직접 적용할 수 있습니다. CSE 팀은 학습한 내용을 사용하여 누구나 다른 기계 학습 프로젝트에 적용할 수 있는 MLOps 완성도 모델 초안을 작성했습니다.

기술 시나리오

기계 학습을 위한 DevOps라고도 하는 MLOps는 프로덕션 환경에서 기계 학습 수명 주기를 구현하는 것과 관련된 철학, 사례 및 기술을 포함하는 포괄적인 용어입니다. 아직까지는 비교적 새로운 개념입니다. MLOps가 무엇인지 정의하려는 시도가 많았으며 많은 사람들이 MLOps가 데이터 과학자가 데이터를 준비하는 방법부터 궁극적으로 기계 학습 결과를 제공, 모니터링 및 평가하는 방법에 이르기까지 모든 것을 소거할 수 있는지 의문을 제기했습니다. DevOps가 기본 관행 세트를 개발하는 데 수년이 걸렸지만 MLOps는 아직 개발 초기 단계입니다. DevOps가 진화함에 따라 종종 서로 다른 기술 및 우선 순위로 작동하는 두 가지 분야(소프트웨어/운영 엔지니어링 및 데이터 과학)를 통합하는 데 어려움이 있음을 발견합니다.

실제 프로덕션 환경에서 MLOps를 구현하려면 극복해야 하는 고유한 과제가 있습니다. 팀은 Azure를 사용하여 MLOps 패턴을 지원할 수 있습니다. Azure는 또한 효과적인 기계 학습 수명 주기 관리를 위한 자산 관리 및 오케스트레이션 서비스를 클라이언트에 제공할 수 있습니다. Azure 서비스는 이 문서에서 설명하는 MLOps 솔루션의 기반입니다.

기계 학습 모델 요구 사항

1단계 파일럿 현장 연구 중 대부분의 작업은 CSE 팀이 단일 지역의 크고 작은 소매점에 적용한 기계 학습 모델을 만드는 것이었습니다. 모델에 대한 주목할만한 요구 사항은 다음과 같습니다.

  • Azure Machine Learning Services 사용

  • Jupyter Notebook에서 개발되고 Python으로 구현된 초기 실험 모델

    참고

    팀에서 크고 작은 매장에 대해 동일한 기계 학습 접근 방식을 사용했지만 학습 및 점수 매기기 데이터는 매장 규모에 따라 다름

  • 데이터를 사용하려면 모델 사용을 준비해야 함

  • 데이터가 실시간으로 처리되지 않고 일괄 처리 방식으로 처리됨

  • 코드 또는 데이터가 변경되거나 모델이 부실할 때마다 모델 재학습

  • Power BI 대시보드에서 모델 성능 보기

  • 과거 평균 기준 모델과 비교하는 경우 MAPE <= 45%일 때 점수 매기기의 모델 성능이 유의미한 것으로 간주됨

MLOps 요구 사항

팀은 단일 판매 지역에 대해 몇 가지 모델만 개발된 1단계 파일럿 현장 연구에서 도출한 솔루션을 스케일 업하기 위해 몇 가지 주요 요구 사항을 충족해야 했습니다. 2단계는 여러 지역에 대한 사용자 지정 기계 학습 모델을 구현했습니다. 구현에는 다음이 포함됩니다.

  • 새로운 데이터 세트로 각 모델을 재학습하기 위해 각 지역의 크고 작은 상점에 대한 주간 일괄 처리

  • 기계 학습 모델의 지속적인 개선.

  • MLOps를 위한 DevOps와 유사한 처리 환경에서 CI/CD에 공통된 개발/테스트/패키지/테스트/배포 프로세스의 통합.

    참고

    이는 데이터 과학자와 데이터 엔지니어가 과거에 일반적으로 작업했던 방식의 변화를 나타냅니다.

  • 매장의 이력, 인구 통계 및 기타 주요 변수를 기반으로 크고 작은 매장의 각 지역을 나타내는 고유한 모델입니다. 모델은 처리 오류의 위험을 최소화하기 위해 전체 데이터 세트를 처리해야 했습니다.

  • 추가 스케일 업 계획으로 14개 판매 지역을 지원하기 위해 초기에 스케일 업할 수 있는 기능

  • 지역 및 기타 매장 클러스터에 대한 장기 예측을 위한 추가 모델을 계획합니다.

기계 학습 모델 솔루션

데이터 과학 수명 주기라고도 하는 기계 학습 수명 주기는 대략 다음과 같은 상위 수준 프로세스 흐름에 맞습니다.

데이터 과학 수명 주기 모델 프로세스 흐름

여기에서 모델 배포는 유효성 검사된 기계 학습 모델의 모든 운영 사용을 나타낼 수 있습니다. DevOps와 비교하여 MLOps는 이 기계 학습 수명 주기를 일반적인 CI/CD 프로세스에 통합하는 추가 과제를 제시합니다.

데이터 과학 수명 주기는 일반적인 소프트웨어 개발 수명 주기를 따르지 않습니다. 여기에는 Azure Machine Learning을 사용하여 모델을 학습시키고 점수를 매기는 것이 포함되므로 이러한 단계는 CI/CD 자동화에 포함해야 했습니다.

데이터의 일괄 처리는 아키텍처의 기초입니다. 두 개의 Azure Machine Learning 파이프라인이 프로세스의 중심이며, 하나는 학습용이고 다른 하나는 채점용입니다. 이 다이어그램은 클라이언트 프로젝트의 초기 단계에 사용된 데이터 과학 방법론을 보여 줍니다.

1단계 데이터 과학 방법론

팀은 여러 알고리즘을 테스트했습니다. 궁극적으로 LASSO 선형 회귀 모델의 앙상블 디자인과 범주 포함이 있는 인공신경망을 선택했습니다. 팀은 크고 작은 매장 모두에 대해 클라이언트가 현장에 저장할 수 있는 제품 수준으로 정의된 동일한 모델을 사용했습니다. 팀은 모델을 빠르게 움직이는 제품과 느리게 움직이는 제품으로 더 세분화했습니다.

데이터 과학자는 팀이 새 코드를 릴리스하고 새 데이터를 사용할 수 있을 때 기계 학습 모델을 학습합니다. 학습은 일반적으로 매주 진행됩니다. 결과적으로 각 처리 실행에는 많은 양의 데이터가 포함됩니다. 팀은 여러 원본에서 다양한 형식의 데이터를 수집하기 때문에 데이터 과학자가 데이터를 처리하기 전에 데이터를 소비 가능한 형식으로 전환하기 위한 컨디셔닝이 필요합니다. 데이터 컨디셔닝에는 상당한 수작업이 필요했으며 CSE 팀은 이를 자동화의 주요 후보로 식별했습니다.

언급한 바와 같이 데이터 과학자들은 이 예측 접근 방식의 유용성을 평가하기 위해 단계 1 파일럿 현장 연구에서 실험적인 Azure Machine Learning 모델을 개발하고 단일 판매 지역에 적용했습니다. CSE 팀은 파일럿 연구에서 매장의 판매 증가가 유의미했다고 판단했습니다. 이러한 성공은 14개의 지리적 지역과 수천 개의 매장을 시작으로 2단계에서 전체 프로덕션 수준에 솔루션을 적용하는 데 정당한 근거가 되었습니다. 그런 다음 팀은 동일한 패턴을 사용하여 영역을 더 추가할 수 있습니다.

파일럿 모델은 스케일 업된 솔루션의 기반이 되었지만 CSE 팀은 모델이 성능을 개선하기 위해 지속적으로 추가 개선이 필요하다는 점을 알고 있었습니다.

MLOps 솔루션

MLOps 개념이 성숙함에 따라 팀에서는 데이터 과학과 DevOps 분야를 통합하는 데 있어 종종 문제를 발견합니다. 그 이유는 분야의 주요 주체, 소프트웨어 엔지니어 및 데이터 과학자가 다양한 기술 세트와 우선 순위로 작용하기 때문입니다.

그러나 그 밑바탕에는 유사점이 있습니다. DevOps와 같은 MLOps는 도구 체인으로 구현되는 개발 프로세스입니다. MLOps 도구 체인에는 다음이 포함됩니다.

  • 버전 제어
  • 코드 분석
  • 빌드 자동화
  • 연속 통합
  • 프레임워크 및 자동화 테스트
  • CI/CD 파이프라인에 통합된 규정 준수 정책
  • 배포 자동화
  • 모니터링
  • 재해 복구 및 고가용성
  • 패키지 및 컨테이너 관리

위에서 언급했듯이 솔루션은 기존 DevOps 지침을 활용하지만 클라이언트 및 데이터 과학 커뮤니티의 요구 사항을 충족하는 보다 성숙한 MLOps 구현을 만들도록 확장되었습니다. MLOps는 다음과 같은 추가 요구 사항과 함께 DevOps 지침을 기반으로 합니다.

  • 데이터/모델 버전 관리는 코드 버전 관리와 동일하지 않음: 스키마 및 원본 데이터가 변경됨에 따라 데이터 세트의 버전 관리가 있어야 합니다.
  • 디지털 감사 내역 요구 사항: 코드 및 클라이언트 데이터를 처리할 때 모든 변경 내용을 추적합니다.
  • 일반화: 데이터 과학자는 입력 데이터/시나리오를 기반으로 모델을 조정해야 하므로 모델은 재사용을 위한 코드와 다릅니다. 새 시나리오에 모델을 다시 사용하려면 모델을 미세 조정/전송/학습해야 할 수 있습니다. 학습 파이프라인이 필요합니다.
  • 부실 모델: 모델은 시간이 지남에 따라 쇠퇴하는 경향이 있으며 프로덕션에서 관련성을 유지하려면 필요에 따라 모델을 다시 학습시키는 기능이 필요합니다.

MLOps 과제

미숙한 MLOps 표준

MLOps의 표준 패턴은 여전히 진화 중입니다. 솔루션은 일반적으로 처음부터 작성되며 특정 클라이언트 또는 사용자의 요구 사항에 맞게 만들어집니다. CSE 팀은 이러한 격차를 인식하고 이 프로젝트에서 DevOps 모범 사례를 사용하려고 했습니다. MLOps의 추가 요구 사항에 맞게 DevOps 프로세스를 보강했습니다. 팀이 개발한 프로세스는 MLOps 표준 패턴이 어떻게 생겼는지 보여 주는 실행 가능한 예입니다.

기술 집합의 차이점

소프트웨어 엔지니어와 데이터 과학자는 팀에 고유한 기술을 제공합니다. 이러한 다양한 기술로 인해 모든 사람의 요구 사항에 맞는 솔루션을 찾기가 어려울 수 있습니다. 실험에서 프로덕션에 이르는 모델 전달을 위해 잘 알려진 워크플로를 구축하는 것이 중요합니다. 팀원은 MLOps 프로세스를 중단하지 않고 변경 내용을 시스템에 통합할 수 있는 방법에 대한 이해를 공유해야 합니다.

여러 모델 관리

어려운 기계 학습 시나리오를 해결하기 위해서는 일반적으로 여러 모델이 필요합니다. MLOps의 과제 중 하나는 다음을 포함하여 이러한 모델을 관리하는 것입니다.

  • 일관된 버전 관리 체계가 있습니다.
  • 모든 모델을 지속적으로 평가하고 모니터링합니다.

모델 문제를 진단하고 재현 가능한 모델을 만들려면 코드 및 데이터의 추적 가능한 계보도 필요합니다. 사용자 지정 대시보드를 보면 배포된 모델의 성능과 개입 시기를 파악할 수 있습니다. 팀은 이 프로젝트를 위해 이러한 대시보드를 만들었습니다.

데이터 컨디셔닝의 필요성

이러한 모델에 사용되는 데이터는 많은 개인 및 공용 원본에서 가져옵니다. 원본 데이터가 무질서하기 때문에 기계 학습 모델이 원시 상태의 데이터를 소비하는 것이 불가능합니다. 데이터 과학자는 데이터를 기계 학습 모델 사용을 위한 표준 형식으로 조정해야 합니다.

파일럿 필드 테스트의 대부분은 기계 학습 모델이 처리할 수 있도록 원시 데이터를 조정하는 데 중점을 두었습니다. MLOps 시스템에서 팀은 이 프로세스를 자동화하고 출력을 추적해야 합니다.

MLOps 완성도 모델

MLOps 완성도 모델의 목적은 원칙과 관행을 명확히 하고 MLOps 구현의 격차를 식별하는 것입니다. 또한 한 번에 모든 것을 수행하려고 하는 대신 MLOps 기능을 점진적으로 성장시키는 방법을 클라이언트에게 보여 주는 방법이기도 합니다. 클라이언트는 다음을 위한 지침으로 사용해야 합니다.

  • 프로젝트의 작업 범위를 예상합니다.
  • 성공 기준을 설정합니다.
  • 결과물을 식별합니다.

MLOps 완성도 모델은 다음 5가지 수준의 기술 기능을 정의합니다.

Level 설명
0 Ops 없음
1 DevOps는 있지만 MLOps 없음
2 자동화된 학습
3 자동화된 모델 배포
4 자동화된 작업(전체 MLOps)

MLOps 완성도 모델의 현재 버전은 MLOps 완성도 모델 문서를 참조하세요.

MLOps 프로세스 정의

MLOps에는 원시 데이터 획득에서부터 모델 출력 전달까지 모든 활동이 포함되며, 이를 채점이라고도 합니다.

  • 데이터 컨디셔닝
  • 모델 학습
  • 모델 테스트 및 평가
  • 빌드 정의 및 파이프라인
  • 릴리스 파이프라인
  • 배포
  • 점수 매기기

기본 기계 학습 프로세스

기본 기계 학습 프로세스는 기존 소프트웨어 개발과 비슷하지만 상당한 차이점이 있습니다. 이 다이어그램은 기계 학습 프로세스의 주요 단계를 보여 줍니다.

기본 기계 학습 프로세스 흐름 다이어그램

실험 단계는 데이터 과학자가 전통적으로 작업을 수행하는 방법을 반영하는 데이터 과학 수명 주기에 따라 다릅니다. 이는 코드 개발자가 작업을 수행하는 방식과 다릅니다. 다음 다이어그램은 이 수명 주기를 더 자세히 보여 줍니다.

데이터 과학 수명 주기의 다이어그램

이 데이터 개발 프로세스를 MLOps에 통합하는 것은 어려운 일입니다. 여기에서 팀이 MLOps가 지원하는 형식으로 프로세스를 통합하는 데 사용한 패턴을 볼 수 있습니다.

데이터 개발 프로세스 및 MLOps를 통합하기 위한 패턴의 다이어그램

MLOps의 역할은 프로덕션 수준 시스템에서 일반적으로 사용되는 대규모 CI/CD 환경을 효율적으로 지원할 수 있는 조정된 프로세스를 만드는 것입니다. 개념적으로 MLOps 모델에는 실험에서 채점에 이르는 모든 프로세스 요구 사항이 포함되어야 합니다.

CSE 팀은 MLOps 프로세스를 고객의 특정 요구에 맞게 개선했습니다. 가장 주목할 만한 것은 실시간 처리 대신 일괄 처리가 필요했다는 것입니다. 팀은 확장된 시스템을 개발하면서 몇 가지 단점을 식별하고 해결했습니다. 이러한 단점 중 가장 중요한 것은 팀이 Azure Data Factory에 기본 제공 커넥터를 사용하여 구현한 Azure Data Factory와 Azure Machine Learning 간의 브리지 개발로 이어졌습니다. 프로세스 자동화가 작동하도록 하는 데 필요한 트리거링 및 상태 모니터링을 용이하게 하기 위해 이 구성 요소 세트를 만들었습니다.

또 다른 근본적인 변화는 데이터 과학자가 학습 및 채점을 직접 트리거하는 대신 Jupyter Notebooks에서 MLOps 배포 프로세스로 실험 코드를 내보낼 수 있는 기능이 필요했다는 것입니다.

다음은 최종 MLOps 프로세스 모델 개념입니다.

최종 MLOps 모델 개념의 다이어그램

중요

채점은 마지막 단계입니다. 프로세스는 기계 학습 모델을 실행하여 예측을 수행합니다. 이는 수요 예측에 대한 기본 비즈니스 사용 사례 요구 사항을 해결합니다. 팀은 통계 예측 방법의 예측 정확도를 나타내는 수단인 MAPE와 기계 학습의 회귀 문제에 대한 손실 함수를 사용하여 예측 품질을 평가합니다. 이 프로젝트에서 팀은 <= 45%의 MAPE가 중요하다고 간주했습니다.

MLOps 프로세스 흐름

다음 다이어그램은 CI/CD 개발 및 릴리스 워크플로를 기계 학습 수명 주기에 적용하는 방법을 설명합니다.

MLOps 프로세스 흐름 원형 다이어그램

  • 기능 분기에서 풀(pull) 요청(PR)이 만들어지면 파이프라인은 코드 유효성 검사 테스트를 실행하여 단위 테스트 및 코드 품질 테스트를 통해 코드 품질의 유효성을 검사합니다. 품질 업스트림의 유효성을 검사하기 위해 파이프라인은 기본 모델 유효성 검사 테스트도 실행하여 모의 데이터 샘플 세트로 엔드투엔드 학습 및 채점 단계의 유효성을 검사합니다.
  • PR이 기본 분기에 병합되면 CI 파이프라인은 동일한 코드 유효성 검사 테스트와 기본 모델 유효성 검사 테스트를 증가된 epoch로 실행합니다. 그런 다음 파이프라인은 코드와 이진 파일이 포함된 아티팩트를 패키지하여 기계 학습 환경에서 실행합니다.
  • 아티팩트를 사용할 수 있게 되면 모델 유효성 검사 CD 파이프라인이 트리거됩니다. 개발 기계 학습 환경에서 엔드투엔드 유효성 검사를 실행합니다. 채점 메커니즘이 게시됩니다. 일괄 채점 시나리오의 경우 채점 파이프라인이 기계 학습 환경에 게시되고 결과를 생성하도록 트리거됩니다. 실시간 채점 시나리오를 사용하려는 경우 웹앱을 게시하거나 컨테이너를 배포할 수 있습니다.
  • 마일스톤이 만들어져 릴리스 분기에 병합되면 동일한 CI 파이프라인 및 모델 유효성 검사 CD 파이프라인이 트리거됩니다. 이번에는 릴리스 분기의 코드에 대해 실행됩니다.

유사한 아키텍처 선택을 할 수 있는 프로젝트에 대한 원형 프레임워크로 위에 표시된 MLOps 프로세스 데이터 흐름을 고려할 수 있습니다.

코드 유효성 검사 테스트

기계 학습을 위한 코드 유효성 검사 테스트는 코드 기반의 품질 유효성 검사에 중점을 둡니다. 코드 품질 테스트(린팅), 단위 테스트 및 코드 검사 측정이 포함된 모든 엔지니어링 프로젝트와 동일한 개념입니다.

기본 모델 유효성 검사 테스트

모델 유효성 검사는 일반적으로 유효한 기계 학습 모델을 생성하는 데 필요한 전체 엔드투엔드 프로세스 단계의 유효성을 검사하는 것을 말합니다. 여기에는 다음과 같은 단계가 포함됩니다.

  • 데이터 유효성 검사: 입력 데이터가 유효한지 확인합니다.
  • 학습 유효성 검사: 모델이 성공적으로 학습될 수 있는지 확인합니다.
  • 점수 유효성 검사: 팀이 입력 데이터로 점수를 매기기 위해 학습된 모델을 성공적으로 사용할 수 있는지 확인합니다.

기계 학습 환경에서 이 전체 단계 세트를 실행하는 것은 비용과 시간이 많이 소요됩니다. 따라서 팀은 개발 시스템에 대해 로컬로 기본 모델 유효성 검사 테스트를 수행했습니다. 위의 단계를 실행하고 다음을 사용했습니다.

  • 로컬 테스트 데이터 세트: 종종 난독 처리되는 작은 데이터 세트로, 리포지토리에 체크 인되어 입력 데이터 원본으로 사용됩니다.
  • 로컬 플래그: 코드가 데이터 세트를 로컬에서 실행하도록 의도했음을 나타내는 모델 코드의 플래그 또는 인수입니다. 이 플래그는 코드에 기계 학습 환경에 대한 모든 호출을 우회하도록 지시합니다.

이러한 유효성 검사 테스트의 목표는 학습된 모델의 성능을 평가하는 것이 아닙니다. 오히려 엔드투엔드 프로세스의 코드 품질이 좋은지 유효성을 검사합니다. PR 및 CI 빌드에 모델 유효성 검사 테스트를 통합하는 것과 같이 업스트림을 푸시한 코드의 품질을 보장합니다. 엔지니어와 데이터 과학자가 디버깅을 위해 코드에 중단점을 넣을 수도 있습니다.

모델 유효성 검사 CD 파이프라인

모델 유효성 검사 파이프라인의 목표는 실제 데이터를 사용하여 기계 학습 환경에서 엔드투엔드 모델 학습 및 채점 단계의 유효성을 검사하는 것입니다. 생성된 학습된 모델은 모델 레지스트리에 추가되고 태그가 지정되어 유효성 검사가 완료된 후 승격을 기다립니다. 일괄 처리 예측의 경우 승격은 이 버전의 모델을 사용하는 채점 파이프라인 게시일 수 있습니다. 실시간 채점의 경우 모델에 태그를 지정하여 승격되었음을 나타낼 수 있습니다.

채점 CD 파이프라인

채점 CD 파이프라인은 모델 유효성 검사에 사용된 것과 동일한 모델 조정자가 게시된 채점 파이프라인을 트리거하는 일괄 처리 유추 시나리오에 적용할 수 있습니다.

개발 및 프로덕션 환경

개발(dev) 환경과 프로덕션(prod) 환경을 분리하는 것이 좋습니다. 분리를 통해 시스템에서 모델 유효성 검사 CD 파이프라인을 트리거하고 CD 파이프라인을 다른 일정으로 채점할 수 있습니다. 설명된 MLOps 흐름의 경우 기본 분기를 대상으로 하는 파이프라인은 개발 환경에서 실행되고 릴리스 분기를 대상으로 하는 파이프라인은 프로덕션 환경에서 실행됩니다.

코드 변경과 데이터 변경

이전 섹션에서는 대부분 개발에서 릴리스로의 코드 변경을 처리하는 방법을 다루었습니다. 그러나 데이터 변경은 코드 변경과 동일한 엄격함을 따라야 프로덕션에서 동일한 유효성 검사 품질과 일관성을 제공해야 합니다. 데이터 변경 트리거 또는 타이머 트리거를 사용하여 시스템은 모델 오케스트레이터에서 모델 유효성 검사 CD 파이프라인 및 채점 CD 파이프라인을 트리거하여 릴리스 분기 프로덕션 환경에서 코드 변경을 위해 실행된 것과 동일한 프로세스를 실행할 수 있습니다.

MLOps 가상 사용자 및 역할

모든 MLOps 프로세스의 핵심 요구 사항은 프로세스의 많은 사용자 요구 사항을 충족해야 한다는 것입니다. 디자인 목적으로 이러한 사용자를 개별 가상 사용자로 간주합니다. 이 프로젝트에서 팀은 다음 가상 사용자를 식별했습니다.

  • 데이터 과학자: 기계 학습 모델과 해당 알고리즘을 만듭니다.
  • 엔지니어
    • 데이터 엔지니어: 데이터 컨디셔닝을 처리합니다.
    • 소프트웨어 엔지니어: 자산 패키지 및 CI/CD 워크플로에 대한 모델 통합을 처리합니다.
  • 운영 또는 IT: 시스템 운영을 감독합니다.
  • 비즈니스 이해 관계자: 기계 학습 모델이 예측한 내용과 기계 학습 모델이 비즈니스에 얼마나 도움이 되는지 궁금합니다.
  • 데이터 최종 사용자: 비즈니스 결정을 내리는 데 도움이 되는 방식으로 모델 출력을 사용합니다.

팀은 가상 사용자 및 역할 연구에서 세 가지 주요 결과를 해결해야 했습니다.

  • 데이터 과학자와 엔지니어는 작업 방식과 기술이 일치하지 않습니다. 데이터 과학자와 엔지니어가 쉽게 협업할 수 있도록 하는 것은 MLOps 프로세스 흐름 디자인에 주요 고려 사항이 됩니다. 모든 팀원이 새로운 기술을 습득해야 합니다.
  • 누구도 소외시키지 않고 모든 기본 가상 사용자를 통합할 필요가 있습니다. 이 작업을 수행하는 방법은 다음과 같습니다.
    • 팀원이 MLOps에 대한 기본 모델을 이해하고 있는지 확인합니다.
    • 함께 작업하는 팀원에게 동의합니다.
    • 공통 목표를 달성하기 위한 작업 지침을 확립합니다.
  • 비즈니스 이해 관계자와 데이터 최종 사용자에게 모델의 데이터 출력과 상호 작용하는 방법이 필요한 경우 사용자 친화적 UI가 표준 솔루션입니다.

다른 팀은 프로덕션 용도로 스케일 업할 때 다른 기계 학습 프로젝트에서 유사한 문제에 직면하게 될 것입니다.

MLOps 솔루션 아키텍처

논리 아키텍처

논리적 MLOps 아키텍처 다이어그램

데이터는 다양한 형식의 여러 원본에서 제공되므로 데이터 레이크에 삽입하기 전에 조건부로 지정됩니다. 컨디셔닝은 Azure Functions로 작동하는 마이크로 서비스를 사용하여 수행됩니다. 클라이언트는 데이터 원본에 맞게 마이크로서비스를 사용자 지정하고 학습 및 채점 파이프라인이 사용하는 표준화된 CSV 형식으로 변환합니다.

시스템 아키텍처

MLOps에서 지원하는 시스템 아키텍처 다이어그램

일괄 처리 아키텍처

팀은 일괄 처리 데이터 처리 체계를 지원하는 아키텍처 설계를 고안했습니다. 대안이 있지만 사용되는 모든 항목은 MLOps 프로세스를 지원해야 합니다. 사용 가능한 Azure 서비스의 전체 사용은 설계 요구 사항이었습니다. 다음 다이어그램은 아키텍처를 보여 줍니다.

일괄 처리 아키텍처의 다이어그램

솔루션 개요

Azure Data Factory는 다음 작업을 수행합니다.

  • Azure 함수를 트리거하여 데이터 수집 및 Azure Machine Learning 파이프라인 실행을 시작합니다.
  • 지속성 함수를 시작하여 완료를 위해 Azure Machine Learning 파이프라인을 폴링합니다.

Power BI의 사용자 지정 대시보드에 결과가 표시됩니다. OpenCensus Python SDK를 통해 Azure SQL, Azure Monitor 및 App Insights에 연결된 다른 Azure 대시보드는 Azure 리소스를 추적합니다. 이러한 대시보드는 기계 학습 컴퓨터의 상태에 대한 정보를 제공합니다. 또한 클라이언트가 제품 주문 예측에 사용하는 데이터를 생성합니다.

모델 오케스트레이션

모델 오케스트레이션은 다음 단계를 따릅니다.

  1. PR이 제출되면 DevOps 코드 유효성 검사 파이프라인을 트리거합니다.
  2. 해당 파이프라인은 단위 테스트, 코드 품질 테스트 및 모델 유효성 검사 테스트를 실행합니다.
  3. 기본 분기에 병합되면 동일한 코드 유효성 검사 테스트가 실행되고 DevOps가 아티팩트를 패키지합니다.
  4. DevOps 아티팩트 수집은 Azure Machine Learning에서 다음을 수행하도록 트리거합니다.
    1. 데이터 유효성 검사.
    2. 학습 유효성 검사.
    3. 채점 유효성 검사.
  5. 유효성 검사가 완료되면 최종 채점 파이프라인이 실행됩니다.
  6. 데이터를 변경하고 새 PR을 제출하면 유효성 검사 파이프라인이 다시 트리거되고 그다음에 최종 채점 파이프라인이 트리거됩니다.

실험 사용

언급했듯이 기존 데이터 과학 기계 학습 수명 주기는 수정 없이 MLOps 프로세스를 지원하지 않습니다. 효과적인 CI/CD 프로세스를 위해 쉽게 스케일링할 수 없는 다양한 종류의 수동 도구와 실험, 유효성 검사, 패키지 및 모델 전달을 사용합니다. MLOps는 높은 수준의 프로세스 자동화를 요구합니다. 새로운 기계 학습 모델이 개발 중이든 기존 모델이 수정되든 상관없이 기계 학습 모델의 수명 주기를 자동화해야 합니다. 2단계 프로젝트에서 팀은 Azure DevOps를 사용하여 학습 작업을 위한 Azure Machine Learning 파이프라인을 조정하고 다시 게시합니다. 장기 실행 기본 분기는 모델의 기본 테스트를 수행하고 장기 실행 릴리스 분기를 통해 안정적인 릴리스를 푸시합니다.

원본 제어는 이 프로세스의 중요한 부분이 됩니다. Git은 Notebook 및 모델 코드를 추적하는 데 사용되는 버전 제어 시스템입니다. 또한 프로세스 자동화를 지원합니다. 원본 제어를 위해 구현된 기본 워크플로에는 다음 원칙이 적용됩니다.

  • 코드 및 데이터 세트에 정식 버전 관리를 사용합니다.
  • 코드가 완전히 개발되고 유효성이 검사될 때까지 새 코드 개발에 분기를 사용합니다.
  • 새 코드의 유효성을 검사한 후 기본 분기에 병합할 수 있습니다.
  • 릴리스의 경우 기본 분기와 별도의 영구 버전 분기가 만들어집니다.
  • 각 데이터 세트의 무결성을 보존할 수 있도록 학습 또는 사용량에 맞춰 조절한 데이터 세트에 대한 버전을 지정하고 원본 제어를 사용합니다.
  • 원본 제어를 사용하여 Jupyter Notebook 실험을 추적합니다.

데이터 원본과 통합

데이터 과학자는 다양한 원시 데이터 원본과 처리된 데이터 세트를 사용하여 다양한 기계 학습 모델을 실험합니다. 프로덕션 환경의 데이터 볼륨은 압도적일 수 있습니다. 데이터 과학자가 다양한 모델을 실험하려면 Azure Data Lake와 같은 관리 도구를 사용해야 했습니다. 공식 식별 및 버전 제어에 대한 요구 사항은 모든 원시 데이터, 준비된 데이터 세트 및 기계 학습 모델에 적용됩니다.

이 프로젝트에서 데이터 과학자는 모델에 입력하기 위해 다음 데이터를 조건화했습니다.

  • 2017년 1월 이후의 과거 주간 배송 데이터
  • 각 우편 번호에 대한 과거 및 예측 일일 날씨 데이터
  • 각 매장 ID에 대한 구매자 데이터

원본 제어와 통합

데이터 과학자가 엔지니어링 모범 사례를 적용하도록 하려면 GitHub와 같은 원본 제어 시스템과 함께 사용하는 도구를 쉽게 통합해야 합니다. 이를 통해 기계 학습 모델 버전 관리, 팀 구성원 간의 협업 및 팀에서 데이터 손실 또는 시스템 중단이 발생하는 경우 재해 복구를 수행할 수 있습니다.

모델 앙상블 지원

이 프로젝트의 모델 디자인은 앙상블 모델이었습니다. 즉, 데이터 과학자들은 최종 모델 설계에서 많은 알고리즘을 사용했습니다. 이 경우 모델은 동일한 기본 알고리즘 설계를 사용했습니다. 유일한 차이점은 다른 학습 데이터와 채점 데이터를 사용했다는 것입니다. 모델은 LASSO 선형 회귀 알고리즘과 인공신경망의 조합을 사용했습니다.

팀은 주어진 요청을 처리하는 프로덕션에서 실행되는 많은 실시간 모델을 지원하는 지점으로 프로세스를 진행하는 옵션을 모색했습니다. 이 옵션은 A/B 테스트 및 인터리브 실험에서 앙상블 모델의 사용을 수용할 수 있습니다.

최종 사용자 인터페이스

팀은 관찰 가능성, 모니터링 및 계측을 위한 최종 사용자 UI를 개발했습니다. 언급했듯이 대시보드는 기계 학습 모델 데이터를 시각적으로 표시합니다. 이러한 대시보드는 사용자에게 친숙한 형식으로 다음 데이터를 표시합니다.

  • 입력 데이터 사전 처리를 포함한 파이프라인 단계
  • 기계 학습 모델 처리의 상태를 모니터링하려면 다음을 수행합니다.
    • 배포된 모델에서 어떤 메트릭을 수집하나요?
      • MAPE: 평균 절대 백분율 오류, 전체 실적을 추적하기 위한 핵심 메트릭입니다. (각 모델에 대해 MAPE 값 <= 0.45를 대상 지정합니다.)
      • RMSE 0: 실제 대상 값이 0일 때 RMSE(제곱 평균 오차)
      • RMSE 전체: 전체 데이터 세트의 RMSE
    • 모델이 프로덕션에서 예상대로 수행되고 있는지 어떻게 평가합니까?
    • 프로덕션 데이터가 예상 값에서 너무 많이 벗어나 있는지 알 수 있는 방법이 있나요?
    • 사용자의 모델이 프로덕션에서 제대로 작동하지 않나요?
    • 장애 조치(failover) 상태가 있나요?
  • 처리된 데이터의 품질을 추적합니다.
  • 기계 학습 모델에서 생성된 점수/예측을 표시합니다.

애플리케이션은 데이터의 특성과 데이터 처리 및 분석 방법에 따라 대시보드를 채웁니다. 따라서 팀은 각 사용 사례에 대한 정확한 대시보드 레이아웃을 설계해야 합니다. 다음은 두 개의 샘플 대시보드입니다.

기계 학습 대시보드의 샘플 스크린샷

기계 학습 모니터링 대시보드의 샘플 스크린샷

대시보드는 기계 학습 모델 예측의 최종 사용자가 쉽게 사용할 수 있는 정보를 제공하도록 설계되었습니다.

참고

부실 모델은 데이터 과학자가 채점이 발생한 날로부터 60일 이상 채점에 사용된 모델을 학습시킨 채점 실행입니다. ML 모니터 대시보드의 채점 페이지에 이 상태 메트릭이 표시됩니다.

구성 요소

고려 사항

여기에서 탐색할 고려 사항 목록을 찾을 수 있습니다. CSE 팀이 프로젝트 중에 배운 교훈을 기반으로 합니다.

환경 고려 사항

  • 데이터 과학자는 종종 Jupyter Notebook부터 시작하여 Python을 사용해 대부분의 기계 학습 모델을 개발합니다. 이러한 Notebooks를 프로덕션 코드로 구현하는 것은 어려울 수 있습니다. Jupyter Notebooks는 실험적인 도구에 가깝지만 Python 스크립트는 프로덕션에 더 적합합니다. 팀은 종종 모델 만들기 코드를 Python 스크립트로 리팩터링하는 데 시간을 할애해야 합니다.
  • DevOps 및 기계 학습을 처음 접하는 클라이언트가 실험 및 프로덕션에는 서로 다른 엄격함이 필요하다는 것을 인식하도록 하여 두 가지를 분리하는 것이 좋습니다.
  • Azure Machine Learning Visual Designer 또는 AutoML과 같은 도구는 기본 모델을 시작하는 데 효과적일 수 있으며 클라이언트는 나머지 솔루션에 적용할 표준 DevOps 관행을 강화할 수 있습니다.
  • Azure DevOps에는 파이프라인 단계를 트리거하는 데 도움이 되도록 Azure Machine Learning과 통합할 수 있는 플러그 인이 있습니다. MLOpsPython 리포지토리에는 이러한 파이프라인의 몇 가지 예가 있습니다.
  • 기계 학습에는 학습을 위해 강력한 GPU(그래픽 처리 장치) 컴퓨터가 필요한 경우가 많습니다. 클라이언트에 사용 가능한 하드웨어가 아직 없는 경우 Azure Machine Learning 컴퓨팅 클러스터를 사용하는 것이 자동 크기 조정되는 비용 효율적인 강력한 하드웨어를 신속하게 프로비저닝하기 위한 효과적인 경로입니다. 클라이언트에 고급 보안 및/또는 모니터링 요구 사항이 필요한 경우 표준 VM, Databricks 또는 로컬 컴퓨팅 사용과 같은 다른 옵션이 있습니다.
  • 클라이언트가 성공하려면 모델 구축 팀(데이터 과학자)과 배포 팀(DevOps 엔지니어)에 강력한 통신 채널이 있어야 합니다. 일상적인 스탠드 업 모임이나 공식 온라인 채팅 서비스를 통해 이를 달성할 수 있습니다. 두 접근 방식 모두 MLOps 프레임워크에서 개발 활동을 통합하는 데 도움이 됩니다.

데이터 준비 고려 사항

  • Azure Machine Learning을 사용하는 가장 간단한 솔루션은 지원되는 데이터 스토리지 솔루션에 데이터를 저장하는 것입니다. Azure Data Factory와 같은 도구는 일정에 따라 해당 위치에서 데이터를 파이핑하는 데 효과적입니다.

  • 클라이언트는 모델을 최신 상태로 유지하기 위해 추가 재학습 데이터를 자주 캡처해야 합니다. 데이터 파이프라인이 아직 없는 경우 새로 만드는 것이 전체 솔루션의 중요한 부분이 될 것입니다. Azure Machine Learning의 데이터 세트와 같은 솔루션을 사용하면 모델의 추적 가능성을 돕기 위해 데이터 버전을 관리하는 데 유용할 수 있습니다.

모델 학습 및 평가 고려 사항

  • 기계 학습 여정을 이제 막 시작하는 클라이언트가 전체 MLOps 파이프라인을 구현하려고 하는 것은 부담스러울 수 있습니다. 필요한 경우 Azure Machine Learning을 사용하여 실험 실행을 추적하고 Azure Machine Learning 컴퓨팅을 학습 대상으로 사용하여 쉽게 사용할 수 있습니다. 이러한 옵션은 Azure 서비스 통합을 시작하기 위해 더 낮은 진입 장벽을 만들 수 있습니다.

  • Notebook 실험에서 반복 가능한 스크립트로의 전환은 많은 데이터 과학자에게 다소 힘든 전환입니다. Python 스크립트에서 학습 코드를 더 빨리 작성할수록 학습 코드의 버전 관리 및 재학습을 더 쉽게 시작할 수 있습니다.

    이것이 가능한 유일한 방법은 아닙니다. Databricks는 Notebooks 일정을 작업으로 지원합니다. 그러나 현재 클라이언트 환경에 따르면 이 접근 방식은 테스트 제한으로 인해 전체 DevOps 방식으로 계측하기 어렵습니다.

  • 모델의 성공 여부를 판단하기 위해 어떤 메트릭이 사용되는지 이해하는 것도 중요합니다. 정확도만으로는 한 모델과 다른 모델의 전체 성능을 결정하기에 충분하지 않은 경우가 많습니다.

컴퓨팅 고려 사항

  • 고객은 컨테이너를 사용하여 컴퓨팅 환경을 표준화하는 것을 고려해야 합니다. 거의 모든 Azure Machine Learning 컴퓨팅 대상은 Docker 사용을 지원합니다. 컨테이너가 종속성을 처리하게 되면 특히 팀에서 많은 컴퓨팅 대상을 사용하는 경우 마찰을 크게 줄일 수 있습니다.

모델 제공 고려 사항

  • Azure Machine Learning SDK는 등록된 모델에서 Azure Kubernetes Service에 직접 배포하는 옵션을 제공하여 적용되는 보안/메트릭에 대한 제한을 만듭니다. 클라이언트가 모델을 테스트할 수 있는 더 쉬운 솔루션을 찾아보려고 할 수 있지만 프로덕션 워크로드를 위해 AKS에 대한 보다 강력한 배포를 개발하는 것이 가장 좋습니다.

다음 단계