MLOps System Design 와 개발 이야기 (1)
와주셔서 감사합니다.
MLOps 개발자로 지내온 시간을 한번은 정리해야겠다 생각이 들어 개념 정리와 함께 시간을 가져보고자 합니다.
보시는 분들께도 도움이 됐으면 좋겠습니다.
MLOps는 재밌는 단어라고 생각합니다.
MLOps 자체가 새로운 직군으로 분류되는 경우도 있고, 기존 Backend나 Devops에서 다뤄야 할 프레임워크가 늘어나는 것으로 인식하고 계시는 분들도 있습니다.
또한 ML Researcher나 Engineer 분들이 Triton, DeepStream, RedisAI, Sagemaker, FastAPI, BentoML, TorchServe 등 서빙에 활용 가능한 다양한 프레임워크들을 공부하고,
CI/CD에서 주기적인 학습과 모델 배포까지 신경써야하니 R&R의 경계가 모호하고 애매해지는 것 같습니다.
Cloud, On-Premise, Hybrid등 환경도 다양하다보니 더더욱 그렇게 되는 것 같습니다.
AI를 이용한 서비스를 유저에게 전달하는데 있어 필요한 모든 과정이다 보니, 일종의 새로운 문화라고 표현하는 글도 봤는데 일리가 있는 것 같습니다.
이렇게 뜨거운 감자가 되다보니 점점 System Architecture가 복잡해 질 수 밖에 없고, 이를 잘 들여다보기 위해선 Design Pattern에 대한 이해가 필요하다고 생각됩니다.
저는 그 동안 당장 눈 앞에 있는 일들을 해결하기 위한 개발을 주로 해와서, 머릿속에 개념들이 점 조직처럼 파편화가 되어있었습니다.
언젠가 이를 연결시켜 지도로 만들어야겠다고 생각하고 있었으나, 그 언젠가는 제가 결재하지 않으면 시작하지 않는다는 사실을 깨닫고.. 경험을 돌아보며 같이 정리를 하고..
오늘부터 지도를 연결시켜 나가기로 결심하여.. 그 동안의 경험과 함께 정리하는 시간을 가져보고자 합니다.
참고 :
https://github.com/mercari/ml-system-design-pattern
(mercari/ml-system-design-pattern)
https://saramin.github.io/2022-05-17-kubernetes-autoscaling/
( 사람인 기술블로그 / Kubernetes에서 HPA를 활용한 오토스케일링(Auto Scaling) )
Web Single Pattern은 가장 간단한 구조로 Inference Server를 빠르게 출시할때 사용 할 수 있는 패턴 중 하나입니다.
모든 Artifact가 웹 서버에 함께 저장되어, 단일 서버 RestAPI를 통해 실행할 수 있습니다.
물론, 같은 Inference Server를 이중화, 다중화하여 Nginx나 Apache를 통한 L7 LoadBalancing이 가능합니다.
기존에 개발했던 상담사 챗봇, 추천 프로젝트에도 위와 같은 구조로 서비스가 들어갔습니다.
점검해야 할 요소
- FastAPI에서 TorchServe의 Health Check를 관리 포인트에 제공 가능 해야함 (모니터링)
- 모델 추가 학습은 학습 전용 서버를 통해 진행 (서버 분리의 필요성)
- 추론(테스트)서버로 학습된 모델이나 임베딩을 배포하고 MD5SUM을 통해 무결성검사 진행 (배포 정상 확인)
- Torch Serve가 이상 없이 올라오고 Inference API 호출이 잘 된다면 OK (Torch Serve 가동 시 warm-up 하면 Good)
단점과 보안 방법
- TorchServe의 Initialize 함수가 작동하는 동안에 VIP에서는 TorchServe가 Model Loading이 끝났는지 확인할 수 있는 방법이 없었습니다. (K8S가 필요한 이유)
(Model Loading 후 CallBack을 보내주면 될 것 같긴 합니다만, Handler에 구현해야하니까요..)
- 마찬가지로, 배포나 업데이트도 Shell Script로 Canary 방식으로 작성해서 진행하긴 했습니다.
(ex : 1번 Inference 서버에 배포 -> OK -> 2번 Infernce 서버에서 에러 -> 1,2번 서버 롤백)
- 추후 K8S를 적용하게 된다면, Container probes를 활용하여 Auto Scaling이나 업데이트시 발생할 수 있는 이슈
(ex : 아직 Pod만 떴는데 요청을 보내버려서 장애 발생)를 보완할 수 있을 것 같습니다.
- livenessProbe :
파드의 진단 결과가 Failure일때 restartPolicy에 따라서 컨테이너를 종료 또는 재시작 시키도록 동작
- readinessProbe :
파드가 트래픽을 받지 않는 상태에서 시작하여 진단 결과 Success일때 트래픽이 유입되도록 동작
- startupProbe가 Container spec에 정의되어 있다면 진단 결과 Success일때,
livenessProbe와 readinessProbe가 활성화 되도록 동작