MLOps 기본 개념

개요

---

MLOps를 구현할 기회가 생겨서 알아보던 중에 기본적인 개념 정도는 정리를 하고 들어가야 할 것 같아서 찾아보던 중에, GCP에서 제공하는 좋은 문서가 있어서 이를 공부하면서 정리해보는 느낌으로 게시글을 작성하려 합니다.

 

아예 AI 쪽으로는 문외한이라 가장 기본적인 부분부터 작성될 예정이니, 이 글을 보실 분들도 참고해주시면 좋을 것 같습니다.

 

참고한 문서는 아래와 같습니다.

https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning?hl=ko

MLOps: 머신러닝의 지속적 배포 및 자동화 파이프라인  |  클라우드 아키텍처 센터  |  Google Cloud

 

MLOps: 머신러닝의 지속적 배포 

---

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

 

DevOps 원칙

1. DevOps란 클라우드 데이터 센터의 운영 환경에서 소프트웨어 코드의 개발과 운영에 관련된 폭넓은 활동을 의미합니다.
2. DevOps는 민첩한 프로젝트 관리 기법과 마이크로 서비스 지원을 중심으로 합니다.
3. DevOps는 버전 제어 표준에 따른 자동화를 통해 소프트웨어 개발 수명주기 전체에 적용됩니다.
4. DevOps에서 가장 흔히 사용되는 버전 제어 솔루션은 Git이며, Subversion과 CVS가 그 뒤를 따르고 있습니다.
5. DevOps에는 소프트웨어 수명 주기, 자동화된 코드 테스팅, 컨테이너 조정, 클라우드 호스팅, 데이터 분석에 대한 CI/CD 요구 사항 관리가 포함됩니다.

 

데이터 과학자는 사용 사례에 대한 특정한 관련 학습 데이터를 고려하여 오프라인 홀드아웃 데이터 세트에서 예측 성능을 갖춘 ML 모델을 구현하고 학습시킬 수 있습니다. 하지만 실제 도전 과제는 ML 모델을 빌드하지 않으며, 이러한 도전 과제는 프로덕션 단계에서 지속적으로 통합 시스템을 운영하기 위해 이를 빌드합니다. 하지만 실제 프로덕션 단계에서 ML 기반 시스템을 운영하는 데에는 예상치 못한 많은 문제가 발생할 수 있습니다. 그 반증으로, 실제 ML 시스템에서 ML 코드가 차지하는 부분은 일부에 지나지 않습니다.

ML 시스템의요소

 

홀드아웃 데이터 세트

- 아래 과정을 통해 머신을 학습시키는 과정을 홀드아웃 데이터 세트라 칭함
- 학습 데이터 세트로만 알고리즘을 학습
- 검증 데이터 세트로 알고리즘의 하이퍼 파라미터를 튜닝
- 기대 성능이 달성될 때까지 1, 2번을 반복적으로 수행
- 알고리즘과 하이퍼 파라미터를 고정하고, 테스트 데이터 세트로 성능을 평가

하이퍼 파라미터

- 네트워크를 구성하는 레이어 수, 학습률 등등을 가리킵니다. 일반적으로 수동으로 변경됩니다.

 

DevOps와 MLOps 비교

---

DevOps는 대규모 소프트웨어 시스템을 개발하고 운영하는데 널리 사용됩니다. 이 방식은 개발 주기 단축, 배포 속도 증가, 안정적인 출시 등의 이점을 제공합니다. 이러한 이점을 누리려면 소프트웨어 시스템 개발에 다음의 두 가지 개념을 도입합니다.

 

지속적 통합 (CI)
지속적 배포 (CD)

 

ML 시스템은 소프트웨어 시스템이므로 규모에 맞춰 시스템을 안정적으로 빌드하고 운영할 수 있도록 유사한 방식이 적용되지만, 다음과 같은 점에서 다른 소프트웨어 시스템과는 다릅니다.

 

