Michelangelo

원문: https://eng.uber.com/michelangelo-machine-learning-platform/

우버에서는 ML-as-a-service 플랫폼으로 미켈란젤로를 쓴다.

미켈란젤로는 팀 내부에서 머신러닝 빌드, 배포, 운영까지 가능한 솔루션이다. 미켈란젤로는 e2e ML workflow 를 수행하도록 설계되어있다: 데이터 관리, 훈련, 측정, 모델 배포 그리고 예측 수행과 예측 모니터링을 한다.

미켈란젤로를 개발하게된 동기

신뢰성있고, 단일화되고 재사용가능한 예측 및 훈련용 데이타 생성 파이프라인 시스템이 없어서 만들게되었다고한다. 미켈란젤로가 없었을때에는, DS 가 쓰는 로컬 머신이 할 수 있는 훈련 량 만큼만 모델 훈련이 가능헀다, 그리고 훈련 실험 결과를 저장하거나, 다른 실험결과를 비교하기가 쉽지 않았다. 무엇보다, 모델을 프로덕션에 배포하는 일관된 방법이 없었다. 대부분의 경우, 엔지니어팀에서 프로젝트에 맞는 서빙 컨테이너를 커스텀하게 만들어서 배포해주는 식이었고, Scully et al 에서 지적한 ML 안티패턴들도 나타나고 있었다.

미캘란젤로는 이러한 문제들을 일관된 워크플로우와 툴을 팀에 표준화해서 사용하게 함으로써 해결하려고했다. 그렇게 함으로써 쉬운 빌드와 스캐일가능한 머신러닝 시스템을 운영하려고했다. 우리의 목표는 이러한 문제를 즉시 해결하는 것이아니고, 비즈니스와 함께 성장하는 시스템을 만드는 것이다.

2015 년에는 도전과제는 scalable 한 모델 훈련과 프로덕션 배포에 컨테이너를 사용하는것이었다. 그리고, 피처 파이프라인을 관리하고 공유할 수 있는 더 나은 시스템을 만드는 것이다. 최근에는 즉, 아이디어로부터 첫 프로덕션 모델까지 만드는것과 빠른 iteration 을 달성하는, 개발자 생산성을 늘리는 것에 관심을 집중하고있다.

예를들면 어떤걸 빌드하고 배포하는가?

우버 잇츠 유즈케이스가 대표적인데, 여러 비슷한 모델을 회사 내에서 다양한 예측 유즈 케이스를 미켈란젤로 플랫폼을 통해 관리하는 것이다.

유즈케이스: 배달에 걸리는 시간 (ETD) 예측하기

우버잇츠에서는 배달 시간 예측, 검색랭킹, 검색 자동화, 그리고 식당 랭킹을 위해 여러가지 모델이 돌고있다. 배달 시간 모델의 경우 주문이 발행되기전에 준비하고 배달하는데 걸리는 시간을 예측을한다. 그리고 배달 프로세스의 각 단계마다 다시 한번씩 예측을 수행을 한다.

Fig1. 미켈란젤로를 통해 빌드된 모델로 예측을 하는 모습

우버잇츠 사용자가 주문 요청을하면, 식당에서는 주문을 받아 음식점이 바쁜정도와, 주문의 복잡도를 가지고 음식을 준비하는데 걸리는 시간을 알아야한다. 음식이 준비되어야 할 시간이 가까워지면, 우버 배달 파트너가 음식을 가지러 파견된다. 파견된 배달 파트너는 음식점을 가고, 주차장 찾은뒤, 음식을 찾고, 차로 돌아가고, 주문고객에게 배달을 한다. 이러한 과정을 모두 수행하는데 걸리는 총 시간을 예측하는 것이 우버잇츠 모델이 예측하고자하는것이다. 그리고 각 프로세스 별로 배달 시간 예측도 수행한다.

