DevOps와 MLOps
DevOps와 MLOps
소프트웨어가 과거에는 단순히 특정 기기(컴퓨터)에서 실행 될 수 있으면 끝이었다. 정말 옛날에는 업데이트도 유저가 수동으로 하였었지만, 광고를 달면서 수익 모델도 창출하고... 시작 페이지도 바꾸고 하는 자동 업데이트 시스템으로 발전하였다.
그런데, 서버-클라이언트의 관계를 갖는 서비스들은, 서버는 지속성을 주요한 요소로 생각한다. 즉, 업데이트가 되더라도 유저(클라이언트) 입장에서는 지속적으로 서비스가 사용이 가능해야한다.
이러한 것을 CI/CD 라고 부른다. CI/CD는 지속적 통합(Continuous Integration), 지속적 배포(Continuous Deployment)를 말하며, 이러한 것은 개발자(Developer)뿐만 아니라 운영자(Operator), QA(Quality Assuarance)와도 연관이 있다. 개발자는 코드 관련된 수정을 할 것이고, 운영자는 최신의 모델로 업데이트 해야하며, QA는 그것에 대해서 평가를 해야한다.
이러한 과정을 잘 묶고, 자동화하려는 기술/시스템을 DevOps 라고 부른다. 그런데 DevOps는 매우 일반화되어있다. 요즘 매우 핫한 ML(Machine Learning)을 이용한 서비스에서는 CI/CD 뿐만 아니라 지속적 학습(CT)이 보장되어야 한다. 예를 들어서, 학습 데이터가 추가 된다던가, 분류해야 하는 레이블이 늘어나는 등 다양한 학습에 관한 시나리오들이 있다. 이러한 학습은 이전의 DevOps에서는 생각하지 못했던 구조이기 때문에- 이 부분에 대해서 추가한 시스템을 MLOps라고 부른다.
다시 한번 정의하면, MLOps는 ML 시스템 개발(Dev)과 ML 시스템 운영(Ops)을 통합하는 것을 목표로 하는 ML 엔지니어링 문화 및 방식이며, 이를 통해 통합, 테스트, 출시, 배포, 인프라 관리 등을 할 수 있으면, ML 시스템을 구성하는 모든 단계에서 자동화 및 모니터링을 지원할 수 있다.
MLOps의 구성 요소
MLOps를 적용하기 위해서 필요한 기본적인 요소는 다음과 같다.
- 대규모 데이터셋
- 컴퓨팅 리소스
- (클라우드 플랫폼에서) ML을 위한 가속기
- 다양한 ML 연구 분야의 빠른 발전
그리고 주변 요소를 포함해서 Hidden Technical Debt in Machine Learning Systems에서 인용하여, Google이 다시 그린 그림은 다음과 같다.
ML/DL 연구, 개발, 운영, QA 모두가 포함되어 정말 많은 요소가 있다. 필자는 위의 모든 과정을 홀로, 혹은 최대 두 명 정도의 선에서 몇번 개발을 경험했다. 하지만 회사에서는 당연히 한두명이 할 수 있는 일이라고 생각해버린다. 매우 안타까운 일이다. 전체 과정을 공부/경험해본다는 느낌으로 시작했을 때는 재밌었지만... 점점 중앙의 ML code에만 집중해서 성능을 끌어올리는 것으로, 여러 문제를 해결하는 것이 내 능력을 극대화 시킬 수 있지 않을까, 회사가 나를 잘 활용 못하는거 아닌가 생각될 때가 많다... 아무련, 이러한 부분이 ML/DL을 연구/개발하시는 분들이 가장 조심해야할 부분이라고 생각한다. CI/CD/CT를 지원하는 서비스 개발은 정말 엄청난 규모의 일이다. 예제 코드가 쉽게 돌아간다고 해서 쉽게 할 수 있다고 생각하지 말자.
사실 다수의 DevOps/MLOps는 클라우드를 기반으로 이루어진다. 그렇기 때문에 Amazon, MS, Google 등에서는 이를 위한 지원이 많다. 아래의 그림은 MS의 Azure에서의 MLOps lifecycle이다. 위의 구성요소만 있는 것 보다는 흐름의 측면에서 이해하기에 좋은 그림이다.
DevOps와 MLOps의 차이점
- 팀: 탐색적 데이터 분석, 모델 개발, 실험에 중점을 두는 데이터 과학자 또는 ML 연구원을 포함합니다. 이러한 구성원 중에는 프로덕션 수준의 서비스를 빌드 가능한 소프트웨어 엔지니어가 없을 수도 있습니다.
- 개발: ML은 기본적으로 실험적입니다. 특성, 알고리즘, 모델링 기법, 매개변수 구성을 다양하게 시도하여 문제에 가장 적합한 것을 최대한 빨리 찾아야 합니다. 도전과제는 효과가 있었던 것과 그렇지 않은 것을 추적하고, 코드 재사용성을 극대화하면서 재현성을 유지합니다.
- 테스트: ML 시스템 테스트는 다른 소프트웨어 시스템 테스트보다 더 복잡합니다. 일반적인 단위 및 통합 테스트 외에도 데이터 검증, 학습된 모델 품질 평가, 모델 검증이 필요합니다.
- 배포: ML 시스템에서 배포는 오프라인으로 학습된 ML 모델을 예측 서비스로 배포하는 것만큼 간단하지 않습니다. ML 시스템을 사용하면 모델을 자동으로 재학습시키고 배포하기 위해 다단계 파이프라인을 배포해야 할 수 있습니다. 복잡성을 추가하는 이 파이프라인을 사용하면 데이터 과학자가 배포하기 전 새 모델을 학습시키고 검증하기 위해 수동으로 수행되어야 하는 단계를 자동화해야 합니다.
- 프로덕션: ML 모델은 최적화되지 않은 코딩뿐만 아니라 지속적으로 진화하는 데이터 프로필로 인해 성능이 저하될 수 있습니다. 즉, 모델은 기존 소프트웨어 시스템보다 다양한 방식으로 손상될 수 있기 때문에 이러한 저하를 고려해야 합니다. 따라서 데이터의 요약 통계를 추적하고 모델의 온라인 성능을 모니터링하여 값이 기대치를 벗어나면 알림을 전송하거나 롤백해야 합니다.
- CI는 더 이상 코드 및 구성요소만 테스트하고 검증하는 것이 아니라 데이터, 데이터 스키마, 모델도 테스트하고 검증하는 것입니다.
- CD는 더 이상 단일 소프트웨어 패키지 또는 서비스만이 아니라 다른 서비스(모델 예측 서비스)를 자동으로 배포해야 하는 시스템(ML 학습 파이프라인)입니다.
- CT는 ML 시스템에 고유한 새 속성으로, 모델을 자동으로 재학습시키고 제공하는 데 사용됩니다.
ML의 Pipeline
- 데이터 추출: ML 태스크를 위해 다양한 데이터 소스에서 관련 데이터를 선택하고 통합합니다.
- 데이터 분석: ML 모델을 빌드하는 데 사용할 수 있는 데이터를 이해하기 위해 탐색적 데이터 분석(EDA)을 수행합니다. 이 프로세스를 통해 다음과 같은 결과가 발생합니다.
- 모델에서 예상하는 데이터 스키마 및 특성 이해
- 모델에 필요한 데이터 준비 및 특성 추출 식별
- 데이터 준비: ML 태스크를 위해 데이터가 준비됩니다. 이 준비에는 데이터 정리가 포함되며, 여기에서 데이터를 학습, 검증, 테스트셋으로 분할합니다. 또한 데이터 변환 및 특성 추출을 대상 태스크를 해결하는 모델에 적용합니다. 이 단계의 출력은 준비된 형식의 데이터 분할입니다.
- 모델 학습: 데이터 과학자는 다양한 ML 모델을 학습시키기 위해 준비된 데이터로 다양한 알고리즘을 구현합니다. 또한 최고 성능의 ML 모델을 갖도록 구현된 알고리즘을 초매개변수 조정에 적용합니다. 이 단계의 출력은 학습된 모델입니다.
- 모델 평가: 모델 품질을 평가하기 위해 홀드아웃 테스트 셋에서 모델을 평가합니다. 이 단계의 출력은 모델의 품질을 평가하는 측정항목 집합입니다.
- 모델 검증: 예측 성능이 특정 기준보다 우수하면 모델이 배포에 적합한 것으로 확인됩니다.
- 모델 제공: 검증된 모델은 예측을 제공하기 위해 대상 환경에 배포됩니다. 이 배포는 다음 중 하나일 수 있습니다.
- 온라인 예측을 제공하기 위해 REST API가 포함된 마이크로서비스
- 에지 또는 휴대기기에 삽입된 모델
- 일괄 예측 시스템의 일부
- 모델 모니터링: 모델 예측 선능이 모니터링되어 ML 프로세스에서 새로운 반복을 호출할 수 있습니다.
MLOps - CI/CD 파이프라인 자동화
아래의 그림과 같이 자동화된 CI/CD 시스템을 사용하면 데이터 과학자가 특성 추출, 모델 아키텍처, 초매개변수에 대한 새로운 아이디어를 빠르게 살펴볼 수 있습니다. 데이터 과학자는 이러한 아이디어를 구현하고 새 파이프라인 구성요소를 대상 환경에 자동으로 빌드, 테스트, 배포할 수 있습니다.
