ChangHyeon Nam's Blog notes and thoughts

ML/MLops 실제 서비스 구축 예시

Comments

마키나락스 개발자가 알려주는 MLOps : 01 개념부터 사례까지를 수강하고 정리한 내용입니다.

예시를 들어가며 가상으로 ML 서비스를 구축하기

예시 상황 : 로봇팔 이상탐지 시스템 구축

  • 어딘가에 있는 자동차 공장
  • X사 로봇팔이 자동차 조립/도색 등의 역할을 수행한다.
  • 로봇팔은 각 축에 센서 데이터 존재한다. (f1,f2,f3)
  • DB에 센서 데이터 적재 중
  • 로봇팔이 고장 나기 전에 알고 싶음.
  • 내부 ML 엔지니어는 데이터소스로부터 학습하여, 이상탐지 모델링을 하려고 함.

!. 복수 명의 ML 엔지니어가 있다고 하자. 각자가 각자의 모델링을 수행한다고 가정하자. 머신러닝 엔지니어 리더는 각 ML 엔지니어가 서로 다른 데이터로 모델링을 하는 것이 문제라고 생각한다.

이로인해 서로 다른 데이터 사용으로 모델 재현이 안 되는 상황이 발생한다. (서로 다른 쿼리로 다른 데이터를 추출할 수도 있다. 또는 데이터를 전처리/eda하는 과정에서 덮어씌우면 데이터가 오염될 수 있다.)

그래서 데이터셋 관리 기능을 도입하여, 읽을 수만 있게 하면 엔지니어들은 전부 동일한 데이터셋에 접근할 수 있게 된다. 또한 변화가 있을 때 버전을 추가하여, 데이터셋에 대한 형상 관리를 할 수 있다.

Untitled

이러한 데이터셋 관리를 Feature store라고 하는데, Feast, MINIO, Hive Table을 이용하여 개발할 수 있다. (또는 원하는 도구를 커스텀해서 개발할 수 있다.)


! 같은 데이터셋을 활용하므로, 엔지니어들은 무수히 많은 실험을 할 수 있다. 하지만 너무 많은 실험을 해서, 어떤 결과인지 기억이 나질 않는다.

Untitled 1

실험관리라고 한다면, 실험과 관련된 모든 정보를 조회할 수 있고, 메타데이터가 저장되어 있어야 한다. 이를 도식화 해보면, 엔지니어들의 실험 결과가 실험 도구에 실험별로 기록하게 된다. 실험관리 도구로 W&B, MLflow를 활용할 수 있다.


! 이제 같은 데이터로 여러 실험을 수행할 수 있다. 그런데 다른 엔지니어로부터 전달받은 소스 코드로 실험을 진행했는데, 실행이 안 되거나, 성능이 다른 경우가 생긴다.

Untitled 2

운영체제 버전, 라이브러리 버전 등 실행 환경이 달라서 생기는 문제다. 이때 이미지로 실행한 환경을 기록하고, 다른 사람과 이를 공유할 수 있다면 재현이 안 되는 이슈를 해결할 수 있다.

개발 환경에 도커와 같은 도구를 이용하여 이미지를 관리하면, 실행 환경을 관리할 수 있다.


!. ML 엔지니어 리더의 2번째 고민은 실험 결과물인 모델을 잘 저장해 두고 싶어 한다. 사람마다 모델 파일을 저장하다 보니, 실험은 잘 기록했지만, 실험 결과물인 모델 파일을 찾기가 어려웠다.

Untitled 3

mlflow, wandb는 모델을 저장할 수 있는 스토리지를 지원한다. 모델 레지스토리로 이를 관리할 수 있다고 하자.


!. 엔지니어들은 이상치를 잡아내는 모델을 만들기 위해 수많은 실험을 돌려야 한다. 이 과정에서 GPU, CPU 메모리 등의 자원을 사용하게 된다. 이때 다른 사람으로 인해 본인이 돌리는 실험이 터지는 상황이 발생한다.

Untitled 4 쿠버네티스를 도입하면, 실험을 돌리기 위한 자원을 먼저 선언하고, 선언한 자원을 쿠버네티스로부터 보장받고 실험을 실행할 수 있다. 쿠버네티스는 추론 서비스뿐만 아니라 다양한 곳에서 역할을 수행한다.


! 머신러닝 실험을 돌리는 과정. 데이터를 불러오고 처리하고, 모델을 학습하고 평가/검증하는 실험 과정을 ML pipeline으로 작성하여 재활용할 수 있다.

Untitled 5

파라미터를 바꿔가며, 실험을 자동화할 수 있다. 그러면 ML pipeline에 대한 대처도 가능하게 된다. 모델 개발 과정에서 Kubeflow pipeline을 통해서 ML pipeline을 구현할 수 있다. Kubeflow는 argo workflow 위에서 실행된다.

개발 시점에서 관리한 실행 환경은 ML 파이프라인을 실행할 때나, 추후 추론 서비스에서도 관리되어야 하므로, 전체 환경에 대한 이미지를 도커를 통해 관리한다.


!. 이제 많은 실험을 통해 만족할 만한 성능을 얻었다고 하자. 실제 추론 서비스를 띄어서, 현실 데이터로 확인해 보려 한다.

Untitled 6

쿠버네티스 위에서는 kserve, bentoml 혹은 seldon core NVIDIA의 triton inference server와 같은 도구를 활용하여 추론 서비스를 띄울 수 있다. 쿠버네티스 위에서 서비스를 띄었다면, 쿠버네티스가 추론 요청이 몰리는 경우에도 scale up을 하면서 서비스가 안정적으로 유지될 수 있게 도와준다. 여기서 canari 배포 등의 여러 배포 전략을 생각해 볼 수도 있다.


! 추론 서비스를 띄었지만, 아직 그 결과를 확인하고 있지 않다. 이제 Monitoring 도구를 활용하여 추론 결과를 관찰하고 싶다.

Untitled 7

grafana, prometheus 등으로 모니터링 시스템을 구축할 수 있다. 그리고 트리거를 주어 ML pipeline을 다시 실행할 수도 있다.


! 이제 자동으로 재학습을 추가하고 싶다.

Untitled 8

모니터링 도구의 알람 기능을 추가하여, argo workflow 위에서 ML pipeline이 실행되게끔 기능을 작성할 수 있다. 새로운 데이터가 10일 쌓였다거나, 모델의 성능이 떨어졌을 때 재학습하게 만들 수 있다.


이제 계속 사용할 수 있는 ML 서비스가 구축되었다고 할 수 있다.

만약 로봇팔 이상 탐지 서비스를 더 많은 공정 라인에 추가하려면 어떻게 할까? 이미 만들어 놓은 model registry에서 꺼낼 수도, ml pipeline을 그대로 사용할 수도 있다.

만약 조립 차종이 달라지면? 데이터를 다시 수집해야 할 수도 있다.