AIML 혼자 공부하기

[AWS-Re:invent 2021] Aurora 사에서 자율주행을 위한 SageMaker와 kubeflow 활용 사례

IniMiniManiMo — Wed, 5 Jan 2022 22:00:37 +0900

원본 발표 제목 : Train ML models at scale with Amazon SageMaker (featuring Aurora)

발표자

Emily Webber, Senior ML Specialist SA, AWS
Yu Guo, Senior Manager of Perception, Aurora

원본 영상 : https://www.youtube.com/watch?v=XKLIhIeDSCY

Aurora 는 자율주행을 개발하는 회사로서 안전하고, 빠르며, 광범위한 자율주행의 장점을 고객들에게 제공하는 것을 미션으로 합니다. 현재 개발한 Aurora Driver는 사람을 이동시키는 세단에서 부터 물건을 이동하는 트럭에 까지 모든 것을 작옫하기 위해 고안된 자율주행 시스템 입니다. Aurora는 교통 네트워크와 자동차 제조사들과 파트너십을 통해 전 세계에 자율주행의 장점을 제공하고 있습니다.

Aurora Perception 팀은 수백 미터를 내다볼 수 있는 라이다와 같은 기반 기술들에 투자하고 있으며, 더욱 안전하고 효과적으로 개발할 수 있는 오프라인 시뮬레이션으로 시스템을 검증하고, 도로에서의 안정성을 확신할 수 있는 충분한 데이터를 제공합니다. Aurora Driver는 주변 환경을 이해하고, 다른 actors에 대해 추론하며, 적절한 행동 경로를 결정하고, 안전한 방법으로 action을 실행하게 합니다. 딥 러닝 기반의 자체 Perception 시스템은 주변 환경을 잘 이해하고 실제 시나리오에서 정확한 의사결정을 가능하게 합니다. Dallas와 Houston 사이 도로에서 자율주행 기술을 개선한 후, 새로운 Aurora Driver 베타를 출시하여 FedEx와 함께 상업적인 용도로 활용해 가고 있습니다.

Aurora Driver 베타는 업그레이드된 하드웨어와 자율주행 시스템을 트럭들이 고속도로와 서비스 거리를 안전하게 주행할 수 있도록 하는 핵심 기능을 제공합니다. Aurora 의 Perception 스택은 3개 task의 딥러닝 엔진으로 구성되어 있는데, Sensor to Tensor, Sensor to Adjustment, RemEx 입니다.

Sensor to Tensor : 라이더, 레이더, 카메라를 통한 detection 엔진
Sensor to Adjustment : recurrence tracker
RemEx (Remainder explainer) : 운전자가 주의해야 하는 환경에 대한 모든 정보를 지원

이 기능은 object persistence engine과 결합되어 운전자에게 끊임없이 장면을 이해할 수 있도록 합니다. 예를 들어, Perception 시스템의 한 부분인 Sensor to Tensor는 다중의 센서 모달리티에서 추론과 학습을 위해 센서 퓨전을 사용하는 딥 러닝 Detection 모듈로 Aurora Driver를 둘러싼 세계에 대한 깊은 이해를 생성합니다. 최신의 초기 sensor fusion 접근은 다양한 센서들의 모달리티를 통한 보완적인 강점을 유지하고, 지도 정보와 함께 다양한 센서들의 모달리티를 전체 3D와 먼거리 범위 내에서 보행자, 차량, 자전거 이용자 등과 같은 actors를 고품질 detection이 가능한 common view로 점진적으로 융합합니다.

센서 융합(fusion)의 가장 큰 어려움은 다른 센서들이 world에 대해 각각 다른 resolution과 view를 가지고 있다는 점입니다. Sensor to Tensor는 점진적으로 world에 대한 다양한 센서 view에서 정보를 점진적으로 추출하고 저장하여, 소위 Euclidean Tensor view라는 common 3D representation을 가져 오며, 라이다, 레이더 이미지, 맵 정보를 통합하여, world에 대해 추론을 할 수 있습니다. 따라서, raw 데이터 입력만으로 얻은 결과는 Euclidean view, Range view, Camera image의 세가지 view에서 상호 보완적인 센서 데이터를 얻을 수 있습니다. 각 View는 유용한 정보를 가지고 있으며, 궁극적으로 Aurora Driver 주변 환경을 전체적으로 representation하는데 기여할 수 있습니다.

각 view에서 가치있는 정보를 추출하기 위해 Neural Convolution 엔진은 들어오는 센서 데이터를 처리하게 되고, Aurora Driver 주변의 world를 애니메이션으로 만들어 냅니다. 라이더와 레이더, 지도 데이터의 Euclidean Tensor view는 Neural Convolution 엔진이 처리하는 텐서를 쌓아 intermediate Euclidean tensor view features를 생성하며, 궁극적으로는 풍부하고 상세한 3D 정보를 생산하기 위해 Euclidean view에서 detection을 하고자 합니다.

이런 작업은 Euclidean ray caster를 사용하는데, ray scatter 엔진으로 range view 데이터에서 Euclidean 공간의 점들로 변환하게 됩니다. Range view 내의 각 픽셀은 3D 내 점에 정확히 대응하게 됩니다. Range view 내 픽셀에 대응하는 features는 3D 내 위치로 추적한 다음 Euclidean view 내 적절한 cell에 배치가 됩니다.

