머신러닝 시스템 디자인 패턴 - 04. 추론 시스템 만들기

4.1 시스템을 만들어야하는 이유

로컬 pc에서만 추론할 수 있게 구성하는 것은 서비스 형태로 활용될 수 없음

다른 외부 시스템과 연계해 모델이 호출되는 구조를 갖춰야함

 

 

추론기(시스템) 패턴 종류

- 웹 싱글 패턴 : 하나의 작은 모델을 하나의 추론기로 동기적으로 추론

- 동기 추론 패턴 : 요청에 대해 동기적으로 추론

- 비동기 추론 패턴 : 요청에 대해 비동기적으로 추론

- 배치 추론 패턴 : 배치 작업으로 추론 실행

- 전처리 / 추론 패턴 : 전처리와 추론으로 서버를 분리

- 직렬 마이크로서비스 패턴 : 의존관계에 있는 추론을 차례로 실행

- 병렬 마이크로서비스 패턴 : 하나의 요청을 여러개의 추론기로 추론

- 시간차 추론 패턴 : 동기 추론과 비동기 추론을 조합하여 추론

- 추론 캐시 패턴 : 추론 결과를 캐시해 성능을 개선

- 데이터 캐시 패턴 : 추론 전의 데이터를 캐시해 성능을 개선

- 추론기 템플릿 패턴 : 추론 패턴을 템플릿으로 만들어 개발의 효율 개선을 도모

- 에지 AI 패턴 : 스마트폰이나 자동차 등, 클라이언트 디바이스에서 추론을 실시

 

4.2 웹 싱글 패턴

한 대의 웹 API 서비스에 머신러닝 추론 모델을 포함

API에 데이터와 함께 요청을 보내면 추론 결과를 얻을 수 있는 구조

가장 간단하면서 기초적인 구성

 

목적

비즈니스 관점에서 모델을 신속하게 릴리스 하는 것

 

아키텍처

외부 인터페이스는 대부분의 시스템에서 사용이 가능한 REST API 로 구성한다. 혹은 gRPC 로 구성

추론기는 파이썬의 웹 프레임워크 Flask 나 FastAPI 로 구현

스테이트 리스 구조로 DB나 스토리지 등의 데이터를 영속적으로 보존하는 퍼시스턴트 계층을 준비하지 않고 웹 서버 한 대로 구성

가용성을 위한 다수 웹 서버 운용의 경우 로드 밸런서를 도입해 부하를 분산시킴

모델을 추론기에 포함시키는 방법은 모델-인-이미지 패턴 또는 모델 로드 패턴을 사용

 

구현

https://github.com/wikibook/mlsdp/tree/main/chapter4_serving_patterns/web_single_pattern

GitHub - wikibook/mlsdp: 《머신러닝 시스템 디자인 패턴》 예제 코드

 

장점

추론기를 가볍고 신속하게 가동시킬 수 있음

장애 대응이나 복구도 간단함

 

검토사항

스케일 아웃이나 로그 설계 등의 웹 시스템 구조가 필요

여러 머신러닝 모델이 추가되면서 복잡한 워크플로가 생기면 웹 싱글패턴으로는 해결이 어려움

 

4.3 동기 추론 패턴

요청에 대해 동기적으로 추론

 

유스케이스

시스템의 워크플로에서 추론결과가 나올때까지 다음 단계로 진행되지 않는 경우

워크플로가 추론 결과에 의존할 경우

 

해결하려는 과제

추론 결과에 따라 이어지는 처리를 달리하는 경우 ex) 공장의 생산라인에 제조되는 물건의 이상을 검지하는 시스템

 

아키텍처

클라이언트는 추론 요청을 전송한 후 응답을 얻을 때까지 후속처리를 진행하지 않고 대기

추론 프로세스(전처리 -> 추론 -> 후처리 -> 출력)도 동기적으로 실행

사용자가 기다리는 시간에 제한을 두는 경우에는 추론 프로세스를 고속화하거나 비동기 추론 패턴을 활용해야함

 

구현

Tensorflow Serving으로 구현

- tensorflowdml savemodel이라는 바이너리 형식으로 출력된 파일을 읽어 추론 API를 기동할 수 있음

