Bkkhyunn

Bkkhyunn

배움과 경험을 기록하고,
세상과 사람을 매개하는
AI 개발자가 되기까지

[MLOps] 1. MLOps 란?

MLOps: Continuous delivery and automation pipelines in machine learning

  • 구글 클라우드에서 제공하는 링크에 들어가면 MLOps 에 대한 기본적 개념과 그 흐름을 알 수 있다.
  • 이 문서는 ML system 을 위한 Continuous Integration(CI), Continuous Delivery(CD), Continuous Training(CT)를 구현하고 자동화하는 기술에 대해 설명한다.
  • Data Science 및 ML 은 복잡한 현실의 문제를 해결하고 산업을 변화시키며 모든 도메인에서 가치를 제공하는 핵심 능력이 되고 있다. 효과적인 ML 적용을 위한 재료들은 다음과 같다.
    • Large Datasets
    • 저렴한 on-demand 컴퓨팅 리소스
    • 다양한 클라우드 플랫폼의 ML 을 위한 도구
    • ML 연구 분야의 빠른 발전(CV, NLP, 추천 시스템 등)
  • 많은 비즈니스에서 Data Science 팀 및 ML 능력에 투자하여 고객에게 비즈니스 가치를 제공할 수 있는 모델을 개발하고 있다.
  • 이 문서는 DevOps 원칙을 ML 시스템(MLOps)에 적용하려는 Data Scientist 및 ML Engineer 를 위한 문서다.
  • MLOps 는 ML 시스템 개발(Dev) 및 ML 시스템 운영(Ops)을 통합하는 것을 목표로 하는 ML 엔지니어링 문화와 관행이다.
  • MLOps 를 수행한다는 것은 통합, 테스트, 릴리즈, 배포 및 인프라 관리를 포함한 ML 시스템 구축의 모든 단계에서 자동화 및 모니터링을 해야한다는 것을 의미한다.
  • Data Scientist 들은 관련 학습 데이터를 받아 오프라인 홀드아웃 데이터셋에서 성능을 갖춘 ML 모델을 구현하고 학습할 수 있다. 그러나 문제는 ML 모델을 만드는 것이 아니라, 통합된 ML 시스템을 구축해 프러덕션 환경에서 지속적으로 운영하는 것이다.
  • Google 은 오랜 프러덕션 ML 서비스를 통해, 프러덕션에서 ML 기반 시스템을 운영하는데 많은 함정이 있을 수 있는 것을 알게되었다.

  • 아래 다이어그램에서 볼 수 있듯, 실제 ML 시스템에서 ML 코드는 일부에 불과하다. 필요한 요소는 매우 많고 복잡하다.

    Untitled그림 1. ML 시스템의 요소

  • ML 코드를 제외하고 configureation, 자동화, 데이터 수집, 데이터 검증, feature engineering, 테스트 및 디버깅, 리소스 관리, 모델 분석, 프로세스 및 메타 데이터 관리, 서빙 인프라 및 모니터링이 ML 시스템에 포함되어 있다.
  • 이런 복잡한 시스템을 개발하고 운영하기 위해 MLOps 에 DevOps 원칙을 적용할 수 있다. 이 문서는 Data Science 실무를 위해 MLOps 환경을 설정할 때 고려해야 할 ML 의 CI, CD, CT 와 같은 개념을 다룬다.
    • DevOps vs MLOps
    • ML 모델 개발의 단계
    • MLOps 성숙도

