1 of 39

So1s

“ML 모델 서빙의 어려운 점을 해결하여 AI 개발자들이 모델 개발에만 집중할 수 있도록 한다.”

팀장 : 이지호

팀원 : 임성빈, 신일섭

2 of 39

프로젝트 소개

01

  1. MLOps 란?
  2. MLOps의 적용사례
  3. So1s의 프로젝트

02

개발 결과

  1. 아키텍처
  2. 기본 기능
  3. 부하 테스트와 SLI, SLO

04

To Be

1. 프로덕트 시장성 검증

2. 향후 로드맵

CONTENTS

03

  • 오토 스케일링 & GPU 스케줄링
  • Wildcard Ingress 구성
  • ABN 테스트 구현

개발 세부사항

3 of 39

01

프로젝트 소개

4 of 39

01.

1. MLOps 란?

프로젝트 소개

ML 파이프라인

  • ML 개발의 파이프라인은 데이터 수집, 전처리 그리고 모델 학습, 검증, 배포 이후 서빙에 필요한 환경 구성 등이 존재

  • 파이프라인은 한번이 끝이 아니라 성능 개선을 위해 계속해서 반복하게 됨 => 비용 증가

5 of 39

  • 2015년, Google에서는 ML 기술 부채에 대한 논문을 발표하며 ”ML 모델링 코드는 전체 시스템의 5% 이하이며 나머지는 데이터, 모델 서빙, 모니터링 등 서비스에 필요한 컴포넌트들이 차지한다.” 라는 의견을 제시

Hidden Technical Debt in Machine Learning Systems (NEURIPS, 2015)

01.

1. MLOps 란?

프로젝트 소개

6 of 39

  • 연구단계에서 제품단계로 나오면서 변화하는 데이터 맞춰 지속적인 개발&배포를 위해 관심도 증가

  • ML 데이터의 규모가 점차 대규모로 확장되면서 더욱 관심도가 증가

최근 5년간 MLOps 관심도 (Google Trend, 2022.08.21)

01.

1. MLOps 란?

프로젝트 소개

7 of 39

  • Uber에서는 MLOps를 위해 Michelangelo라는 플랫폼을 직접 개발
  • Michelangelo 덕분에 3년 만에 ML 제품을 0개에서 수백 개를 출시

  • Constru에서는 ML 실험을 재현하는데 걸리는 시간을 1/2로 단축
  • 2022년 3월 기준, 내년 130만 달러를 절감할것으로 예상

  • ECOLAB은 MLOps 플랫폼을 사용하여 모델 배포 시간을 12개월에서 30~90일로 단축

2. MLOps 의 적용사례

01.

프로젝트 소개

  • Naver Clova에서는 사내의 모델 서빙 플랫폼 CLOps을 직접 개발
  • CLOps를 통해 모델 배포를 할때 수동적으로 하던 리소스, 네트워크, 모니터링 등의 환경 구성을 자동화

8 of 39

3. So1s의 프로젝트

프로젝트 소개

01.

업스테이지 요구사항

  • 모델 서빙 플랫폼
  • 러닝커브가 높지 않은 플랫폼
  • 서버상태, 리소스, 트래픽 관련 모니터링
  • GPU Affinity, AB Test 등 전략적 기능
  • HPA, 실시간 업데이트 등 고가용성을 위한 기능

9 of 39

3. So1s의 프로젝트

프로젝트 소개

Monitoring

Strategy

Test

So1s 프로젝트의 커버리지

01.

10 of 39

“머신러닝 서빙에 필요한 다양한 기능들을 제공하는 프레임워크”

3. So1s의 프로젝트

프로젝트 소개

01.

  • 개발한 모델을 실시간으로 사용할 수 있도록 API 서버로 배포

  • 모델의 코드, 파일, 메타 정보등을 함께 버전으로 관리

  • 모델을 실시간으로 배포, 업데이트가 가능하도록 다양한 배포 전략을 지원

  • 두개 이상의 모델에 대한 성능 비교를 위한 ABN Test가 가능하도록 환경 구성을 지원

  • 배포된 모델 서버에 대한 리소스, 네트워크 등에 대한 모니터링

Model Serving

Monitoring

Model Version Managing

Deployment Strategy

Test

11 of 39

“머신러닝 서빙에 필요한 다양한 기능들을 제공하는 프레임워크”

3. So1s의 프로젝트

프로젝트 소개

01.

Model Serving

Monitoring

Model Version Managing

Deployment Strategy

Test

So1s 솔루션

서빙에 대한

개발, 운영 부담 X

개발자

12 of 39

02

개발 결과

13 of 39

So1s 플랫폼

모니터링

인하우스 대시보드