- APK는 표준으로 gRPC와 REST API 엔드포인트를 제공

 

준비물 : 학습 시 Keras 모델을 생성하고 전처리, 추론, 훠리를 하나의 SavedModel로 만들어야함

https://github.com/wikibook/mlsdp/tree/main/chapter4_serving_patterns/synchronous_pattern

GitHub - wikibook/mlsdp: 《머신러닝 시스템 디자인 패턴》 예제 코드

 

추론기의 구성 방법은 다양함

웹 API를 FastAPI로 자체 구현할 수도 있지만

scikit-learn 라이브러리에서 학습한 모델이라면 모델을 pickle로 출력해 추론기 내부에서 scikit-learn을 사용할 수 있고, ONNX 형식으로 출력해 ONNX Runtime을 가동시킬 수도 있음

Tensorflow 또는 Keras의 경우에는 Tensorflow Serving을 사용할 수 있음

PyTorch를 사용했다면 ONNX Runtime이나 Torch Serve를 선택할 수 있음

 

이점

아키텍처의 단순함으로 관리가 쉬움

예측이 완료될 때까지 프로세스가 진행되지 않아서 서비스 워크플로우가 단순해짐

검토사항

예측 속도가 병목현상이 됨

예측 지연으로 인해 사용자 경험이 악화되지 않도록 해결방법을 고려해야함

 

4.4 비동기 추론 패턴

비동기적으로 수행되는 추론 패턴

추론 결과를 클라이언트에서 사용하지 않음

추론 결과를 응답하지 않음

추론 결과는 요청과는 다른 과정으로 가져옴

 

유스케이스

클라이언트 애플리케이션에서 추론 요청 직후의 처리가 추론 결과에 의존하지 않는 워크플로일 경우

클라이언트와 추론 결과의 출력처를 분리하고 싶은 경우

추론에 시간이 걸려 클라이언트를 기다리게 하고 싶지 않은 경우

 

해결하려는 과제

연산량이 커서 추론에 다소 시간이 걸리는 경우 → 속도가 느린 추론 처리는 결국 시스템 전체의 성능 저하로 이어지기 때문

추론에 시간이 많이 소요되는 무거운 머신러닝 모델이라면 비동기적인 워크플로를 활용해 시스템의 전체 성능을 유지할 것을 권장

 

 

아키텍처

큐(Apache Kafka)나 캐시(Rabbit MQ 또는 Redis Cache)를 배치해 추론 요청과 추론 결과의 취득을 비동기화

 

추론 결과를 큐나 캐시에 저장하는 방식

추론 결과를 다른 시스템에 출력하는 방식

직접 클라이언트에 추론결과를 전달하기 위해서는 커넥션이 필요하게 됨으로 시스템 복잡성이 높아져 권장하지 않음

 

구현

과정

클라이언트로부터의 추론 요청 엔드포인트에는 FastAPI 로 프락시가 중개한다.

프락시는 추론 요청에 대해 작업 ID를 응답하고 백그라운드에서 Redis 에 요청 데이터를 등록한다.

Redis 에 등록된 요청 데이터는 배치로  추론하고, 추론 결과는 다시 Redis 에 등록된다.

클라이언트가 작업 ID를 프락시에 요청하면 추론이 완료되었을 때 그 결과를 얻게 된다.

비동기 추론 패턴은 프락시, Redis, 배치 서버, TensorFlow Serving 등의 여러 리소스를 조합해서 구현한다. 

각 리소스를 개별 컨테이너로 구축하고 도커 컴포즈로 가동시키는 구성을 지향한다.

 

코드

https://github.com/wikibook/mlsdp/tree/main/chapter4_serving_patterns/asynchronous_pattern

GitHub - wikibook/mlsdp: 《머신러닝 시스템 디자인 패턴》 예제 코드

 

이점

클라이언트의 워크플로와 추론의 결합도를 낮출 수 있음

추론의 지연이 긴 경우에서도 클라이언트에 대한 악영향을 피할 수 있음

 

검토사항

요청을 핸들링하는 방식

Queue 방식

요청을 FIFO로 추론