이 프로세스는 Range view 내 각 픽셀에 대해 반복되어 Range 데이터에서 해당 Euclidean Tensor view를 생성합니다. 최종적으로는 Range view에서 갭쳐된 정보를 Euclidean View Tensor 로 이전하게 되는데, Euclidean View Tensor는 다른 센서 모달리티에서 비롯된 다른 Euclidean Feature map과 융합할 수 있기 때문입니다. 이런 점에서 모든 센서 모달리티의 feature maps은 Euclidean tensor view 에 있게 됩니다.

Feature maps들은 모두 함께 쌓을 수 있으며, Neural Convolution 엔진으로 처리하여 고품질의 3D detection을 생성할 수 있습니다. 이런 Detections는 속도, width, height, 길이 카테고리, 각 detection에 대한 위치의 불확실성 등을 포함하는 object의 속성을 포함합니다. 이것은 우리 주변의 world에 대한 다양한 센서 inputs에서 파생된 데이터를 풍부하게 representation을 생성하게 됩니다.

Object persistence 엔진을 통해 2개의 Task 특화된 딥러닝 모듈을 통합하여 도로 내 탐지한 actors를 계속해서 추적할 수 있고, 그들에 대해 추론할 수 있습니다. Perception은 자율 주행 스택에서 하나의 단계이며, 이외에도 여러 모듈이 있습니다.

Perception 외 motion planning, ML aided Labeling, Simulation 등도 머신러닝과 딥러닝을 활용합니다. Aurora의 ML 개발 workflow를 위해 차량 로그(Vehicle Logs)를 수집하고 레이블(Labels)과 결합하며, 다양한 팀들에서, 다양한 모델들을 사용하기 위한 통합된 학습 데이터를 생성합니다. 이 값들은 Feature Store에 저장하고, 여기서 시각화(Visualization)와 탐색(Exploration)을 이 가능하게 됩니다.

다음 단계로는 학습 데이터를 활용하여 모델을 학습(Model Training)하고 테스트 데이터로 다양한 성능 메트릭을 이용하여 모델의 성능을 측정합니다. 모델과 전체 자율주행 모듈이 정상적으로 동작하는지 확인하기 위해 일련의 검사를 거친 후 모델을 차량에 배포합니다. 이런 단계들은 매우 복잡하고 반복적으로 진행될 수 있는데, 차량으로 모델을 배포하는 타임 라인, 출시 일정, 취급해야하는 다양한 모델, 다양한 데이터 유형, 발전되는 시나리오와 방법 등이 당면하는 어려움들이 됩니다. 이런 이유에서 더욱 빠르게 반복 가능한 ML 개발 사이클이 필요하고, 자율주행 기술 뒤에 있는 모델 개선에 대한 다양한 가설들을 빠르게 실험해 볼 수 있는 large-scale 학습이 필요합니다.

Aurora는 ML 워크플로우를 관리하기 위해 Kubeflow를 사용하는데, use case별로 학습을 시작하는 3가지 방법이 있습니다.

Command Line이나 UI를 통한 학습 실행
주기적인 이슈를 확인하는 계획된 CI/CD 작업에 따른 학습 실행
신규 데이터의 확보 등과 같이 upstream 프로세스에 의한 학습이 실행

이러한 트리거들 중 하나를 통해 학습이 시작되면, build, orchestration, compute 3가지 계층에서 작업이 진행됩니다.

Build - Kubeflow는 모든 단계에 필요한 Container 이미지를 통합하여 파이프라인을 트리거하기 전에 Harbor registry 와 Amazon ECR로 push 하는데, Kubeflow는 AWS IAM role과 같은 표준 authentication 을 지원합니다.
Orchestration - Kubeflow orchestration 은 SageMaker training Kubeflow component를 사용하여 SageMaker에서 학습을 수행합니다.
Compute - SageMaker training job에서 필요한 GPU 인스턴스를 확보하고, 분산학습을 수행합니다.

학습이 진행되는 상황은 Amazon CloudWatch와 TensorBoard 등에서 로그에서 확인하거나 로그 기능에서 학습 진행 상황 또는 다른 표준 및 사용자 지정 메트릭을 모니터링할 수 있습니다. 학습 후에는 TensorRT로 export 하는 것과 같은 후처리 단계를 통해 체크포인트 파일을 가져옵니다. Metric Evaluation 단계에서는 테스트 데이터를 이용하여 모델 성능을 검증합니다.

이렇게 학습에서 모델 평가까지 일반적인 ML workflow에 대해 Kubeflow와 SageMaker를 통합해서 사용할 수 있습니다. Kubeflow UI에서 과거 jobs 에 대한 이력을 쉽게 볼 수 있으며, 실험 결과를 비교할 수 있습니다. 입력 파라미터를 비교하여 실험 조건의 어떤 측면이 실행 결과에 영향을 주었는지 확인하고 동일한 Tensorboard에서 시각화 할 수 있습니다.

