Computing Service

연산을 수행하는 가상의 컴퓨터로 일반적으로는 서버를 말합니다. CPU, 메모리, GPU 등을 선택합니다. 당연하겠지만, 이들의 성능이 좋아질수록 과금되는 금액이 비쌉니다. 클라우드 서비스를 이용하기 위해서는 인스턴스를 생성 후 인스턴스에 들어가서 사용이 가능합니다. 여기서 인스턴스란 클라우드 서비스에서 제공하는 서버 리소스를 말합니다. [1]

• 예시 : AWS(EC2), Google Cloud (Compute Engine)

Serverless Computing 

컴퓨팅 서비스와 유사하지만, 서버 관리를 클라우드 쪽에서 진행하는 것을 말합니다. 컴퓨팅 서비스는 서버에서 오류가 나면 이용자가 디버깅을 해야하지만, 서버리스는 그럴 필요가 없습니다. 사용하기 위해서는 코드를 클라우드에 제출하면, 그 코드를 가지고 서버를 실행합니다. 요청 부하에 따라 자동으로 확장되는 기능인 Auto Scaling 옵션도 있습니다.

• 예시 : AWS (Lambda), Google Gloud (Cloud Function)

Stateless Computing 

컨테이너 기반으로 서버를 실행하는 구조를 말합니다. 여기서 Stateless란 컨테이너 외부(DB, 클라우드 저장소 등)에 데이터를 저장하고, 컨테이너는 그 데이터로 동작하는 것입니다. 서버리스와 유사하게 요청 부하에 따라 자동으로 확장되는 기능인 Auto Scaling 옵션도 있습니다.

• 예시 : AWS (ECS), Google Gloud (Cloud Run)

Object Storage 

다양한 형태의 데이터를 저장할 수 있는 저장소입니다. 이미지, csv 어떤 형태든 저장이 가능하며, API를 사용해 데이터에 접근합니다.