클라이언트와 추론기의 중간에 큐를 이용. 클라이언트가 enqueue, 추론기가 dequeeu함 

장애의 원인에 따라서는 되돌릴 수 없는 사태가 발생하기도 함

 

Cache 방식

추론의 순서에 구애되지 않는 경우

클라이언트와 추론기의 중간에 캐시 서버를 놓음. 클라이언트로부터 요청 데이터를 캐시 서버에 등록함. 추론기는 추론 이전의 캐시 데이터를 가져와 추론하고, 추론 결과를 캐시에 등록함. 추론 전 데이터를 추론이 끝난 상태로 변경함.

서버 장애로 인해 추론이 실패하더라도 재시도 가능

 

시계열 추론 시스템

순서를 보장하지 않기 때문에 시계열 추론 시스템에서는 비동기가 아닌 동기 추론 패턴을 선택해야함

 

 

4.5 배치 추론 패턴

대량의 데이터를 하나로 정리하여 추론하고 싶은 경우

작업으로서 전처리와 추론을 실행하고 추론 결과를 저장함

 

유스케이스

실시간 추론이 필요 없는 경우

과거의 데이터를 정리해 추론하고 싶은 경우

야간, 시간, 월 등 정기적으로 쌓이는 데이터를 추론하고 싶은 경우

 

아키텍처

구현

과정

배치 서버가 데이터베이스에서 정기적으로 배치 대상 데이터를 취득

-> 추론

-> 추론 결과를 데이터베이스에 등록

 

환경

MySQL, SQLALchemy, k8s 사용. k8s에서 cronjabs가 실행됨

 

코드

https://github.com/wikibook/mlsdp/tree/main/chapter4_serving_patterns/batch_pattern

GitHub - wikibook/mlsdp: 《머신러닝 시스템 디자인 패턴》 예제 코드

 

이점

서버 리소스 관리를 유연하게 실시하여 비용 절감이 가능

시간적인 여유를 두고 스케줄링할 수 있다면 서버 장애 등으로 추론에 실패하더라도 재시도 가능

 

검토사항

배치 작업에 걸리는 시간과 추론 결과가 필요한 시점을 잘 계산해서 배치 실행 시간이나 배치 빈도를 조정해야함

 

배치 처리 실패 시 대응 방법을 정해놔야함

- 전체 재시도 : 데이터 간의 상관관계가 추론에 영향을 미치는 경우

- 일부 재시도

- 방치 : 다음 배치 작업에서 정리해 추론 or 실패 데이터는 추론하지 않음. 시간이 지나면 추론이 필요없어지는 경우 방치함

 

배치 기간이 길다면, 모델이나 시스템이 방치되어 발생하는 트러블 슈팅을 위해 정기적으로 소량의 데이터로 배치 추론을 실행하는 것을 권장

 

4.6 전처리 / 추론 패턴

추론기에서 전처리와 추론을 서로 다른 서버에서 실행하는 패턴

각 서버의 유지보수가 용이해짐

 

유스케이스

전처리와 추론에서 필요로 하는 라이브러리나 코드베이스, 미들웨어, 리소스가 크게 다를 경우

전처리와 추론을 컨테이너 레벨로 분리해서 장애의 격리 및 가용성, 유지보수성이 향상될 경우

 

해결하려는 과제

전처리가 포함되지 않은 라이브리를 사용하여 전처리 코드와 모델 파일이 따로 취급되는 경우

ex) 전처리에 scikit-learn이나 opencv를 사용하고, 모델은 tensorflow나 pytorch로 구현

 

데이터 종류에 따른 전처리

- 수치 데이터 : 표준화 및 정규화

- 카테고리 데이터 : one-hot encoding 및 결손치 보완

- 자연어 처리 : 형태소 분석, bag of words, ngram

- 이미지 : 리사이즈, 픽셀의 정규화

 

아키텍처

전처리 서버와 추론기 사이에 로드 밸런서가 필요

 

간단한 전치리 / 추론 패턴

 

앞에 proxy를 두는 구성

프록시를 두면 전처리와 추론을 마이크로서비스화할 수 있음