팀 기술: ML 프로젝트에서 팀은 일반적으로 탐색적 데이터 분석, 모델 개발, 실험에 중점을 두는 데이터 과학자 또는 ML 연구원을 포함합니다. 이러한 구성원 중에는 프로덕션 수준의 서비스를 빌드 가능한 소프트웨어 엔지니어가 없을 수도 있습니다.

개발: ML은 기본적으로 실험적입니다. 특성, 알고리즘, 모델링 기법, 매개변수 구성을 다양하게 시도하여 문제에 가장 적합한 것을 최대한 빨리 찾아야 합니다. 도전과제는 효과가 있었던 것과 그렇지 않은 것을 추적하고, 코드 재사용성을 극대화하면서 재현성을 유지합니다.

테스트: ML 시스템 테스트는 다른 소프트웨어 시스템 테스트보다 더 복잡합니다. 일반적인 단위 및 통합 테스트 외에도 데이터 검증, 학습된 모델 품질 평가, 모델 검증이 필요합니다.

배포: ML 시스템에서 배포는 오프라인으로 학습된 ML 모델을 예측 서비스로 배포하는 것만큼 간단하지 않습니다. ML 시스템을 사용하면 모델을 자동으로 재학습시키고 배포하기 위해 다단계 파이프라인을 배포해야 할 수 있습니다. 복잡성을 추가하는 이 파이프라인을 사용하면 데이터 과학자가 배포하기 전 새 모델을 학습시키고 검증하기 위해 수동으로 수행되어야 하는 단계를 자동화해야 합니다.

프로덕션: ML 모델은 최적화되지 않은 코딩뿐만 아니라 지속적으로 진화하는 데이터 프로필로 인해 성능이 저하될 수 있습니다. 즉, 모델은 기존 소프트웨어 시스템보다 다양한 방식으로 손상될 수 있기 때문에 이러한 저하를 고려해야 합니다. 따라서 데이터의 요약 통계를 추적하고 모델의 온라인 성능을 모니터링하여 값이 기대치를 벗어나면 알림을 전송하거나 롤백해야 합니다.

 

ML 및 기타 소프트웨어 시스템은 소스 제어의 지속적 통합, 단위 테스트, 통합 테스트, 소프트웨어 모듈 또는 패키지의 지속적 배포가 유사합니다. 그러나 ML에서는 몇 가지 주목할 만한 차이점이 있습니다.

 

CI는 더 이상 코드 및 구성요소만 테스트하고 검증하는 것이 아니라 데이터, 데이터 스키마, 모델도 테스트하고 검증하는 것입니다.

CD는 더 이상 단일 소프트웨어 패키지 또는 서비스만이 아니라 다른 서비스(모델 예측 서비스)를 자동으로 배포해야 하는 시스템(ML 학습 파이프라인)입니다.

CT는 ML 시스템에 고유한 새 속성으로, 모델을 자동으로 재학습시키고 서빙하는 데 사용됩니다.

 

ML을 위한 데이터 과학 단계

---

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

 

1. 데이터 추출: ML 태스크를 위해 다양한 데이터 소스에서 관련 데이터를 선택하고 통합합니다.

2. 데이터 분석: ML 모델을 빌드하는데 사용할 수 있는 데이터를 이해하기 위해 탐사적 데이터 분석을 수행합니다. 이 프로세스를 통해 다음과 같은 결과가 발생합니다.

    - 모델에서 예상하는 데이터 스키마 및 특성 이해
    - 모델에 필요한 데이터 준비 및 특성 추출 식별

3. 데이터 준비: ML 태스크를 위해 데이터가 준비됩니다. 이 준비에는 데이터 정리가 포함되며, 여기에서 데이터를 학습, 검증, 테스크 세트로 분할합니다. 또한 데이터 변환 및 특성 추출을 대상 태스크를 해결하는 모델에 적용합니다. 이 단계의 출력은 준비된 형식의 데이터 분할입니다.

