머신러닝 / 딥러닝의 Product Serving과 디자인 패턴

전체 개요 

정의

일반적인 IT 제품들은 요청(Request)에 대해 결과(예를 들어, 웹이나 앱의 화면)를 클라이언트에 제공하는 방식으로 이뤄집니다. 이는 음식점에서 종업원이 손님에게 음식을 서빙하는 것처럼 IT Product Serving이라 얘기할 수 있습니다. 그리고 Product라고 하는 것은 개발자가 만든 어떠한 산출물일 것이고요. 

 

이를 머신러닝과 딥러닝 분야로 적용시키면 다음과 같습니다. 머신러닝/딥러닝 분야에서 Product Serving이란 모델의 예측 결과를 클라이언트에 제공하는 방식일 것입니다. 이 분야에서 Product는 연구 및 개발(R&D)단계에서 만든 모델을 일반적으로 사용할 수 있도록 배포하는 것입니다. 

 

디자인 패턴

소프트웨어 개발에 있어서 디자인 패턴이란 소프트웨어가 어떻게 구성되고 작동할지에 대한 설계하는 공통적인 방식을 일컫습니다. 소프트웨어 개발은 기본적으로 귀찮은 것을 싫어하는 사람들이 많기에 코드의 재사용성, 가독성, 확장성을 높일 수 있도록 디자인 패턴들이 다양하게 고안됐습니다.

 

머신러닝/딥러닝 분야에서도 디자인 패턴이 있는데, 기존 소프트웨어 개발과 달리 데이터, 모델, 코드를 모두 고려해야 하는 특수성이 있습니다. 아래는 고려해야 하는 세부적 요소를 나열한 것 입니다.

• 대용량 모델 로드
• 모델 관리
• 데이터 전처리
• 이상치 제외
• 모델 연산 시간

종류

머신러닝 / 딥러닝에서 Product Serving에는 크게 배치(Batch Serving)와 온라인(Online Serving) 두가지로 나눌 수 있습니다. 우선 배치는 데이터를 일정 묶음(배치)으로 나눠서 처리하는 방식이 있습니다. 예를 들어, 매월 말에 처리하는 방식이 있을 수 있습니다. 이는 실시간 응답이 중요하지 않고 대용량 데이터를 처리해야 할 필요가 있을 때 활용할 수 있습니다.

 

다음으로 온라인 방식은 실시간으로 클라이언트가 요청할 때 서빙하는 방식입니다. 예를 들어, 번역처럼 실시간 응답이 중요하거나 개별 맞춤,데이터가 실시간으로 변한다면 이 방식을 채택하는 것이 적절할 것입니다. 

 

그렇다면 위 두가지 방식에 대한 디자인 패턴 사례를 살펴보도록 하겠습니다. 소개할 방식은 배치 방식의 배치 패턴과 온라인 방식의 Web Single, Synchronous, Asynchronous 패턴입니다. 이외에도 다양한 패턴을 아래 링크에서 확인할 수 있습니다.

ml-system-design-pattern | System design patterns for machine learning

ml-system-design-pattern

디자인 패턴 사례

Batch

배치 패턴은 주기적으로 예측 결과를 데이터베이스에 저장하고 활용하는 쪽은 데이터베이스에서 결과를 읽어서 사용하는 방식을 채택합니다. 패턴의 다이어그램은 다음과 같이 나타낼 수 있습니다.

 

배치 패턴 [2]

 

위 다이어그램에서 나타나는 것 중 주요 구성 요소는 다음과 같으며, 이에 대한 역할은 다음과 같습니다.

• Job Management Server : 작업을 실행하는 서버, Apache Airflow 등을 주로 사용, 특정 시간에 Batch job을 실행
• Job : 어떤 작업 실행에 필요한 모든 활동(모델 로드, 데이터 로드 등)으로 Python 스크립트로 실행하거나 Docker Image로 실행
• Data : 서비스에서 사용하는 DB나 데이터 웨어하우스에 저장. 데이터를 불러오는 스케줄링 job이 존재.