DevOps vs MLOps

  • DevOps 는 대규모 소프트웨어 시스템을 개발하고 운영할 때 많이 사용하는 관행이다.
  • 이 방법은 개발주기 단축, 배포 속도 향상 및 신뢰할 수 있는 릴리즈와 같은 이점을 제공한다. 이런 이점을 달성하기 위해 소프트웨어 시스템 개발에서 아래 두 가지 개념을 사용한다.
  • ML 시스템은 소프트웨어 시스템이므로 ML 시스템을 안정적으로 구축하고 운영하는데 DevOps 와 유사한 관행이 도움이 된다. 그러나, ML 시스템은 아래와 같은 이유로 다른 소프트웨어 시스템과 다르다.
    • Team Skills
      • ML 프로젝트를 담당하는 팀에는 일반적으로 EDA, 모델 개발 및 실험에 중점을 둔 Data Scientist 또는 ML researcher 로 구성된다.
      • 이 멤버는 프로덕션급 서비스를 구축할 수 있는 숙련된 소프트웨어 엔지니어가 아닐 수도 있다.
    • Development
      • ML 은 본질적으로 실험이다. 풀고자 하는 문제에 가장 적합한 것을 찾기 위해 다른 feature, 알고리즘, 모델링 기술 및 파라미터 구성을 시도한다.
      • 이 때 무엇이 효과가 있었고 그렇지 않았는지를 추적해야 하고 코드 재사용을 최대화하면서 재현성을 유지하는 것이 중요하다.
    • Testing
      • ML 시스템 테스트는 다른 소프트웨어 시스템 테스트보다 더 복잡하다. 일반적인 단위 및 통합 테스트 외에도 데이터 검증, 훈련 후 모델 품질 평가 및 모델 검증이 필요하다.
    • Deployment
      • ML 시스템에서 배포는 오프라인에서 ML 모델을 훈련하고 배포하는 간단한 과정이 아니다.
      • ML 시스템은 자동으로 모델을 재학습하고 배포하기 위해 다단계 파이프라인을 구축이 필요하다.
      • 이 파이프라인은 복잡하지만 Data Scientist 가 새롭게 학습하고 검증한 모델을 배포하기 전에 수동으로 수행하던 단계를 자동화해야 한다.
    • Proudction
      • ML 모델은 최적이 아닌 코딩 뿐만 아니라 지속적으로 변화하는 데이터 프로파일 때문에도 성능이 저하될 수 있다.
      • 즉, 모델들이 기존 소프트웨어 시스템보다 더 많은 방식으로 붕괴될 수 있다.
      • 이런 성능 저하를 고려해야할 필요가 있고, 따라서 발생하는 데이터의 통계치를 추적하고 모델의 온라인 성능을 모니터링해야 한다. 이 때 값이 예상치를 벗어날 때 알림을 보내거나 롤백해야 한다.
  • continuous integration(CI - 소스 제어, 단위 및 통합 테스트) 과 continuous delivery(CD - 소프트웨어 모듈 또는 패키지)에서 ML 및 다른 소프트웨어 시스템은 유사하다. 그러나 ML 에서는 몇 가지 주목해야 할 점이 있다.
    • ML 시스템에서 CI 는 코드와 구성 모듈 등을 테스트하고 검증하는 것 뿐만 아니라, 데이터, 데이터 스키마 및 모델을 테스트하고 검증하는 역할도 한다.
    • ML 시스템에서 CD 는 더 이상 단일 소프트웨어 패키지나 서비스가 아니라 모델 예측과 같은 다른 서비스를 자동으로 배포해야 하는 시스템(ML 학습 파이프라인)에 관한 것이다.
    • CT 는 ML 시스템의 고유한 속성으로, 모델을 자동으로 재학습하고 서빙하는 것과 관련이 있다.