미켈란젤로 플랫폼에서는 우버잇츠 DS가 gradient boosted decision tree regression models 을 사용해서 이러한 e2e 시간을 측정했다. 모델을 위한 피처들은 다음과 같은 정보들을 가지고있다. 요청으로부터 오는 정보의 경우 그날의 시각, 배달 장소. 이력으로 부터 알 수 있는 7일간 평균 음식 준비시간, 그리고 거의 실시간으로 계산되는 지난 한시간 동안 음식을 준비하는데 걸리는 평균 시간. 모델들은 우버의 데이타 센터에서 부터 미켈란젤로에 있는 모델 서빙 컨테이너에 배포되고 이러한 배포 과정은 우버잇츠 마이크로서비스의 네트워크 요청에 의해서 수행된다. 이러한 음식 주문에서 부터 음식 준비와 배달까지에 관한 예측 수행들은 우버잇츠의 주문고객에게 표시된다.

미켈란젤로 시스템 아키텍쳐

미켈란젤로는 여러 오픈소스와 인하우스에서 빌드된 컴포넌트를 모아 구성되어있다. 주로 사용되는 오픈 소스 컴포넌트의 경우 HDFS, Spark, Samza, Cassandra, MLLib, XGBoost, and TensorFlow 이다. . 우버는 주로 성숙한 오픈소스를 쓰려고 하고있고, 포크하여 커스터마이즈 한뒤 기여하는 것을 선호한다. 가끔씩 오픈소스를 쓰는것이 사용사례에 맞지 않는다면 직접 시스템을 만들기도한다.

미켈란젤로는 우버의 데이타와 컴퓨트 인프라상에 빌드 되어 모든 우버의 트랜잭션 및 로그 데이타를 제공하는 데이타 레이크가 된다. 또한 카프카 브로커의 역할도하는데, 서비스로부터 발생하는 로그 메시지를 집합(aggregate)한다 또한 Samza streaming , Cassandra cluster, 그리고 우버의 인하우스 서비스 프로비져닝과 배포 툴을 포함한다.

머신러닝 워크플로

어떤 문제해결을 할때에 우버에서는 같은 워크플로를 쓰는 경우가 많다. 분류과 회귀를 하거나 시계열 예측을 하는 경우가 그렇다. 워크플로는 보통 implementation-agnostic 한 성질이 있다, 그래서 새로운 알고리즘 타입과 프레임워크를 지원하기위해 확장이 되기가 쉽다. 또한 온라인 과 오프라인 예측 사용사례에서와 같은 서로 다른 배포 방식에도 이러한 확장성이 필요하다.

우버에서는 미켈란젤로를 scalable, reliable, reproducible, easy-to-use, and automated tools 특성을 갖도록 설계하였다. 아래와 같은 6단계 워크플로를 수행한다.

데이터를 관리한다
모델을 훈련한다
모델을 측정한다
모델을 배포한다
예측을 수행한다
예측을 모니터링한다

데이터 관리

좋은 피처를 찾는 것은 머신러닝에서 가장힘든 부분이고 우버에서는 데이타 파이프라인을 빌드하고 관리하는것이 완성형 머신러닝 솔루션에 있어서 일반적으로 가장 비용이 많이 드는 부분이다.

플랫폼은 훈련 및 예측을 위한 피처와 라벨 데이타 셋을 생성하기 위한 데이타 파이프라인을 빌드 할 수 있는 표준화된 툴을 제공해야한다. 이러한 툴은 사내 데이타 레이크나 데이타 웨어하우스, 온라인 데이터 서빙 시스템과 통합이 잘 되어있어야 한다. 파이프라인은 확장가능하고 성능이 우수해야한다, 통합 데이타 플로와 데이타 품질 모니터링도 마찬가지이다. 또한 온라인과 오프라인 모델 훈련과 예측도 지원해줘야한다. 이상적으로는 피처를 생성해서 팀내에 공유할 수 있는 형태면 좋은데, 반복된 작업을 줄이고 데이타 품질을 높이기 때문이다. 이러한 방식은 강한 가드레일이 되어 사용자를 배스트 프랙티스를 사용하도록 가이드한다(예를들면 훈련과 예측 각각에 같은 데이타 생성 프로세스가 사용되도록하는 것을 보장하는것을 쉽게할 수 있다).