SageMaker를 이용해서 ideation에서 차량에 배포되는 모델까지의 반복적인 일정이 단축되었습니다. 몇주가 걸리던 이런 일들이 이제 며칠에서 일주일로 단축되었습니다. 또한, 입력 파라미터를 검토하고 로그를 확인하는 데 매우 편리합니다. 학습 비용에 대한 관리도 쉬워졌으며, 직접 관리해야 하는 인프라가 많이 줄어들었다는 점도 좋은 장점 중 하나입니다. 다양한 단계별로 수집된 데이터를 이용해서 Kubeflow에서는 이를 통해 실험의 전체적인 lineage를 추적하는 활동이 가능하게 되었습니다.

이런 점에서 Amazon SageMaker는 2개의 분산학습 라이브러리를 제공합니다.

모델의 사이즈가 훨등히 큰 모델의 경우 1개의 GPU 리소스에서 모델학습이 어려운 경우가 발생할 수 있습니다. 이런 경우 우리는 Model Parallel library를 이용하여 OOM (Out-Of-Memory)가 발생하는 것을 방지할 수 있습니다. SageMaker는 성능이 우수한 자체 Model Parallel library를 제공하는데, 기존의 학습 코드에서 5~6줄 정도를 변경한다면 SageMaker에서 바로 적용이 가능합니다.

SageMaker에서는 Data Parallel library도 제공합니다. 기존 NCCL을 제거하고 대체하는 새로운 communication protocol을 통해서 NCCL 과 MPI-baed 솔루션인 Horovod 대비 20~40% 속도를 개선하였습니다. 아래는 이와 관련된 논문입니다. 이 library의 경우에도 기존 학습 코드가 DDP가 가능하도록 구현되어 있다면 큰 변경 없이 바로 사용이 가능합니다.

[AWS-Re:invent 2021] Qualtrics 사에서 SageMaker 기반 MLOps 구현기 소개

IniMiniManiMo — Wed, 5 Jan 2022 15:12:59 +0900

원본발표제목 : Use SageMaker to develop ML models faster (featuring Qualtrics)

발표자

Dr. Ali Arsanjani, AI/ML Specialist SA, AWS
Samir Joshi, ML Engineer, IQ R&D, Qualtrics

원본 영상 : https://www.youtube.com/watch?v=G9dwSJHwprU

Qualtrics는 미국의 Experience Management 회사입니다. 고객, 임직원, 브랜드와 제품의 experience gap을 가깝게 하는데 도움을 주는 기술을 개발하며, XMOS (Experience Operating System) 을 통해 gap을 식별하고, 집중해야 하는 것과 해야 할 일을 알게 되며, 궁극적으로는 다양한 활동을 통해 문화를 만들게 됩니다.

Qualtrics는 이러한 일들에 Natural Language Processing, tabular 데이터에 대한 Predictive model, time-series prediction 등을 포함해서 몇 가지 ML use case들이 있습니다. NLP이 경우, 고객들이 experience를 더 잘 관리할 수 있도록 활동적인 인사이트를 제공하기 위해 수억 개의 예측 규모로 large-scale ML을 사용하고 있습니다. Tabular 데이터셋으로는 churn 예측, 분류 등을 포함해서 특정 브랜드와 고객의 데이터에 특화된 customer specific한 모델들을 개발하고 있습니다. time-series 예측과 anomaly detection에 대해서는 gap을 식별하고, 고객의 패턴을 예측하는 데 활용하고 있습니다.

Qualtrics는 이런 ML 작업을 위해 SageMaker 기반으로 구성된 Qualtrics ML Platform에서 labeling 등의 데이터 준비와 학습 및 모델 배포 과정을 수행하고 있으며, SageMaker의 Ground Truth와 Real-time Inference, Batch Transform 등을 활용합니다.

우선적으로 Qualtrics은 ML 워크로드를 수행하는데 있어서 몇가지 어려움들이 있었습니다. 이를 universal model들과 customer-specific model들로 나누어서 생각해보면 아래와 같습니다.

Challenges Encountered – Universal Models
- NLP에 사용되는 다수의 언어 모델들은 GPU를 사용하는 large-scale deep learning 모델로 복잡하고, 비용적인 부담이 발생하게 되는데, 특히 Qualtrics의 인프라는 on-premise와 AWS를 함께 사용하는 하이브리드 클라우드 환경을 사용하고 있음
- ML워크로드에 활용하는 툴들이 제각각이고, 데이터 탐색, 분석이나 온 디멘드 기반 학습 등이 어려운 제한적인 개발 환경임
- 규모에 따라 유연하게 제공하는 레이블링 툴이 없음
Challenges Encountered – Customer-Specific Models
- 고객들은 자신의 데이터와 학습 모델 등 자신들의 리소스가 다른 사람들이 활용되는 것을 원치 않기에 ML 라이프사이클의 각 단계는 고객 리소스에 대해 완벽하게 격리된 환경을 보장하는 워크플로우가 필요
- 수십, 수백, 수천 개의 모델이 구축된 다음, 고객은 각각 다른 방식으로 모델과 예측 결과에 접근하기에 다양한 로드 패턴으로 배포되고 호출하는 방법이 필요