프록시를 중개시켜 데이터의 취득, 전처리, 추론을 분할할 수 있음

장) 각 서버를 독립적인 라이브러리나 코드베이스, 리소스로 개발할 수 있음

단) 컴포넌트가 늘어나 코드베이스나 버전 관리, 장애 대응이 어려워짐

 

구현

https://github.com/wikibook/mlsdp/tree/main/chapter4_serving_patterns/prep_pred_pattern

GitHub - wikibook/mlsdp: 《머신러닝 시스템 디자인 패턴》 예제 코드

 

 

이점

효율적인 리소스 사용 및 장애 분리

각 리소스의 증감을 유연하게 구현할 수 있음

사용할 라이브러리의 버전을 전처리와 추론기에서 독립적으로 선택할 수 있음

 

검토사항

전처리와 추론기의 버전이 싱크가 맞는지 확인해야함

당연히 전처리와 추론기가 호환이 되는지 직접 돌려봐야함

 

 

4.7 직렬 마이크로서비스 패턴

msa를 도입한 패턴

 

유스케이스

여러 개의 추론기로 구성되는 시스템에서 추론기 사이의 의존성이 명확한 경우

여러 개의 추론기로 구성되는 시스템에서 추론의 실행 순서가 정해져있는 경우

 

해결하려는 과제

하나의 입력 데이터에 대해 여러 개의 추론기를 조합하여 하나의 추론을 완성하는 워크플로

ex) 고양이 사진 분류 -> 위치와 품종을 분류해 삼색 고양이면 일본식으로, 서양품종 고양이라면 서양식으로 스타일을 변환하는 서비스

 

모든 추론 모델을 동일한 추론기에 포함시킨다면 추론기의 사이즈가 방대해지고 효율성이 떨어짐

추론 모델과 추론기를 1:1로 구성하는 것이 개발과 운용 측면에서 매우 유연함

 

아키텍처

직렬 마이크로서비스 패턴에서는 의존관계가 있는 여러 추론 모델을 각각의 추론기로 배치하여 추론을 하나로 이어 붙여서 실행함

추론 모델이 다른 추론 모델에 의존해서 학습된 경우 추론 모델을 한쪽만 갱신하는 것은 불가능. 일괄적으로 추론기를 갱신해야함

요청을 보내는 추론기의 엔드포인트는 프록시에서 환경변수로 설정할 수 있게 하는게 운용의 편의성을 향상시킴

프록시는 운용과 가동을 유연하게 함

 

 

구현

전처리 / 추론 패턴과 거의 동일

 

이점

각 추론 모델을 순서대로 실행하는 것이 가능

앞 추론 모델의 결과에 따라 다음 모델로의 추론 요청을 선택하는 구성도 가능

각 추론에서 서버나 코드베이스를 분할해 효율적인 리소스의 활용과 장애 분리가 가능

 

검토사항

각 추론기의 소요 시간의 합 = 클라이언트에 대한 응답 소요 시간

 

지연 이슈 해결 방안

가벼운 모델을 사용해야함

퍼포먼스 튜닝 필요

리소스 증강

 

모든 모델을 포함한 추론기 vs 직력 마이크로 서비스 패턴

모든 모델을 포함한 추론기

장) 모델 간 데이터 통신 지연 최소화 

단) 개별 모델의 갱신이나 스케일 아웃이 어려움

 

직렬 마이크로 서비스 패턴

장) 추론기 별 스케일 아웃이나 모델의 갱신이 유연함

단) 서버 간 지연의 발생

 

인터페이스 통일

프락시와 추론기의 요청 방법은 공통화해야함

 

 

4.8 병렬 마이크로서비스 패턴

추론기를 병렬로 구성해 각 추론기에 개별적으로 요청을 보냄

 

유스케이스

의존관계가 없는 여러 개의 추론을 병렬로 실행할 경우

여러 개의 추론 결과를 마지막으로 집계하는 워크플로일 경우

하나의 데이터에 대해 여러 개의 추론 결과를 필요로 할 경우

 

해결하려는 과제

하나의 데이터에 대해 분류와 회귀로 서로 다른 추론 결과를 얻어 놓고, 각 결과를 다른 목적으로 사용하고 싶은 경우

 

