머신러닝 서비스를 만들고 싶은 분들에게 🤲

모델은 만들었는데 이제 어떻게 해야 하지?? 🚬

대부분의 데이터 과학자, 데이터 분석가, 머신러닝 엔지니어들은 실험과 학습과 같은 연구에 중점을 둡니다.

예를 들겠습니다.

당신은 사람 얼굴만 보면 정확한 범죄 확률을 예측해 모든 범죄를 막을 수 있는 머신러닝 프로젝트에 참여했습니다.

수 많은 실험과 연구로 성능이 폭발적인 환상적인 모델을 만들었습니다. 모든 CCTV에 모델을 설치하면 마이너리티 리포트는 꿈이 아닙니다.

이제 어떻게 할까요?

전국의 CCTV 프로그래머에게 파이썬 설치 방법과 모델 파일을 첨부한 이메일을 발송할까요?

아니면 전국의 CCTV 영상 파일을 매일 매일 받아 로컬 머신 혹은 사내에 설치된 DGX 머신에서 돌려 결과를 다시 전달할까요?

위와 같은 방법들은 많은 문제를 포함합니다.

첫째, 모든 CCTV의 컴퓨팅 사양이 같지 않습니다.

내가 필요로 하는 프레임워크나 라이브러리가 설치가 안될 수 있습니다.

로컬 컴퓨터에서 당연하게 사용하는 파이썬조차 설치가 힘들 수 있습니다.

둘째, 수동 작업은 너무 힘듭니다.

프로덕션 레벨에서의 반복적인 작업들은 연구 개발에 들어가야할 시간들을 뺏어갑니다.

셋째, 실험 환경과 프로덕션 환경이 분리되어 있지 못합니다.

작업 환경에 cronjob이나 airflow를 사용하여 배치를 돌릴 수 있습니다.

그러나 실험 환경의 리소스를 나눠서 쓰게 됩니다.

넷째, 위 문제가 해결되었다 해도 모델을 업데이트할 때 마다 같은 작업을 반복해야 합니다.

힘들게 배포한 모델에 오류가 숨어있었습니다.

더 많은 실험을 통해 모델의 성능이 눈에 띄게 좋아졌습니다.

새로운 라이브러리의 추가, 새로운 작업, 새로운 스케줄링이 필요하다면 위 작업을 다시 해야할 까요?

한 보고서에 따르면 AI를 다루는 기업은 88%가

위와 같은 문제로 인해 테스트 단계에서 벗어나지 못하고 있습니다.

이제, MLOps

MlOps 구글트랜드

MLOps로 불리는 머신러닝 파이프라인은
전 세계 모든 조직들이 공통적으로 고민하는 문제입니다.

분석가와 머신러닝 엔지니어에 대한 관심이 지금보다 조금 적었을 때,

SW 개발자들은 비슷한 문제를 오랜기간 고민했습니다.

수 많은 CI/CD

Git, Jenkins, Travis CI, TeamCity, Circle CI

한 번쯤 들어보신 적 있는 위의 이름들은 로컬 컴퓨터의 작업 코드를 원격지 서버의 코드와 동일하게 보장하기 위한 도구들입니다.

보통, 코드의 형상관리는 Git에서 하는게 일반적이죠.

Git에 있는 마지막 형상 코드를 젠킨스등 CI/CD라 불리는 도구들을 통해서 원격지 서버에 배포했습니다.

이를 DevOps라 부르고 있고,

현재, 필드에서 말하는 MLOps는 이 아이디어를 일정 부분 가져옵니다.

DevOps와 MLOps는 뭣이 같고, 뭣이 다른데??

일반적으로 웹 서비스를 구축할 때,

과거에는 코드를 서버에 업로드시키는 것만으로도 배포가 완료되는 시절이 있었습니다.

보통은 배치 작업같은 것이 필요없으니까, FTP같은 프로그램으로 서버에 올리면 끝났어요.

하지만, 웹 프레임워크가 발전하고 프로그래밍 언어가 발전하면서 다양한 외부 프레임워크의 의존성이 강해졌고,

곧 빌드라는 작업이 필요하게 됩니다.