데이타 관리 컴포넌트는 온라인과 오프라인 파이프라인으로 나눠진다. 현재, 오프라인 파이프라인은 배치 모델 훈련과 배치 예측 잡들에 데이터를 주입하기 위해 사용되고 온라인 파이프라인은 온라인 저지연예측에 사용되는 데이터를 주입해준다.

추가로, 데이타 관리에 레이어를 추가헀는데, 팀들간에 공유, 디스커버리, 그리고 여러 머신러닝 문제를 해결하기 위해 선정된 피처 셋들이 선정된 피처스토어이다. 우버는 많은 모델링 문제가 비슷한 피처를 쓴다는 것을 발견했고, 이러한 피처들은 엄청난 가치를 발휘할때가 팀들간에 공유가 되어 각 프로젝트에 적용될때이다.

Fig2. 데이타 준비 파이프라인이 피처스토테이블과 훈련 데이타 저장소에 데이타를 밀어 넣고있다.

오프라인 모델 (훈련 모델)

우버의 트랙잭션 및 로그 데이타의 경우 HDFS 데이타 레이크로 흘러들어가고 스파크와 하이브 SQL 연산 잡으로 쉽게 접근이 가능하다. 우버는 컨테이너와 스캐쥴링을 통해 잡들을 돌려 피처들을 만들어 프로젝트에 넣어주거나, 피처스토어로 발행이 되게끔해준다 그리고 팀간에 공유가 되게한다. 이러한 배치 잡들이 스캐쥴러나 트리거로 돌고 이러한 잡들이 데이타 품질 모니터링 툴과 통합되면 파이프라인에서 빠르게 회귀를 통해 로컬 혹은 업스트림 코드나 데이타 이슈를 감지할 수 있다.

온라인 모델 (배포된 모델)

온라인에 배포된 모델은 HDFS 에 있는 데이타를 접근할 수 없다, 그리고 몇 피처들을 연산할때 우수한 성능으로 수행할 수 있는 우버 뒷단의 서비스에 사용되는 온라인 DB 에 접근하기 어려울 때가 있다(예를들면 우버잇츠의 주문 서비스에 바로 쿼리해서 평균 음식 주문시간을 특정 식당에서 특정 시간동안에 한해서 계산하기가 어려울 수 있다).

대신, 우버에서는 온라인 모델에서 사용되는 피처들을 미리 연산되게끔한뒤 카산드라에 저장하여 빠른 시간에 읽을 수 있도록 한다.

이러한 온라인으로 서빙되는 피처를 위해서 두가지 옵션을 제공한다, 배치 precompute 와 near-realtime compute 옵션이다.

Batch precompute : 대량의 precomputing을 수행하고 historical 피처들을 HDFS 로부터 가져와서 Cassandra 로 집어 넣는것이다. 간단하면서도 효과적이고 historical 피처들에도 잘 동작한다 왜냐하면 피처들이 몇시간 혹은 하루에 겨우 한번 업데이트를 하기 때문이다. 이러한 시스템은 같은 데이타를 보장하고 배치 파이프라인은 측정과 서빙 둘다에 사용된다. 우버잇츠는 이 시스템을 쓸때 예를들면 지난 7일간의 음식 준비 시간에 대한 피처를 저장하기 위해서 쓴다.
Near-real-time compute: 카프카와 연관된 메트릭을 발행하고 삼자 기반 스트리밍 연산 잡을 돌려 피처들을 집합하는 과정을 저지연성으로 달성한다. 이러한 피처들은 카산드라로 직접 저장이 되고 이후의 훈련 잡을 위해 HDFS 로 로그를 보낸다. 배치 시스템 처럼, 거의 실시간 연산은 똑같은 데이타가 훈련과 서빙에 쓰이는 것을 보장한다. 콜드 스타트를 방지하기 위해, 데이터를 backfill 하기 위한 툴을 제공하고 배치 잡을 로그 이력에서 수행함으로써 훈련 데이타를 생성한다. 우버 잇츠에서는 Near real time 파이프라인을 식당의 1시간내에 평균 식사 준비 시간 피처를 위해 쓴다.