다음 단계로 진행하기 전 SageMaker에서는 제공하는 일반적인 ML Reference Architecture를 잠깐 살펴보면 아래와 같습니다.

초기 단계에서는 데이터를 수집하고, 정제한 다음, 변환에 대해 정의를 한 후, 전처리를 거쳐서 Feature Store에 저장하게 됩니다. 다음 모델을 학습하면서 디버깅을하고, 데이터 셋 내 bias를 평가한 후, 이를 완화하고, 경우에 따라 모델 내의 bias도 평가하고 완화하는 작업을 합니다. 메트릭과 bias 관점에서 학습된 모델이 적합한 경우 이를 Model Registry에 등록합니다. 이후 모델을 선택할 수 있으며, 다양한 방식으로 모델을 배포할 수 있습니다. real-time endpoint 나 batch transform으로 제공이 가능하거나, async 방식으로 인퍼런스 수행도 가능합니다. SageMaker Monitor는 data drift또는 concept drift를 탐지하기 위해 endpoints를 모니터할 수 있고, 새로운 데이터 또는 새로운 모델 개발이 필요한 경우 Pipeline을 재시행이 가능합니다. 추가적인 요소는 코드 변경 시에 필요한 CICD 파이프라인도 구성할 수 있습니다.

조직은 다양한 어려움 부분을 해결하면서 원하는 ML Platform을 구축하기 위해 성숙도의 첫번째 단계부터 다른 단계로 가기 위해 다양한 시도와 고난, 성장통을 겪게 되었습니다. Exploring을 시작으로 Crawl, Walk, Run, Sprint로 진행되는 시간에 따라 조직의 역량과 정교함, 그리고 투자에 대한 수익이 점차 증가하게 됩니다. 이런 과정에서 well-architected framework의 5가지 pillars를 생각하면서 구성하는 것도 필요합니다. 초기 단계에서 모든 Pillar를 만족할 필요는 없습니다. 하지만, Sprint 단계에서는 각각의 Pillar가 만족스럽게 가져갈 경우에 scale을 하더라도 시스템에 대한 저하를 고민하지 않을 수 있습니다. 또한, 개발/테스트, 스테이징, Production 환경의 분리도 고려해야 합니다. Explore에서 Sprint에 이르기까지 성숙도의 여러 단계를 거치면서 개발 및 테스트, 스테이징 및 Production과 같은 여러 환경에서 이러한 작업을 수행해야 합니다. 성숙도 Curve가 올라갈 수록 이런 부분은 더욱 필요하게 되며, 환경에 대한 5개 Pillar의 성숙도도 높아져야 합니다.

Qualtrics은 성숙도 단계를 아래 일정으로 진행하고 있습니다. 현재는 Crawl과 Walk를 거쳐서 Run 단계이며, 많은 ML 시스템들에 대해 Sprint 단계를 앞두고 있습니다.

Crawl : 우선 Qualtrics 내부 인프라에서 CPU 인스턴스로 작은 모델을 production에서 운영하는 것입니다. 이 단계에서는 2가지 어려운 점이 있었습니다.
- Scalability : 필요한 throughput을 제공하는 GPU 또는 accelerator 인스턴스가 내부적으로 부족하고, 또한 예측을 위해 더욱 크고, 고품질의 모델을 배포하는 것도 어려웠음
- Time to launch : 데이터 탐색과 학습을 위한 환경이 부족하여, 모델 개발과 이를 상용화하는데 더딘 상황이였음

Walk : SageMaker를 적용하는 관점에 집중하면서, 첫 단계로 AWS SageMaker에서 모델들을 배포하였고, SageMaker 노트북과 Training job, Hyperparameter Optimization 등 학습과 데이터 분석 작업을 수행하였습니다.
- 고객에게 필요한 throughput에 도달하기 위해 managed endpoints를 통해 auto-scaling GPU가 가능한 SageMaker의 real-time inference로 모델을 배포
- SageMaker 노트북과 SageMaker Studio를 데이터 과학자들의 환경으로 제공
- SageMaker Ground Truth로 데이터에 효율적으로 레이블링 할 수 있으며, 가장 중요한 것은 데이터가 저장되는 환경과 동일한 환경에 두는 것이 가능
- Experimentation Platform으로 더 나은 모델 metrics 추적과 서로 간의 모델 벤치마크, 그리고 상용화를 위한 모델 승인 등 제공

Run : 2021년과 올해 초로 넘어가면서 Experimentation Platform에서 모델 생성, SageMaker training과 Hyperparameter Optimization, 모델 검증, production 규모로의 모델 배포 등을 위한 파이프라인을 통해 자동화되는 대규모 ML 시스템을 제공
- 모델은 작은 customer-specific model들에서 부터 큰 규모의 universal 모델까지 다양한 크기로 고객들에게 모두 서빙이 됨
- 현재 10 ~ 50개 모델을 배포하고 향후 수백에서 수천개로 확장할 계획임
- Universal 모델에 대해 상용화로 다양한 large-scale transformer 기반 모델을 배포해서 사용 중
  - 대략적인 크기로 압축 시 약 700MB 이며, Latency가 중요한 경우 실시간 inference endpoint를, Throughput이 중요한 경우 Batch transform을 사용 (둘 다 동일 code을 사용)
  - 고객들을 위해 모델을 지속적으로 개선하기 위해 Model Monitoring과 Model retraining 등의 Feedback Pipeline을 개발