아키텍처

기본 병렬 마이크로서비스 패턴

프락시를 두어 추론기와 클라이언트를 중개

장) 추론 결과에 따라 프락시에서 응답을 제어할 수 있음

 

데이터 취득 분리 구조

추론을 위한 입력 데이터를 프락시에서 일괄 수집하지 않고, 추론 서버에서 취득

장) 각 모델이 필요한 데이터를 취득해 복잡한 워크플로를 실현할 수 있음 (각 모델에 dependency가 있는 데이터를 프록시에서 처리를 하지 않아도됨)

단) DWH나 스토리지의 액세스 횟수로 오버헤드가 발생될 수 있음

 

비동기 병렬 마이크로 서비스 패턴

 

해당 아키텍처의 장점

추론기의 추가와 삭제를 유연하게 제어 -> 운용이 쉬워짐

- 프록시에서 환경변수로 추론기의 엔드포인트를 관리하면 추가/삭제가 쉬워짐

 

구현

프록시 : fastapi

프록시에서의 추론 요청 : httpx(requests의 후속 버전) + asyncio로 비동기 요청

https://github.com/wikibook/mlsdp/tree/main/chapter4_serving_patterns/horizontal_microservice_pattern

GitHub - wikibook/mlsdp: 《머신러닝 시스템 디자인 패턴》 예제 코드

 

이점

추론 서버를 분할하여 리소스 조정과 장애 분리가 가능함

추론 워크플로 사이에 의존관계를 두지 않으면서도 유연한 시스템 구축이 가능함

 

검토사항

 

동기 / 비동기를 결정해야함

동기 추론 방식일 시

타임아웃을 고려해야함

하나의 추론기라도 느리면 전체 추론기의 지연속도가 증가함

 

타임아웃 전략

1. all or nothing : 응답하거나, timeout으로 응답하지 않거나

2. 각 추론기에 대한 요청에 타임아웃 설정 : 대기 시간 내에 처리된것만 응답. 각 추론 결과에 관계성이 있거나 모든 추론결과가 필요하다면 해당 구조 불가능.

 

비동기 추론 방식일 시

빠른 추론을 선택적으로 취하는 경우, 좋은 결과가 나올 수 없을 수 있음.

빠른 추론이 좋은 추론은 아님.

 

운용의 복잡성

추론기의 갯수가 늘어나면 운용상 실수로 장애가 발생할 리스크가 생김

-> 프록시에 연결된 엔드포인트가 10개 미만으로 컨트롤

프록시에 연결된 추론기가 10개 이상이라면 하나의 프록시를 더 두어야함

 

 

4.9 시간차 추론 패턴

지연에 차이가 있는 추론이라도 시스템 차원에서 새롭게 고안된 유효하게 활용할 수 있는 패턴

유스케이스

인터렉티브한 애플리케이션에 추론기를 삽입할 경우

응답이 빠른 추론기와 느린 추론기를 조합한 워크플로를 만들고 싶은 경우

해결하려는 과제

여러 추론기를 조합할 경우 추론기 간의 지연시간에 차이가 있는 병렬 마이크로서비스 패턴

 

아키텍처

이미지같은 비정형 데이터를 다루면 느려지는 경향이 있음

사용자의 경험은 정확도와 속도의 균형이 중요함

빠른 추론기를 이용해 낮은 품질을 먼저 제공 후, 사용자가 다른 서비스를 이용하는 동안 좋은 품질의 결과를 제공할 수 있음

ex) 이미지 낮은 해상도 먼저 제공 후, 품질이 향상된 이미지를 제공

 

두 종류의 추론기 배치

1. 빠르고 동기적으로 추론 결과를 응답하는 추론기

2. 비동기적이고 처리가 무거운 추론기

 

 

구현

https://github.com/wikibook/mlsdp/tree/main/chapter4_serving_patterns/sync_async_pattern

GitHub - wikibook/mlsdp: 《머신러닝 시스템 디자인 패턴》 예제 코드

 

이점

신속하게 응답하면서 더욱 나은 추론 결과를 제공할 수 있음

 

