Week 17 - Product Serving 1

Prodect Serving 개요

Serving이란?

수행할 작업에 적한 연구 과정이 끝난 후 이를 실제 생활에서 사용할 수 있도록 배포하는 것을 말한다. 모델의 서비스화라고 이해하면 쉽다.

예시

• 유튜브 알고리즘
• DeepL 번역기

Serving의 종류

Batch Serving

• 데이터를 일정 묶음 단위로 서빙(정기 배송처럼 생각하기)
• Usecase
  • 실시간 응답이 중요하지 않은 경우
  • 대ㅐ량의 데이터를 처리할 때
  • 정기적인 일정으로 수행할 때
• 적정 인력: Batch Serving이 보다 쉬운 편이기 때문에 인력이 적을 때
• 데이터 저장: RDB, Data Warehouse

On-line(Real Time) Serving

• Client가 요청할 때마다 서빙(주문 후 바로 받는 상황 생각하기)
• Usecase
  • 실시간 응답이 중요한 경우
  • 개별 요청에 대한 맞춤 처리가 필요할 경우
  • 동적인 데이터에 대응해야 할 때
• 적정 인력: API 서버, 실시간 처리 등의 경험 필요
• 데이터 저장: 요청할 때 데이터를 함께 제공

머신러닝 디자인 패턴

Batch Serving - Batch Pattern

상황

• 모델 개발 완료 후 가장 간단하며, 최소한의 비용으로 배포하고자 할 때
• 위 Usecase 참고

어떻게

• DB: 모델의 예측을 주기적으로 수행하여 해당 결과를 DB에 저장
• 서비스 서버: DB에 주기적으로 접근하여 예측 결과 추출

Job Management Server

• Apache Airflow를 주로 사용
• 특정 시간에 주기적으로 Batch Job을 실행

Job

• 특정 작업을 수행하기 위한 Model Load, Data Load도 Job에 포함됨
• Python Script, Docker Image 등으로 실행

Data

• 서비스에서 사용되는 DB(AWS RDS 등), Data Warehouse 등에 저장
• 서비스 서버에도 데이터 관련 스케줄링 Job이 존재하여 특정 시간 단위로 데이터를 추출

장점	- 기존에 사용하던 코드 재사용 가능 - API 서버를 개발하지 않아도 되는 단순함 - 서버 리소스를 유연하게 관리 가능(오래 걸릴 Job에 리소스를 추가로 투입)
단점	- 별도의 스케줄러(Ex. Apache Airflow) 필요

Web Single Pattern - Online Serving

상황

• Batch Pattern 적용 이후 결과 반영에 텀이 존재
• 위 Usecase 참고

어떻게

• API 서버 코드에 모델을 포함하여 배포
• 예측이 필요한 곳에서 해당 서버에 직접 Request 요청
• 예측 서버: Fast API, Flask 등으로 단일 REST API 서버를 개발 후 배포
• Client: 앱에서 직접 요청 또는 서비스 서버를 통해 요청

Data

• 요청 시 데이터를 함께 담아 요청, 해당 데이터를 바탕으로 예측 수행
• 상황에 따라 용량 제한 발생 가능

Load Balancer

• 트래픽을 분산시켜 서버에 부하가 걸리지 않도록 조절
• Nginx, Amazon ELB(Elastic Load Balancer) 등

장점	- 보통 하나의 프로그래밍 언어로 진행 - 단순한 구조 - 처음 Online Serving을 할 때 용이함
단점	- 구성 요소 하나(모델, 전처리 코드 등)가 바뀌면 전체적인 수정이 필요 - 모델이 큰 경우, 로드가 오래 걸림 - 요청 처리가 오래 걸리는 경우, 서버에 부하 발생 가능

Synchronous Pattern - Online Serving

상황

• Fast API로 모델을 Web Single 패턴으로 구현, Client는 API 서버로 요청 후 끝날 때까지 대기
• 예측 결과에 따라 Client의 로직이 즉각적으로 달라져야 하는 경우

어떻게

• Web Single Pattern을 동기적으로 서빙
• 대부분의 REST API 서버는 동기적으로 실행됨

장점	- 단순한 구조와 Workflow - 예측이 완료될 때까지 프로세스가 다른 작업을 할 필요 없음
단점	- 예측 속도가 병목 - 예측 지연으로 사용자 경험 악화

Asynchronous Pattern - Online Serving

상황

• Synchronous로 수행 시 수많은 요청을 감당할 수 없어졌을 때
• CPU와 Memory를 증가하면 단기적으로 해소가 되긴 하지만 궁극적인 해결법이 될 수 없음
  • Black Friday와 같이 단기적으로 사용하는 방법이기도 함
• 예측과 Client 진행 프로세스의 의존성이 없는 경우
• 예측 요청을 하고 응답을 바로 받을 필요가 없는 경우
• 예측을 요청하는 Client와 응답을 반환하는 목적지가 분리된 경우

어떻게

• 요청이 들어올 때마다 개별적으로 처리가 될 수 있도록 수행
• Client는 당장 결과를 받지 않아도 되지만, 최종적으로는 결과를 받아야 함
  • 예측 수행 중에는 다른 작업을 수행하다가 완료 후 푸쉬 알림을 전송하는 등의 방법

Queue

• Client와 예측 서버 사이에 메시지 시스템 추가
  • 요청을 Queue에 저장(push), 요청을 불러와서(pull) 해당 작업 수행
• Apache Kafka

장점	- Client와 예측 프로세스가 분리되어 서로 의존적이지 않음 - Client가 예측을 기다릴 필요 없음
단점	- 메시지 Queue 시스템 설계 필요 - 전체적으로 구조가 복잡해질 수 있음 - 완전한 실시간 예측에는 적합하지 않음(Queue의 push, pull에 시간 소요)

Anti Serving Pattern

Online Bigsize Pattern: 실시간 작업이 필요한 서비스에 예측이 오래 걸리거나 너무 큰 모델을 사용하는 경우

• Batch로 변경이 가능한지 검토
• 중간에 cache 서버 추가, 전처리를 분리하는 작업으로 Bigsize를 피하는 방법

All-in-one Pattern: 하나의 서버에 여러 개의 예측 모델을 띄워 사용하는 모듈 및 패키지들의 의존도가 높은 경우

• 모델 벼로 서버를 분리하여 배포(Microservice 패턴)