Part-1에서는 MLOPs에 대한 소개와 플러스제로에서 어떻게 적용하려고 하는지에 대한 내용을 소개드렸습니다.
Part-2에서는 데이터 중심적 (Data Centric)과 관련있는 MLOPs 컴포넌트와 AI 모델 개발 및 학습시 플러스제로에서 고려하는 부분을 소개드렸습니다.
이번 Part-3에서는 “AI모델 배포”에 중점을 맞추어 소개드리려고 합니다.
AI 모델을 배포하기 이전에, 고려되어야 하는 사항이 몇가지가 있습니다.
고려사항중의 첫번째는, “어디에서 모델이 작동해야 하는가?" 라는 질문을 우선 정리가 되어야 합니다.
AI모델은 사내 또는 클라우드 서비스에서 제공하는 서버를 이용하여 사용 될 수도 있으며, Edge Device에서 또한 사용 될 수도 있습니다.
Edge Device의 경우 한정된 컴퓨팅 자원이 있기에 거대한 AI모델을 해당 디바이스에서 작동하게 하기 위해 추가적인 작업을 필요로 합니다. 가장 보편적으로 사용하는 툴로는 Nvidia사 에서 제공하는 TensorRT, TF-Lite 등 다양한 툴을 사용하여 학습된 모델을 경량화 및 Edge Device에서 사용 가능하도록 변환 작업을 통한 배포를 진행합니다.
현재 플러스제로에서는 Edge Device를 AI 모델 배포를 위한 “Target Machine”으로 사용하지 않습니다.
Edge Device배포와 관련된 툴에 대해서는 링크를 참고해 주세요
TensorRT: https://developer.nvidia.com/tensorrt
TF-Lite: https://www.tensorflow.org/lite
Torch-Mobile: https://pytorch.org/mobile/home/
플러스제로에서는 AI모델을 Edge Device가 아닌, 서버 또는 클라우드 서비스에서 구동하도록 하고 있습니다.
모델을 서버에서 구동하게 한다고 하여도 학습된 모델을 바로 배포하는 것이 아닌, 다양한 방법을 통하여 “배포” 관점에서의 퍼포먼스를 개선하려 하고 있습니다.
다음으로 넘어가기 이전에 AI모델의 “학습”과 “배포" 관점에서의 주요 퍼포먼스 지표를 정리해 보았습니다.
AI모델의 학습과 배포는 같은 모델을 기반으로 설정하지만, 관심있게 보는 지표는 다릅니다.
한 예를 들어보면, 연구자가 개발하고, 학습한 모델은 99.7%의 정확도를 보여주었습니다.
99.7%의 정확도를 산출하기 위해서 연구자는 GPU를 사용하여 학습 및 예측을 하였으며, 값이 입력되고 결과가 출력 되기 까지 7초의 시간이 걸렸습니다. 해당 모델을 사용하는데 소요된 컴퓨터의 자원의 양은 11GB의 GPU메모리를 사용하였습니다.
연구자의 입장에서는 높은 정확도를 보여주는 모델을 획득 할수 있게 되었습니다.
이번에는 동일한 모델 서빙 관점에서 바라봐 보겠습니다.
우선 첫번째로 현재 학습된 모델은 사용자가 결과를 받기까지 7초의 시간이 소요됩니다. 또한 많은 양의 GPU를 가지고 있지 못한 상황에서 5명이 동시에 호출할 경우 GPU메모리가 부족 할 수도 있습니다. 설상가상으로 서빙을 위한 서버에는 가용한 GPU가 없는 상황 일 수도 있습니다.
해당 Case를 잘 기억해 주세요. 이번 Part-3에서는 이 Case를 기반으로 이어집니다.
1. Model Serving Types
AI모델의 서빙은 여러가지의 분기점이 있습니다.
우선 첫번째로는 해당 서비스의 성격에 따라 달라집니다.
첫번째로는 데이터를 모델에게 어떻게 주는 방법에 따라 달라집니다.
어떤 서비스는 사용자는 모델의 결과를 받기위해 데이터를 직접 주는 방법이 있는 반면, 어떤 서비스는 사내 데이터베이스에 저장되어 있는 데이터를 통해 데이터를 받아볼 수 있습니다.
전자의 경우에는 Real-Time형태로가 필요한지를 검토해 보아야 하지만, 후자의 경우는 일정 주기마다 데이터가 데이터베이스에 갱신이 된다면 간단한 형태를 취할수 있습니다.
이런 경우는 AI모델의 Batch Prediction방법이라 알려져 있습니다.
Batch Prediction은 주기적으로 모델을 실행시킴으로써, 저장되어 있는 데이터를 사용하여 처리하고, 다시 저장하는 형태를 취합니다.
해당 방식은 가장 간단하고, 사용자에게 비교적 낮은 Latency로 결과를 제공할수 있습니다.
그러나, 사용자는 최신의 데이터를 빠르게 받아볼수 없고, 모델의 버그같은 예외상황을 빠르게 확인하기 어려울수 있습니다
그렇다면, 전자의 경우는 어떠한 방식으로 모델을 사용해야 할까요?
해당 방법은 Model-in-Service라는 형태를 취하게 됩니다. 서비스안에 AI모델이 포함이 되는 형태입니다.
이런 형태는 서비스를 사용하는 Front-End가 되는 Web Server에 AI모델을 포함 시키는 형태로, web server에서 다이렉트로 모델을 호출하게 됩니다.
그러나, 대부분의 Front와 AI모델은 각각 다른 프로그래밍 언어로 쓰여져 있어 연결이 힘들수도 있습니다.
또한 AI모델이 구동된다면, 서비스의 인프라를 사용하기 때문에 서비스의 전반적인 속도가 느려질 수 있으며, GPU를 포함하지 않은 서버가 많습니다. 또한 모델과 서비스의 스케일링이 다른 방법으로 진행 될 수도 있습니다.
이러한 단점들을 보완하기 위해서 가장 많이 사용하고 있는 방법은 Model-as-Service 방법을 가장 많이 사용하고 있습니다.
Model-as-Service란 AI모델을 Web 서비스처럼 별개의 서비스로 배포하는 방법입니다.
이 방식은 모델 서버와 web 서버가 분리되어 있어서 각 서비스의 스케일을 조정할수 있으며, 이전에 소개드린 방법들과 비교하였을때 더 유연하다는 장점을 가지고 있습니다.
하지만, 이런 방식은 결과적으로 사용자가 결과를 받기까지 시간이 늘어날 수 있으며, 서버의 인프라가 더 복잡해질 가능성이 높습니다. 또한, 모델이 주요한 서비스를 생성해야하는 추가 작업을 필요로 합니다.
플러스제로에서는 Model-as-Service 방법을 통하여 AI모델을 배포하고 있습니다.
그렇다면, Model-as-Service 형태를 위한 몇가지 컴포넌트와 기술 스택을 소개드리겠습니다.
2. Model Serving Types
REST API
- 독립된 서비스들의 통신을 위해서 프로토콜을 이용한 통신을 사용하기위한 API가 필요합니다.
API는 사용자와 모델과의 연결 통로라고 이해하시면 편할것 같습니다.
REST-API Post
Rest-API Response
Dependencies
- 독립된 서비스를 사용하기 때문에, 각 서비스는 개발환경과 동일한 패키지 의존성을 가지게 됩니다.
의존성은 개발 및 운영에 있어서 업데이트에 어려움이 있으며, 심지어 개발에 사용한 버전이 달라짐에 따라 서비스가 작동하지 않을 수도 있습니다.
이러한 문제점을 최소화 하기 위해 플러스제로는 “컨테이너"를 적극 사용하고 있습니다.
컨테이너 엔진 중, 보편적으로 사용하고 있는 Docker를 사용하여 AI모델을 학습시킬때 사용한 프레임워크의 버전을 동일하게 가져갈 수 있도록 하고 있습니다.
한 예시로, 문장의 의도를 분석하는 AI모델은 Pytorch-1.11을 사용하고 있으나, Keyword를 추출하는 모델은 Pytorch-1.10을 사용하고 있습니다. 물론 Pytorch의 경우 해당 버전의 컨플릭트가 비교적 적게 발생하지만, 이전 Tensorflow를 사용할때 버전 0.1 이 바뀜에 따라 코드가 작동하지 않았던 이력이 있어서 저희 연구팀은 의존성을 최소화 하기 위해 서비스별로 컨테이너화를 진행하고 있습니다.
Part-1에서 잠깐 언급드렸었던 Kubernetes는 이런 컨테이너들을 오케스트레이션 (설정, 관리, 조정 등)을 위해 사용을 고려하고 있습니다. 현재는 이런 컨테이너들의 작업을 도커 컴포즈와 Airflow를 통한 워크플로우를 설정하여 진행하고 있습니다.
Micro-Batching
- Micro Batching은 앞서 소개드렸던 데이터베이스에서의 Batch 작업하고는 다른 구조를 가지고 있습니다.
<BentoML - Adaptive Micro Batching>
Micro-Batching을 활용하여 다수의 사용자가 모델의 사용을 요청하였을때, 일정 시간 이내의 요청을 Batch로 처리하는 방법입니다.
이러한 방식은 최종 사용자에게 모델의 결과를 보여주기 까지의 소요시간을 늘릴수도 있으나, 다수의 사용자의 경우 이러한 방식은 더욱 효과적일 수 있습니다.
<Single User Inference>
<Adaptive Batching Inference>
앞서 소개드린 내용처럼 플러스제로의 연구팀은 AI모델 배포를 위해 컨테이너와 Micro-Batching이 효과적으로 구현된 BentoML을 이용하여 모델을 패키징 하고 있습니다.
이렇게 패키징 (컨테이너화)된 AI모델을 도커컴포즈 또는 쿠버네틱스에 올림으로써 ai모델의 배포를 진행합니다.
모델의 배포 방식은 여러 방식중에서 Blue-Green Deployment 또는 Canary Deployment 형태로 배포를 진행하고 있습니다.
Conclude
플러스제로의 MLOPs 시리즈는,
Part-1 [플러스제로가 생각하는 MLOPs]
Part-2 [데이터 중심적인 AI모델]
Part-3 [AI모델 배포]
를 소개드렸습니다.
MLOPs와 관련된 모든 컴포넌트를 소개드리지 못 하였지만, 플러스제로 연구팀은 데이터 중심적인 사고와 함께, 플러스제로의 파트너 분들의 비즈니스 의사결정을 원조할수 있는 효과적인 인공지능의 개발과 서비스를 제공하는 파트너로 매출에 0을 더하기 위해 노력하고 있습니다.