MLOps: 머신러닝의 지속적 배포 및 자동화 파이프라인

이 문서에서는 머신러닝 (ML) 시스템을 위한 지속적 통합 (CI), 지속적 배포 (CD), 지속적 학습 (CT)을 구현하고 자동화하는 기술을 설명합니다. 이 문서는 주로 예측 AI 시스템에 적용됩니다.

데이터 과학 및 ML은 복잡한 실제 문제를 해결하고, 업계를 혁신하고, 모든 도메인에서 가치를 창출하는 데 핵심적인 역할을 합니다. 현재 효과적으로 ML 적용하기 위한 요소는 다음과 같습니다.

• 대규모 데이터 세트
• 저렴한 주문형 컴퓨팅 리소스
• 다양한 클라우드 플랫폼에서 ML을 위한 전문 가속기
• 다양한 ML 연구 분야 (예: 컴퓨터 비전, 자연어 이해, 생성형 AI, 추천 AI 시스템)의 빠른 발전

따라서 많은 비즈니스가 데이터 과학팀과 ML 기능에 투자하여 사용자에게 비즈니스 가치를 제공할 수 있는 예측 모델을 개발하고 있습니다.

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

데이터 과학자는 사용 사례에 대한 특정한 관련 학습 데이터를 고려하여 오프라인 홀드아웃 데이터 세트에서 예측 성능을 갖춘 ML 모델을 구현하고 학습시킬 수 있습니다. 하지만 실제 도전과제는 ML 모델을 빌드하지 않으며, 이러한 도전과제는 프로덕션 단계에서 지속적으로 통합 시스템을 운영하기 위해 이를 빌드합니다. Google에서는 프로덕션 ML 서비스의 오랜 역사를 바탕으로 프로덕션에서 ML 기반 시스템을 운영하는 데 많은 문제가 발생할 수 있다는 사실을 알게 되었습니다. 이러한 문제 중 일부는 Machine Learning: The High Interest Credit Card of Technical Debt에 요약되어 있습니다.

다음 다이어그램과 같이 실제 ML 시스템의 일부만 ML 코드로 구성됩니다. 필수 주변 요소는 광범위하고 복잡합니다.

그림 1. ML 시스템의 요소. Hidden Technical Debt in Machine Learning Systems에서 인용됨

위 다이어그램에는 다음 시스템 구성요소가 표시되어 있습니다.

• 구성
• 자동화
• 데이터 수집
• 데이터 확인
• 테스트 및 디버깅
• 리소스 관리
• 모델 분석
• 프로세스 및 메타데이터 관리
• 서빙 인프라
• 모니터링

이와 같은 복잡한 시스템을 개발하고 운영하려면 ML 시스템(MLOps)에 DevOps 원칙을 적용하면 됩니다. 이 문서에서는 ML의 CI, CD, CT와 같은 데이터 과학 방식에 MLOps 환경 설정 시 고려해야 할 개념을 다룹니다.

다음과 같은 주제를 설명합니다.

• DevOps와 MLOps 비교
• ML 모델 개발 단계
• MLOps 성숙도 수준
• 생성형 AI를 위한 MLOps

DevOps와 MLOps 비교

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

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

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

다음과 같은 점에서 다른 소프트웨어 시스템과는 다릅니다.

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

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

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

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

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

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

• CI는 더 이상 코드 및 구성요소만 테스트하고 검증하는 것이 아니라 데이터, 데이터 스키마, 모델도 테스트하고 검증하는 것입니다.
• CD는 더 이상 단일 소프트웨어 패키지 또는 서비스만이 아니라 다른 서비스(모델 예측 서비스)를 자동으로 배포해야 하는 시스템(ML 학습 파이프라인)입니다.
• CT는 ML 시스템에 고유한 새 속성으로, 모델을 자동으로 재학습시키고 서빙하는 데 사용됩니다.

다음 섹션에서는 예측 서비스로 제공하기 위해 ML 모델을 학습시키고 평가하는 일반적인 단계를 설명합니다.

ML을 위한 데이터 과학 단계

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

1. 데이터 추출: ML 태스크를 위해 다양한 데이터 소스에서 관련 데이터를 선택하고 통합합니다.
2. 데이터 분석: ML 모델을 빌드하는 데 사용할 수 있는 데이터를 이해하기 위해 탐색적 데이터 분석 (EDA)을 수행합니다. 이 프로세스를 통해 다음과 같은 결과가 발생합니다.
   • 모델에서 예상하는 데이터 스키마 및 특성 이해
   • 모델에 필요한 데이터 준비 및 특성 추출 식별
