[MLOps] Machine Learning Pipeline에 대한 이해 (1)

머신러닝 파이프라인의 필요성

기본적으로 파이프라인을 통해 얻는 이점은 생산성 향상, 예측 가능한 품질 획득, 장애 대응능력 향상이다.

1. 생산성 향상
 - 일반적으로 한 두개의 모델을 직접 서빙하는 건 가능하나, 동시의 수백개의 모델을 컨트롤할 수 없음

2. 예측 가능한 품질 획득
 - 일반적으로 모델 서빙 후 퍼포먼스에 대한 측정을 잘 안한다 / 배포하고 끝냄
 - 모델은 서빙 후 지속적으로 품질이 떨어진다. -> 품질 관리가 필요
 - 이것도 시스템화 시켜야 컨트롤 가능

3. 장애 대능 능력 향상 
 - ML 프로젝트는 장애가 일어나는 지조차 알기 어렵다
 - 시스템의 스케일링이 커질수록 파이프라인이 필요
 - PoC(Proof of Concept) Level에서 Production Level로 끌어올리는 과정이 파이프라인이라고 보면 된다

 

그러나,

ML 시스템 개발 및 배포(모델 Save 후 Predict)는 쉽지만 (MLOps Level 0)

서빙된 모델의 성능을 측정하고 지속적 개선을 하는 시스템 (MLOps Level 1)을 갖추기는 어렵다

 

해당 문제가 지속된다면 기술 부채가 발생할 수 있음

 

---

기존 소프트웨어 엔지니어링과의 차이점

기존 소프트웨어 엔지니어링 방식 일부

 전통적인 소프트웨어 엔지니어링에서는 위 방법 등을 활용해서 기술 부채를 줄여왔음

 그런데, 소프트웨어 엔지니어링은 추상화(Abstraction)가 명확하다.

     - (ex. OOP에서 몬스터를 슬라임, 오크로 추상화 가능, 그리고 각각이 hp라는 variable을 공유하는 등 공유하는 특성과 함수가 명확한 편)

 

 그러나, ML System은 추상화가 잘 되지 않는다.

     - (ex. 거대한 모델에서 일부만 고치기가 쉽지 않다, 유닛 테스트 자체도 어려움) 

 

그럼 어떻게 기술 부채를 줄일 수 있을까? - 이것이 ML pipeline이 푸는 핵심적인 문제이다.

 

---

Machine Learning에서 문제의 특징

1. 비교적 쉬운/어려운 ML problem
    - 데이터의 변화가 천천히(빠르게) 일어날 때 (분기, 월 단위)
        - 모델 교체가 빈번하지 않다면, 직접 배포하면 된다
    - 모델 재학습
        - 모델 성능 저하
        - 더 많은 데이터로 모델 성능 개선할 때
        - SW 혹은 시스템의 변화 시
    - 라벨링
        - 직접적인 피드백
        - 수집한 데이터 라벨링
        - 클라우드 소싱 활용

즉, 변화가 많을 때 ML problem은 점점 어려워진다.

코딩과 엔지니어링 관점에서, ML programming의 대표적인 문제들

이 뿐만 아니라, 일반 SW 프로젝트와는 다르게 ML 프로젝트는 팀의 구성도 다르다.

  - SW 프로젝트 내부 구성 인원은 어느 정도의 SW 지식을 함께 공유하고 있다.

  - ML 프로젝트 구성인원(Research Scientist, Research Engineer, SW engineer, ...)은 각기 도메인 지식이 각기 달라 협업 관점에서 난이도가 높다. 

 

또한 개발 프로세스에서도 문제가 발생한다.

  - ML은 본질적으로 실험이다.

  - 다른 feature, 알고리즘, 하이퍼파라미터 등의 구성을 시도해 가능한 빨리 문제점에 fit한 것을 찾는 과정이지만, 보장은 안 됨(정답이 없다)

  - 따라서 ML 시스템의 테스트는 SW보다는 어렵다.

 