Data science steps for ML

  • 모든 ML 프로젝트는 비즈니스 사용 사례를 정의하고 성공 기준을 설정한 후, ML 모델을 제품으로 만드는 아래의 과정을 포함한다(일반적으로). 이 과정들은 수동으로 완료하거나 자동 파이프라인을 통해 완료할 수 있다.
    • 데이터 추출 : ML Task 를 위해서 다양한 데이터 소스에서 관련 데이터를 선택하고 통합한다.
    • 데이터 분석 : ML 모델 구축에 사용 가능한 데이터를 이해하기 위해서 탐색적 데이터 분석(EDA)을 수행한다. 이 과정은 다음과 같다.
      • 모델에서 기대하는 데이터 스키마 및 데이터 특성 이해
      • 모델에 필요한 데이터 준비 및 feature engineering 식별
    • 데이터 준비 : ML Task 를 위해 데이터를 준비한다. 여기에는 데이터 정리가 포함되며 데이터를 학습, 검증, 테스트 세트로 분할한다. 또한 해당 task를 해결하기 위해 데이터 변환 및 feature engineering 을 적용한다. 이 단계의 결과물은 준비된 형식으로 분할된 데이터다.
    • 모델 학습 : Data Scientist 는 다양한 알고리즘을 구현해서 준비된 데이터로 다양한 ML 모델을 학습한다. 또한 구현된 알고리즘을 하이퍼 파라미터 튜닝해서 최상의 성능을 갖는 ML 모델을 얻는다. 이 단계의 결과는 훈련된 모델이다.
    • 모델 평가 : 모델 품질을 평가하기 위해서 홀드 아웃 테스트 세트에서 모델을 평가한다. 이 단계를 통해 모델의 품질을 평가하기 위한 metric 을 얻을 수 있다.
    • 모델 검증 : 모델이 특정 베이스라인보다 성능이 우수하면 배포에 적합한 것으로 확인된다.
    • 모델 서빙 : 검증된 모델은 예측 서비스를 위해 대상 환경에 배포된다. 이 배포는 다음 중 하나일 수 있다.
      • 온라인 예측을 제공하기 위한 REST API 가 포함된 마이크로 서비스
      • 엣지 또는 모바일 장치에 내장된 모델
      • 배치 예측 시스템의 일부
    • 모델 모니터링 : ML 프로세스에서 새로운 이터레이션을 잠재적으로 실행하기 위해 모델 예측 성능을 모니터링한다.
  • ML 프로세스의 성숙도는 이런 단계들의 자동화 수준을 의미한다.
  • 또한 ML 프로세스의 성숙도는 새로운 데이터를 제공하거나 새로운 모델을 학습하는 속도를 반영한다.
  • 아래부터는 자동화를 수반하지 않는 가장 일반적인 레벨에서부터, ML 및 CI/CD 파이프라인을 자동화하는 3가지 MLOps 레벨에 대해 살펴보자.

MLOps Level 0 : 수동 프로세스

  • 많은 팀들이 SOTA 모델을 만들 수 있는 Data Scientist 와 ML 연구자들을 보유하고 있지만, ML 모델을 만들고 배치하는 과정은 전적으로 수동적이다.

  • 즉 MLOps 성숙도의 기본 수준, 레벨 0으로 간주된다. 다음 다이어그램은 이 단계의 워크플로우를 보여준다.

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

특징

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

도전 과제

  • MLOps 레벨 0은 ML 을 상황에 맞게 적용하기 시작하는 많은 기업에서 흔히 볼 수 있다.
  • 이러한 수동적이고 Data Scientist-driven 한 프로세스는 모델이 거의 변경되거나 학습되지 않을 경우에 충분할 수 있다.
  • 실제로 모델들은 실제로 배포될 때 깨지는 경우가 많다. 모델은 배포된 환경의 다이나믹한 변화나 데이터의 변화에 적응하지 못한다.
  • 이런 문제를 해결하고 프러덕션 환경에서 모델의 정확성을 유지하려면 다음을 수행해야 한다.
    • 프로덕션 환경에서 모델의 품질을 적극적으로 모니터링한다.
      • 모니터링을 통해 성능 저하 및 모델 지속성을 감지할 수 있다.
      • 이는 새로운 실험 반복과 새로운 데이터에 대한 모델 재학습(수동 학습)의 신호로 작용한다.
    • 프러덕션 모델을 자주 재학습
      • 진화하는 패턴을 포착하려면 최신 데이터를 사용해 모델을 재학습 해야한다.
      • 예를 들어 앱이 ML 을 사용해 패션 제품을 추천하는 경우 해당 추천은 최신 트렌드 및 제품에 맞게 조정되어야 한다.
    • 모델을 제작하기 위한 새로운 구현을 지속적으로 실험
      • 최신 아이디어와 기술의 진보를 활용하려면 feature engineering, 모델 아키텍처 및 하이퍼 파라미터와 같은 새로운 구현을 시도해야 한다.
      • 예를 들어, 얼굴 탐지에 컴퓨터 비전을 활용할 때 얼굴의 패턴은 고정되어 있지만 탐지 정확도를 더 개선시킬 수 있는 새로운 기술이 있을 수 있다.
  • 이 수동 방법의 문제를 해결하기 위해서는 CI/CD 및 CT 에 대한 MLOps 관행이 도움이 된다.
  • ML 학습 파이프라인을 배포하여 CT 를 활성화할 수 있고, ML 파이프라인의 새로운 구현을 신속하게 테스트, 구축 및 배포할 수 있도록 CI/CD 시스템을 설정할 수 있다. 이런 특징들은 다음 섹션에서 더 자세히 설명된다.

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

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

  • 다음 그림은 CT 를 위한 자동 ML 파이프라인을 나타낸 것이다.

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