코드짜는 것도 짜증나는데 배포 단계가 늘어나는 걸 귀찮아했던 개발자들은

Git 리포지터리의 마지막 코드를 빌드와 업로드를 대신해 주는 걸 생각하게 됩니다.

좀 편해졌다 싶었더니, 외부 프레임워크가 점점 발전하다보니 또 문제가 생겨요.

본질적으로 내 로컬 컴퓨터랑 서버 컴퓨터의 사양이 다르니 자꾸 오류가 생겨요.

이번에 개발자들은 내 로컬 환경과 동일한 환경을 서버에 통째로 올려버리는 걸 만들어 버립니다.(=도커)

점점 접점이 있다는 것이 느껴지시나요?

주피터 설치하는 법, 아나콘다 설치하는 법, 텐서플로 설치하는 법

네이버에 검색하면서 다들 고생 한 번씩 해보셨을 겁니다.

머신러닝 서비스는 웹 서비스에서 사용하는 라이브러리에 비해 설치가 굉장히 까다롭습니다.

또, 버전 의존성이 매우 크지만, 호환성은 매우 취약합니다.

머신러닝 서비스를 운영할 컴퓨터마다 로컬 실험 환경과 똑같은 환경으로 세팅하기는 절대로 쉽지 않습니다.

도커

도커를 사용하는 것이 텐서플로를 사용하는 가장 쉬운 방법입니다.

텐서플로 공식문서에 다운로드 챕터에 포함되어 있는 제일 첫 문구입니다.

그렇지만, 아직도 머신러닝 엔지니어나 데이터 분석가들은 도커의 사용을 어려워합니다.

도대체 도커를 왜 써야하는데??

혹시 DGX 머신을 가지고 있으신가요?

수 많은 가상 환경과 버전이 충돌하는 프레임워크들로 범벅이 되어 있진 않은가요?
GPU를 나눠서 실험 환경과 서비스 환경을 분리할 수 있을까요?
다른 사람이 GPU를 점유하고 있을 때, 언제 끝나나 기다리시고 계신가요?

제플린에서 머신러닝 코드를 실행하시나요?

나의 코드가 제플린 서버를 멈추게 하여 다른 작업자의 야근을 유도하진 않았나요?
내 코드가 환경에 비해 적은 리소스, 혹은 많은 리소스를 사용하진 않나요?
배치 작업을 하기 위해 airflow등 외부 도구에 의존하진 않나요?

결국, 문제는 분리

공통 환경을 사용하는 각 작업자의 독립적인 실험 환경 분리
실험 환경과 서비스 환경의 분리
분리된 실험 환경과 서비스 환경의 동일한 환경 보장

도커는 작업 환경의 분리와 이식이 가능한, 이 세상이 허락한 유일한 마약.

왜냐면, 단 한번만 익숙해지면 알아서 쓰게됩니다.

데이터 분석가를 위한 도커 포스트를 작성 중입니다.

쿠버네티스

어렵지만, 자세히 알지 못해도 됩니다.

도커 파일로 만든 컨테이너들의 생성(=코드의 실행)과 삭제(=리소스 부족으로 인한 폭파)와 스케줄링(=배치 작업)을 대신해주는 친절한 도구입니다.

머신러닝 엔지니어와 분석가가 도커 파일만 작성할 줄 안다면,

MLOps 개발자가 이 도구를 이용해 모델과 분석 코드의 배포, 스케줄링이 가능하게 해줄 겁니다.

다음 포스트는
아주 아주 아주 낮은 수준의 머신러닝 파이프라인을 다룰 예정입니다.
그런데도, 양이 적지 않습니다. 😹

Azure MLOps

다음 포스트에서는 파이프라인 뒷부분에 해당하는 모델 배포 자동화 파이프라인을 소개합니다.

머신러닝파트가 운영하는 서비스에 구축되어 있는 환경입니다.

모델과 머신러닝 프레임워크 환경의 자동 빌드
모델의 프로덕션 환경에 배포와 스케줄링
새로운 모델의 업데이트
배포된 모델의 모니터링와 관리

그 다음 포스트에서는 데이터 처리와 학습, 실험, 재 학습이 포함된 파이프라인을 소개할 것입니다.