3. 데이터 준비: ML 태스크를 위해 데이터가 준비됩니다. 이 준비에는 데이터 정리가 포함되며, 여기에서 데이터를 학습, 검증, 테스트 세트로 분할합니다. 또한 데이터 변환 및 특성 추출을 대상 태스크를 해결하는 모델에 적용합니다. 이 단계의 출력은 준비된 형식의 데이터 분할입니다.
4. 모델 학습: 데이터 과학자는 다양한 ML 모델을 학습시키기 위해 준비된 데이터로 다양한 알고리즘을 구현합니다. 또한 최고 성능의 ML 모델을 갖도록 구현된 알고리즘을 초매개변수 조정에 적용합니다. 이 단계의 출력은 학습된 모델입니다.
5. 모델 평가: 모델 품질을 평가하기 위해 홀드아웃 테스트 세트에서 모델을 평가합니다. 이 단계의 출력은 모델의 품질을 평가하는 측정항목 집합입니다.
6. 모델 검증: 예측 성능이 특정 기준보다 우수하면 모델이 배포에 적합한 것으로 확인됩니다.
7. 모델 서빙: 검증된 모델은 예측을 제공하기 위해 대상 환경에 배포됩니다. 이 배포는 다음 중 하나일 수 있습니다.
   • 온라인 예측을 제공하기 위해 REST API가 포함된 마이크로서비스
   • 에지 또는 휴대기기에 삽입된 모델
   • 일괄 예측 시스템의 일부
8. 모델 모니터링: 모델 예측 성능이 모니터링되어 ML 프로세스에서 새로운 반복을 호출할 수 있습니다.

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

MLOps 수준 0: 수동 프로세스

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

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

특성

다음 목록은 그림 2와 같이 MLOps 수준 0 프로세스의 특징을 보여줍니다.

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

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

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

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

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

• 예측 서비스를 의미하는 배포: 이 프로세스는 전체 ML 시스템을 배포하는 대신 예측 서비스(예: REST API가 포함된 마이크로서비스)로 학습된 모델을 배포하는 것과 관련이 있습니다.

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

엔지니어링팀은 보안, 회귀, 부하 및 카나리아 테스트를 비롯하여 API 구성, 테스트, 배포를 위한 자체적인 복잡한 설정을 가질 수 있습니다. 또한 일반적으로 새로운 ML 모델 버전의 프로덕션 배포는 모델이 모든 예측 요청 트래픽을 제공하도록 승격되기 전에 일반적으로 A/B 테스트 또는 온라인 실험을 거칩니다.

도전과제

MLOps 수준 0은 사용 사례에 ML을 적용하기 시작하는 많은 비즈니스에서 일반적입니다. 모델이 거의 변경되지 않거나 학습되지 않는 경우에는 이 수동적인 데이터 과학자 기반 프로세스로도 충분할 수 있습니다. 실제로는 실제 환경에 모델이 배포될 때 손상되는 경우가 많습니다. 모델은 환경의 동적인 변화 또는 환경이 설명된 데이터의 변화에 적응하지 못합니다. 자세한 내용은 Why Machine Learning Models Crash and Burn in Production(머신 러닝이 프로덕션 단계에서 다운 및 번인 되는 이유)를 참조하세요.

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

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

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

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

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

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

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

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

그림 3. CT용 ML 파이프라인 자동화

특성

다음 목록은 그림 3과 같이 MLOps 수준 1 설정의 특징을 보여줍니다.

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

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

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

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

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

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

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

추가 구성요소

이 섹션에서는 ML 지속적 학습을 사용 설정하기 위해 아키텍처에 추가해야 하는 구성요소를 설명합니다.

데이터 및 모델 유효성 검사

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

• 데이터 검증: 이 단계는 모델 학습 전에 모델을 재학습할지 또는 파이프라인 실행을 중지할지 결정하는 데 필요합니다. 이 결정은 파이프라인에서 다음을 식별하면 자동으로 수행됩니다.

  • 데이터 스키마 편향: 이러한 편향은 입력 데이터의 이상으로 간주됩니다. 따라서 데이터 처리 및 모델 학습 단계를 포함한 다운스트림 파이프라인 단계가 예상 스키마를 준수하지 않는 입력 데이터를 수신합니다. 이 경우 데이터 과학팀이 조사할 수 있도록 파이프라인을 중지해야 합니다. 팀은 이러한 변경사항을 스키마에서 처리하기 위해 파이프라인에 대한 수정 또는 업데이트를 출시할 수 있습니다. 스키마 편향에는 예기치 않은 특성을 수신하거나, 예상되는 모든 특성을 수신하지 않거나, 예기치 않은 값을 포함하는 특성을 수신하는 경우가 포함됩니다.
  • 데이터 값 편향: 이러한 편향은 데이터의 통계적 속성에 큰 변화를 주어 데이터 패턴이 변경되고 있음을 의미합니다. 모델의 재학습을 트리거하여 이러한 변경사항을 포착해야 합니다.

