정치적 및 조직적 과제는 차치하고, 데이터 과학 팀이 종종 사일로에서 작업하고 엔지니어링 및 DevOps 팀과 단절되며 수동 개발 프로세스(즉, “점보” Jupyter Playground)를 사용한다는 사실이 주요 장애물이다. 이 프로세스들은 생산 가능한 ML 파이프라인으로 수동 변환되어야 한다. 이를 위해서는 ML 엔지니어, 데이터 엔지니어, DevOps 및 개발자로 구성된 별도의 팀이 추가 시간과 리소스를 투자해야 하는데, 이는 종종 처음에 예상했던 것보다 훨씬 더 많은 것이다. 데이터 준비나 모델 훈련 논리에 변화가 있을 때마다 이 전체 사이클이 반복된다.

AI 서비스와 애플리케이션은 모든 비즈니스에서 필수적인 부분이 되기 시작하고 있습니다. 이러한 추세에 따라 더욱 복잡해지는 책임감이 발생합니다. 데이터, 코드 및 실험 추적을 추가하고, 개념 드리프트를 감지하기 위한 모델을 모니터링하며, AutoML 기술과 Ensemble 등을 사용하여 모델 정확도를 향상시킬 필요가 있다.

현재 지배적인 연구 지향 데이터 과학 접근 방식은 이 환경에서 더 이상 우세할 수 없습니다. 데이터 과학은 마이크로 서비스, CI(연속 통합), CD(연속 배포), 코드 버전 관리(Git) 및 구성/메타데이터 버전 관리(GitOps)를 통해 신속한 변화를 위한 소프트웨어 개발 방식을 채택해야 합니다.

제가 데이터 과학 팀장들과 이야기를 나누면, 그들은 모두 이 접근법에 동의하지만 구현에는 어려움을 겪고 있습니다. 결국, 데이터 과학자가 소프트웨어 개발자나 ML 엔지니어가 아닌 데에는 이유가 있습니다. 프로세스를 자동화하고 소프트웨어와 데이터 과학 관행 간의 격차를 해소할 수 있는 방법이 필요합니다. 여기서 보여드릴 새로운 오픈 소스 툴이 유용하게 활용될 수 있습니다.

본 게시글에서는 ML 운영 속도를 높이고 마찰을 줄이는 방법을 제안하고 보여드리겠습니다.

분할 및 정복

데이터 과학 노트북이나 캐글 프로젝트를 운영 환경에서 실행할 수 있는 것으로 바꾸려고 시도한 적이 있습니까? 행운을 빌어요. 일반적인 프로젝트에는 데이터 수집, 데이터 준비, 기능 분석, 차트 작성, 교육, 검증 등으로 시작하는 XXL 노트북이 포함됩니다.

일반적으로 여러 노트북에서 동일한 보일러 플레이트 및 도우미 기능이 중복되고, 코드가 기능에서 구성되지 않으며, 예외가 거의 처리되지 않는 등의 문제가 발생합니다. 노트북을 버전 제어하려고 하면 풀 요청을 검토하고 주석을 다는 것은 말할 것도 없고 버전 간의 차이를 찾기가 매우 어렵습니다.

우리가 취해야 할 첫 번째 단계는 프로젝트를 잘 정의되고 문서화된 API로 기능(예: 데이터 탐색, 교육 등)으로 나누는 것이다. 이러한 기능이 공유된다면 별도의 Python 또는 노트북 파일에 저장해야 합니다. API를 정의할 때 코드를 디버깅하고 추적하고 이해하는 것이 더 쉬우며, 개별 기능을 테스트하거나 더 큰 흐름의 일부로 사용할 수 있습니다. 개별 기능 또는 단계를 마이크로 서비스로 리팩터링하는 것은 전체 프로젝트 노트북을 리팩터링하는 것보다 훨씬 더 간단합니다. 이마저도 어떻게 자동화할 수 있는지 나중에 보여드리겠습니다.

번거로움 없이 실험에서 생산까지

이제 데이터 과학 코드와 워크플로우를 개별 기능으로 분리했으므로 생산 또는 규모를 염두에 두고 이러한 기능을 실행할 수 있는 방법을 찾고 다음 요구 사항을 해결해야 합니다.

• 배포 가능(필요한 패키지, Kubernetes 런타임 사양 등으로 도커 이미지 작성)

• 견고성 및 고장 처리 기능 추가

• 매개 변수, 결과, 데이터 및 메타데이터를 사용하여 실행 추적

• 성능 최적화, 까다로운 워크로드 또는 대규모 데이터셋에 대한 확장 지원