02.

1. 아키텍처

개발 결과

인퍼런스 서버 관리

모델 관리

테스트 환경 관리

14 of 39

So1s 플랫폼

모니터링

인하우스 대시보드

인퍼런스 서버 관리

모델 관리

테스트 환경 관리

02.

1. 아키텍처

개발 결과

15 of 39

Control Plane

Data Plane

Service

Service

Data Plane

Service

Data Plane

Service

Kubernetes�API Server

16 of 39

Kubernetes Cluster

Service Mesh - Istio

S3

Serving Engine

Data Plane

Service

Control Plane

Service

Monitoring & Logging

Prometheus

Grafana

Elasticsearch

Kibana

Fluent Bit

Dashboard

React

MUI

Jotai

Tailwind

17 of 39

인퍼런스 서버 이미지 빌드

02.

2. 기본 기능

개발 결과

18 of 39

인퍼런스 서버 이미지 배포

02.

2. 기본 기능

개발 결과

19 of 39

모니터링

실제 서비스가 정상적으로 동작하고 있는지 확인하기 위해서는 여러가지 지표를 통해서 파악 가능. 이외에도 모니터링을 통해 향후 추세를 파악할 수 있고 장애의 원인도 빠르게 식별 가능��따라서 지속가능한 서비스를 운영하기 위해서 모니터링 환경이 반드시 구축되어야함

02.

2. 기본 기능

개발 결과

20 of 39

Alert 설정

네트워크 확인

리소스 확인

어떤 인퍼런스 서버가 어느 정도의 CPU, GPU, Memory 리소스를 사용하고 있는가 확인 가능

인퍼런스 서버별 가용성과 레이턴시 확인 가능

어떤 인퍼런스 서버에 문제가 발생하면 Slack 채널에 경고 메세지 발송

02.

2. 기본 기능

개발 결과

21 of 39

빌링 대시보드

사내에서 팀 혹은 개발자가 얼마나 많은 클라우드 리소스를 사용했는지 알 수 없음.

따라서 So1s는 계정별로 리소스 사용량에 따라 지불할 금액을 보여주는 빌링대시보드를 추가

이를 통해 과도한 리소스 사용을 방지할 수 있으며, 리소스 사용 히스토리에 따라 전략적으로 리소스 운영 가능

02.

2. 기본 기능

개발 결과

22 of 39

02.

3. 부하테스트와 SLI, SLO

개발 결과

부하테스트와 SLI, SLO

개발 내에서 동작하는 것으로는 프로덕션 상에서 정상 동작할 수 있다는 것을 보장하지 못함

따라서 인퍼런스 서버 빌드 및 생성과 인퍼런스 서버 예측 요청에 대해 부하테스트 진행

또한 사용자 입장에서 명확한 지표를 제공하고자 SLI 측정 및 SLO 선정

23 of 39

02.

3. 부하테스트와 SLI, SLO

개발 결과

부하테스트 시나리오

SLI 선정

  • 인퍼런스 서버 Predict API 부하 요청
    • 모델 : efficientNet, Boston, Resnet
  • Control Plane GET / POST API 부하 요청
    • 모델 : efficientNet, Boston, Resnet
    • 병렬적으로 진행 & 유저수 = 최대 100명 / 1초에 25명 변동
  • 집계 간격 : 평균 1분 - (Grafana에서 자유롭게 설정 가능하게 할 예정)
  • 집계 범위 : Control Plane 요청 API, 인퍼런스 서버에 대한 Predict API
  • 측정 빈도 : 매 20초 (Prometheus Default Value)
  • 집계에 포함할 요청들 : Prometheus에서 수집한 API 요청에 대한 성공률
  • 데이터의 수집 방식 : Promethues에 의해 수집

24 of 39

02.

3. 부하테스트와 SLI, SLO

개발 결과

25 of 39

02.

3. 부하테스트와 SLI, SLO

개발 결과

26 of 39

02.

3. 부하테스트와 SLI, SLO

개발 결과

27 of 39

02.

3. 부하테스트와 SLI, SLO

개발 결과

SLO 선정 결과

Service

인퍼런스 서버

SLO Type

HTTP 요청 성공률

Objective

85.14% successful in previous 1 hour

Service

Control Plane API 서버

SLO Type

HTTP 요청 성공률

Objective

90% successful in previous 1 hour

28 of 39

03

개발 세부사항

29 of 39

03.

1. 오토 스케일링 & GPU 스케줄링

개발 세부사항

Metrics Aggregator

HPA AutoScaler

Inference Server

Inference Server

Inference Server

Deployment

Prometheus Adapter

Prometheus

DCGM Exporter

Istio Telemetry