- SageMaker는 수백 개의 독립적인 모델들에 대해 HPO, Training jobs, Batch Transformation, real-tim inference는 수평적으로 확장 가능

Sprint : 향후 SageMaker를 이용하여 다양한 서비스를 적용할 계획임

Qualtrics가 SageMaker를 사용한 이유는 2020년 부터 사용하면서, SageMaker는 ML 라이프사이클의 모든 분야를 다루고 있으며, AWS의 다른 서비스를 활용할 수 있도록 잘 통합되어 제공하고 있습니다. 새로운 use case를 제공할 수 있는 새로운 features를 계속 제공하여 충분히 활용 가능하고 확장이 가능합니다. 또한 SageMaker와 통합하는데 중요한 것은 AWS Team 과의 파트너십과 commitment 입니다.

[AWS-Re:invent 2021] Implementing MLOps practices with Amazon SageMaker (featuring Vanguard)

IniMiniManiMo — Tue, 4 Jan 2022 17:02:17 +0900

발표자

Shelbee Eigenbrode, Principal AI/ML Specialist SA, AWS
Ritesh Shah, Head of Architecture for Data, Analytics, and Machine Learning, Vanguard

원본 영상 : https://www.youtube.com/watch?v=fuXUi_hoK78

이 세션은 Vanguard에서 Machin Leanring의 MLOps를 구성한 사례를 얘기하고 있습니다.

이를 위해 우선 간단하게 SageMaker에서 활용할 수 있는 기능을 언급합니다. 상단에는 SageMaker native 옵션은 SageMaker의 Projects, Pipelines, Model Registry 등이 있습니다. 그리고 몇 가지 AWS 서비스와 Third-party 등 활용할 수 있는 다양한 사례와 서비스가 있습니다.

그리고,SageMaker의 MLOps-ready Capabilities는 Machine Learning에서의 어려움을 해결하는데 다양한 솔루션을 제공하고 있습니다.

1. Enabling innovation while balancing governance needs

첫번째는 데이터 과학자가 그들이 필요한 리소스를 사용할 수 있는 방법입니다. 컴퓨팅과 스토리지 등의 리소스에 접근하는 모델 개발 환경에 대해 균형 있게 IT 요구사항을 조정해야 합니다.

보안, 신뢰성, 컴플라이언스 등을 확실하게 제공하기 위해 MLOps의 구성은 everything-as-code로 제공하는 것이 유리하며, 이럴 경우 코드를 사용하여 모델 개발 활동에 대한 환경을 구성할 수 있습니다. AWS Service Catalog를 사용하게 되면 일정하고 반복적인 매커니즘을 제공하여 코드를 통해 guardraids를 가진 모델 개발 환경을 제공할 수 있습니다.

두번째는 모델 개발과 모델 배포 활동 간의 gap을 연결하는 어려움이 있습니다. 일반적으로 모델의 end-to-end의 Lineage를 추적하고 configuration을 관리하는 것으로, SageMaker의 Model Registry를 통해 모델 개발과 모델 배포 간의 간격을 줄일 수 있습니다.

다음으로 어려운 부분은 파이프라인 간의 추적성을 제공하는 것입니다. 이를 위해 CI/CD 개념을 MLOps에 적용해 볼 수 있습니다. MLOps에서는 데이터에 대한 versioning과, 모델 versioning, lineage tracking등의 ML에 좀더 특화된 요구사항을 고려해야 하며, SageMaker Projects는 이를 위해 좋은 솔루션입니다.

또 다른 어려운 부분은 time-to-market을 개선하기 위해 모델의 배포에 대한 반복적이고 일정한 프로세스를 구성하는 것입니다. 여기에는 Amazon SageMaker Projects와 Pipelines을 함께 고려해 볼 수 있습니다.

마지막으로는 Model에 대한 성능을 지속하는 방법입니다. 시간이 지날 수록 모델 성능은 떨어질 수 있으며, 이는 학습에 사용하는 데이터와 현재 데이터의 차이에서 발생합니다. 이를 data drift 또는 concept drift라고 합니다. 모델을 모니터링하는 것은 SageMaker Model Monitor 등을 통해 시스템과 전략을 가져갈 필요가 있습니다.

SageMaker가 제공하는 전반적인 MLOps-ready features들을 활용하면 위와 같이 end-to-end의 구성이 가능합니다. 데이터 준비 과정에서 정제와 변환 등 데이터의 workflow는 SageMaker Data Wrangler와 Processing Job을 이용할 수 있습니다. Pipeline의 부분으로 features에 대해 저장할 수 있으며, 이를 Training job에서 활용할 수 있습니다. 실험에 대한 정보는 SageMaker Experiments를 통해 쉽게 저장하거나 활용할 수 있으며, 이를 통해 가장 성능이 좋은 모델에 대한 결과 등을 리스트해서 볼 수 있습니다. 이후 모델을 Model Registry에 등록하게 되면, 모델에 대한 key metadata를 저장하게 됩니다. 이후 KPI에 최대한으로 만족하는 threshold를 가진모델 버전에 대해 모델을 target된 환경으로 배포가 가능합니다. 모델 배포 후에는 Model Monitor를 통해서 concept drift 또는 data drift와 같은 어떤 이슈가 있을 때 알람을 제공할 수 있습니다.

