[FEATURE] Flask Serving 관련 논의사항

[ssaru]

🚀 Feature

• 모델 서빙 관련 논의

Motivation

• 한두달쯤 모델 구현 및 재현이 완료되면 모델 Serving을 하게될 예정입니다.

• 모델 Serving에 대비하여 Flask-Serving을 준비하려합니다.

• 모델 Serving할 때, 어떤방식으로 관리할지 함께 논의해보면 좋을 것 같습니다.

Pitch

1. Flask-Serving을 하는 Flask-RESTful 모체 코드가 있습니다

2. 사용자가 model serving을 위한 작성할 handler.py가 있습니다

   • POST로 받은 모든 parameter를 dict타입으로 handler로 전달받습니다

3. Dockerfile로 (1), (2)를 묶으며, nginx와 uWSGI로 함께 묶어 빌드됩니다.

   • micro service architecture를 구성하는 측면에서 nginx와 uWSGI를 묶는게 옳은 방식인지 잘 모르겠습니다. 회사에서는 별도의 gRPC를 구성해서 쓰기 때문에 제가 이쪽으로 경험이 없네요;;
   • Serving을 위해 빌드한 Dockerfile은 컨테이너화하여 E2E 테스트를 수행합니다
   • gunicorn은 제가 잘모르는데 @soeque1 님께서 의견 주시면 감사하겠습니다. 🙇‍♂️

4. serving폴더에는 배포를 위한 helm 챠트가 존재하며, 사용자를 자신의 모델에 맞춰 helm챠트 value를 넣어둡니다

5. 빌드된 Dockerfile은 github docker package에 업로드됩니다.

• (3), (4), (5)는 GitHub Action에서 일괄적으로 처리합니다.

비동기 MQ관련

• 초기에는 동기식으로 서버를 구축할 생각입니다만, 추후에 RabbitMQ나 Kafka를 붙여서 비동기 스트리밍을 지원해볼까 생각하고있습니다.
  • Adaptive Batch Inference도 고려 중입니다.
• 확장성을 고려했을 때, 위의 구성이 올바른지 모르겠습니다.

Additional context

[soeque1]

Deep learning serving 관련 예제들은 많이 존재하지만

딥러닝 특히 Bert이상의 큰 모델들을 서빙하는 것에 대하여
리소스, 속도, 안전성을 고려하여 설계 및 개발하는 것은 시간과 노력 & 경험이 필요하다고 생각됩니다.
오픈소스 Tool(혹은 프로젝트) 마다 조금씩 부족한 부분들이 있고, 각자의 프로젝트에서 이를 개선해나가고 있는 것으로 알고 있습니다.

1. 웹서버가 필요한가?
   1.1. 웹서버의 여러 기능 중 우리에게 가장 필요한 것은?

• 특정 app 이 이상있을 때 자동 re-load
• 동시성 처리
• 캐시
• 로드 밸런싱
• SSL

등등 여러가지가 있겠으나 -> 대부분 혹은 일부 k8s나 클라우드의 기능으로 대처할 수도 있고

1.2. 웹서버 & 파이썬을 사용하지 않는다면 uWSGI나 gunicorn이 필요없겠죠.
=> 예를 들어, 아주 나이브하게는 특정 app 컨테이너를 k8s에서 auto-scale하는 것도 방법일테구요.

그럼에도 불구하고, 아직까지는 flask 등을 이용한 파이썬 어플리케이션의 경우 웹서버를 사용하는 것이 더 효율적이라고 생각됩니다.
=> 또한 구성도 쉬우니까요.. 최적 환경을 찾는 건 까다롭지만요;;

2. uwsgi vs gunicorn

• 개인적으로는 gunicorn을 선호합니다.
• 퍼포먼스 차이보다는 문서가 상대적으로 더 잘되어 있습니다.
• model serving에서 중요한 preload와 process fork 등이 gunicorn에서 더 명확하다(쉽다)고 판단됩니다.
  (예, tokenizer 공유 등)
• uwsgi도 용례에 맞게 잘쓰면 좋다고 생각합니다.

3. 'nginx와 uWSGI로 함께 묶어' 의 경우 컨테이너를 분리하는 것이 일반적이라고 생각됩니다.
   => 그러나, 편의에 따라 묶어도 좋다고 생각합니다.

[종합의견]
서론이 길었는데..
각자 분야나 경험이 조금씩 다르고, 심지어 같다고 하더라도 프로젝트마다 정답은 다르다고 생각합니다.
저는 <자발적인 외부 스터디인만큼> 서로 협업할 수 있는 동기부여가 가장 중요하다고 생각합니다.
하려는 것을 <웬만하면> 막지말자!
현재 우리가 기대하는 "소비자 수요"를 감당하기 위해서는 무엇을 선택하든 다 좋다고 생각합니다.
같은 맥락으로 비동기든 gRPC든 python + uwsgi + flask 든 torchServe 든 public cloud lambda나 function 이용, 기능추가 모두 좋다고 생각합니다.

그러나 <기민하게 새로운 기능>을 추가하거나 <누구나 쉽게 변경할 수 있는 시스템 구조>만 잘 지켜졌으면 좋겠습니다.
제가 리뷰를 희망하는 것도 이 포인트에서 같이 기여하고 싶었습니다.

=> 다른 분 의견도 들어봐야겠지만, 우선 제시한 방법으로 하시고

• MQ
• gRPC
  등 추가 기능들이 잘 수용될 수 있도록 하면 좋겠습니다.

• 개인적으로는 챌린지하거나 말도 안되는 기능같은 것도 환영합니당! (같이하면 재밌을 것 같습니다)

TL;DR

• 개인이 하고싶은 것들을 마음껏 하게하자. 단, 변경도 언제든 쉽게!