• 예시 : AWS (S3), Google Gloud (Cloud Storage

Database 

클라우드 서비스에서 제공하는 데이터 저장소입니다. 보통 웹이나 앱 서비스에 연결해서 사용됩니다. 

• 예시 : AWS (RDS), Google Gloud (Cloud SQL)

Data Warehouse 

데이터 웨어하우스는 데이터 저장소라는 점에서 동일하지만, 데이터 분석이라는 목적이 분명합니다. 데이터 분석에 특화된 데이터베이스로 분석을 위해서 DB, Object Storage의 데이터를 이동시킵니다. 

• 예시 : AWS (Redshift), Google Gloud (BigQuery)

AI Platform  

머신러닝, 딥러닝 등 AI에 대한 수요가 늘어나면서 AI 연구 및 개발 과정을 편리하게 해주는 서비스도 많아지고 있습니다. 이를 도울 수 있는 다양한 제품과 MLOps 서비스를 제공하는 것을 AI Platform이라 합니다.

• 예시 : AWS (Lambda), Google Gloud (Cloud Function)

Virtual Private Cloud (VPC)

VPC는 논리적으로 격리된 가상 네트워크입니다. 같은 네트워크이지만 보안상 이유로 분리를 했기 때문에 여러 서버를 하나의 네트워크로 묶는 개념이라고 볼 수 있습니다. VPC에서 추가적인 개념인 서브넷(subnet)은 VPC 안에서 여러 망으로 쪼개는 것으로 외부에서 접근 가능한 public subnet과 접근 불가능한 private subnet 로 구분됩니다. 라우팅 테이블은 네트워크 트래픽이 전달되는 위치를 결정합니다. [2]

참고자료

[1] https://aws.amazon.com/ko/what-is/cloud-instances/

[2] https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/what-is-amazon-vpc.html 

[3] 변성윤. "[Product Serving] 클라우드 서비스". boostcamp AI Tech. 

온라인 서빙

고려사항

온라인 서빙은 실시간으로 클라이언트 요청에 대한 서비스를 제공해야 하는 구조 입니다. 따라서 고객 경험을 좋게 하기 위해서는 지연 시간(Latency)를 최소화할 필요가 있습니다. 이를 위해 고려할만한 사항은 다음과 같은 방법을 고려할 수 있습니다.

• 데이터 전처리 서버 분리 (Feature를 미리 가공 등)
• 모델 경량화
• 병렬 처리
• 예측 결과 캐싱

방법론

온라인 서빙을 구현하기 위해서는 크게 3가지 방법론이 있습니다. 먼저 직접 웹서버를 구축하는 방식입니다. 머신러닝, 딥러닝은 보통 파이썬을 통해 구현되므로 파이썬의 대표적인 웹 프레임워크인 Flask나 FastAPI를 활용하는 것입니다. 자체적으로 서비스를 빠르게 만들 필요가 있을 때 고려해볼만한 방법입니다.

다음으로는 클라우드 서비스를 활용하는 것입니다. AWS의 SageMaker나 GCP의 Vertex AI 등이 대표적인 사례입니다. 이러한 서비스들은 클라우드 회사에서 구축해놓은 기능을 활용하는 것이기 때문에 인력이 부족한 경우 사용을 고려할 수 있습니다만, 이미 만들어놓은 서비스를 활용하는 만큼 많은 비용이 청구될 수 있습니다. 또 이미 만들어진 기능이기 때문에 자유도가 떨어지는 문제도 있습니다.

마지막으로 오픈소스를 활용하는 방식입니다. Tensorflow Serving, Torch Serve, MLFlow, BentoML 등을 활용하는 방식입니다. 모든 방식에 장단점이 존재하므로 잘 비교해서 활용하는 것이 필요합니다.

서버 아키텍처

모놀리스 아키텍처

모놀리스 아키텍처, 영어로는 Monolithic Architecture는 하나의 큰 서버로 모든 로직들이 거대한 코드 베이스 하나로 개발되고 저장됩니다. 클라이언트는 서버(또는 로드 밸런서)에 요청하고 서버 내부에서 처리하는 방식입니다. 이 아키텍처는 배포해야 할 코드 프로젝트는 하나이기 때문에 초기에는 편리하나, 향후에는 복잡도가 증가하기 때문에 규모나 단계에 따라 바뀌어야 할 수도 있는 방식입니다.

마이크로 서비스 아키텍처

Micro Service Architecture는 작은 여러 개의 서버로 개발되고, 모든 로직이 개별 코드에 저장되는 방식입니다. 클라이언트는 하나의 서버에 요청하고 이 요청을 내부 (기능) 서버로 요청한 후에 내부 서버에서 처리하고 요청했던 서버로 반환합니다. 머신러닝, 딥러닝은 이 경우를 채택하는 경우가 많을 수 있습니다.

REST API

Representational State Transfer(REST) API는 통신 규약인 HTTP을 기반으로 하는 웹 기술을 기반으로 하는 인터페이스인 Web API 중 하나입니다. REST API는 자원을 표현하고 상태를 전송하는 것에 중점을 둔 Web API입니다.

REST API의 사용

REST API는 서버에 요청을 보내는 메서드와 대상인 URL로 구성되어 있습니다. 메서드는 서버에 요청을 보내는 방식으로 GET(조회), POST(생성), PUT(전체 업데이트), PATCH(부분 업데이트), DELETE(삭제)가 있습니다.

URL은 인터넷 상 자원을 식별하기 위한 위치를 찾는 방식으로 프로토콜(HTTP와 같이 표기), 호스트(IP나 도메인으로 표기), 포트, URL 파라미터로 이뤄져 있습니다.

여기서 IP는 네트워크에 연결된 특정 PC의 주소 체계(Internet Protocl)을 말하며, 숫자 덩어리의 숫자에 따라 IPv4, IPv6로 구분됩니다. 그리고 IP 주소 뒤에 나오는 숫자인 포트는 PC에 접속할 수 있는 통로를 의미합니다.

URL 파라미터

URL 파라미터는 인터넷 상 자원의 위치를 찾기 위한 URL 내에서 특정 자원을 구분짓기 위한 방법입니다. 크게 쿼리 파라미터와 패스 파라미터가 있으며, 우선 쿼리 파라미터부터 살펴보겠습니다.

쿼리 파라미터는 URL 끝에 추가하면서 특정 리소스의 추가 정보 제공 또는 데이터를 필터링할 때 사용합니다. 이는 선택적 정보를 정렬, 필터링해야 하는 경우에 사용하면 좋습니다. 쿼리 파라미터는 아래와 같이 표현됩니다.

• 예시 : http://host/users?name=yoon

패스(Path) 파라미터는 리소스의 정확한 위치나 특정 리소스를 찾을 때 사용합니다. 패스 파라미터는 필수적인 정보에 대해 식별해야 하는 경우 사용하면 좋습니다. 패스 파라미터는 아래와 같이 표현됩니다.

• 예시 : http://host/users/yoon

HTTP 헤더와 페이로드

헤더는 클라이언트와 서버의 요청과 응답에서 주고받는 문자열의 리스트를 말합니다.[2] 페이로드(Payload)란 전송되는 데이터를 말합니다.[3] 아래 이미지에서 보면 헤더를 확인할 수 있습니다. 방법은 참고 자료를 보시면서 따라하면 됩니다. [4]

앞서 말한 메서드와 URL 외에도 헤더와 페이로드를 사용해서 요청도 가능합니다. 한번 예시를 들어보겠습니다. 각 요소들에 대한 설명은 아래에 첨부하겠습니다.

curl -X POST -H "Content-Type: application/json" -d '{"name":"who"}' http://localhost:8080/users

• curl : 터미널에서 HTTP 요청할 때 사용하는 도구
• -X POST : HTTP 메서드로 POST 사용
• -H "Content-Type: application/json" : 헤더에 Content-Type: application/json 라는 key: value를 추가 
• -d '{"name":"who"}' : 페이로드로 json을 추가 
• http://localhost:8080/users : URL로 어디로 요청을 보낼까를 명시

참고자료

[1] 변성윤. "[Product Serving] 웹 프로그래밍 지식". boostcamp AI Tech.
[2] https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

[3] https://hanamon.kr/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-http-%ED%8E%98%EC%9D%B4%EB%A1%9C%EB%93%9C-payload%EB%9E%80/

[4] https://www.kyumin.blog/6

전체 개요 

정의

일반적인 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

디자인 패턴 사례

Batch

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

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

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

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

Web Single

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

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

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

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

Synchronous

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

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

Asynchronous

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

여기서 눈에 띄는 구성요소는 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