ML DP

• 머신러닝 특수 DP : Data, Model, Code 고려
• Serving 패턴 : 모델을 production 환경에 서빙하는 패턴
• Training 패턴 : 모델을 학습하는 패턴
• QA 패턴 : 모델의 성능을 평가하기위한 패턴
• Operation 패턴 : 모델을 운영하기 위한 패턴

Serving 패턴

• Web single 패턴 : 빠르게 출시하고 싶은 경우
  • FastAPI, Flask등으로 단일 REST 인터페이스 생성
  • 전처리 포함, 간단하게 생성 가능
  • 단순한 아키텍쳐 / 유지 보수 불편함
• Synchronous 패턴 : 예측의 결과에 따라 로직이 달라지는 경우
  • 예측이 끝날 때까지 프로세스 block(동기적)
  • REST API는 대부분 Synchronous 패턴
  • 단순한 아키텍쳐, workflow / bottle neck, UX 악화
• Asynchronous 패턴 : 예측에 의존성이 없는 경우(비동기적)
  • 클라이언트와 서버사이에 메세지(Queue) 추가
  • 특정 메세지의 Request 데이터를 Queue에 저장
  • 특정 서버는 Queue의 데이터를 가져와서 예측
  • 클라이언트가 예측을 기라릴 필요가 없음 / 실시간 예측에 적절하지 않음
• Batch 패턴 : 예측 결과를 실시간으로 얻을 필요가 없을 경우
  • 데량의 데이터를 스케쥴링하여 예측
  • Input, Output은 warehouse에 저장
  • 서버 리소스 유연하게 관리 / 스케쥴링 서버 필요
• Preporcess - Prediction 패턴 : 전처리와 예측을 분리하는 경우
  • 전처리 서버, 예측 서버 분리
  • 효율적 리소스 사용, Fault Isolation / 서버 2개 운영, 네트워크 연결 병목 발생 가능
• Microservice Vertical 패턴 : 여러 모델이 순차적으로 연결되는 경우
  • 예측한 결괏값이 Input으로 다시 들어가는 경우
  • 각각의 모델을 별도의 서버로 배포
  • 이전 예측의 결과를 여러 개로 분기할 수 있음 / 동기적 실행, 병목, 복잡한 구조
• Microservice Horizontal 패턴 : 하나의 Request에 병렬로 실행
  • 마지막에 예측 결과 통합
  • 리소스를 독립적으로 사용, 다른 모델에 의존성 없음 / 복잡한 구조
• Prediction Cache 패턴 : Request할 때 데이터, 예측 결과 저장
  • 입력 데이터를 캐시로 활용할 수 있는 경우
  • 예측 속도 개선, 오래된 caching 제거
  • 반복되는 요청이 있는 경우 성능 개선 / 캐시 서버 운영 필요
• Serving Anti 패턴 - Online Bigsize 패턴
  • 실시간 온라인 서비스에 예측이 오래 걸리는 모델 사용
  • 모델 경량화 필요
  • 배치로 변경한지, 캐시 서버 추가, 전처리 분리 등 검토
• Serving Anti 패턴 - All-in-one 패턴
  • 하나의 서버에 여러 예측 모델
  • 라이브러리 선택 제한, 장애 대응 어려움

Training 패턴

• Batch Training 패턴 : 주기적으로 학습해야 하는 경우
  • 스케줄링 서버 필요
  • 모델을 저장하는 작업 필요
  • 정기적인 재학습 , 업데이트 / 데이터 수집, 전처리, 학습, 평가에서 오류 고려
• Pipeline Training 패턴 : 각 작업을 별도로 컨트롤하고 싶은 경우
  • 각 작업을 개별 리소스로 분
  • 이전 작업의 결과가 Input으로 들어감
  • 처리완료된 데이터를 중간에 저장
  • 장애 분리, 컨테이너 재사용 / 다중 구조로 관리 어려움
• Training Anti 패턴 - Training code in Serving 패턴 : 학습, 실험, 평가 코드가 서빙에 사용
• Training Anti 패턴 - Too many pipes 패턴 : 파이프라인이 너무 복잡한 경우

QA 패턴

• 예측 서버와 모델의 성능 평가를 위한 패턴
• 추천 시스템에서 자주 사용
• Shadow AB Test 패턴 : 새로운 모델이 잘 동작하는지 확인하는 경우
  • 배포하기 전에 test
  • Request가 기존 모델과 새로운 모델에게 모두 전달
  • Production에 영향을 주지 않고 성능 확인 / 예측 서버에 대한 비용 발생
• Online AB Test 패턴 : 온라인으로 여러 예측 모델을 측정하는 경우
  • Request가 지정된 비율로 트래픽을 나눠서 기존 모델, 신규 모델에 예측
  • 새로운 모델의 예측 결과, 속도 확인 / 신규 모델이 바로 노출되어 부정적 영향 발생 가능
• QA Anti 패턴 - Offline Only 패턴 : Offline Test Data로만 진행되는 경우
  • 모델의 비즈니스 가치 입증하기 어려움

Operation 패턴

• 설정, 로깅, 모니터링 들을 위한 패턴

• Model in Image 패턴 : 서비스 환경과 모델을 통합하여 관리

  • Docker Image 안에 모델이 저장되어 있는 경우
  • Production 환경 = Dev 환경 / 모델을 수정하면 Docker Image Build 수행해야함

• Model Load : Docker 이미지와 모델 파일 분리

  • 모델 업데이트가 빈번한 경우
  • 서버 이미지 경량화
  • 서버 이미지 재사용, 이미지 경량화 / 서비스 시작 시간, 서버 이미지와 모델 관리 필요

• Prediction Log 패턴 : 예측, 지연시간 로그 사용

  • 프로세스에서 로그 저장 x, 메세지 시스템으로 pass
  • 장애 파악을 위해 로깅, 모니터링
  • 예측 결과, 모델의 Latency 분석 가능 / 로그 저장 비용 발생

• Condition Based Serving 패턴 : 상황에 따라 예측하는 대상이 다양한 경우

  • 사용자의 상태, 시간, 장소에 따라 예측 대상이 바뀌는 경우
  • 상황에 따라 알맞은 모델 제공 / 모델 수에 따라 비용 증가

• Operation Anti 패턴 - No Logging 패턴 : 별도의 로그를 남기지 않는 경우