배치 패턴은 기존 코드를 재사용 가능하고, API 서버를 개발하지 않아도 되기 때문에 빠르게 제품을 출시하거나 테스트할 경우 유용합니다. 그리고 남는 서버 리소스를 추가 투입할 수도 있기 때문에 유연하게 서버 관리가 가능하다는 장점도 있습니다. 하지만, 별도의 스케줄러를 고려해야 한다는 단점도 있습니다. 

Web Single

Web Single 방식은 API 서버 코드에 모델을 포함시켜 배포하는 방식입니다. 이후에 예측이 필요한 곳(클라이언트, 서버 등)에서 필요할 때 직접 요청하는 방식으로 모델의 결과를 반환합니다. 패턴의 다이어그램은 다음과 같이 나타낼 수 있습니다.

 

Web Single 패턴 [3]

 

위 다이어그램에서 나타나는 것 중 주요 구성 요소는 다음과 같으며, 이에 대한 역할은 다음과 같습니다.

• REST Server : API 서버가 실행될 때 모델을 로드하고 전처리도 같이 포함. FastAPI, Flask 등 단일 REST API 서버 개발 후 배포
• Client : 앱에서 직접 요청하거나 서비스 서버에 요청해서 실행 가능.
• Data : 요청할 때 같이 데이터를 담아 요청. 상황에 따라 데이터 용량 제한 가능.
• Load Balancer : 트래픽을 분산시켜 과부하 방지 (Ngnix, Amazon ELB 등 사용)

Web Single 패턴은 하나의 프로그래밍 언어로 아키텍처를 단순하게 작성할 수 있습니다. 그렇기 때문에 빠른 출시와 실시간 결과를 얻을 때 활용할 수 있씁니다. 하지만, 구성 요소 중 하나만 바뀌어도 전체 업데이트가 필요하기 때문에 정식 제품으로 활용하기에는 유지-보수 관점에서 적절하지는 않습니다. 또한, 모델을 직접 로드하기 때문에 큰 모델의 경우 시간이 소요되고 서버 부하 가능성도 있어 모니터링이 필요합니다.  

Synchronous

동기(Synchronous) 방식은 Web Single과 거의 유사하며, 예측이 완료될 때까지 워크플로우를 중단합니다. 패턴의 다이어그램은 다음과 같이 나타낼 수 있습니다.

 

Synchronous 패턴 [4]

 

이 패턴은 Web Single과 거의 유사해서 아키텍처와 처리하는 입장에서 워크플로우가 단순합니다. 하지만, 예측 결과가 나오는 시간에 따라 워크플로우가 중단되기 때문에 병목현상이 발생할 수 있어서 많은 사람이 이용하는 서비스에는 사용이 적합하지 않습니다. 그래도 비교적 간단하게 예측 결과에 따라 클라이언트 로직이 달라져야 할 경우 사용하면 좋은 방식입니다. 

Asynchronous

이 패턴은 Synchronous가 하나의 작업이 시작하고 결과를 기다리는 동안의 문제를 해결하기 위해 등장한 것으로 그동안 다른 작업을 수행하는 패턴입니다. 패턴의 다이어그램은 다음과 같이 나타낼 수 있습니다.

Asynchronous 패턴 [5]

 

여기서 눈에 띄는 구성요소는 Queue로 클라이언트와 예측 서버 사이의 메시지 역할을 수행합니다. 이로써 클라이언트와 예측 프로세스를 분리하여 의존성을 해소하는 효과가 있지만, Queue라는 새로운 구성요소를 만들어야 하고 중간에 한번 거치는 것 때문에 완전한 실시간 예측이 불가능하다는 단점이 있습니다.

참고자료

[1] 변성윤. "[Product Serving] Serving의 정의와 다양한 패턴". boostcamp AI Tech.

[2] https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Batch-pattern/design_en.html

[3] https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Web-single-pattern/design_en.html

[4] https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Synchronous-pattern/design_en.html

[5] https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Asynchronous-pattern/design_en.html