MLOps
"MLOps는 머신러닝팀과 운영팀의 문제를 해결하기 위한 방법이다."
관리해야할 모델이 적다면 서로 협업을 통해 충분히 해결 가능하지만, 개발해야 할 모델이 많아진다면 '사일로 현상'이 나타나게 된다.
사일로 효과(Orgnizational Silos Effect)는 조직 부서 간에 서로 협력하지 않고 내부 이익만을 추구하는 현상을 의미한다. 조직 내에서 개별 부서끼리 서로 담을 쌓고 각자의 이익에만 몰두하는 부서 이기주의를 일컫는다.
MLOps의 목표는 개발한 모델이 정상적으로 배포될 수 있는지 테스트하는 것이다.
MLOps의 두 가지 목표
- ML과 Ops 두 팀의 생산성 향상
- ML->Ops로 머신러닝 팀에서 직접 운영을 할 수 있도록 도와주는 것
Levels of MLOps
Hidden Technical Debt in ML System
구글은 2015년부터 MLOps의 필요성을 말했다. 아래의 논문이 구글의 생각을 담은 논문이다.
이 논문의 핵심은 머신러닝을 이용한 제품을 만드는데 있어서, 머신러닝 코드는 전체 시스템을 구성하는데에 있어서 아주 일부일 뿐이라는 것이다.
구글은 이 논문을 더 발전시켜 MLOps라는 용어를 만들어 확장시켰다. 더 자세한 내용은 구글 클라우드 홈페이지에서 확인할 수 있다고 한다.
구글은 MLOps의 발전 단계를 총 3단계로 나누었다.
0단계: 수동 프로세스
0단계에서 두 팀은 '모델'을 통해 소통한다. 머신러닝팀은 쌓여있는 데이터로 모델을 학습시키고 학습된 모델을 운영팀에게 전달한다. 운영팀은 전달받은 모델을 배포한다.
초기의 머신러닝 모델들은 '모델' 중심의 소통을 통해 배포한다. 이런 배포 방식에는 여러 문제가 있다.
이러한 상황이 일어나는 이유는 머신러닝 모델의 특성에 있다. 학습된 머신러닝 모델이 동작하기 위해서는 다음의 3가지가 필요하다.
- 파이썬 코드
- 학습된 가중치
- 환경 (패키지, 버전 등)
만약 이 3가지 중 한가지라도 전달이 잘못된다면, 모델이 동작하지 않거나 예상치 못한 일이 발생할 수 있다. 많은 경우는 환경이 일치하지 않아서 동작하지 않는 경우이다. 머신러닝은 다양한 오픈소스를 사용하므로 오픈소스 특성상, 어떤 버전을 쓰는지에 따라서 같은 함수라도 결과가 다를 수 있다.
서비스 초기에는 관리할 모델이 많지 않기 때문에 이러한 문제를 금방 해결할 수 있다. 하지만 관리하는 기능들이 많아지고 서로 소통에 어려움을 겪게 된다면, 성능이 더 좋은 모델을 빠르게 배포할 수 없게 된다.
1단계: ML 파이프라인 자동화
Pipeline
그래서 MLOps에서는 '파이프라인'을 이용해 이러한 문제를 방지하고자 했다. MLOps의 파이프라인은 도커와 같은 컨테이너를 이용해 머신러닝 엔지니어가 모델 개발에 사용한 것과 동일한 환경으로 동작되는 것을 보장한다. 이를 통해, 환경이 달라서 모델이 동작하지 않는 상황을 방지한다.
파이프라인은 범용적인 용어로 여러 다양한 태스크에서 사용된다. 머신러닝 엔지니어가 작성하는 파이프라인의 역할은 무엇일까?
머신러닝 엔지니어가 작성하는 파이프라인은 학습된 모델을 생산한다. 그래서 파이프라인 대신 학습 파이프라인(Training Pipeline)이 더 정확하다고 볼 수 있다.
Continuous Training
그리고 'Continuous Training(CT)' 개념이 추가된다. CT는 왜 필요할까?
Auto Retrain
Real World에서 데이터는 Data Shift라는 데이터의 분포가 계속해서 변하는 특징이 있다. 그래서 과거에 학습한 모델은 시간이 지남에 따라 모델의 성능이 저하되는 문제가 있다. 가장 간단하고 효과적인 해결책은 최근 데이터를 이용해 모델을 재학습하는 것이다.
Auto Deploy
하지만 제조업과 같이 한 공장에서 여러 레시피를 처리하는 경우, 무조건 재학습을 하는 것이 좋지 않을 수도 있다. 'Blind Spot'이 대표적인 예시라고 한다.
예를 들어, 자동차 생산 라인에서 모델 A에 대해서 모델을 만들고 이를 이용해 예측을 진행하고 있다고 하자. 만약 전혀 다른 모델 B가 들어오면 이전에 보지 못한 데이터 패턴이기 때문에, 모델 B에 대해서 새로운 모델을 학습해야 한다.
모델 B에 대해서 모델을 만든 후 모델은 예측을 진행한다. 그런데 만약 데이터가 다시 모델 A로 바뀐다면? 만약 Retraining 규칙만 있다면 다시 모델 A에 대해서 새로운 모델을 학습하게 된다. 그런데, 머신러닝 모델이 충분한 성능을 보이기 위해서는 충분한 양의 데이터가 모여야 한다. Blind Spot이란 이렇게 데이터를 모으기 위해서 모델이 동작하지 않는 구간을 말한다.
Blind Spot을 해결하는 방법은 간단할 수 있다. 모델 A에 대한 모델이 과거에 있었는지 확인하고 만약 있었다면, 새로운 모델을 바로 학습하기 보다는 이전 모델을 이용하여 다시 예측을 하면 이런 Blind Spot을 해결할 수 있을 것이다. 이렇게 모델과 같은 메타 데이터를 이용해 모델을 자동으로 변환해주는 것을 Auto Deploy라고 한다.
CT를 위해서는 Auto Retraining과 Auto Deploy 두 가지 기능이 필요하다. 둘은 서로의 단점을 보완해 계속해서 모델의 성능을 유지할 수 있게 한다.
2단계: Continuous Integration(CI)/Continuous Delivery(CD) 파이프라인의 자동화
CI와 CD는 개발팀과 운영팀의 장벽을 해제하기 위한 구체적인 방법이다. 이 방법을 통해서 개발팀에서는 운영팀의 환경을 이해하고 개발팀에서 개발중인 기능이 정상적으로 배포까지 이어질 수 있는지 확인한다. 운영팀은 검증된 기능 또는 개선된 제품을 더 자주 배포해 고객의 제품 경험을 상승시킨다.
DevOps에서의 CI/CD의 대상은 소스 코드이다. MLOps의 CI/CD 대상 또한 소스 코드인 것은 맞지만, 더 엄밀히 정의하자면 학습 파이프라인이라고 볼 수 있다.
모델을 학습하는데에 있어서 영향이 있는 변화에 대해 실제로 모델이 정상적으로 학습이 되는지 (CI), 학습된 모델이 정상적으로 동작하는지 (CD)를 확인해야 한다. 그래서 학습을 하는 코드에 직접적인 수정이 있는 경우에는 CI/CD를 진행해야 한다.
코드 외에도 사용하는 패키지의 버전, 파이썬의 버전 변경도 CI/CD의 대상이다. 많은 경우, 머신 러닝은 오픈 소스를 이용한다. 앞서 말했듯이 오픈 소스는 그 특성상 버전이 바뀌었을 때, 함수의 내부 로직이 변하는 경우도 있다. 물론 어느 정도 버전이 올라갈 때 이와 관련된 알림을 주지만, 한 번에 버전이 크게 바뀐다면 이러한 변화를 모를 수도 있다. 그래서 사용하는 패키지의 버전이 변하는 경우에도 CI/CD를 통해 정상적으로 모델이 학습, 동작하는지 확인을 해야한다.
Reference