공유되는 피처스토어

중앙화된 피처스토어를 통해 엄청난 가치를 얻었는데 어떤 우버팀이든 정규 피처들을 만들고 관리할 수 있다는것이다 그리고 팀 내에서 쓰고 다른 사람들과 공유를 할 수 있다는 것이다. 고수준에서는 두가지를 달성하게된다.

사용자가 공유 피처스토어에 피처를 약간의 메타데이터를 통해 쉽게 추가를 한다.
한번 피처들이 피처스토어에 있다면, 온라인과 오프라인에서 구독이 굉장히 쉬워진다, 요 과정은 피처의 canonical 이름을 모델 설정에서 참조해서 알 수 있게된다. 이러한 정보와 함게, 시스템은 올바른 HDFS 데이타 셋을 모델 훈련 혹은 배치 예측에 사용하고 올바른 값을 카산드라를 통해 온라인 예측에서 가져올 수 있도록한다.

현재 우버는 피처스토어에 10000개에 가까운 피처들을 가지고 머신러닝 프로젝트에 진행에 속력을 더하고있다. 그리고 회사내의 팀들이 새로운 피처를 하나씩 추가하고있다. 피처 스토어의 피처들은 자동적으로 계산되고 매일 업데이트된다.

미래에는, 우버에서 피처스토어를 검색할 수 있는 자동화된 시스템을 만드는 방법과 예측 문제를 풀기위한 가장 강력한 피처를 식별하는 방법을 찾으려고한다

피처 선택과 변환에 사용되는 도메인 특정 언어(DSL)

피처들은 데이타 파이프라인으로 만들어지거나 클라이언트 서비스에서 모델에 적합하지 않은 데이터를 보내줌으로써 생성이된다, 그리고 이러한 피처들은 꼭 필요한 값이 빠져있을때가 있다. 또한, 모델이 제공된 피처의 일부집합만 있어도 괜찮을 때도있다. 어떤 경우에는 하루의 시각 보다 한주의 하루로 타임스탬프를 바꾸는게 게절별 패턴을 캡쳐하기 위해 유리한 경우가있다. 다른 사례의 경우, 피처값들은 정규화 되어야할때가 있다(평균 값을 빼고 표준 편차로 나눈다는 말이다).

이러한 문제를 해결하기 위해, 우버에서는 DSL 을 만들었다. 모델러는 DSL 을 통해 훈련 및 예측 시간에 모델에 보내진 피처를 select, transform, and combine 할 수 있다. DSL 은 Scala 로 만들었다. DSL 로 또 할 수 있는게 고객 팀에서 각자 커스텀 함수를 만들 수 있다. 접근자 함수들과 현재 컨텍스트(데이타 파이프라인인데, 요경우는 오프라인 모델이나 현재 클라이언트 요청에서 사용되는 온라인 모델을 뜻한다)의 피처 값을 가져오거나 피처 스토어로부터 피처를 가져올 수 있다.

DSL이 모델 설정의 일부가 되도록 하는것이 좋고, 훈련과 예측에 같은 DSL 이 적용되어야 같은 final set 피처가 생성이 되어 모델로 들어가게된다.

**Train models(모델 훈련)**

미켈란젤로는 오프라인, 분산 트레이닝을 지원한다. 지원되는 훈련의 종류로는 의사결정 트리, 선형과 로지스틱 모델 그리고 비지도 학습모델(예를들면 K-means), 시계열 모델 그리고 딥뉴럴 네트워크가 있다. 분산 모델 훈련의 경우 수십억개의 샘플 훈련에서 부터 작은 데이터셋으로 빠른 이터레이션 훈련까지 가능하다.