4. 모델 학습: 데이터 과학자는 다양한 ML 모델을 학습시키기 위해 준비된 데이터로 다양한 알고리즘을 구현합니다. 또한 최고 성능의 ML 모델을 갖도록 구현된 알고리즘을 하이퍼 파라미터 조정에 적용합니다. 이 단계의 출력은 학습된 모델입니다.

5. 모델 평가: 모델 품질을 평가하기 위해 홀드아웃 테스트 세트에서 모델을 평가합니다. 이 단계의 출력은 모델의 품질을 평가하는 측정항목 집합입니다.

6. 모델 검증: 예측 성능이 특정 기준보다 우수하면 모델이 배포에 적합한 것으로 확인됩니다.

7. 모델 서빙: 검증된 모델은 예측을 제공하기 위해 대상 환경에 배포됩니다. 이 배포는 다음 중 하나일 수 있습니다.

    - 온라인 예측을 제공하기 위해 REST API가 포함된 마이크로서비스
    - 에지 또는 휴대기기에 삽입된 모델
    - 일괄 예측 시스템의 일부

8. 모델 모니터링: 모델 예측 성능이 모니터링되어 ML 프로세스에서 새로운 반복을 호출할 수 있습니다.

탐사적 데이터 분석

- 수치 요약과 시각화를 사용하여 데이터를 탐색하고 변수 간 잠재적 관계를 찾아내는 프로세스
- 데이터에서 이상치 또는 비정상적인 관측치와 같은 이상 징후를 찾아내고, 패턴을 발견하고 변수 간 잠재적 관계를 파악하여 나중에 보다 공식적인 통계 방법을 사용하여 검정할 수 있는 흥미로운 질문이나 가설을 세울 수 있습니다.

 

이러한 단계의 자동화 수준은 새 데이터가 제공된 새 모델의 학습 속도 또는 새 구현이 제공된 새 모델의 학습 속도를 반영하는 ML 프로세스의 성숙도를 정의합니다. 다음 섹션에서는 자동화가 필요하지 않은 가장 일반적인 수준부터 ML 및 CI/CD 파이프라인 모두를 자동화하는 수준까지 세 가지 MLOps 수준을 설명합니다.

 

MLOps 수준 0: 수동 프로세스

---

많은 팀에서는 최첨단 모델을 빌드할 수 있는 데이터 과학자와 ML 연구원이 있지만, ML 모델을 빌드하고 배포하는 과정은 완전히 수동으로 이루어집니다. 이는 컨텐츠 성숙도의 기본 수준 또는 수준 0으로 간주됩니다. 다음 다이어그램은 이 프로세스의 워크플로우를 보여줍니다.

 

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

 

특성

1. 수동, 스크립트 기반, 양방향 프로세스: 데이터 분석, 데이터 준비, 모델 학습, 모델 검증을 포함한 모든 단계가 수동입니다. 각 단계를 수동으로 실행하고, 한 단계에서 다른 단계로 수동 전환해야 합니다. 이 프로세스는 일반적으로 작업 가능한 모델이 생성될 때까지 데이터 과학자가 노트북에서 작성하고 실행하는 실험 코드에 의해 이루어집니다.

2. ML과 작업 간 연결 해제: 이 프로세스는 모델을 만드는 데이터 과학자와 모델을 예측 서비스로 제공하는 엔지니어를 분리합니다. 데이터 과학자는 엔지니어링팀에 학습된 모델을 아티팩트로 전달하여 API 인프라에 배포합니다. 이 전달에는 학습된 모델을 스토리지 위치에 배치하거나, 모델 객체를 코드 저장소에 확인하거나, 모델 레지스트리에 업로드하는 작업이 포함될 수 있습니다. 그런 다음 모델을 배포하는 엔지니어는 짧은 지연 시간을 제공하기 위해 필요한 기능을 프로덕션 단계에서 사용할 수 있도록 해야 합니다. 이를 통해 학습-서빙 편향이 발생할 수 있습니다.

3. 간헐적인 출시 반복: 데이터 프로세스는 데이터 과학팀이 모델 구현을 변경하거나 새 데이터로 모델을 재학습시키는 등 자주 변경되지 않는 몇 가지 모델을 관리한다고 가정합니다. 새 모델 버전은 1년에 두어 번만 배포됩니다.