검토사항

추론의 정확도와 속도의 균형을 잘 맞춰야함

어떤 추론기에서 동기적으로 응답하고, 어떤 추론기로 비동기적으로 처리할지 분담해야함

 

4.10 추론 캐시 패턴

사내 데이터처럼 반복적으로 사용되는 기존 데이터의 경우, 같은 데이터를 같은 추론기로 여러 번 추론하는 경우 이전에 추론했던 결과를 그대로 사용 하는 패턴

 

유스케이스

동일한 데이터에 대한 예측 요청을 받고, 동일한 데이터를 식별할 수 있는 경우

예측 결과가 자주 변경되지 않는 경우

입력 데이터를 검색할 수 있는 경우

추론의 지연을 단축하고 싶은 경우

 

해결하려는 과제

시스템은 기능, 속도, 비용의 밸런스를 갖춰야함

캐시 패턴을 이용해 반복된 작업으로 기능, 속도, 비용이 낭비되는 것을 방지

 

 

아키텍처

캐시 타이밍

1. 사전에 배치 추론을 실행하고 캐시함

2. 추론 시에 캐시함

3. 1과 2의 조합

 

사전에 배치 추론을 실행하고 캐시하는 경우

단) 대상되는 데이터가 요청되지 않으면 캐시가 소용 없음

 

추론시에 캐시하는 경우

단) 중복 데이터가 적으면 캐시 양이 늘어남 -> 비용 상승

 

캐시 삭제

캐시가 늘면 디스크 비용이 상승하기 때문에 정기적으로 삭제해야함

 

삭제 전략

가장 많이 쓰지 않는 캐시 삭제(LRU : Least Recently Used)

최근에 사용되지 않는 캐시(LFU : Least Frequently Used)

 

캐시 검색 타이밍

1. 추론기에 추론을 요청하기 전에

2. 추론기에 추론을 요청함과 동시에

 

추론기에 추론을 요청하기 전에 캐시를 검색하는 경우

장) 캐시 hit 수만큼 추론기의 부하를 줄일 수 있음

단) 캐시 miss 시 캐시를 검색하는데 시간이 걸림 -> 추론 지연 및 성능 저하

 

추론기에 추론을 요청함과 동시에 캐시를 검색하는 경우

캐시 히트 시 추론 요청을 바로 취소하고 응답함 - 요청을 식별할 수 있어야해서 해시값을 key로 사용해야함

캐시 미스 시 추론 결과를 기다렸다가 응답함

 

장) 성능 저하가 없음

단) 모든 요청을 추론기로 송신함 -> 추론기의 자원을 모두 사용해야함

 

구현

 

이점

추론 속도의 개선이 가능

추론기의 비용을 절감할 수 있음

 

검토사항

때에따라 캐시 서버의 비용이 오히려 커질 수 있음

유사한 요청이 많지만 동일한 요청은 적은 경우 적합하지 않음 -> 최근접 이웃(Nearest neighbor) 탐색방법으로 보강할 수 있음

 

 

 

4.11 데이터 캐시 패턴

추론 결과를 캐시하는 것이 아닌, 데이터와 전처리된 데이터를 캐시하고 빠르게 취득하는 패턴

 

유스케이스

동일한 데이터의 추론 요청이 발생하고, 동시에 그 데이터가 동일한 것으로 식별이 가능한 경우

동일한 데이터를 반복적으로 처리할 경우

입력 데이터를 캐시 등으로 검색할 수 있는 경우

데이터를 매우 빠르게 처리하고 싶은 경우

 

해결하려는 과제

1. 데이터 취득 및 다운로드로 지연이 발생하는 것을 방지하기 위해

2. 데이터의 반복적인 전처리 작업으로 병목현상이 발생하는 것을 방지하기 위해

 

 

아키텍처

데이터 캐시 타이밍

1. 사전에 배치로

2. 추론 요청 시에

3. 1과 2를 조합

 

사전에 배치로 데이터를 캐시하는 경우

사전에 데이터를 취득 후, 배치성으로 전처리 작업을 끝내고 데이터를 캐시함

 

캐시 사용)

