Product Serving(1): Serving

SeongGyun Hong·2024년 12월 9일
Product Servingnaverboostcamp

NaverBoostCamp

목록 보기
40/64

1. Serving이란?

  • 모델 예측결과를 요청한 Client에게 제공하는 과정
    • 데이터에 기반하여 모델 예측 결과를 제공하는 것
    • 서빙의 대표적인 예시: 유튜브 메인 화면
      • 개인화 추천 알고리즘으로 볼만한 영상을 자동으로 리스트업 해줌

2. Serving의 종류

2.1 Batch Serving

  • 데이터를 일정 묶음 단위로 서빙
    • ex) 14~15시 사이에 생성된 데이터
    • 정기 배송을 받고 싶은 경우에 해당함

2.2 Online(Real Teime) Serving

  • 클라이언트가 요청할 때 서빙
    • ex) API Request
    • 요청할 때 데이터를 같이 제공, 실시간
    • 주문이 들어오면 바로 만들어 전달하는 경우에 해당

2.3 어떤 Serving을 사용해야 하는가

  • 정답이 없다.
  • 문제의 상황, 문제 정의, 제약 조건, 개발 인력, 데이터 저장 형태, 레거시 유무 등에 따라 결정되기 때문에 수많은 방법론 중에서 하나를 선택하면 된다.

Batch Serving

  • 실시간 응답이 중요하지 않은 경우:
    데이터 처리에 일정 시간이 소요되어도 괜찮은 경우
    • 대량의 데이터를 처리할 때
    • 정기적인 일정으로 수행할 때
  • 인력
    • 인력이 적은 경우:
      Batch Serving이 Online Serving 보다 쉬울 수 있음

  • 데이터 저장 형태

    • RDB, 데이터 웨어하우스(GCP의 Big Query)

  • 예시

    • Netflix의 추천시스템, DoorDash의 레스토랑 추천
    • 1시간, 4시간, 24시간 단위로 예측 후에 DB에 저장하고, 서비스(앱/웹)은 DB에 있는 예측 결과를 활용하게 됨

Online Serving

  • 상황
    • 실시간 응답이 중요한 경우:
      즉각적으로 응답을 제시해야 하는 경우
    • 개별 요청에 대한 맞춤 처리가 중요할 때
    • 동적인 데이터에 대응할 때: 데이터가 지속적으로 변하는 경우

  • 인력

    • API서버, 실시간 처리 등의 경험이 필요

  • 데이터 저장 형태

    • 요청할 때 같이 데이터 제공
    • API, 메세지

  • 예시

    • 유튜브의 추천 시스템(새로고침)
    • 번역
    • 은행의 사기 탐지 시스템: 실시간 거래 이슈 탐지
    • 요청(Request)이 오면 바로 요청에 대한 응답(Response) 제공

3. Serving 패턴

소프트웨어 개발에 있어서의 패턴 => 디자인 패턴

  • 디자인(Design)
    • 소프트웨어 개발 분야에서는 디자인이라함이 단순 외관만을 의미하는 것은 아님
    • 소프트웨어의 구조, 구성 요소의 관계, 시스템의 전반적인 행동 방식
    • 즉, 소프트웨어를 어떻게 구성하고, 어떻게 상호 작용할지를 담은 내용

디자인패턴 = Template

  • 과거부터 문제를 해결한 사람들이 반복된 내용을 패턴으로 정리
  • 코드의 재사용성, 가독성, 확장성 등을 향상시키기 위한 목적으로 도입됨.
  • 주로 객체 지향 프로그래밍에서 사용되지만, 다른 프로그래밍 패러다임에서도 유용
  • 개발 과정의 커뮤니케이션에서 이런 패턴을 사용하기도 함
    • ex) "이번 서빙은 Batch 패턴으로 구현하죠"
  • 안티 패턴: 보통 좋지 않다고 알려진 패턴
  • 머신러닝의 특수성으로 별도의 디자인 패턴이 생김
    • 일반적인 소프트웨어 개발: Only Code
    • 머신러닝 개발의 특수성: Data, Model, Code
  • 머신러닝 서비스를 개발하다 고민하는 특수 포인트
    • 대용량 Model Load
    • Model 관리
    • 데이터를 대량으로 가져와서 전처리
    • 데이터를 통계적으로 확인해서 이상치 제외
    • 예측 요청 후 반응 시간이 오래 소요될 수 있음(모델이 연산하는 과정 이슈)
    • 학습, 예측, 운영하면서 생기는 노하우 => 패턴화
    • 지금도 계속 변하고 있을 머신러닝 디자인 패턴(LLM 이후에도 LLMOps 분야에서 계속 새로운 시도가 생기고 있을 것)
    • 상황에 따라 다르기에 이런 방법들이 항상 Best는 아니지만, 구현하기 전에 참고할 수 있음
    • 소개하는 여러 패턴을 합쳐서 하나의 패턴으로 만들 수도 있음
  • 제일 간단한 Serving 4가지 패턴
    • Batch Serving
        1. Batch 패턴
    • Online Serving
        1. Web Single 패턴
        1. Synchronous 패턴
        1. Asynchronous 패턴