Prometheus Custom Metrics를 통한 오토 스케일링

30 of 39

03.

1. 오토 스케일링 & GPU 스케줄링

개발 세부사항

1GPU - 3

2GPU - 1

1GPU - 4

2GPU - 2

GPU Node A

Least Requested Priority 플러그인 - Worst Case

2GPU - 5

1GPU - 4

2GPU - 1

1GPU - 3

2GPU - 2

Node Resources Fit 플러그인 Bin Packing 방식

2GPU - 5

GPU Node B

GPU Node A

GPU Node B

GPU 스케줄링 개선 사항

31 of 39

03.

2. Wildcard Ingress 구성 - Before

개발 세부사항

Ingress (ALB)

Service (NLB)

Deployment

x18 LBs

Route 53 DNS

Subdomain A Record

Ingress (ALB)

Service (NLB)

Deployment

EKS Cluster

Legacy Architecture

32 of 39

03.

2. Wildcard Ingress 구성 - After

개발 세부사항

Service (ClusterIP)

Deployment

Route 53 DNS

Gateway

VirtualService

Ingress (ALB)

Istio Gateway

Service (NLB)

Service (ClusterIP)

Deployment

Gateway

VirtualService

Istio Service Mesh

Modern Architecture

x2 LBs

*.so1s.io

33 of 39

03.

2. Wildcard Ingress 구성 - 비용 절감

개발 세부사항

Before

After

34 of 39

03.

3. ABN 테스트 구현 - v1 (Legacy)

개발 세부사항

Service (ClusterIP)

Deployment

Route 53 DNS

Gateway

VirtualService

Ingress (ALB)

Istio Gateway

Service (NLB)

Istio Service Mesh

Service (ClusterIP)

Deployment

Two Endpoints / Fixed Weights

Traffic Splitting v1 API

*.so1s.io

35 of 39

03.

3. ABN 테스트 구현 - v2 (Modern)

개발 세부사항

Service (ClusterIP)

Deployment

Route 53 DNS

Gateway

VirtualService

Ingress (ALB)

Istio Gateway

Service (NLB)

Istio Service Mesh

Service (ClusterIP)

Deployment

Multiple Endpoints / Dynamic Weights

Traffic Splitting v2 API

*.so1s.io

1..n

x : y : z …

36 of 39

04

To Be

37 of 39

1. 프로덕트 시장성 검증

To Be

04.

네이버 클로바 CLOps 개발자 이현동님 미팅

현동님은 네이버 클로바의 MLOps 시스템인 CLOps를 개발하였고, 이에 대한 내용으로 DEVIEW에 연사로 참여한 경험이 있음

So1s와 같은 도메인인 MLOps 플랫폼을 개발한 노하우를 받기 위해 미팅 진행

프로덕트에 대한 피드백과 개선 의견을 받기 위해 전문가 미팅 진행

안재만 CEO님과의 컨택을 통해 사내 발표 및 질의응답 진행

VESSL은 MLOps 파이프라인 전체를 커버하는 시스템으로, 비즈니스와 사용성에 관한 피드백을 받기 위해 미팅 진행

VESSL AI 사내 발표 및 미팅

업스테이지 월간 미팅

업스테이지 소프트웨어 엔지니어인 조남준님, 유경민님과의 월간 피드백 미팅 진행

업스테이지의 경우, 노코드 AI 솔루션인 AI Pack을 개발한 회사이자 동시에 So1s 벤처 프로젝트의 발주 기업이므로, 프로젝트에 대한 사용성과 응용 방법을 찾기 위해 미팅 진행

38 of 39

2. 향후 로드맵

To Be

04.

최종점검 이후 업스테이지 미팅을 통한 활용 방안 논의

사용성을 끌어올려서 자체 사업화, 창업 도모

오픈소스화 도모

활용도와 외부 개발자의 참여, 안정성을 높이기 위해 오픈소스를 통한 활용 방안을 물색중

다만, 사업화와는 거리가 멀어지는 One-way door 결정이기 때문에 신중할 필요가 있음

현재는 백오피스 플로우가 매끄럽지 않거나, Service to Service 기능을 통해 외부 클라이언트가 사용하는 것에 많은 문제가 남아있음

따라서, 고도화 과정을 통해 사용성과 상품성을 끌어올리고 지속성장 과정을 통해 자체 사업화, 즉 창업을 도모하고 있음

12월 초에 업스테이지와 벤처 프로젝트 관련 미팅 일정이 잡혀있는 상태

이 미팅을 통해, 프로덕트 활용 방안 및 B2B 비즈니스 관련 논의 예정

프로덕트 활용 방안 논의

39 of 39

Thank you

So1s