많이 늦게 글을 작성하게 되었네요.. ㅎㅎ
저번글에서는 ML이라는게 어떤 과정으로 일어나고, 또 MLOps가 어떤 느낌인지만 봤었습니다.
2021.09.27 - [MLops] - MLOps 란 무엇인가? (1)
MLOps 란 무엇인가? (1)
이번 포스팅에서는 MLOps에 대한 기본적인 설명부터 작성해보고, 제가 공부했던 내용들을 포스팅에 적을 계획입니다. DevOps에 대해서는 많이들 들어보시고, 잘 아실거라 생각합니다. 하지만 MLOps
keyog.tistory.com
이번에는 머신러닝에서 일어나는 문제사항들을 좀 더 자세하게 살펴보고 MLOps를 어떻게 구성해야할지 작성해보겠습니다.
쉽게 만들 수 있는 ML 서비스
ML을 통한 서비스를 만들고자할때, 다음과 같은 상황은 ML을 하시는 분들이라면 쉽게 풀어낼 수 있습니다.
굳이 MLOps가 필요하지 않고, 오히려 MLOps를 도입했을때, 아까운 리소스가 소모될 수도 있습니다.
- ML에 필요한 데이터의 변화가 적고, 데이터를 구하기가 쉬운 경우
- 서비스를 운영함에 있어서 ML모델의 변경주기가 긴 경우
- 모델을 재학습하는 이유가 모델의 성능개선을 위한 것이거나 시스템이 변해서 하는 경우
- 서비스 범위가 넓지 않아서, 늘 비슷한 환경에서 같은일을 하는 ML모델인 경우
이 4가지는 간단하게 말하면, 변화가 적은 환경에서 모델이 이미 잘 적응해서 서비스를 무리없이 해내고 있는 상황이라고 볼 수 있습니다.
예를 들어보자면 주차번호판 인식이나, 방범 CCTV에 들어갈 수 있는 모델이 될 것 같습니다.
NLP 분야에서는 구글번역기 같은 번역이 이에 해당될 수 있습니다.
어려운 ML 서비스
그렇다면 서비스하기 어려운 상황은 어떤것들이 있을까요?
위와는 반대로 변화가 큰 상황이라고 볼 수 있습니다. 이런 경우가 MLOps를 통한 자동화된 시스템을 필요로하게 된 이유가 됩니다.
- 데이터의 변화가 시간단위, 일단위로 지속적으로 변화가 있고, 과거의 데이터가 점점 쓸모없어지는 상황
- 학습된 모델이 지속적으로 새로운 데이터를 직면하며 성능이 떨어지는 경우
- 모델 재학습이 단순 성능 개선을 위한 것이 아니라 지속적으로 훈련을 해야만하는 서비스인 경우
- 추천시스템처럼 지속적인 피드백이 모델의 성능에 영향을 끼칠 수 있는 경우
- 하나의 서비스에서 관리해야하는 모델이 너무 많은 경우
이 5가지가 ML서비스를 진행함에 있어서 고려되는 문제들이라면 MLOps를 도입해도 좋을 거라고 생각합니다.
머신러닝 프로그래밍자체의 문제
ML 서비스하는 모델을 만들어 배포하고 서비스하는 것 뿐만 아니라, 프로그램을 만들어내는 단계에서 생길 수있는 문제들도 분명히 존재합니다.
진화하는 데이터
우리가 ML모델을 만들기 위한 데이터들은 분명히 진화하고 있습니다. 간단한 예를 들어보면 아래와 같습니다.
그림처럼 자동차를 인식해야하는 모델에서 예전 자동차 이미지 데이터셋을 구하기 쉽다고, 예전의 데이터로만 훈련해버리면 최근의 자동차인 모습이 전혀다른 초소형 전기자동차를 올바르게 인식하지 못할 수 있습니다.
자연어도 마찬가지 입니다. 인터넷 말투를 정확하게 해석하거 어떤 분류나 분석을 해야하는 모델을 구축할때도 이러한 문제는 일어날 수 있습니다.
자동차보다도 인터넷의 변화, 알잘딱깔센같은 최신유행어 등등 더 빠르게 변화되는 데이터로 볼 수 있습니다.
문제 정의의 어려움
ML모델을 구축하는데 앞서서 문제정의 자체가 어려워서 모델을 구축하기 힘들 수 있습니다.
예를 들면, 자동차 운전자의 졸음방지를 위한 모델구축이나 개인화에 초첨을 맞춘 모델들을 어떻게 구성해야하고 어떤 모델들을 써야하며 어떤 모델의 성능이 좋은지 알 수없는 상태에서 시작할 수 밖에 없습니다.
이 부분은 커뮤니티가 넓게 설정되지 않을 수록 어려워지는 부분입니다.
데이터셋 자체의 문제
어렵게 어렵게 데이터셋을 구했으나, 해당 데이터를 검증해보고나니 오류가 많은 데이터셋이었을 수 있습니다.
또는 어떤 특정 모델을 구축하기 위한 데이터 자체가 부족해서 구할 방법이 없을 수도 있겠죠.
앞에 한번 논문을 통해 다뤘던 적이 있는 데이터들의 편향을 어떻게 해결할 것인지도 중요한 이슈중 하나 입니다.
오류가 많은 데이터셋이라면, 데이터에 대한 검증을 진행하며 오류가 없는 데이터들로 이루어진 새로운 데이터셋을 생성해야합니다.
데이터의 편향이 많이 일어나는 데이터인지 확인하기 위해 데이터를 시각화하거나 요약하여 메타데이터를 생성해내는 작업이 필요할 수 있습니다.
정말 올바르게 만들어진 모델?
어떤 데이터셋을 통해서 ML모델을 생성하였는데, 막상 실제 환경에서 테스트해보니 원하지 않는 성능이 나온 경험이 다들 있으실 거라고 생각합니다.
모델이 정말 올바르게 만들어졌는지, 어떤 데이터를 썻기 때문에 어떻게 결과값을 반환하는지, 모델이 어떤환경에서 잘되고 어떤환경에서 안되어서 어떻게 수정해야하는지 등등 다양한 부분들을 파악하고 모델의 설명가능성을 높이는 일은 매우 중요합니다.
F1 Score, Accuracy, precision, recall 등 성능 평가지표들이 다양하게 사용하고, 실제 테스트환경과 비슷한 환경에서 모델을 검증하고 모델을 개선해나가야 합니다.
로그 디자인
WEB과 다르게 ML 개발을 진행하며 대부분은 Logging을 진행하지 않는 것같습니다.
사용한 Feature들의 일자별 정리라던가, 어떤 Hyper Parameter들을 사용하였을때의 결과값이 어땠는지
모델들의 레거시는 잘 관리하고 또 모델이 배포된 이후에 피드백들은 어떤지를 확인해야 합니다.
하지만 이를 사람이 보고서처럼 정리하기에는 무리가 있는 것도 사실이기에 자동화된 시스템을 구축해야 하지만 ML에서만큼은 잘 이루어지지 않는것처럼 보입니다.
배포단계에서 해결해야할 문제
이미 모델을 서비스하고 있다면, 발생할 수 있는 문제들도 또 있습니다.
- 지속적으로 변화되는 데이터 프로파일 때문에 모델의 성능이 저하되는 경우
- 데이터의 통계치를 추적해야하고 온라인으로 성능을 모니터링하며 예상치에서 벗어나는 경우 알림과 롤백이 진행되어야 합니다.
모델이 배포되는 상황은 다음과 같습니다.
- 개발자가 직접 요청하여 수동으로 배포를 하는 경우
- 일단위, 주단위로 지속적으로 배포하는 경우
- 새 학습데이터가 일정량 채워져서 모델을 재학습하여 배포하는 경우
- 모델의 성능이 눈에 띄게 저하되어 목표치 성능을 벗어난 경우
- 데이터 분포에서 중요한 큰 변화가 있어서 모델을 재학습 하여 배포하는 경우
이러한 5가지의 상황들은 모델이 재학습에 들어가고 새로운 모델로 교체되는 트리거 포인트가 될 수 있습니다.
MLOps Level
그렇다면 이러한 문제들을 해결하기 위해서는 MLOps. 즉, 머신러닝 자동화 파이프라인을 어떻게 구축해야하고 어떤 요소들을 만들어야 할까요?
해당 부분은 구글에서 말하고 있는 MLOps의 아키텍처를 통해서 확인할 수 있습니다.
MLOps: 머신러닝의 지속적 배포 및 자동화 파이프라인 | Google Cloud
MLOps: 머신러닝의 지속적 배포 및 자동화 파이프라인 이 문서에서는 머신러닝(ML) 시스템을 위한 지속적 통합(CI), 지속적 배포(CD), 지속적 학습(CT)을 구현하고 자동화하는 기술을 설명합니다. 데
cloud.google.com
구글에서는 ML을 위한 Code는 일부분일뿐 결국 ML서비스는 다른요소들이 더 많다고 이야기 합니다.
Level 0 : 수동 프로세스
우리나라에도 많은 ML 연구원들이 있고 뛰어난 모델들이 현재도 많이 생성되고 배포되고 있습니다.
하지만 많은 기업들이 ML 연구원들이 만들어준 모델을통해 서버에 붙여 수동으로 배포하고 있는 것도 사실입니다.
구글에서는 이러한 과정을 콘텐츠 성숙도가 Level 0라고 분류하였습니다.
과정은 대략 이렇습니다.
- ML 연구원은 오프라인 데이터셋을 통해 데이터를 검증하고 모델을 훈련시켜서 모델이 생성되면, 모델 저장소에 저장합니다.
- Operation을 위한 개발자는 Model 저장소에 있는 모델을 Prediction이 가능한 형태로 serving합니다.
즉, CI/CD 과정이 없는 수동프로세스를 뜻 합니다.
Level 1 : ML 파이프라인 자동화
Level 1 부터 사실 갑자기 어려워집니다. 위 Level 0에서 이루어지는 일련의 과정들을 파이프라인을 통해 자동화 시키고 트리거를 통해서 모델 재학습을 진행하며, 프로덕션으로 서비스 되는 모델을 모니터링하는 과정이 모두 포함되어 있습니다.
일련의 과정들을 자동화시키는것을 MLOps라고 부르며 구글에서 Level 1으로 분류하였습니다.
과정은 대략 이렇습니다.
- 지속적으로 변화할 수 있는 Feature store를 구축하여 오프라인으로 데이터 분석을 진행합니다.
- 데이터 분석을 통해서 어떤 Model을 구축하였다면, 해당 코드를 Github같은 코드저장소에 저장하고 파이프라인으로 생성합니다.
- 생성된 파이프라인이 Feature store에서 Batch로 데이터를 가져와서 재학습을 진행하고 모델을 생성하면 모델 저장소로 저장합니다.
- 새롭게 저장된 모델은 CD 파이프라인을 통해 serving 가능한 형태로 배포됩니다.
- 배포된 모델의 성능을 모니터링하며, 성능에 이슈가 생기면 트리거를 주어 재학습을 진행하여 재배포를 합니다.
- 이 때 파이프라인이 동작하는 과정 (파이프라인의 동작 시간, 파이프라인 실행자, 전달된 매개변수)을 metadata store에 저장하고 관리합니다.
Level 1에서는 모델의 배포는 자동화가 되었지만, 모델의 실험과 모델의 구조를 만들어내는 것은 수동으로 연구개발을 해야 하는 형태 입니다.
Level 2 : CI/CD 파이프라인 자동화
Level 2는 머신러닝의 구성요소들을 대부분 자동화 시킨 형태 입니다.
구글에서는 이런 구조를 Level 2로 분류하고 완전한 MLOps로 바라봅니다.
과정은 대략 이렇습니다.
- 데이터가 저장되는 Feature store를 구축하면 데이터분석 시스템이 이를 분석하고 검증합니다.
- 데이터 분석을 통해서 어떤 Model을 구축하였다면, 해당 코드를 Github같은 코드저장소에 저장합니다.
- 소스 저장소에 소스코드를 이는 CI 파이프라인을 통해 패키징을 진행합니다.
- 패키징된 소스코드는 CD 작업을 통해 자동화된 파이프라인으로 배포되어 Feature store에서 데이터를 가져오며 재학습을 진행할 수 있는 형태가 됩니다.
- 파이프라인에서 학습되어 나오는 모델은 모델 저장소로 저장되며 CD 파이프라인을 통해 serving하게 됩니다.
- 배포된 모델의 성능을 모니터링하며, 성능에 이슈가 생기면 트리거를 주어 재학습을 진행하여 재배포를 합니다.
- 이 때 파이프라인이 동작하는 과정 (파이프라인의 동작 시간, 파이프라인 실행자, 전달된 매개변수)을 metadata store에 저장하고 관리합니다.
즉, Level1과 Level2의 차이점은 소스코드에 대한 CI/CD (즉, DevOps의 영역의 업무)가 추가된 것이라고 할 수 있습니다. 결과적으로, 소스코드만 관리하면 일련의 과정들이 자동으로 이루어지기 때문에 더 자동화 되었다고 볼 수 있습니다.
마치며 ..
이번 포스팅에서는 ML에서 일어나는 문제사항들과 그를 해결하기 위한 MLOps의 구조를 알아보았습니다.
Level 이 높아질수록 다양한 컴포넌트들이 필요하고 DB, CI/CD, 데이터 엔지니어링, 모니터링 등등 너무많은 요소들이 필요해지는 것 같습니다.
다음 포스팅에서는 이런 아키텍처들에 사용되는 Application들이 무엇이 있는지 작성해보도록 하겠습니다.
물론.. 언제작성될지 몰라서 기약없긴 하지만요.. ㅋㅋ
그럼 긴 글을 읽어주셔서 감사합니다!
'MLops' 카테고리의 다른 글
| MLOps 란 무엇인가? (1) (0) | 2021.09.27 |
|---|