Vanguard는 1975년에 설립된 미국 펜실베니아에 위치한 투자 관리 회사입니다.

Vanguard의 ML 플랫폼을 구성하는 것은 아래 4가지의 목표로 시작을 했습니다.

Objective	Goal
데이터 과학자들이 사용하는 유용한 플랫폼을 구성하는데 시간을 줄이자	24시간 내 그들이 필요한 플랫폼을 제공
다른 어플리케이션과 서비스들에서 ML 모델을 소비할 수 있는 시간을 최소화하자	100% 모델 배포의 자동화
ML을 사용하는데 발생하는 리스크는 최소화하자	데이터 과학자나 모델러가 위험을 줄이기 위해 준수해야 하는 모든 컨트롤의 유효성 검사 자동화
플랫폼 사용에 대한 사용자 만족도를 증가시키자	사용자 만족도를 매년 10% 향상

이를 위해 첫번째 단계는 MDLC (Model Development Life Cycle)와 각 단계에서 제공해야 하는 capabilities를 정의하는 것이였습니다.

Define Problem
- 진행 : 특정 모델에 대한 owner 또는 product owner와 데이터 과학자, ML ops 엔지니어, 그리고 모델 개발에 관련된 다른 페르소나들의 full stack 팀을 구성하면서 문제에 대한 정의를 수행하였습니다.
- 구현 : Vanguard에서는 데이터 과학자들과 팀들의 상호 소통을 Chabot 기술을 이용하여 자동화하였습니다. 예를 들어, "나는 새로운 문제가 있어", 또는 "나는 새로운 팀이야" 을 남기면, Chatbot은 직접 IAM role을 셋업하게 되며, 실험, 디버깅 및 Bias와 Explanable한 정보를 얻을 수 있는 SageMaker 기능, Model registry, 필요한 다양한 서비스 등을 포함해서 MLOps capabilities를 제공합니다.
Prepare data
- 진행 : 다음은 문제를 이해하기 위해 데이터를 준비하는 과정입니다. 내부에는 여러가지 작은 단계가 있는데 데이터를 이해하거나, 데이터를 식별 또는 데이터의 gap을 확인하거나, 모델 개발을 위해 사용할 수 있는 데이터에 접근을 셋업하는 등이 있습니다. Feature Engineering을 하여 모델에 도움이 되는 feature를 구성하였습니다.
- 구현
  - 앞 단계와 동일하게 Chabot을 통해 데이터 레이크 내 접근이 필요한 S3 bucket의 IAM Role을 자동으로 업데이트합니다.
  - 팀은 Chatbot을 통해 SageMaker Studio 내 project 환경을 구성합니다.이 셋업은 CI/CD의 파이프라인의 자동화된 셋업으로 구성됩니다. 이 때 2가지 타입의 코드 저장소를 설정했습니다. 하나는 데이터 과학자들이 개발한 노트북과 학습 스크립트 코드이고, 다른 하나는 ML 엔지니어가 이후 단계에서 Endpoint 또는 batch inferences를 구성하는데 제공할 수 있는 configuration 저장소 입니다.
  - 마지막으로 다음 단계를 시작할 수 있도록 Project에 대한 최대한의 권한을 해당 Project와 관련된 Team에게 제공합니다.

Develop model
- 진행 : Prepare data와 모델 개발은 반복적인 프로세스로 진행을 하게 됩니다. 때에 따라 문제를 명확하게 이해하기 위해서는 Define Problem 단계로 돌아가기도 했습니다.
- 구현 : 데이터 과학자는 SageMaker Sutdio Notebook을 사용하고, SageMaker Processing과, EMR 또는 Athena 등의 다른 데이터 처리 스텝을 조율하기 위해 SageMaker Pipeline을 이용합니다. 반복적인 실험에 대해 Experiments 등을 활용할 수 있으며 모든 실험을 완료된 다음, Model Registry에 모델을 등록하게 됩니다. Model Registry에서는 모델을 버전별로 관리하면서 사용할 수 있습니다. 데이터 과학자는 계속해서 학습 스크립트 등을 code 저장소에 push할 수 있습니다. Vanguard에서는 AWS native container 들 보다는 알고리즘을 위해 생성한 container를 가져와서 사용합니다.
Controls toll gate
- 진행 : 모델에 대한 risk 정도를 수립하여, risk 분석을 통해 모델이 low risk인지, medium / high/ extremely high risk 인지를 식별합니다. 이 tiers에 대해 모델을 배포할 수 있기 위한 controls을 어떻게 할 것인지를 구성하였습니다.
- 구현: 모델의 owner는 Chatbot을 통해 모델을 을 개발하는 다양한 관점에서 질문에 답변하게 됩니다. 이 질문은 모델의 owner가 모델의 risk tier를 결정하느데 도움을 줍니다. Chatbot은 이를 기반으로 risk tier를 자동으로 선택하고, 생성한 SageMaker project와 Model Registry, Model에 risk tier를 tag 합니다. 전체 questionnaire는 대답에 대한 분석을 위해 S3에 저장합니다.
Deploy model
- 진행 : 코드를 검증하고, 코드가 조직 내 보안 규정에 만족해야 했으며, 코드는 사람이 배포하기 보다는 CI/CD 파이프라인을 이용하여 배포하였습니다.
- 구현: 모델에 대한 승인이 되면, CI/CD 파이프라인을 통해 자동으로 실행이 되며, 코드에 대한 보안 취약성, 코드의 품질 점검, risk tier 별 제어 확인 후에 컨테이너로 ECR에 배포하게 됩니다. production의 변경 record는 ServiceNow에 추가하고, 모델을 배포한 다음, 모엘 모니터링을 셋업합니다.
Monitor
- 진행: 파이프라인의 일부로서, 어떤 이상 또는 drift 또는 bias가 감지될 수 있도록 모델의 모니터링을 구성하고자 하였습니다.
- 구현 : Vanguard는 data drift, model quality, bias drift, feature drift 에 대해 모델 모니터링을 사용하였습니다.