요청이 오면 저장된 캐시를 검색해서 전처리 완료된 데이터를 사용

 

추론 요청시에 캐시하는 경우

요청한 데이터에 캐시 데이터가 없을 시 캐시함

 

캐시 저장 및 사용)

요청이 들어오면 필요한 데이터를 취득함과 동시에 캐시를 검색함

-> 캐시가 있다면 그 데이터 사용

-> 캐시가 없다면 취득한 데이터를 캐시로 저장함

 

구현

전처리 데이터를 캐시

캐시 타이밍은 배치성 + 추론 요청 마다

https://github.com/wikibook/mlsdp/tree/main/chapter4_serving_patterns/data_cache_pattern

GitHub - wikibook/mlsdp: 《머신러닝 시스템 디자인 패턴》 예제 코드

 

 

이점

데이터 취득이나 전처리, 특징 추출의 오버헤드를 줄일 수 있음

고속으로 추론 개시가 가능함

 

검토사항

캐시 용량 거대함

추론 결과보다 데이터 캐시가 더 큰 용량을 갖음

 

4.12 추론기 템플릿 패턴

베이스가 되는 추론기는 템플릿을 통해 만들고, 추가로 필요한 부분만 변경

 

유스케이스

동일한 입출력의 추론기를 대량으로 개발하고 릴리스하는 경우

추론기 중 모델 이외의 부분을 공통화하는 경우 

 

해결하려는 과제

추론기 안에서 학습이나 모델과 관련이 없는 부분은 개발상의 규칙으로 공통화할 수 있음

 

공통화 가능한 요소

- 인프라

    - OS

    - 네트워크

    - 인증인가

    - 보안

    - 로그 수집

    - 감시 통보

머신러닝과 관련성이 없는 미들웨어나 라이브러리

    - 웹 애플리케이션 서버나 작업 관리 서버

    - REST API 라이브러리 및 Protocol Buffers와 gRPC

    - 로그의 형식

 

공통화가 불가능한 요소

머신러닝 모델을 가동시키기 위한 프로그래밍 언어와 라이브러리

- 프로그래밍 언어의 버전

- 머신러닝 라이브러리의 버전

- 입출력 인터페이스

- 데이터의 전처리 및 후처리의 구현

 

아키텍처

추론기 템플릿 패턴에서는 추론기의 코드나 인프라 구성, 배포 방침 등을 공통화해서 재사용성을 높인 템플릿을 준비

공통화 가능한 부부분은 공통화하고 재이용을 가능하게 함

모델의 고유의 요소들을 JSON 이나 YAML 형식의 파라미터로 설정

전처리와 추론 이외의 파이썬 코드를 공통화 하는 것도 도움됨

인프라 레이어로서 통보나 로그의 수집, 인증 허가 등을 공통화 할 수 있음

머신러닝과 직접적인 관련이 없는 미들웨어와 라이브러리를 템플릿으로 만듦

 

주의할점

템플릿의 버전을 업데이트할 때 가동 중인 서비스도 업데이트가 필요한지 파악해야함

템플릿 갱신 시 하위 호환성을 유지해야함

 

구현

웹 싱글 패턴으로 템플릿 작성

jjinja2 사용

템플릿에 포함되는 항목

- FastAPI로 웹 API 구현

- ONNX Runtime에 의한 추론 클래스

- Dockerfile

- 도커 컴포즈 매니페스트

- 쿠버네티스 매니페스트

 

코드 : https://github.com/wikibook/mlsdp/tree/main/chapter4_serving_patterns/template_pattern

GitHub - wikibook/mlsdp: 《머신러닝 시스템 디자인 패턴》 예제 코드

 

이점

개발 효율을 향상시킬 수 있음

동일한 운용 방침으로 관리가 가능함

릴리스나 통합 테스트의 공통화가 가능함

 

검토사항

하위호환성과 업데이트 방침을 미리 정해둬야함

넓은 범위를 지원하려고 하면 보안에 취약해지거나 버전마다 조건 분기 등으로 소프트웨어가 복잡해질 가능성이 있음

 

 

4.13 에지 AI 패턴