• 모델 검증: 이 단계는 새 데이터가 제공된 모델을 학습시킨 후에 발생합니다. 모델을 프로덕션으로 승격하기 전에 사용자가 모델을 평가하고 검증합니다. 이 오프라인 모델 검증 단계는 다음으로 구성됩니다.

  • 모델의 예측 품질을 평가하기 위해 테스트 데이터 세트에서 학습된 모델을 사용하여 평가 측정항목 값을 생성합니다.
  • 새로 학습된 모델에서 생성된 평가 측정항목 값을 현재 모델과 비교합니다(예: 프로덕션 모델, 기준 모델 또는 기타 비즈니스 요구사항 모델). 새 모델이 프로덕션으로 승격되기 전에 현재 모델보다 우수한 성능을 제공하는지 확인합니다.
  • 모델의 성능이 데이터의 다양한 세그먼트에서 일관성이 있는지 확인합니다. 예를 들어 새로 학습된 고객 이탈 모델은 이전 모델보다 전반적인 예측 정확도가 더 높을 수 있지만 고객 리전당 정확도 값은 큰 차이가 날 수 있습니다.
  • 예측 서비스 API와의 인프라 호환성 및 일관성을 포함하여 모델의 배포를 테스트해야 합니다.

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

Feature Store

수준 1 ML 파이프라인 자동화를 위한 선택적 추가 구성요소는 Feature Store입니다. Feature Store는 학습 및 제공을 위한 특성의 정의, 스토리지, 액세스를 표준화하는 중앙 집중식 저장소입니다. Feature Store는 특성 값에 대한 높은 처리량 일괄 처리 및 짧은 지연 시간 실시간 제공을 위한 API를 제공해야 하며, 학습 및 제공 워크로드를 모두 지원해야 합니다.

Feature Store는 데이터 과학자가 다음을 수행하는 데 도움이 됩니다.

• 동일하거나 유사한 특성 세트를 다시 만들지 않고 항목에 사용 가능한 특성 세트 탐색 및 재사용
• 특성 및 관련 메타데이터를 유지하여 정의가 다른 유사한 특성 사용 방지
• Feature Store에서 최신 특성 값 제공

• Feature Store를 실험, 지속적 학습, 온라인 서빙을 위한 데이터 소스로 사용하여 학습-서빙 편향 방지. 이 접근 방식을 사용하면 학습에 사용되는 특성이 제공 중에 사용됩니다.

  • 실험의 경우 데이터 과학자는 Feature Store에서 오프라인 추출을 가져와 실험을 실행할 수 있습니다.
  • 지속적 학습의 경우 자동화된 ML 학습 파이프라인은 학습 태스크에 사용되는 데이터 세트의 최신 특성 값의 배치를 가져올 수 있습니다.
  • 온라인 예측의 경우 예측 서비스는 고객 인구통계 특성, 제품 특성, 현재 세션 집계 특성 등의 요청된 항목과 관련된 특성 값의 배치를 가져올 수 있습니다.
  • 온라인 예측 및 특성 검색의 경우 예측 서비스는 항목과 관련된 특성을 식별합니다. 예를 들어 엔티티가 고객인 경우 관련 기능에는 연령, 구매 내역, 탐색 행동이 포함될 수 있습니다. 서비스는 이러한 특성 값을 일괄 처리하고 개별적으로가 아닌 한 번에 항목에 필요한 모든 특성을 가져옵니다. 이 검색 방법은 특히 여러 항목을 관리해야 할 때 효율성을 높이는 데 도움이 됩니다.

메타데이터 관리

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

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

ML 파이프라인 트리거

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

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

도전과제

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

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

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

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

다음 다이어그램은 자동화된 ML 파이프라인 설정과 자동화된 CI/CD 루틴의 특성을 가진 CI/CD를 사용하여 ML 파이프라인을 구현하는 방법을 보여줍니다.

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

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