SageMaker는 이를 구현하기 위해 많은 부분에 걸쳐 capabilities를 제공하고 있기에, 효과적으로 MLOps를 구성하는데 도움이 많이 됩니다. 이후 Vanguard는 Feature Store를 개선하는 부분과 Feature 관리에 대한 custom CI/CD 파이프라인을 구성하는 영역으로 확장할 계획입니다. 그리고 모니터링에 대해 endpoint외에도 batch로 확장하고, endpoint의 모니터링을 메모리/ CPU / GPU 사용량 관점에 대해 운영적인 healthness까지 고려할 계획이라고 합니다.

[AWS-Re:invent 2021] Prepare data for ML with ease, speed, and accuracy (featuring Fidelity)

IniMiniManiMo — Tue, 4 Jan 2022 12:28:15 +0900

발표자

Romi Datta, Ph.D. - SageMaker Product Management, AWS
Kiran Kandala - VP Engineering, ML & Advanced Analytics, Fidelity Investments

원본 영상 : https://www.youtube.com/watch?v=D1jD9WoYU0Y

머신 러닝에서 데이터 준비 과정은 가장 힘들 일입니다. 실제 데이터 과학자의 일 중 80% 정도는 데이터를 정제하거나, 데이터셋을 구성하는 일, 데이터를 수집하는 일 등 데이터 준비와 관련된 일이죠. 이에 대해 AWS는 4가지의 데이터 준비과정에서 발생하는 어려움을 나열하였습니다.

Time-consuming & Resource intensive
Requires Multiple tools
Data Preparation tools are typically not DevOps friendly
Common data preparation tasks require writing code

이러한 어려움을 해결하기에 앞서 Amazon SageMaker를 이용하게 되면 다음과 같이 Machine learning의 workflow에서 활용할 수 있는 구성이 가능합니다. 고객의 데이터, 알고리즘, 코드, 데이터의 feature 및 학습된 모델 weights, 인퍼런스 관련 데이터 등을 S3와 SageMaker Feature Store 등으로 저장 및 관리할 수 있으며, SageMaker의 서비스를 통해 Processing, training과 Inference까지의 전체적인 ML Pipeline 구성이 가능합니다.

이 가운데 위 어려움을 해소하기 위해 SageMaker의 Data Wrangler와 Feature Store를 활용할 수 있습니다.

Data Wranlger는 S3와 Athena, Redshift 등에서 데이터를 가져와 EDA (Exploratory Data Analysis)을 위한 Visualization과, 데이터를 학습에 활용할 수 있는 Features로 변환하는 Tool 기능을 제공하며, Data의 workflow를 구성할 수 있는 기능을 함께 제공합니다.

그리고, 이렇게 변환된 Features를 저장할 수 있는 저장소로 Feature Store를 활용할 수 있습니다.

이 세션은 Fidelity에서 활용한 SageMaker의 Feature Store에 대한 내용을 위주로 구성되어 있습니다.

SageMaker Feature Store는 다양한 데이터 소스에서 들어오는 데이터를 일관된 Feature 로 저장할 수 있도록 제공하는 저장소로서 이를 통해 여러 소스의 데이터를 재사용할 수 있도록 하며, 학습과 추론 시 사용하는 데이터의 일관성을 유지할 수 있는 기능을 제공합니다.

실시간으로 추론을 수행하는 경우 실시간으로 들어오는 데이터 소스를 Features로 전환하고, 이를 추론과 동시에 저장해야 하는 일들이 있습니다. 저장을 하는 이유는 향후 이 데이터를 다시 학습 등에 사용할 필요가 있기 때문이죠.