4. CI 없음: 구현 변경사항이 거의 없으므로 CI가 무시됩니다. 일반적으로 코드 테스트는 노트북 또는 스크립트 실행의 일부입니다. 실험 단계를 구현하는 스크립트와 노트북은 소스로 제어되며 학습된 모델, 평가 측정 항목, 시각화와 같은 아티팩트를 생성합니다.

5. CD 없음: 모델 버전이 자주 배포되지 않으므로 CD는 고려되지 않습니다.

6. 예측 서비스를 의미하는 배포: 이 프로세스는 전체 ML 시스템을 배포하는 대신 예측 서비스로 학습된 모델을 배포하는 것과 관련이 있습니다.

7. 활성 성능 모니터링 부족: 프로세스가 모델 성능 저하 및 기타 모델 동작 드리프트를 감지하는 데 필요한 모델 예측 및 작업을 추적하거나 로깅하지 않습니다.

 

도전 과제

모델이 거의 변경되지 않거나 학습되지 않는 경우에는 이 수동적인 데이터 과학자 기반 프로세스로도 충분할 수 있습니다. 실제로는 실제 환경에 모델이 배포될 때 손상되는 경우가 많습니다. 모델은 환경의 동적인 변화 또는 환경이 설명된 데이터의 변화에 적응하지 못합니다. 이러한 문제를 해결하고 프로덕션 단계에서 모델의 정확성을 유지하려면 다음을 수행해야 합니다.

1. 프로덕션 단계에서 적극적으로 모델 품질 모니터링: 품질을 모니터링하면 성능 저하 및 모델 비활성을 감지할 수 있습니다. 이는 새로운 실험 반복 및 새 데이터에 대한 모델 재학습의 단서 역할을 합니다.

2. 프로덕션 모델 자주 재학습: 진화하고 새로운 패턴을 포착하려면 최신 데이터로 모델을 재학습시켜야 합니다. 예를 들어 앱에서 ML을 사용하여 패션 제품을 추천하는 경우 추천은 최신 트렌드와 제품에 맞게 조정되어야 합니다.

3. 모델을 생성하기 위한 새로운 구현을 지속적으로 실험: 최신 아이디어와 기술의 발전을 활용하려면 특성 추출, 모델 아키텍처, 하이퍼 파라미터 등의 새로운 구현을 시도해야 합니다. 예를 들어 얼굴 인식에 컴퓨터 비전을 사용하는 경우 얼굴 패턴은 고정되지만, 더 나은 새로운 기술을 사용하여 감지 정확도를 향상시킬 수 있습니다.

학습-서빙 편향

학습 도중의 성능과 제공 도중 성능 간의 차이를 뜻합니다. 이러한 편향의 원인은 다음과 같습니다.

1. 학습 파이프라인과 서빙 파이프라인에서 데이터를 처리하는 방식의 차이
2. 학습 시점과 제공 시점 사이의 데이터 변화
3. 모델과 알고리즘 간의 피드백 루프

가장 좋은 해결책은 시스템 및 데이터 변경사항으로 인해 편향이 알 수 없게 되지 않도록 명시적으로 모니터링 하는 것입니다.

 

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

---

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

 

다음 그림은 CT용 자동화된 ML 파이프라인을 도식화하여 보여줍니다.

 

CT용 ML 파이프라인 자동화

 

특성

1. 빠른 실험: ML 실험 단계가 조정됩니다. 단계 간 전환은 자동으로 이루어지므로 실험을 빠르게 반복하고, 전체 파이프라인을 프로덕션으로 더 빠르게 이동할 수 있습니다.

2. 프로덕션 단계에서 모델의 CT: 다음 섹션에서 설명하는 실시간 파이프라인 트리거를 기반으로 하는 새로운 데이터를 사용하여 모델이 프로덕션 단계에서 자동으로 학습됩니다.

