🍥 스타트업 MLOps 활용기

스타트업도 MLOps가 필요한가?

스타트업에서는 AI 서비스가 새롭게 도입되고 제거되는 일들이 빠르게 진행되는 것 같아요. 환경이 빠르게 바뀌어 이에 맞춰서 배포 환경 또한 바뀌어야 할때도 있구요. 무엇보다 한명의 팀원이 모델 실험, 관리, 배포, 서빙, 인프라 관리, 모니터링, 분석일을 모두 하기 때문에(그렇게 풀스택이 된다..) 최대한 머신러닝 엔지니어가 해야하는 일들을 자동화, 효율화시키는 것이 중요합니다.

다른 스타트업에서도 MLOps에 대해 관심이 많을 것이라 생각하여 글을 작성하게 되었어요. 저희는 GCP 클라우드를 사용하고 있어 아래 내용은 GCP와 관련된 서비스들이 주로 활용되고 있으나 타 클라우드에서도 비슷한 서비스가 있을 것이기 때문에 참고해서 MLOps를 적용한다면 더 쉽고 빠르게 적용될 수 있을 것이라 생각합니다!

MLOps 구성도

 

Google Cloud Build를 사용한 CD

우리 회사에서 가장 처음으로 도입한 MLOps는 Docker였다. 우리는 맥북에서 API를 개발하고 debian 기반의 리눅스 환경에 모델을 배포하고 서빙한다. 그러다보니 맥북 환경과 배포 환경이 달라져 신경써야할 것들이 많아졌다. 패키지 버전이 달라지는 경우가 있었고 패키지가 환경에 따라 다르게 설치해야하는 경우가 있었다. 그렇게 docker container 위에서 API를 개발하기 시작했고 docker image를 그대로 감싸 배포하게 되었다.

배포를 위해서 자연스럽게 다른 MLOps가 추가되었는데 cloud build였다. cloud build를 통해 docker image에 들어갈 패키지 설치와 storag에 저장된 AI 모델들을 copy하게 되었으며 코드가 변경될 때마다 자동으로 Docker image를 빌드할 수 있어 빠르게 빌드할 수 있게 되었다. docker image의 경우 container registry에 저장하고 있어 자동으로 image 버전을 관리할 수 있게 되었다.

BentoML이 빠르다고 하던데..

기존에 Flask를 사용하고 있었으나 속도를 높이기 위해 여러가지 시도를 하던 중 BentoML이 Flask보다 속도가 빠르고 머신러닝 모델 서빙에 특화되어 있다는 BentoML 제작자의 말에 솔깃하여 서빙툴을 BentoML로 변경하였다. Flask에 비해 BentoML은 서버 엔지니어가 없는 스타트업에게 적합했고 도입하기까지 리서치 기간은 꽤 걸렸지만 손쉽게 API를 개발하고 배포할 수 있게 만들어주었다. 그러나 여기서 문제가 생긴다..

새로운 API들이 서빙되기까지 시간이 많이 소요되어 비동기적으로 post를 날려야하는 상황이 왔는데 두개의 API에 동시 요청이 들어왔을 때 pending되는 문제가 발생했다.. 그 이유는 BentoML이 WSGI 방식이었기 때문이었다. 해결하기 위해 ASGI 기반의 FastAPI를 wrapping하여 사용하게 되었고 자연스럽게 FastAPI를 추가로 도입하게 되었다.

WSGI와 ASGI

• WSGI
  • python 애플리케이션, 스크립트가 웹 서버와 통시하기 위한 인터페이스
  • 한 번에 하나의 요청과 응답만 처리하여 응답이 즉시 반환됨.
    • 웹소켓 또는 롱 폴링 HTTP 연결과 같이 장시간 지속되는 연결을 처리할 방법이 없음.
  • 동기 전용. 멀티스레드 연결 풀을 사용하더라도 응답이 반환될 때까지 각 연결이 차단됨.
  • 많은 WSGI 설정에 스레드와 스레드 풀을 처리할 수 있는 기능이 있지만, WSGI 인터페이스 자체가 동기적이라는 점에 의해 제한됨.
• ASGI
  • 함수 전반에서 비동기 메타포를 사용함.
    • 함수 자체는 async이며 HTTP 헤더와 응답 본문을 별도의 두가지 await send() 명령으로 보냄.
    • 따라서, 함수 자체와 이 함수의 send 명령은 아무것도 차단하지 않음.
    • 즉, 다른 많은 연결의 application 및 send 호출과 동시에 교차가 가능함. 

몇시 몇분 몇초에 발생한 에러라구요..?

대부분이 그렇듯 프론트엔드에서 요청이 들어오고 백엔드를 거쳐 AI 서버에 요청이 들어오는 구조이다. 그렇다보니 어디에서 에러가 발생했는지 찾기 어렵다. 순차적으로 프론트엔드, 백엔드에 아무 문제가 없거나 AI 서버에서 에러 메세지를 받았다는 것이 확인되면 AI팀에 전달되고 해당 시간에 로그를 확인해보고 어떤 문제가 발생했는지 디버깅 했었다.

datadog을 도입하고 나서 빠르게 에러를 확인할 수 있게 되었으며, trace_id를 통해 하나로 이어진 프론트엔드, 백엔드, AI로 쉽게 에러 디버깅이 가능해졌고 datadog의 metric을 통해 우리가 서빙하고 있는 모델이 어떤 예측값을 내고 있는지 쉽게 확인할 수 있게 되었다.

마치며

MLOps 시작해야지..하면서 도입했던 툴보단 필요에 의해 도입하는 경우가 더 많았던 것 같아요. 대부분의 머신러닝 엔지니어분들도 이런 비슷한 고민을 하고 있을 것 같은데 저희 회사에서 도입한 흐름을 보고 가장 필요한 것 먼저 하나씩 해본다면 어느새 MLOps를 도입한 회사가 되어 있을 것 같아요! 아직 더 신경써야할 것이 많지만 지난해 불편했던 점들을 하나씩 해결해나가면서 꽤 즐거웠던 도입기였습니다😀 이 글을 읽으신 분들에게 도움이 되셨길 바랍니다. 지금까지 읽어주셔서 감사합니다!💛