특징

  • 다음 목록은 그림 3과 같이 MLOps 레벨 1의 특징이다.
    • 빠른 실험
      • ML 실험의 단계들이 조정된다. 단계 간 전환이 자동화되어 실험 반복이 빨라지고, 전체 파이프라인을 프로덕션으로 전환할 준비가 더 잘된다.
    • 프로덕션 모델의 CT
      • 모델은 라이브 파이프라인 트리거를 기반으로 최신 데이터를 사용해 프로덕션 환경에서 자동으로 학습된다.
    • 실험-운영 환경의 조화
      • 개발 또는 실험 환경 안에서 사용되던 파이프라인은 사전 프로덕션(preproduction) 및 프로덕션 환경에서도 사용된다.
      • 이는 DevOps 를 통합하기 위한 MLOps 관행의 핵심 부분이다.
    • 구성 요소 및 파이프라인을 위한 모듈화된 코드
      • ML 파이프라인을 구축하기 위해서는 컴포넌트가 재사용 가능하고, 합성 가능하며, 잠재적으로 ML 파이프라인 간에 공유 가능해야 한다.
      • 따라서 EDA 코드가 노트북에 여전히 존재할 수 있지만, 컴포넌트의 소스 코드는 모듈화되어야 한다. 또한 컴포넌트는 아래 작업을 수행하기 위해서 컨테이너화 되어야한다.
        • 커스텀 코드 런타임에서 실행 환경을 분리하기.
        • 개발(development) 환경과 프로덕션 환경 간에 재현 가능한 코드 만들기.
        • 파이프라인에서 각 구성 요소를 분리하기. 구성 요소는 자체 버전의 런타임 환경을 가질 수 있으며, 서로 다른 언어와 라이브러리를 가질 수 있다.
    • CD
      • 프러덕션의 ML 파이프라인은 새로운 데이터로 학습된 새로운 모델에 대한 예측 서비스를 지속적으로 제공한다.
      • 온라인 예측을 위해서 예측 서비스로 학습되고 검증된 모델을 제공하는 모델 배포 단계가 자동화된다.
    • 파이프라인 배포
      • 레벨 0 에서는 학습된 모델을 프로덕션에 예측 서비스로 배포한다.
      • 레벨 1 의 경우 학습된 모델을 예측 서비스로 제공하기 위해 자동 및 순환적으로 실행되는 전체 학습 파이프라인을 배포한다.