• 소스 제어
• 서비스 테스트 및 빌드
• 배포 서비스
• 모델 레지스트리
• Feature Store
• ML 메타데이터 저장소
• ML 파이프라인 조정자

특성

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

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

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

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

2. 파이프라인 지속적 통합: 소스 코드를 빌드하고 다양한 테스트를 실행합니다. 이 단계의 출력은 이후 단계에서 배포될 파이프라인 구성요소(패키지, 실행 파일, 아티팩트)입니다.

3. 파이프라인 지속적 배포: CI 단계에서 생성된 아티팩트를 대상 환경에 배포합니다. 이 단계의 출력은 모델의 새 구현이 포함되는, 배포된 파이프라인입니다.

4. 자동화된 트리거: 파이프라인은 일정 또는 트리거에 대한 응답에 따라 프로덕션 단계에서 자동으로 실행됩니다. 이 단계의 출력은 모델 레지스트리로 푸시되는 학습된 모델입니다.

5. 모델 지속적 배포: 학습된 모델을 예측의 예측 서비스로 제공합니다. 이 단계의 출력은 배포된 모델 예측 서비스입니다.

6. 모니터링: 실시간 데이터를 기반으로 모델 성능의 통계를 수집합니다. 이 단계의 출력은 파이프라인을 실행하거나 새 실험 주기를 실행하는 트리거입니다.

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

지속적 통합

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

• 특성 추출 로직을 단위 테스트합니다.

• 모델에 구현된 다양한 메서드를 단위 테스트합니다. 예를 들어 범주형 데이터 열을 허용하는 함수가 있다면 이 함수를 원-핫 특성으로 인코딩합니다.

• 모델 학습이 수렴하는지 테스트합니다(즉, 모델의 손실이 반복으로 인해 중단되고 몇 가지 샘플 레코드를 과적합함).

• 모델 학습에서 0으로 나누거나 작은 값 또는 큰 값을 조작하여 NaN 값을 생성하지 않는지 테스트합니다.

• 파이프라인의 각 구성요소가 예상 아티팩트를 생성하는지 테스트합니다.

• 파이프라인 구성요소 간의 통합을 테스트합니다.

지속적 배포

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

• 모델을 배포하기 전에 모델과 대상 인프라의 호환성을 확인합니다. 예를 들어 모델에 필요한 패키지가 서빙 환경에 설치되어 있는지, 그리고 필수 메모리, 컴퓨팅, 가속기 리소스가 사용 가능한지 확인해야 합니다.

• 예상되는 입력으로 서비스 API를 호출하고 응답이 예상하는 응답을 가져오도록 하여 예측 서비스를 테스트합니다. 이 테스트는 일반적으로 모델 버전을 업데이트하고 해당 버전이 다른 입력을 예상할 때 발생할 수 있는 문제를 포착합니다.

• 초당 쿼리 수(QPS) 및 모델 지연 시간과 같은 측정항목을 포착하기 위한 서비스 부하 테스트가 포함된 예측 서비스 성능 테스트

• 재학습 또는 일괄 예측을 위한 데이터 유효성 검사

• 모델이 배포되기 전에 예측 성능 목표를 충족하는지 확인

• 테스트 환경에 대한 자동 배포(예: 개발 분기에 코드를 푸시하여 트리거된 배포)

• 사전 프로덕션 환경에 대한 반자동 배포(예: 검토자가 변경사항을 승인한 후 기본 분기에 코드를 병합하여 트리거된 배포)

• 사전 프로덕션 환경에서 여러 번의 성공적인 파이프라인 실행 후에 프로덕션 환경에 대한 수동 배포

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

다음 단계

• TensorFlow Extended, Vertex AI Pipelines, Cloud Build를 사용하는 MLOps 아키텍처에 대해 자세히 알아보기
• 머신러닝 작업(MLOps) 실무자 가이드에 대해 알아보기
• YouTube에서 Google Cloud 의 MLOps 권장사항(Cloud Next '19)을 시청합니다.
• Google Cloud에서 AI 및 ML 워크로드와 관련된 아키텍처 원칙 및 권장사항에 대한 개요는 Well-Architected Framework의 AI 및 ML 관점을 참조하세요.
• 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 Cloud 아키텍처 센터를 확인하세요.

참여자

저자:

• Jarek Kazmierczak | 솔루션 설계자
• 칼리드 살라마 | 머신러닝 담당 소프트웨어 엔지니어
• 발렌틴 후에르타 | AI 엔지니어

기타 참여자: 수닐 쿠마르 장 바하두르 | 고객 엔지니어