자주 나오는 용어 정리

  • 예측 서버: 모델 예측 제공
  • 데이터베이스: 회원가입 등 데이터 저장
  • 서비스 서버: 유저에게 제공

3.1 Batch 패턴

  • 핵심
    실시간성이 필요 없는 경우에 주기적으로 예측 결과를 DB에 저장하고, 활용하는 쪽은 DB에서 결과를 읽어와서 사용

  • 장점

    • 기존에 사용하던 코드를 재사용 가능
    • API 서벌를 개발하지 않아도 되는 단순함
    • 서버 리소스를 유연하게 관리할 수 있음 (오래 걸릴 Job에 서버 리소스 추가 투입)

  • 고민할 점

    • 별도의 스케쥴러 (Apache Airflow 등) 필요

  • Use Case

    • 예측 결과를 실시간으로 얻을 필요가 없는 경우
    • 대량의 데이터에 대한 예측을 하는 경우
    • 예측 실행이 시간대별, 월별, 일별로 스케쥴링 해도 괜찮은 경우


출처: https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Batch-pattern/design_en.html

  • Job Managemnet Server

    • 작업을 실행하는 서버
    • Apache Airflow 등을 주로 사용
    • 특정 시간에 주기적으로 Batch Job을 실행시키는 주체

  • Job

    • 어떤 작업 실행에 필요한 모든 활동
    • Job이 실행되는 과정에 Model Load, Data Load도 포함
    • Python Script를 그냥 실행하는 경우도 있고, Docker Image로 실행하는 경우도 존재

  • Data

    • 서비스에서 사용하는 DB(AWS RDS 등) 또는 데이터 웨어하우스에 저장
    • 서비스 서버에서도 데이터를 불러오는 스케줄링 Job이 존재 => 특정 시간 단위로 가져옴

3.2 Online Serving 패턴

  • Web Single 패턴

    • Web(웹 기반 애플리케이션)에서 Single(단일 요청 처리)
    • 모델이 항상 Load 된 상태에서 예측을 해주는 API 서버를 만들고, 추천 결과가 필요한 경우에 서비스 서버에서 이 예측 서버에 직접 요청을 하면 어떨까? => Online Serving

  • 핵심

    • API 서버 코드에 모델을 포함시킨 뒤 배포
    • 예측이 필요한 곳(클라이언트, 서버 등)에서 직접 Request 요청

  • 장점

    • 보통 하나의 프로그래밍 언어로 진행
    • 아키텍쳐의 단순함
    • 처음 사용할 때 좋은 방식

  • 고민할 점

    • 구성 요소 하나(모델, 전처리 코드)가 바뀌면 전체 업데이트가 필요
    • 모델이 큰 경우, 로드 시간이 오래 걸림
    • 요청처리가 오래 걸리는 경우 서버부하가 올 수 있음

  • Use Case

    • 예측 서버를 빠르게 출시하고 싶은 경우
    • 예측 결과를 실시간으로 얻을 필요가 있는 경우
    • Web Single 패턴을 기본으로 삼고 이어지는 패턴들을 적용


출처: https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Web-single-pattern/design_en.html

