반갑습니다
Airflow에 대해 글을 작성하면서 좀 배워볼까 합니다.
Airflow는 다양한 AI 모델을 Serving할 때 많이 사용되는 도구입니다.
그 전에 Serving에 대해 먼저 다뤄야 할 것 같네요.
Serving에 대해서도 많이 들어봤지만 잘 몰랐는데, 이번 기회에 같이 알아가보면 좋을 듯 합니다.
Serve(제공하다)에서 파생된 용어로, 데이터의 다양한 처리 과정을 압축하여 사용자가 원하는 결과물을 내보내는 과정을 의미합니다.
사용자(Client)는 원하는 정보를 요청(Request)하면 요청에 맞는 작업들을 Background에서 수행하고 결과물을 제공합니다.
ML Serving을 예로 들면 데이터 전처리를 수행하여 모델의 Predict 결과물을 받아오는 과정을 의미할 수 있겠네요.
Serving에는 크게 두 가지 종류가 있습니다.
Batch Serving
Online(Real-Time) Serving
각각 살펴보겠습니다.
데이터를 일정 묶음 단위로 서빙하는 것을 의미합니다.
지정한 시간에 한번씩 Task를 수행한다고 보시면 되겠습니다.
예를 들어 실시간 데이터가 쌓이는 상황이라면, 1시~2시/2시~3시 이런식으로 한시간 간격마다 데이터를 처리해서 제공하면 Batch Serving이라 볼 수 있는것이죵
주로 대량의 데이터를 처리하거나
실시간 응답이 중요하지 않거나
정기적인 일정마다 수행하고 싶을 때 Batch Serving을 사용합니다.
클라이언트의 요청이 들어오면 실시간으로 데이터를 제공합니다.
API Request를 날리면 바로 원하는 정보를 받을 수 있는 상황이 Online Serving입니다.
주문후 즉시조리 같은 느낌이네요 ㅎㅎ
주로 실시간 응답이 중요하거나
개별 요청에 대한 맞춤 처리가 중요하거나
동적인 데이터(데이터가 계속변함)를 다뤄야 할 때 Online Serving을 사용합니다.
은행의 사기 탐지 시스템 같은 서비스들은 Batch Serving으로 구현되면 이미 사용자는 이미 다털리고 망하겠죠. 이럴 때 Online Serving이 중요하게 사용되지 싶습니다.
일반적으로는 Batch Serving이 Online Serving보다 조금 더 쉽다고 하네요.
보통 개발 분야에서 Patten이라 하면 디자인 패턴을 의미합니다.
디자인 패턴이란, 소프트웨어의 구조, 구성 요소의 관계, 시스템의 전반적인 행동 방식등을 의미합니다.
사람들이 많이 쓰는 소프트웨어 구조들을 디자인 패턴이라고 생각하시면 되겠습니다.
패턴이 왜 중요할까요
몇가지 이유를 나열해보면
ML 서빙에서의 디자인 패턴은 일반적인 소프트웨어 패턴과는 조금 다릅니다.
아무래도 코드만 다루는 개발과 다르게 모델, 데이터, 코드를 한 번에 다뤄야 하는 분야이다 보니 특수성이 있는 듯 합니다.
실시간성이 필요 없는 경우에 주기적으로 예측 결과를 DB에 저장하고 활용하는 쪽은 DB에서 결과를 읽어와 사용합니다.
Batch 패턴의 경우에는 Job Management Server을 따로 둡니다.
이 다음 글에 소개할 Apache Airflow가 주로 사용됩니다.
특정 시간이 주기적으로 Batch Job을 실행하는 주체가 되겠습니다.
(Job이라는 것은 모델 로드, 데이터 로드를 다 포함하는 파이썬 스크립트 또는 Docker Image입니다.)

위 사진과 같이 특정 시간마다 Data를 DB에서 가져온 뒤 결과를 Result table에 저장합니다.
Batch 패턴의 장점으로는
등이 있습니다.
매 주에 한번씩 노래를 일주일치 노래를 추천해주는 서비스 등에 활용이 될 수 있겠습니다.
Web (웹 기반 어플리케이션 ) Single (단일, 하나의 요청을 처리) 두 단어가 합쳐진 용어입니다. Online Serving에 활용되는 패턴입니다.
실시간으로 요청을 처리해야 하는 작업에 사용되는 패턴입니다.
모델이 항상 Load되어 있는 API 서버를 만들고, 서비스 서버에서 직접 Request를 보내는 방식으로 구현됩니다.