추가 구성 요소

  • 여기서는 ML continuous training(CT) 을 사용하기 위해 아키텍처에 추가해야 하는 구성 요소에 대해 설명한다.

    Data and model validation

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

    Feature store

    • 레벨 1 ML 파이프라인 자동화를 위한 선택적인 추가 구성 요소는 feature store 다.
    • feature store 는 학습 및 서비스를 위한 feature 의 정의, 저장 및 액세스를 표준화하는 중앙 집중식 저장소다.
    • 또한 feature store 는 feature 값에 대해 처리량이 많은 배치 처리 서비스와 지연 시간이 짧은 실시간 서비스를 위한 API 를 제공해야 하고, 두 서비스 유형 모두 학습 및 서빙 워크로드를 지원해야 한다.
    • Feature store 는 다음 역할을 수행하면서 Data Scientist 를 도와준다.
      • 동일하거나 유사한 feature 를 재생성하지 않고, 사용 가능한 feature set 을 발견하거나 재사용한다.
      • feature 와 관련된 메타 데이터를 유지해서, 정의가 다른 비슷한 feature 를 사용하지 않는다.
      • feature store 에서 최신 feature 값을 제공한다.
      • feature store 를 실험, CT 및 온라인 서빙을 위한 데이터 소스로 사용함으로써 training-serving skew 를 피한다. 이 방법을 사용하면 학습에 사용되는 feature 가 서빙 중 사용되는 feature 와 동일해진다.
        • 실험을 위해, Data Scientist 는 feature store 에서 오프라인으로 데이터를 추출하고 실험할 수 있다.
        • CT 를 위해, 자동화된 ML 학습 파이프라인은 모델 학습에 사용되는 데이터셋의 최신 feature 값을 배치 단위로 가져올 수 있다.
        • 온라인 예측의 경우, 예측 서비스는 고객의 인구통계적 feature, 제품 feature, 현재 세션 집계 feature 와 같이 요청된 엔티티와 관련된 feature 를 배치 단위로 가져올 수 있다.

    Metadata management

    • ML 파이프라인의 각 실행 정보는 데이터 및 artifacts, 재현성 및 비교를 돕기 위해 기록된다. 또한 오류 및 이상치를 디버깅하는데 도움이 된다. 파이프라인을 실행할 때마다 ML 메타 데이터 저장소는 아래의 메타 데이터를 기록한다.
      • 실행된 파이프라인 및 구성 요소 버전
      • 파이프라인의 시작 및 종료 날짜, 시간 그리고 파이프라인이 각 단계를 완료하는데 걸린 시간
      • 파이프라인의 실행기(executor)
      • 파이프라인에 전달된 파라미터
      • 준비된 데이터의 위치, 이상치 검증 결과, 계산된 통계, 범주형 feature 에서 추출된 어휘 등, 파이프라인의 각 단계에서 생성된 artifatcs 가리키는 포인터를 기록한다.
        • 이런 중간 출력을 추적하면 이미 완료된 단계를 다시 실행할 필요없이, 실패로 인해 중단된 경우 가장 최근 단계의 파이프라인부터 실행할 수 있다.
      • 이전 모델 버전으로 롤백해야 하는 경우 또는 모델 검증 단계에서 파이프라인에 새로운 테스트 데이터가 주어졌을 때 이전 모델 버전에 대한 평가 metric 을 생성해야 하는 경우, 이전에 학습된 모델을 가리키는 포인터를 기록한다.
      • 학습 및 테스트 세트 모두에 대해 모델 평가 단계에서 생성된 모델 평가 지표를 기록한다.
        • 이런 평가 지표를 사용하면 모델 검증 단계에서 새로 훈련된 모델의 성능과 이전 모델의 성능을 비교할 수 있다.

    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 시스템을 통해 Data Scientist 는 feature engineering, 모델 아키텍처 및 하이퍼 파라미터에 대한 새로운 아이디어를 신속하게 탐색할 수 있다.
  • 이런 아이디어를 구현하고 새로운 파이프라인 구성 요소를 대상 환경에 자동으로 빌드, 테스트, 배포할 수 있다.

  • 다음 다이어그램은 자동화된 ML 파이프라인 설정과 자동화된 CI/CD 루틴을 가지는 CI/CD 를 사용하느 ML 파이프라인의 구현을 보여준다.

    Untitled그림 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 자동화 파이프라인의 단계를 보여준다.

    Untitled그림 5. 자동화된 ML 파이프라인의 CI/CD 단계

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