예측/추론 Server

  • FastAPI, Flask 등으로 단일 REST API 서버를 개발 후 배포

    • 예: POST api-server-url/predict로 예측

  • API 서버가 실행될 때 모델을 로드

  • API 로직 내에 전처리도 같이 포함

  • Client

    • 앱에서 직접 요창할 수도 있고, 앱이 서비스 서버에 요청하고 서비스 서버가 예측 서버에게 또 요청할 수도 있음 (개발을 어떻게 했는지에 따라 다르다)
    • 웹 페이지라면 브라우저에 요청

  • Data

    • 요청할 때 같이 데이터를 담아 요청
    • 상황에 따라 데이터의 용량 제한이 있을 수 있음

  • Load Balancer

    • 트래픽을 분산시켜서 서버에 과부하를 걸리지 않도록 해줌
    • Nginx, Amazon ELB(Elastic Load Balancing) 등을 사용

  • Synchronous 패턴
    하나의 작업이 끝날 때까지 다른 작업을 시작하지 않고 기다리고, 작업이 끝나면 새로운 작업을 시작하는 방식
    FastAPI로 모델을 Web Single 패턴으로 구현하고, 클라이언트는 API 서버로 요청을 한 뒤 이 요청이 끝날 때까지 기다려야 하는 경우가 해당

  • 핵심
    앞에서 설명한 Web Single 패턴을 동기적(Synchronous)으로 서빙
    기본적으로 대부분의 REST API 서버는 동기적으로 서빙

  • 장점

    • 아키텍처의 단순함
    • 예측이 완료될 때까지 프로세스가 다른 작업을 할 필요가 없어서 Workflow가 단순해짐

  • 고민할 점

    • 예측 속도가 병목이 됨
      동시에 1000개의 요청이 올 경우 대기시간이 길어지거나 Drop 혹은 Time out이 올수도
    • 예측 지연이 있는 경우 사용자가 부정적 경험을 할 수 있음

  • Usecase
    예측의 결과에 따라 클라이언트의 로직이 즉각적으로 달라져야 하는 경우

출처: https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Synchronous-pattern/design_en.html

  • Asynchronous 패턴
    하나의 작업을 시작하고 결과를 기다리는 동안 다른 작업을 할 수 있음
    작업이 완료되면 시스템에서 결과를 알려줌
    (음식점 진동벨과 유사)

    Stynchronous 패턴으로 서빙한 결과 API 서버에서 이제 수많은 요청을 감당할 수 없어졌음
    API 서버의 CPU와 memory를 증가하면 해소가 되긴 하겠지만 이건 비싸고 단기간 해결방법임. 나중에 또 요청 더 늘어가면 어떡할래?

    그래서 등장한게 Asynchronous
    API 서버의 부하가 늘지 않게 요청을 하며 다 처리할 수 있어야 하고, 클라이언트의 경우 당장의 결과를 받지 않더라도 최종적으로만 결과를 받으면 됨

  • 핵심
    앞에서 설명한 Web Single 패턴을 비동기적(Asynchronous)으로 서빙

  • 장점
    클라이언트와 예측 프로세스가 분리 => 관계가 의존적이지 않음
    클라이언트가 예측을 기다릴 필요는 없음

  • 고민할 점

    • 메시지 Queue 시스템을 만들어야 함
    • 전체적으로 구조가 복잡해짐
    • 완전한 실시간 예측엔 적절하지 않음(메시지를 가져갈 때 시간이 소요될 수 있음)

  • Usecase

    • 예측과 클라이언트 진행 프로세스의 의존성이 없는 경우
    • 예측 요청을 하고 응답을 바로 받을 필요가 없는 경우
    • 예측을 요청하는 클라이언트와 응답을 반환하는 목적지가 분리된 경우


출처: https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Asynchronous-pattern/design_en.html

  • Queue
    • 클라이언트와 예측 서버 사이에 메시지 시스템(Queue)을 추가
    • 대표적인 메시지 프레임 워크: Apache Kafka
    • 지하철 물품 보관소와 유사한 역할
    • Push:
      메시지 저장
    • Pull:
      메시지를 가지고 와서 작업(예측) 수행

4. Anti Serving

권장되지 안는 패턴

3.1 Online Bigsize 패턴

실시간 대응이 필요한 온라인 서비스에 예측이 오래걸리는 모델을 사용하는 경우

  • 요청에 대한 응답이 막 10초씩 걸린다.. ㅠㅠ

  • 문제

    • 일반적으로 BigSize 모델은 배포할 때 서버 실행과 서빙이 느리다.
    • 속도와 비용 Tradeoff를 조절하여 모델 경량화 하는 작업이 필요하다.

  • 대안

    • 실시간이 아닌 배치로 변경하는 것도 가능한지 검토
    • 중간에 캐시 서버를 추가하고, 전처리를 분리하는 것도 BigSize를 탈피하는 방법

3.2 All-in-one 패턴

하나의 서버에 여러 예측 모델을 띄우는 경우...
predict1, predict2, predict3으로 나눠서 하나의 서버에서 모두 실행하는 경우

  • 문제
    • 라이브러리 선택 제한이 존재함
    • 장애가 발생할 경우(서버가 갑자기 다운) 시스템이 전체적으로 마비됨 (SPOF, Single Point Of Failure)
  • 대안
    • 모델 별로 서버를 분리하여 배포(Microservice 패턴)
profile
SeongGyun Hong
헤매는 만큼 자기 땅이다.
이전 포스트

Generative AI(4): image(stable Diffusion, 평가)

다음 포스트

Product Serving(2): Airflow

0개의 댓글