모델 설정은 모델 타입, 하이퍼 매개변수, 데이타소스 참조, 피처 DSL , 컴퓨팅 리소스 선언이 있다( 머신의 숫자, 메모리, GPU 사용유무 등). 이러한 설정들은 YARN or Mesos cluster 상에서 도는 훈련 잡 설정을 구성하는 설정이 된다.

모델 훈련 이후에는, 성능 지표(ROC curve 와 PR curve 가 있다) 가 평가 되고, 모델 측정 리포트에 포함된다. 훈련의 마지막에는, 원본 설정, 학습된 매개변수, 그리고 측정 리포트가 저장되어 모델 저장소에 저장되고 분석과 배포에 사용된다.

단일 모델을 훈련하는것 뿐만아니라, 미켈란젤로는 모든 타입의 모델 타입과 파티션 모델에 대해서 하이퍼 매개변수 탐색을 지원한다. 파티션 모델에 대해서는 , 자동적으로 훈련 데이타를 사용자 설정 기반으로 파티셔닝 하고 각 파티션마다 한 모델씩 훈련을 한다, 그리고 부모 모델로 필요할때마다 fallback(예를들어, 도시 별 모델을 훈련했지만 원하는 정확도를 달성하지 못하는 경우 나라 수준의 모델로 돌아오도록 할 수 있다).

훈련 잡은 UI 와 API 를 통해 관리되고 설정된다, 가끔 주피터 노트북을 통해서 설정되기도한다. 팀에서는 API 를 사용하고, workflow 툴을 사용해서 모델 재훈련 스캐쥴링을 한다.

모델 훈련 잡은 피처스토어와 훈련 데이타 저장소 셋을 사용해서 모델을 훈련하고 훈련이 끝나면 모델 저장소에 저장하게된다.

모델 평가하기(**Evaluate models)**

모델은 문제를 해결하기위한 최선의 형태가 되기 위해 피처셋,알고리즘, 하이퍼 매개변수를 확인하기 위해 체계적인 탐색과정으로 훈련을 하여 이상적인 모델에 도달하기 위해 수백번의 모델을 훈련을 하게된다. 비록 결국 프로덕션에 쓰이지 않더라고, 이러한 모델들은 엔지니어들로하여금 최고의 성능을 내는 모델 설정을 하게끔 한다. 이러한 훈련된 모델들을 추적하고, 평가하고, 서로 비교를 하는것은 보통 커다란 도전과제로 다가오는데 그 시점이 너무 많은 모델이 있고 여러가지의 값들을 추가할때 이다.

미켈란젤로의 모든 모델에 대해서, 우버는 버저닝이 들어간 오브젝트를 카산드라의 모델 저장소에 저장하는데 아래와 같은 정보를 가진 레코드로 저장하게된다

누가 모델을 훈련했는지
훈련 잡의 시작과 끝 시간
전체 모델 설정 (사용된 피처, 하이퍼 매개변수 등)
훈련과 테스트 데이타 셋 참조값
각 피처의 분포와 상대적 중요도
모델 정확도 메트릭
각 모델 타입에 대한 표준 차트와 그래프 (e.g. ROC curve, PR curve, and confusion matrix for a binary classifier)
학습이 완료된 모델의 매개변수들
모델 시각화를 위한 요약 통계

이러한 정보들은 웹 UI 를 통해 알거나 API 호출로 쉽게 파악이 가능하다, 둘다 각 모델을 조사하거나 둘 이상의 모델을 서로 비교하기 위해서도 쓸 수 있다.

**Model accuracy report(모델 정확도 리포트)**

회귀 모델에 대한 모델 정확도 리포트는 표준 정확도 메트릭과 차트를 보여준다.분류 모델은 다른 셋을 보여주는데 아래 사진과 같다.

회귀 모델 리포트는 회귀 관련 성능 지표를 보여준다

2진 분류 성능 리포트는 분류 관련 성증지표를 보여준다

**Decision tree visualization(의사 결정트리 시각화)**