3. 실험-운영 균형: 개발 또는 실험 환경에서 사용되는 파이프라인 구현은 사전 프로덕션 및 프로덕션 환경에서 사용되며, 이는 DevOps 통합을 위한 MLOps 방식에 있어 핵심적인 요소입니다.

4. 구성요소 및 파이프라인의 모듈화된 코드: ML 파이프라인을 구성하려면 ML 파이프라인 전체에서 구성 요소를 재사용, 구성, 공유할 수 있어야 합니다. 따라서 EDA 코드는 여전히 노트북에 있을 수 있지만 구성 요소의 소스 코드는 모듈화되어야 합니다. 또한 구성 요소를 컨테이너화하여 다음을 수행하는 것이 좋습니다.

    - 커스텀 코드 런타임에서 실행 환경을 분리합니다.
    - 개발 및 프로덕션 환경 간에 코드를 재현 가능하도록 합니다.
    - 파이프라인의 각 구성 요소를 격리합니다. 구성 요소는 자체 런타임 환경 버전을 가질 수 있으며 다양한 언어 및              라이브러리를 갖습니다.

5. 모델의 지속적 배포: 프로덕션 단계의 ML 파이프라인은 새 데이터로 학습된 새 모델에 예측 서비스를 지속적으로 배포합니다. 학습 및 검증된 모델을 온라인 예측용 예측 서비스로 제공하는 모델 배포 단계가 자동화됩니다.

6. 파이프라인 배포: 수준 0에서는 학습된 모델을 프로덕션에 예측 서비스로 배포합니다. 수준 1의 경우, 학습된 모델을 예측 서비스로 제공하기 위해 자동으로 반복 실행되는 전체 학습 파이프라인을 배포합니다.

 

추가 구성 요소

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

카나리아 배포

- 전체 서버로 배포를 하는 것이 아닌, 일부 서버 혹은 사용자에게만 배포한 이후에 정상 동작이 확인되면 전체를 배포하는 방식

 

• Feature Store
  • 수준 1 ML 파이프라인 자동화를 위한 선택적 추가 구성요소는 Feature Store입니다. Feature Store는 학습 및 제공을 위한 특성의 정의, 스토리지, 액세스를 표준화하는 중앙 집중식 저장소입니다. Feature Store는 특성 값에 대한 높은 처리량 일괄 처리 및 짧은 지연 시간 실시간 제공을 위한 API를 제공해야 하며, 학습 및 제공 워크로드를 모두 지원해야 합니다.
  • Feature Store는 데이터 과학자가 다음을 수행하는데 도움이 됩니다.
    • 동일하거나 유사한 특성 세트를 다시 만들지 않고 항목에 사용 가능한 특성 세트 탐색 및 재사용
    • 특성 및 관련 메타데이터를 유지하여 정의가 다른 유사한 특성 사용 방지
    • Feature Store에서 최신 특성 값 제공
    • Feature Store를 실험, 지속적 학습, 온라인 서빙을 위한 데이터 소스로 사용하여 학습-서빙 편향 방지. 이 접근 방식을 사용하면 학습에 사용되는 특성이 제공 중에 사용됩니다.
      1. 실험의 경우 데이터 과학자는 Feature Store에서 오프라인 추출을 가져와 실험을 실행할 수 있습니다.
      2. 지속적 학습의 경우 자동화된 ML 학습 파이프라인은 학습 태스크에 사용되는 데이터 세트의 최신 특성 값의 배치를 가져올 수 있습니다.
      3. 온라인 예측의 경우 예측 서비스는 고객 인구통계 특성, 제품 특성, 현재 세션 집계 특성 등의 요청된 항목과 관련된 특성 값의 배치를 가져올 수 있습니다.

 

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

 

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

드리프트

- ML이나 예측 분석에 있어서 드리프트란 어떠한 예측하지 못한 변화에 의해 모델의 예측 성능이 시간이 경과함에 따라 떨어지는 것을 말합니다.

개념 드리프트