Continuous integration(지속적인 통합)

  • CI 를 통해서 새로운 코드가 소스 코드 저장소로 커밋되거나 푸시될 때 파이프라인과 구성 요소가 빌드되고, 테스트되고, 패키지된다.
  • CI 프로세스에는 패키지, 컨테이너 이미지, 실행 파일을 빌드하는 것 외에도 다음 테스트가 포함될 수 있다.
    • Feature engineering 로직을 단위 테스트한다.
    • 모델에 구현된 다양한 메소드들을 단위 테스트한다.
      • 예를 들어, 범주형 데이터 컬럼을 가져오는 함수가 있으며 이 함수를 one-hot feature 로 인코딩하는 방법을 테스트한다.
    • 모델 학습이 수렴되는지 테스트한다.
      • 즉, 모델의 loss 가 이터레이션에 의해 감소하는지 그리고 일부 샘플 레코드에 오버피팅되는지를 테스트한다.
    • 모델 학습에서 0 으로 나누거나 작거나 큰 값을 조작해 NaN 값을 생성하지 않는지 테스트한다.
    • 파이프라인의 각 구성 요소를 테스트해 예상 아티팩트가 생성되는지 확인한다.
    • 파이프라인 구성 요소 간의 통합 테스트

Continuous delivery(지속적인 전달)

  • MLOps 레벨 2에서, 해당 시스템은 대상 환경에 새로운 파이프라인 구현을 지속적으로 배포하고 새로 학습된 모델의 예측 서비스를 제공한다.
  • 파이프라인 및 모델을 빠르고 안정적이고 지속적으로 제공하려면 다음을 고려해야 한다.
    • 모델을 배포하기 전에 대상 인프라와 모델의 호환성 확인
      • 예를 들어, 모델에 필요한 패키지가 서빙 환경에 설치되어 있고 예측에 필요한 메모리, 컴퓨팅 및 가속기 자원이 있는지 확인해야 한다.
    • 기대되는(알맞은) input 으로 서비스 API 를 호출해서 예측 서비스를 테스트하고, 예상되는 응답을 얻는지 테스트해야 한다.
      • 이 테스트는 일반적으로 모델 버전을 업데이트할 때 발생할 수 있는 문제들을 포착하고, 다른 입력을 기대한다.
    • 예측 서비스 성능 테스트
      • 이 테스트에는 QPS(Queries per second), model latency 와 같은 지표들을 파악하기 위해서 서비스를 로드 테스트하는 것을 포함한다.
    • 재학습 또는 배치 단위 예측을 위한 데이터 검증
    • 모델이 배포되기 전에 예측 성능 목표를 충족하는지 확인
    • 테스트 환경에 대한 자동 배포(ex. dev 브랜치에 코드를 푸시하여 트리거되는 배포)
    • 사전 프로덕션 환경에 대한 semi-자동 배포(ex. 리뷰어가 변경 사항을 승인한 후 코드를 main 브랜치에 merge 해서 트리거되는 배포)
    • 사전 프로덕션 환경에서 파이프라인을 여러 번 성공적으로 실행한 후 프로덕션 환경에 수동 배포
  • 요약하면, 프로덕션 환경에서 ML 을 구현하는 것은 모델을 예측용 API 로 배포하는 것만 의미하지 않는다. 오히려 새로운 모델의 재학습 및 배포를 자동화할 수 있는 ML 파이프라인 배포를 의미한다. CI/CD 시스템을 구축하면 새로운 파이프라인 구현을 자동으로 테스트하고 배포할 수 있다.
  • 이 시스템을 사용하면 데이터 및 비즈니스 환경의 빠른 변화에 대처할 수 있다. 모든 프로세스를 MLOps 의 다른 레벨로 즉시 이동할 필요는 없다. ML 시스템 개발 및 생산의 자동화를 개선하기 위해 이러한 관행을 점차 구현할 수 있다.
맨 위로 이동 ↑

댓글 남기기

관련 게시글