위 그림과 같이 서버에 모델이 로드가 돼 있고, 요청을 보낼 때마다 결과를 바로바로 받아올 수 있도록 설계되었습니다. (가운데의 Load Balancer는 트래픽을 분산시켜 서버에 과부하가 걸리지 않도록 합니다.
)
이 경우, 예측/추론 서버는 FastAPI, Flask 등으로 단일 REST API 서버를 개발 후 배포해야 합니다.
POST 요청을 보내 predict, inference를 수행하도록 하는 것이지요.
머신러닝 모델의 경우, API 로직 내에 전처리도 함께 포함합니다.
Client는 앱, 브라우저, 서버에서 요청을 보내 결과물을 받아올 수 있습니다.
모델의 경우, Request할 때 데이터를 같이 담아 Request합니다.
예시) Chat GPT의 Query, Youtube의 검색 Engine 등
Web Single 패턴의 장점은
가 있습니다.
하지만 코드를 묶어서 하나로 배포하다 보니 구성요소가 바뀌면 전체 업데이트가 필요하다던가, 모델이 큰 경우 Load에 시간이 오래 걸린다던가 요청 처리가 오래 걸리는 경우, 서버에 부하가 걸릴 수 있다는 단점이 있습니다.
단순한 만큼 단점이 좀 있군요.
구조가 단순한 만큼, 빨리 서버를 출시해야하는 분들이나 좀 배워보고 싶다 하시는 분들이 도전해보면 좋을 것 같습니다.
Synchronous (동기식) 패턴은 하나의 작업이 끝날 때까지 다른 작업을 시작하지 않고 기다리고, 작업이 끝나면 새로운 작업을 시작하는 방식입니다.
위에서 설명한 Web Single 패턴을 동기적(Synchronous)으로 서빙할 때 사용되는 패턴입니다.
대부분의 REST API 서버는 동기적으로 서빙됩니다.
Synchronous 패턴의 장점으로는
들이 있지만,
동시에 수많은 Request들이 들어온다면 순서대로 처리하는 만큼 대기 시간이 길어지는 병목현상이 발생합니다.
Asynchronous (비동기식) 패턴은 하나의 작업을 시작하고, 결과를 기다리는 동안 다른 작업을 시작하는 방식입니다.
Synchronous 패턴은 API 서버에 부하가 걸리는 단점이 존재합니다.
이를 해결하기 위한 비동기식 패턴입니다.
비동기식이 와닫지 않으신다면..
카페에서 진동벨을 나눠주는 것과 비슷하다고 생각하시면 되겠습니다.

클라이언트와 예측 서버 사이에 메시지 시스템 (Queue)를 추가합니다.
이 때 사용되는 프레임워크는 Apache Kafka입니다.
장점으로는
가 있습니다.
단점은.. 난이도가 어렵다는 것이겠죠.
Queue 시스템도 만들어야 하고 구조도 복잡해집니다.
또, 완전한 실시간 예측은 아닙니다.
요청이 많다면 약간의 대기 시간이 생기게 되겠습니다.
Anti Serving 패턴은 일반적으로 권장되지 않는 패턴을 의미합니다.
개발할 때 주의해야 하는 구조를 의미합니다.
Online Bigsize 패턴은 실시간 대응이 필요한 서비스에 응답이 오래 걸리는 시스템 구조를 의미합니다.
요청 하나 할때마다 LLM을 로드하는 코드는 좋지 않겠죠.
이런 경우, 모델을 경량화하거나 Batch Serving을 고려하는 것이 합리적이겠습니다.
캐시를 이용하여 속도를 올리는 것도 하나의 방법이 되겠습니다.
All-in-one 패턴은 하나의 서버에 여러 예측 모델을 로드하는 경우를 의미합니다.
이렇게 개발하면 사실 패턴에 대해 잘 알지 못하는 분도 개발하면서 좀 서늘할거같습니다.
단점을 나열해보면
대안으로는 예측 모델 1,2,3 을 모델 별로 서버를 분리하여 배포하는 것이 알맞는 방법이 되겠습니다.
.
.
.
이로서 서빙에 대해 소개하고 다양한 패턴들을 소개해봤습니다.
웹, 서빙, 서버.... 역시 어렵습니다.
이해도 중요하지만, 암기를 많이 해야하는 듯 합니다.
큰일티비군요 .. ㅠㅠ
다음 글에서는 Airflow에 대해서 작성해보겠습니다.
감사합니다 !