중요한 모델의 경우에는 복잡한 시각 툴을 써서 모델러들이 모델의 행위를 이해하고, 디버깅 할 수 있도록 한다. 의사 결정 트리 모델의 경우 사용자가 각 개별 트리를 보면서 전체 모델에 대한 상대적 중요성, 분할 지점, 특정 트리에 대한 각 기능의 중요성 및 다른 변수 중에서 각 분할에서의 데이터 분포를 탐색하여 알 수 있게 해준다. 사용자는 피처 값들을 특정할 수 있고 시각화는 의사결정 트리 path 를 묘사 할 수 있도록해준다. 그리고 전체적인 모델 예측을 묘사한다.

**Feature report ( 피처 리포트)**

미켈란젤로는 피처 리포트로 각 피처를 정렬해서 중요도를 기반으로 보여준다 . 두가지 피처를 같이 선택하면 피처 상호작용을 two-way partial dependence diagram 으로 볼 수 있다.

피처들을 볼 수 있고, 모델에 가하는 영향도를 알 수 있으며 상호 작용을 피처 리포트를 통해서 탐색해볼 수 있다.

**Deploy models (모델 배포)**

미켈란젤로는 e2e 배포가 가능한데, UI 나 API 로 할 수 있고 3가지 모드를 지원한다.

offline deployment: 모델은 오프라인 컨테이너에 배포되서 스파크 잡을 돌려서 배치 예측값들을 생산 한다. 이러한 작업은 반복 스캐쥴링이나 필요에 따라 요청이 가능하다.
online deployment: 온라인 예측 서비스 클러스터에 배포되고 ( 수백대의 머신이 로드밸런서 뒷단에 존재한다) 유저가 서비스에 RPC 호출을 통해 결괏값을 받을 수 있다.
library deployment: 서빙 컨테이너에 모델을 수행하도록 하려고하는데 그 컨테이너가 다른 서비스에 라이브러리로 임베딩이 되어 자바 API 로 호출이 되는 경우의 배포. online deployment 와 비슷하다.

모든 경우에 대해서 필요한 모델 아티팩트들은 ZIP 파일로 되어있고 연관된 호스트로 복제되어 우버의 데이터 센터를 넘어 코드 배포 인프라로 넘어가게된다. 예측 컨테이너들은 자동적으로 디스크로부터 새로운 모델들을 불러오고 예측 요청을 핸들링하기 시작한다.

많은 팀들이 자동 스크립트로 일반 모델 재훈현과 배포를 미켈란젤로 API 로 작성해뒀다. 우버잇츠의 경우 데싸와 엔지니어를 통해 웹 UI 를 통해 수동트리거를 한다.

**Make predictions**

모델이 배포가 되고 서빙 컨테이너로 불러와졌을때, 서빙 컨테이너가 예측을 할때에는 데이타 파이프라인에서 불러온 피처 데이타를 기반으로 예측 하거나 client 서비스로부터 직접 예측한다. 피처 스토어에있는 raw 피처들은 DSL 을 통해 수정되고, 추가 피처를 추가할 수 있다. 마지막 피처 벡터가 만들어지고나면 스코어링을 위해 모델에 전달이 된다. 온라인 모델의 경우에는, 예측값들이 하이프에 쓰여지는데 이 값들은 다운스트림 배치 잡이나 사용자를 통해 SQL 기반 쿼리 툴을 통해 Consume 된다.

온라인, 오프라인 예측 서비스는 피처 벡터 셋들을 사용해서 예측값들을 생성한다.

**Referencing models (모델 참조하기)**

하나 이상의 모델은 동시에 하나의 서빙 컨테이너에 배포될 수 있다. 이러한 기능은 예전 모델에서 새로운 모델로 교체를 하기 위한 A/B 테스팅이 가능하게끔 해준다. 서빙 중에는 서빙을 위해 배포된 모델은 UUID, 태그(alias) 를 통해 식별된다. 온라인 모델의 경우에는, 클라이언트 서비스가 원하는 모델의 피처 벡터를 모델의 UUID 혹은 모델의 태그를 전달 한다. 태그 참조의 경우에는 배포된 같은 태그를 가진 모델중 가장 최신 모델을 참조하게된다. 배치 모델들의 경우에는, 모든 배포된 모델들은 각 배치 데이타 셋의 score 를 매기기 위해 쓰고 예측 결과 레코드들은 모델 UUID 와 태그를 가지고있어서 consumer 가 적합한 필터를 걸 수 있도록 한다.

