이번주 강의 주제는 Product Serving이었다.
개인적으로 좀 기대를 했던 주제이기도 했는데, AI 모델을 서빙하는 서버 구조가 일반적인 백엔드 서버 구조와 어떤 다른점이 있을지가 궁금했었다.🤔
전에 백엔드를 공부했었다보니, 금방 강의 진도를 끝낼 수 있을 것이라고 생각했는데 생각외로 실습 과정에서 에러도 많이 발생하고, 새로운 것들이 많아서 강의 진도가 늦어졌다.
그래도 2주에 걸쳐서 진행되는 주제이다보니 이번주에 전체 10강 중 절반은 끝내야겠다 생각했었는데, 무사히 딱 절반까지는 끝낼 수 있었다.
이번주에 학습한 내용은 크게 세 가지였다.
1) Airflow
2) Poetry
3) FastAPI
Product Serving에 앞서 모델을 서빙하는 방식을 정해야하는 데, 모델을 서빙하는 방식에는 두 가지가 있다.
1) Batch Serving
2) Online Serving
Batch Serving은 특정 단위로 모델 예측값을 생성한 뒤에 저장해두었다가, 묶음 단위로 서빙하는 것을 말한다. Online Serving은 클라이언트에서 요청이 오면 그때마다 바로 모델 예측을 생성하여 실시간으로 서빙하는 것이다.
여기서 Airflow는 Batch Serving을 위한 것이고, FastAPI는 Online Serving을 위한 것이라고 할 수 있다.
Poetry는 그동안 requirements.txt로 관리하던 개발 환경을 좀 더 효율적이고 쉽게 관리할 수 있도록 하는 도구이다.
나는 FastAPI에 대한 내용을 기대하고 있었는데 생각보다 Airflow에 관한 내용이 재미있었다. FastAPI는 기존에 백엔드 서버에서 REST API를 구현하는 방식과 유사한 부분이 많았는데, Airflow는 색다른 내용이라 실습하는게 굉장히 재미있었다.
Airflow는 DAG을 사용하여 작업의 흐름과 순서를 정의하고, 이 DAG을 Scheduler를 통해 관리하고 스케줄링한다. 그리고 스케줄에 따라 Operator로 정의된 작업 클래스들을 Executor로 실행하는 구조이다. 이 Airflow를 통해 일정 주기로 모델을 새로 학습시키고, 예측을 생성하여 묶음 단위로 서빙하는 Batch Serving을 구현할 수 있다.
FastAPI는 자바로 REST API를 구현하는 것과 구조적으로 크게 다르진 않았지만, 인상적이었던건 Swagger를 따로 라이브러리를 설정해주지 않아도 자동으로 생성해준다는 점이었다. 또한 Pydantic으로 데이터 Validation과 Config 관리를 하는 부분은 좀 더 깊게 학습해보고 싶다.
🚩FastAPI를 좀 더 활용해서 디테일한 모델 서빙 과정을 구현해보기
🚩최종 프로젝트 아이디어 생각해보기