Online Feature Store는 각 record 식별자 별로 최신의 Feature 값을 유지하며, 15KB 페이로드에 대해 10밀리초 미만의 P95 지연 시간을 지원하는 수준으로 필요시 즉시 이 값을 활용할 수 있습니다. Offline Feature Store는 새로운 record를 계속 추가하는 방식이며, 이력 정보를 모두 저장합니다. Offline Feature Store는 write 후에는 일관성 유지를 위해 최대 15분 정도의 시간이 소요됩니다.

Fidelity Investments에서는 이 세션을 통해 Feature Store를 활용한 Architecture를 공유하고 있습니다.

전체적인 아키텍처는 데이터를 우선 실시간 추론을 위해 Online Feature Store에 저장한 다음 향후 모델 학습에 사용하기 위해 Offline Feature Store에 Sync를 하는 방식으로 사용하고 있습니다.

데이터를 batch로 ingest (put_record)하는 아키텍처를 좀 더 deep 하게 살펴보면,

데이터 소스로 부터 각 SA(Subject Area) 별로 데이터를 가져오고, 이 데이터의 메타 정보를 Manifest 파일로 구성합니다. SA는 예를 들어 계좌 (accounts), 잔고 (blances) 또는 거래 (transactions)등이 될 수 있고, 각 SA 별로는 대략 100 개 이상의 feature들이 있습니다.
SA가 저장된 S3의 위치 정보로 Manifest 파일을 생성한 다음 이를 S3에 저장하면, 저장 이벤트를 통해 SNS와 SQS를 거쳐서 Lambda에서 manifest 파일을 읽습니다.
Lambda에서는 각 SA별로 이벤트를 생성하여 병렬로 이 작업을 진행하게 됩니다.
각 SA 별로 구성된 Queue에서는 Lambda 실행하여 Step functions을 진행하게 됩니다.
그림의 1번 스텝과 같이 Step functions는 단계적으로 먼저 FeatureGroup(DB의 테이블 단위와 유사 개념) 을 구성합니다. 요청되는 feature의 스키마와 기존 FeatureGroup의 스키마가 다른 경우 FeatureGroup의 버전은 증가하게 됩니다. Fidelity의 경우는 배치 모드에서 use case별로 대략 17개의 FeatureGroup을 사용하고 있습니다.
그림의 2번 스텝에서는 상호 참조되는 ID를 표준화하는 몇가지 전처리 작업에서 Glue 서비스를 통해 진행합니다.
다음으로는 SageMaker Processing jobs을 통해 SageMaker는 S3에서 feature 데이터를 읽고, Online Feature Store에 ingest 하게 됩니다.

이 아키텍처는 SA별로 이벤트를 발생하고 병렬로 이를 처리할 수 있도록 SQS와 Lambda를 이용한 fan-off pattern을 활용하고 있기에 scalability와 configurability를 제공하고 있습니다.

실시간으로 사용하는 경우 다양한 디지털 채널을 통해 들어오는 데이터 스트림은 수백여개의 feature를 ingest 합니다. 예를 들어 클릭과 같은 스트림 등이 이에 속하게 됩니다. 이런 클릭들은 Kinesis stream을 통해 데이터를 잡아낼 수 있으며, Flink 와 EMR을 사용하여 1시간 단위의 time window에 대해 이 features들을 집계하여 제공합니다. Features들은 클릭 스트림 데이터와 페이지에 임베딩되어 있는 값들을 기반으로 생성됩니다. 이 features들은 이벤트를 통해 SQS로 전달되고, Lambda는 이 이벤트를 읽어서 Feature Store에 업데이트를 합니다. 또한, high throughput과 high performance를 위해 Lambda 사이의 멀티스레딩을 사용할 수 있습니다.

실시간 Ingestion이 완료되면 발생하는 이벤트를 이용하여 SageMaker endpoint에 추론을 요청합니다. 추론 시에 모델에서 특정 구성 파일을 읽을 수 있는 Feature Set Library를 개발하였는데, 구성 파일은 모델이 예측하는데 필요한 관련된 FeatureGroups들과 features들을 매핑하는 정보가 포함되어 있습니다. 이 Feature Set Library는 BatchGetRecord API를 이용하여 각 FeatureGroups 내의 features들을 가져오게 됩니다. 예를 들어 아래 그림과 같이 기존 Batch를 통해 구성된 FeatureGroup 1에서 4개의 features를, FeatureGroup 2에서 2개의 features를 가져오고, Real-time에서 생성된 FGr 에서 8개의 features를 가져올 수 있습니다. Event Router가 SageMaker Endpoint의 예측값을 응답 받으면, Prediction store에 저장하고, donwstream 어플리케이션은 이 결과를 notify로 받아서, 고객의 서비스에 반영하게 됩니다. Fidelity Online의 경우 사용자가 college에 대해 저장하는 옵션을 찾고 있다면, 특정 pipeline이 사용자의 의도를 식별해서 다양한 옵션을 사용자에게 표시할 수 있습니다.

모델 학습에 대해서도 Offline Feature Store를 이용하여 학습에 활용할 수 있습니다.

Fidelity는 현재 600 여개의 Subject Areas를 생성하여 사용하고 있으며, batch inference에서 백여개의 모델을 활용하고 있습니다. 향후 이 중 몇개는 real-time 모델들로 배포할 계획이라고 합니다.