• 운영: 로깅, 모니터링, 보안 강화 등을 지원합니다.

이는 보통 개발자, 데이터 및 ML 엔지니어로 구성된 팀이 코드를 리팩터링하여 프로덕션 준비를 하는 곳이며, 이는 리소스를 훨씬 더 많이 추가하고 프로세스를 상당히 지연시키는 것을 의미합니다. 팀이 고립되어 있는 조직에서는 이러한 작업이 매우 어려우며 프로세스 도중에 많은 데이터 과학 이니셔티브를 포기하게 됩니다.

또 다른 접근 방식은 코드에서 프로덕션으로 마이그레이션하고 실행 및 데이터를 추적하는 방법을 자동화하여 팀 간에 협업하고 수동 작업을 최소화하는 것입니다.

우리는 데이터 과학 기능을 사용하여 자동으로 구축 및 배포하고 실제 사용량에 따라 확장하며 최소한의 작업으로 모든 입출력을 모니터링하기를 원합니다. 이는 오늘날 이미 “서버리스” 기술로 이루어졌으며, 고유한 데이터 과학 문제와 개발 방식에 맞게 조정하기만 하면 됩니다.

MLRun이라는 새로운 오픈 소스 프레임워크는 Nuclio(서버리스 엔진) 및 Kubeflow 파이프라인(파이프라인 오케스트레이션)과 함께 작동하여 MLOps 프로세스를 자동화하고 CI/CD + Git 관행을 데이터 과학에 도입합니다. 이 기술의 초기 채택자들은 전체 제공 시간을 수개월에서 수주로 단축하여 계산 리소스와 인력을 크게 줄였으며, 마침내 모든 실험과 데이터를 완벽하게 파악할 수 있게 되었다고 보고했습니다.

MLRun은 SDK와 Kubernetes 서비스를 제공합니다. SDK는 코드 IDE, Jupyter 노트북, Google Collab 또는 AWS Sagemaker와 같은 관리되는 노트북 서비스, 프로덕션 컨테이너 등 어디에서나 사용할 수 있습니다. 모든 기능 활동, 입력 및 출력을 자동으로 추적할 수 있습니다. 다양한 기능 간에 전달되는 파라미터와 데이터를 처리하며, 하나의 명령으로 로컬 코드를 분산 기능 또는 완전한 ML 파이프라인으로 변환할 수 있습니다. (자세한 내용은 mlrun 문서 참조)

MLRun 서비스는 모든 클라이언트의 추적 정보를 기록하고, 제공된 코드 + 메타데이터를 기반으로 “서버리스” 기능을 자동 프로비저닝하며, Kubeflow 파이프라인을 조정하여 워크플로우를 엔드 투 엔드로 관리하고, 실행 중인 작업/실험, 기능 및 아티팩트에 대한 관리 엔드 투 엔드 가시성을 위한 웹 기반 UI를 제공합니다.

자동화된 ML 파이프라인

데이터 과학 파이프라인에는 단일 기능 이상이 필요합니다. 데이터를 수집 및 준비하고, 주요 기능을 선택하고, 모델을 교육하고, 검증하고, 배포하는 등의 작업을 수행해야 합니다. 파이프라인(워크플로우)을 조립해야 합니다. 이를 위해 Kubeflow 파이프라인을 사용합니다. 그리고 MLR이 파이프라인을 구성, 실행 및 추적하도록 해야 합니다.

이 예는 노트북과 마켓플레이스 기능으로 구성된 완전한 ML 파이프라인을 보여줍니다. 이 파이프라인은 데이터를 수집하고 AutoML, 검증, 모델 배포 및 프로덕션 테스트를 통해 기능 분석 교육을 실행합니다. 파이프라인은 명령줄 또는 SDK를 통해 수동으로 트리거하거나 풀 요청 주석과 같은 Git 이벤트에 의해 트리거될 수 있습니다. Git 기반 MLOps 자동화에 대한 자세한 내용은 다음 블로그 게시물에서 다루겠습니다.

파이프라인 결과를 추적하려면 MLRun UI를 사용하거나 결과 요약을 슬랙 채널 또는 Git 풀 요청에 코멘트로 푸시할 수 있습니다.

요약

데이터 과학 및 MLOps 작업은 신속한 변화를 위한 CI/CD 및 서버리스 방식을 채택하여 시간과 리소스를 크게 절약하는 방식으로 자동화할 수 있습니다. MLRun 프로젝트는 새로운 것이지만 생산성과 생산 시간 단축을 목표로 하는 최초의 전체론적 MLOps 자동화 솔루션입니다.