- 입력 데이터에서부터 예측하려고 하는 정답 라벨(목적 변수)의 의미/개념/통계적 특성이 모델 훈련 때와 비교하여 변화가 있음을 의미합니다.

데이터 드리프트

- 모델의 훈련 시 입력 데이터의 통계적 분포와 테스트 시 / 실제 배포 환경에서의 입력 데이터의 통계적 분포가 어떠한 변화에 의해 차이가 발생하고 있는 것을 의미합니다.

 

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

---

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

 

CI/CD 및 자동화된 ML 파이프라인

 

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

1. 소스 제어
2. 서비스 테스트 및 빌드
3. 배포 서비스
4. 모델 레지스트리
5. Feature Store
6. ML 메타데이터 저장소
7. ML 파이프라인 조정자

 

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

CI/CD 자동화된 ML 파이프라인의 단계

 

위 파이프라인은 다음 단계로 구성됩니다.

 

1. 개발 및 실험: 새 ML 알고리즘과 실험 단계가 조정되는 새 모델링을 반복적으로 시도합니다. 이 단계의 출력은 ML 파이프라인 단계의 소스 코드이며, 소스 코드는 소스 저장소로 푸시됩니다.
2. 파이프라인 지속적 통합: 소스 코드를 빌드하고 다양한 테스트를 실행합니다. 이 단계의 출력은 이후 단계에서 배포될 파이프라인 구성요소(패키지, 실행 파일, 아티팩트)입니다.
3. 파이프라인 지속적 배포: CI 단계에서 생성된 아티팩트를 대상 환경에 배포합니다. 이 단계의 출력은 모델의 새 구현이 포함되는 배포된 파이프라인입니다.
4. 자동화된 트리거: 파이프라인은 일정 또는 트리거에 대한 응답에 따라 프로덕션 단계에서 자동으로 실행됩니다. 이 단계의 출력은 모델 레지스트리로 푸시되는 학습된 모델입니다.
5. 모델 지속적 배포: 학습된 모델을 예측의 예측 서비스로 제공합니다. 이 단계의 출력은 배포된 모델 예측 서비스입니다.
6. 모니터링: 실시간 데이터를 기반으로 모델 성능의 통계를 수집합니다. 이 단계의 출력은 파이프라인을 실행하거나 새 실험 주기를 실행하는 트리거입니다.

 

데이터 분석 단계는 파이프라인이 새 반복의 실험을 시작하기 전에 데이터 과학자가 수행하는 수동 프로세스입니다. 모델 분석 단계 또한 수동 프로세스입니다.

 

지속적 통합

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

- 특성 추출 로직을 단위 테스트합니다.
- 모델에 구현된 다양한 메서드를 단위 테스트합니다. 예를 들어 범주형 데이터 열을 허용하는 함수가 있다면 이 함수를 원-핫 특성으로 인코딩합니다.
- 모델 학습이 수렴하는지 테스트합니다. (즉, 모델의 손실이 반복으로 인해 중단되고 몇 가지 샘플 레코드를 과적합함)
- 모델 학습에서 0으로 나누거나 작은 값 또는 큰 값을 조작하여 NaN 값을 생성하지 않는지 테스트합니다.
- 파이프라인의 각 구성 요소가 예상 아티팩트를 생성하는지 테스트합니다.
- 파이프라인 구성 요소 간의 통합을 테스트합니다.

원-핫 인코딩

- 단어 집합의 크기를 벡터의 차원으로 하고, 표현하고 싶은 단어의 인덱스에 1의 값을 부여하고 다른 인덱스에는 0을 부여하는 단어의 벡터 표현 방식

과적합 (Overfitting)

- 모델이 학습 데이터에 대한 정확한 예측을 제공하지만 새로운 데이터에 대해서는 제공하지 않을 때 발생하는 바람직하지 않은 기계 학습 동작입니다

NaN (Not a Number)

- 컴퓨터 시스템에서 숫자 타입의 데이터이지만 정의되지 않는 값을 뜻합니다

 

지속적 배포

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

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