만약 새로운 모델로 옛날 모델을 교체를 하는 경우 두 모델이 같은 시그니쳐를 가지는 경우 (같은 셋의 피처를 가지는 경우) , 사용자는 새로운 모델을 예전 모델과 같은 태그를 부여하게되면 컨테이너는 새로운 모델을 써서 즉시 시작이 된다. 이러한 기능은 사용자가 모델을 클라이언트 코드를 변경하지 않으면서 모델을 업데이트 할 수 있게끔한다. 사용자들은 또한 새로운 모델을 단지 UUID 만 가지고 배포할 수 있으며 이후에는 클라이언트의 설정이나 중간 서비스의 설정을 바꾸어서 점진적으로 예전 모델UUID 에서 새로운 모델 UUID 로 변경하도록 트래픽 스위치를 할 수 있다.

A/B 테스팅의 경우, 사용자들이 경쟁 모델을 UUID 혹은 태그로 배포하고 우버의 experimentation 프레임워크를 사용해서 트래픽 비율을 조정할 수 있고 각 모델의 성능 메트릭을 추적할 수 있다.

**Scale and latency(스케일과 지연)**

머신 러닝 모델이 stateless 하고 어느것도 공유하지 않기 때문에, scale out 은 offline, online 둘 다 쉽다. 온라인 모델의 경우, 호스트를 늘리면 되고 로드 밸런서가 부하를 분산하도록 하면된다. 오프라인 예측의 경우, 스파크 실행기를 더 늘려서 스파크가 직접 병렬처리를 관리하도록 한다.

**Monitor predictions(모델 예측 모니터링)**

모델이 훈련되고 평가가 될때 과거 데이터가 항상 쓰이게된다. 모델이 미래에도 잘 동작하기 위해서는, 데이터 파이프라인이 계속해서 정확한 데이터를 보내고 모델이 더 이상 정확하지 않은지 확인하기 위해 예측을 모니터링하는 것이 중요하다.

이 문제를 해결하기 위해 미켈란젤로는 자동으로 예측의 일정 비율을 기록하고 선택적으로 보류할 수 있고 이후에 보류했던 예측 값들을 데이터 파이프라인을 통해 생성된 예측된 결과 값(혹은 라벨)에 조인할 수 있게한다. 이러한 정보들을 가지고 실시간으로 모델 정확도 측정 값들을 생성 할 수 있다, 이러한 측정값들은 R-squared/coefficient of determination, root mean square logarithmic error (RMSLE), root mean square error (RMSE) 그리고 mean absolute error metrics 값으로 우버의 시계열 모니터링 시스템에 노출시켜 사용자들이 차트를 시간대별로 분석하고 알람 스레스홀드를 설정할 수 있다.

예측값들은 샘플링되고 비교되어 관측값으로 나타내어져서 모델 정확도 지표를 생성하게된다.

**Management plane, API, and web UI (관리 화면, API 와 UI)**

마지막으로 중요한 시스템은 API 계층이다. API 계층은 애플리케이션 관리를 해주는데, 웹 UI 와 네트워크 API 통합에 사용되어 우버의 시스템 모니터링과 알람 인프라에 통합되어있다. API 계층은 또한 워크플로 시스템을 통해 배치 데이타 파이프라인, 훈련 잡들, 배치 예측 잡들, 그리고 배치와 온라인 모델 컨테이너의 배포 오케스트레이션을 가능하게 해준다.

미켈란젤로 사용자는 각 컴포넌트들을 웹 UI, REST API, 모니터링과 알람 툴을 통해 상호작용한다.