디자인 패턴
디자인 패턴이란?
-
문제를 해결하는 방법을 패턴화해서 표현
-
반복적으로 발생하는 문제를 어떻게 해결할 지에 대한 솔루션
-
개발할 때 구조화된 패턴을 뜻
머신러닝 디자인 패턴
-
머신러닝 개발 특수성
- Data, Model, Code
-
기존 소프트웨어 개발은 Code로만 이루어져 있음
-
크게 4가지 패턴
-
Serving 패턴
- 모델을 production 환경에 serving하는 패턴
-
Training 패턴
- 모델을 학습하는 패턴
-
QA 패턴
- 모델 성능을 Production 환경에서 평가하기 위한 패턴
-
Operation 패턴
- 모델을 운영하기 위한 패턴
-
Serving 패턴
Serving 패턴이란?
-
머신러닝 모델을 production 환경에서 어떻게 사용할 것인가?
-
앞서 배운 Online Serving, Batch Serving도 Serving 패턴 중 하나
Web Single 패턴
-
Usecase
- 예측 서버를 빠르게 출시하고 싶은 경우 사용
-
Architecture
-
FastAPI, Flask 등으로 단일 REST 인터페이스 생성
- 클라이언트가 요청을 보내면, REST Server가 Response를 반환하는 단순 구조
-
요청 시 전처리도 같이 포함
-
간단하게 생성할 수 있는 구조
-
-
단점
- 구성 요소 하나가 바뀌면 전체가 업데이트 되어야 함
Synchronous 패턴
-
Usecase
-
예측 결과에 따라 로직이 달라지는 경우 사용
- e.g., 예측 결과가 강아지면 강아지 화면, 고양이면 고양이 화면
-
-
Architecture
-
예측이 끝날 때까지 프로세스를 block
-
REST API는 대부분 Synchronous 패턴
-
-
장점
- 예측이 완료될 때까지 프로세스가 다른 작업을 할 필요가 없어 workflow가 단순함
-
단점
- 예측 속도가 병목이 됨
- 예측 지연으로 사용자 경험이 악화될 수 있음
- 예측 속도가 병목이 됨
Asynchronous 패턴
-
Usecase
-
예측과 진행 프로세스의 의존성이 없는 경우 사용
-
예측 요청을 하고 응답을 바로 받을 필요가 없는 경우
-
예측을 요청하는 클라이언트와 응답을 반환하는 목적지가 분리된 경우
-
-
Architecture
-
클라이언트와 예측 서버 사이에 메세지 시스템(Queue) 추가
-
특정 메세지에 Request 데이터를 메세지 Queue에 저장 (Push)
-
특정 서버는 메세지 Queue의 데이터를 가져와 예측 (Pull)
-
-
단점
- 실시간 예측엔 적절하지 않음
Batch 패턴
-
Usecase
-
예측 결과를 실시간으로 얻을 필요가 없는 경우
-
대량 데이터에 대한 예측을 하는 경우
-
예측 실행이 시간대별, 월별, 일별로 스케줄링해도 괜찮은 경우
-
-
Architecture
-
Airflow 등으로 batch 작업을 스케줄링에 맞게 trigger
-
Input, output 데이터는 데이터 웨어하우스 등에 저장
-
-
API 서버를 개발하지 않아도 되는 단순함
-
스케줄링을 위한 서버 필요
Preprocess - Prediction 패턴
-
Usecase
-
전처리와 예측을 분리하고 싶은 경우
-
전처리와 예측에서 사용하는 언어가 다른 경우
-
리소스를 분리해 효율성을 향상
-
-
Architecture
-
전처리 서버와 예측 서버를 분리
-
Request 할 경우 맨 처음에 전처리 서버로 가서 전처리하고, 그 후 예측 서버로 request
-
-
장점
- Fault Isolation: 장애를 격리할 수 있음
Microservice Vertical 패턴
-
Usecase
-
여러 모델이 순차적으로 연결되는 경우
-
A 모델 결과를 B 모델 Input으로 사용하는 경우
-
예측끼리 의존 관계가 있는 경우
-
-
Architecture
-
각각 모델을 별도 서버로 배포
-
동기적으로 순서대로 예측하고, 예측 결과를 다른 모델에 또 request
-
-
단점
- 동기식으로 실행되기 때문에 대기 시간이 더 필요함
Microservice Horizontal 패턴
-
Usecase
-
하나의 Request에 여러 모델을 병렬로 실행하고 싶은 경우
-
보통 마지막에 예측 결과 통합
-
e.g., 마스크 분류 모델에서 연령대 예측 모델 + 마스크 분류 모델 + 성별 예측 모델로 나눠 구성
-
-
Architecture
- Vertical 패턴과 유사하게 각각 모델을 별도 서버에 배포
Prediction Cache 패턴
-
Usecase
-
Request 할 때 데이터를 저장하고, 예측 결과도 별도로 저장해야 하는 경우
-
예측 결과가 자주 변경되지 않는 경우
-
입력 데이터를 캐시로 활용할 수 있는 경우
-
-
Architecture
-
Request가 올 경우 해당 데이터로 예측한 결과가 있는지 캐시에서 검색 (Redis 활용)
-
만약 예측 결과가 있다면 해당 데이터 바로 return, 없다면 모델에서 예측
-
오래된 예측이 있다면 주기적으로 삭제하는 로직이 필요
-
-
장점
- 반복되는 요청이 있는 경우 성능 개선 가능
Serving Anti 패턴
※ Anti 패턴: 좋지 않은 패턴
1) Online Bigsize 패턴
-
실시간 대응이 필요한 온라인 서비스에 예측이 오래 걸리는 모델 사용하는 경우
-
모델 경량화 작업이 필요
-
실시간이 아닌 배치로 변경하는 것도 가능한지 검토
-
중간에 캐시 서버를 추가하고, 전처리 분리하는 것도 bigsize 탈피하는 방법
2) All-in-one 패턴
-
하나의 서버에 여러 예측 모델을 띄우는 경우
-
라이브러리 선택 제한 존재
- e.g., 어떤 모델은 pandas 1.0, 다른건 0.7
-
장애가 발생할 경우 로그 확인이 어려움
Training 패턴
Training 패턴이란?
-
학습 파이프라인 구성을 위한 패턴
-
자주 학습하는가?, 학습 component 다양한 단계를 재사용하는가?를 고려
Batch Training 패턴
-
Usecase
- 주기적으로 학습해야 하는 경우
-
Architecture
-
Batch Serving 패턴처럼 스케줄링 서버 필요
-
학습 과정에서 데이터 전처리, 평가 과정 모두 필요
-
저장한 모델 파일을 사용할 수 있도록 저장하는 작업 필요
-
-
단점
- 데이터 수집, 전처리, 학습, 평가 과정에서 오류가 발생할 상황을 고려해야 함
Pipeline Training 패턴
-
Usecase
-
학습 파이프라인 단계를 분리해 각각 선택하고 재사용할 수 있도록 만드는 경우
-
각 작업을 별도로 컨트롤하고 싶은 경우
-
-
Architecture
-
Batch Training 응용 버전
-
각 작업을 개별 리소스로 분할 (서버, 컨테이너 등) → 전처리 서버는 메모리 크게, 서빙 서버는 GPU 사용 등
-
시간이 많이 걸리는 작업은 자주 실행, 다른 작업은 적게 실행
-
이전 작업 실행 결과가 후속 작업의 input
-
처리 완료된 데이터를 데이터 웨어하우스에 중간 저장
-
-
장점
-
장애 분리
-
컨테이너 재사용 가능
-
workflow 기반 작업
-
-
단점
- 다중 구조로 여러 작업 관리해야 함
Training Anti 패턴
1) Training code in Serving 패턴
-
학습, 실험, 평가에 사용해야 하는 코드가 Serving 코드에 들어간 경우
-
학습, 실험, 평가를 위한 환경과 Serving을 같이 처리하는 경우
-
Research 단계와 production 단계에서 필요한 코드와 로직은 다름
- 리소스도 마찬가지로 분리해야 함
2) Too many pipes 패턴
-
학습 파이프라인이 너무 다양하고 복잡한 경우
-
데이터 소스가 너무 많아서 각각 가져오는 방법이 다양하고, 추상화되어 있지 않은 경우
QA 패턴
QA 패턴이란?
-
예측 서버와 모델 성능 평가를 위한 패턴
-
모델이 처음 된다면 배포 끝이지만, 기존 모델이 있고 신규 모델이 있다면 모델 비교해야 함
-
Production 환경에 영향이 없도록 테스트하는 패턴과 바로 영향이 가는 패턴이 존재
Shadow AB Test 패턴
-
Usecase
-
새로운 예측 모델이 Production 환경에서 잘 동작하는지 확인하고 싶은 경우
-
새로운 예측 서버가 Production 환경의 부하를 견디는지 확인하고 싶은 경우
-
-
Architecture
-
예측 모델, 서버를 Production 환경에 배포하기 전에 사용
-
Request가 들어온 경우 기존 모델과 새로운 모델에게 모두 전달되고,
Response는 기존 모델 서버에만 전달됨 (새로운 모델 결과는 별도 저장만 함) -
모델이 잘 예측하는지 동시에 2개의 모델을 실행해서 파악할 수 있음
-
새로운 모델이 문제가 생기면 AB Test에서 제거하고 다시 개선
-
Risk가 적음 (현재 모델은 그대로 운영하기 때문)
-
-
장점
- Production 환경에 영향을 주지 않고 새로운 모델 성능 확인 가능
-
단점
- 새로운 예측 서버에 대한 비용
Online AB Test 패턴
-
Usecase
-
새로운 모델이 Production 환경에 잘 동작하는지 확인하고 싶은 경우
-
새로운 예측 서버가 Production 환경의 부하를 견디는지 확인하고 싶은 경우
-
온라인으로 여러 예측 모델을 측정하고 싶은 경우
-
-
Architecture
-
Shadow AB Test 패턴과 큰 방식은 동일
-
Request가 들어오면 지정된 비율 (e.g., 1:1)로 트래픽을 나눠 절반은 기존 모델, 절반은 신규 모델에 예측
-
보통은 새로운 모델에 10% 정도 들어가게 조정
-
-
장점
-
Production 환경에서 새로운 모델 예측 결과, 속도 확인 가능
-
여러 모델 예측 결과를 수집해 분석 가능
-
-
단점
-
새로운 모델이 바로 비즈니스에 노출되므로 부정적 비즈니스 영향 발생 가능
-
새로운 예측 서버에 대한 비용 발생
-
QA Anti 패턴
1) Offline Only 패턴
-
머신러닝 모델이 Online Test 하지 않고, Offline Test data로만 진행되는 경우
-
머신러닝 모델의 비즈니스 가치를 입증하기 어려움
-
Production 환경에도 꼭 사용하는 시기가 필요
- e.g., Offline evaluation: 99% accuracy, Online evaluation: 50% accuracy
Operation 패턴
Operation 패턴이란?
-
머신러닝 시스템의 설정, 로깅, 모니터링 등 운영을 위한 패턴
-
모델 이미지를 함께 Docker Image로 만들 것인지, 로그를 어떻게 저장할 지, 저장된 로그로 모니터링 할 것인지 등을 고려
Model in Image 패턴
-
Usecase
-
서비스 환경과 모델을 통합해서 관리하고 싶은 경우
-
Docker Image 안에 모델이 저장되어 있는 경우
-
-
Architecture
-
Docker Image로 모델 코드와 모델 파일 등을 저장해서 사용
-
Production 환경에선 이 이미지를 Pull해서 사용
-
-
장점
- Production 환경과 Dev 환경을 동일하게 운영 가능
-
단점
- 모델 수정이 빈번하면, Docker Image Build를 계속 수정
Model Load 패턴
-
Usecase
-
Docker 이미지와 모델 파일을 분리하고 싶은 경우
-
서버 이미지는 공통으로 사용하되, 모델은 여러개 사용하는 경우
-
-
Architecture
-
개발 코드는 Docker Image로 Build
-
모델 파일은 Object Storage 등에 업로드하고 프로세스 시작할 때 모델 파일 다운
-
분리를 통해 서버 이미지 경량화할 수 있는 패턴
-
-
장점
-
모델과 서버 이미지 구분
-
서버 이미지 재사용 가능, 서버 이미지 경량화
-
-
단점
-
모델 파일을 가지고 와야하기 때문에 서비스 시작이 더 오래걸릴 수 있음
-
서버 이미지, 모델 관리를 해야 함
-
Prediction Log 패턴
-
Usecase
-
서비스 개선을 위해 예측, 지연 시간 (latency) 로그를 사용하려고 할 경우
-
Data validation, 예측 결과 등을 확인하고 싶은 경우
-
-
Architecture
-
프로세스에서 로그를 저장하지 않고, 메세지 시스템으로 넘겨서 프로세스가 저장에 신경쓰는 시간을 줄임
-
장애 등을 파악할 수 있도록 로그도 기록하고 모니터링도 할 수 있도록 대비해야 함
-
-
단점
- 로그가 많아지면 저장 비용 발생
Condition Based Serving 패턴
-
Usecase
-
상황에 따라(특정 조건) 예측해야 하는 대상이 다양한 경우
-
룰 베이스 방식으로 상황에 따라 모델 선택하는 경우
-
-
Architecture
- 사용자의 상태, 시간, 장소에 따라 예측 대상이 바뀔 수 있음
-
장점
- 상황에 따라 알맞은 모델 제공
-
단점
- 모델 수에 따라 운영 비용 증가
Operation Anti 패턴
1) No Logging 패턴
- 별도 로그를 남기지 않는 경우
※ 모든 이미지 및 코드 출처는 네이버 커넥트재단 부스트캠프 AI Tech 5기입니다. ※