스마트폰 단말 내부나 자동차 내부에서 추론하면 실시간성을 확보할 수 있는데 이러한 기술을 에지 AI 라고 한다. 

유스케이스

디바이스(스마트폰이나 전자기기, 자동차 등)에서 직접 추론하고 싶은 경우

실시간으로 추론하고 싶은 경우

보안 문제상 추론에 사용한 데이터를 서버 사이드로 송신하고 싶지 않은 경우

디바이스의 컴퓨팅 리소스, 데이터, 전력량으로 전처리를 포함한 추론이 가능한 경우

해결하려는 과제

디바이스에서 실시간 처리가 필요한 유스케이스

지연시간을 최소화하고 사용자 경험을 훼손하지 는 요건

정보 보안의 중요성이 증대되어 PII 를 서버 사이드로 송신하지 않고 디바이스 안에 가둔 채 추론하여 사용자의 정보를 보호 하고자 하는 경우

디바이스 사이드 특화 모델 MobileNet 모델의 개발이나 Neural architecture search, AutoML 을 사용해 추론 정확도와 연산 비용을 최적화한 모델의 탐색이 연구되고 있음

 

 

구현

https://github.com/wikibook/mlsdp/tree/main/chapter4_serving_patterns/edge_ai_pattern

스마트폰으로 데이터의 입력부터 전처리, 추론, 후처리까지를 일련의 연산으로 변환해주는 mediapipe 라는 라이브러리가 있음

이점

디바이스 내에서 추론이 가능해져 실시간에 가까운 속도로 추론 결과를 응답할 수 있음

데이터를 외부로 노출시킬 필요가 없으므로 정보 보안과 관련된 위험을 경감할 수 있음

검토사항

모델의 갱신, 수정이 어려움.

애플리케이션의 용량이 커짐

디바이스에 맞는 모델 개발 자체가 어려움

 

 

4.14 안티 패턴 : 온라인 빅사이즈 패턴

복잡하고 파라미터 수가 많은 알고리즘을 사용하여 높은 정확도의 모델을 얻었지만

연산량이 많아 느리고, 웹 시스템에서 사용자가 장시간 기다리게 되어 비즈니스 가치를 창출하지 못하는 패턴

 

상황

실시간 처리 시스템에서 지연이 큰 추론 모델을 이용하는 경우

서비스의 요구 지연 시간과 실제 지연 시간이 다른 경우

완료 시간이 정해진 배치에서 '추론 횟수 * 회당 추론 시간'이 완료시간을 초과하는 경우

 

이점

연산량이 많고 복잡한 모델일수록 머신러닝의 평가치가 개선되는 경향이 있음

복잡한 모델을 만드는 것이 즐거움

 

과제

속도와 비용의 희생을 최소화해야함

간단하고 합리적인 모델을 만드는 것도 흥미로워야함

 

회피 방법

시스템적 요구 처리시간이나 스피드를 사전에 정의

비용에 여유가 있다면 스케일 아웃이나 스케일 업, 추론용 GPU 사용을 검토

시간차 추론 패턴으로 경량화된 추론기와 무거운 추론기의 균형을 맞춤

추론 캐시 패턴이나 데이터 캐시 패턴으로 고속화

 

 

4.15 안티 패턴 : 올-인-원 패턴

마이크로 서비스 패턴이나 시간차 추론 패턴을 고려하지 않고, 여러 추론기를 한 서버에서 동작하는 경우

 

상황

여러 추론 모델을 가동시키는 시스템에서 모든 모델이 동일한 서버에서 가동중인 경우

 

구체적인 문제

서버 비용은 저렴할 수 있으나 모델 개발, 장애 분리, 모델 갱신이 어려워 운용 비용이 증가

모델 개발의 단점으로 환경 선택의 자유도가 제한됨

모든 로그를 다 탐색해야함

시스템의 갱신 빈도가 잦아서 작업의 비용이 늘어남

 

 

이점

추론기의 서버 비용을 아낄 수 있음

과제

개발과 운용의 비용이 증가함

회피 방법

각 추론 모델을 마이크로서비스로 구현하고 낮은 결합도로 운용함

병렬 마이크로서비스패턴을 활용함