배포에서도 문제가 있다.

 - 모델을 학습했다고 배포하지 않는다 -> 트리거 포인트가 여러 개

     - 모델을 검증 후 배포 결정을 리서치 리더가 내린 후 서빙

     - 모델 성능 하락 시 재학습 후 서빙

     - 데일리로 학습 후 서빙

     - 온라인 실시간 서빙

 

프로덕션에서도 문제가 있다.

 - 데이터 프로파일 문제

     - 데이터 통계치 추적 및 모델의 온라인 성능을 모니터링해 예상치를 벗어날 때 알림 or 롤백해야 함

 

---

MLOps의 핵심 문제

모델 학습&배포 트리거, 진화하는 데이터셋, CI/CD/CT, 모델 관리 시스템 문제가 있다.

 

1. 모델 학습 & 배포 트리거

  - 요청 시 : 파이프라인의 임시 수동 실행
  - 일정 기준 : 라벨이 지정된 새 데이터는 매일, 매주 또는 매월
  - 새 학습 데이터 : 새 데이터가 들어오는 경우 모델의 재학습을 트리거
  - 모델 성능 저하 시 : 성능 저하가 눈에 띄는 경우 모델 재학습
  - 데이터 분포의 중요한 변화 시 (Concept Drift) : 예측 시 사용되는 feature의 데이터 분포에 큰 변화가 있으면, 모델이 오래된 걸 의미

 

2. 진화하는 데이터셋과 Metric

이것이 문제가 되는 이유는, 데이터 파이프라인을 완벽하게 설계해야 하기 때문 : 데이터 엔지니어링 역량이 필요

데이터셋이 바뀌면 평가 기준도 바뀌어야 한다

 

3. CI / CD / CT - 지속적 통합 / 지속적 배포 / 지속적 학습

기존 SW 엔지니어링에 더해, CT 파이프라인도 만들어야 한다. 

그런데, Training을 위해서는 데이터 파이프라인을 자동화가 필요하고, 앞서 언급되었던 기술 부채가 해결되어야 한다.

 

---

MLOps 성숙도

구글에서 MLOps 수준을 성숙도로 표현하여 Level 0부터 Level 2까지 만들어놓았다.

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

 

1. Level 0

Level 0의 특징

- 수동, 스크립트 중심, 대화식(Interactive) 프로세스
- ML과 운영의 분리
- 드문 릴리즈 반복
- CI / CD 부재
- 배포는 예측 서비스를 의미
- Active 성능 모니터링 부족

대화식 프로세스 : .ipynb로 대충 만들어서 배포하는 경우를 의미

드문 릴리즈 반복 : 모델 배포 주기가 거의 없다시피 한 상태

 

우리 나라에도 대부분 그렇고, model registry도 없는 경우도 허다하다고 한다.

 

 

2. Level 1

Level 1의 특징

- 빠른 실험
- 프로덕션 모델의 CT
- 실험 운영 환경의 조화
- 구성 요소 및 파이프라인을 위한 모듈화된 코드
- 지속적인 모델 제공
- 파이프라인 배포

CT가 가능한 경우 / 자동으로 데이터 정리된 후 학습 & 배포가 이루어지는 상황

 

Level 1만 해도 아키텍쳐가 굉장히 복잡한 것을 알 수 있다.

학습 데이터가 orchestrated experiment 단위에서 파이프라인이 작동하고, 파이프라인이 패키징되어 형상 관리가 가능

말하자면 쿠베플로우 관점에서 설명이 된 것이다. (쿠베플로우 파이프라인이 패키징 파일을 yaml 형식으로 만들 수 있음)

 

 

3. Level 2

Level 2의 특징

- Production에서 파이프라인을 빠르고 안정적으로 업데이트하려면 자동화된 CI/CD 시스템 필요
- 자동화된 CI/CD을 통해 Data Scientist는 Feature Engineering, 모델 아키텍처 및 하이퍼 파라미터에 대한 새로운 아이디어를 신속하게 탐색할 수 있음

 

Level 1에서, 파이프라인에 대한 CI-CD 시스템이 있는 것을 Level 2라고 함 / 나머지는 Level 1과 비슷