안녕하세요 Steve Lee입니다.
금주부터 Coursera의 MLOps 신규 강좌 학습을 본격적으로 시작하게 되었습니다. 🙌
본 포스팅은 Coursera의 MLOps 특화 과정을 학습하며 정리한 정리노트입니다.
Week 1: Overview of the ML Lifecycle and Deployment
1주차는 machine learning production system의 필요성과 문제점들에 대해 빠르게 학습합니다. 차주에는 지속적으로 변화하는 데이터를 직면하는 환경에서 production system을 배포하고 강건하게 production system을 배포할 수 있는 방안에 대해 살펴봅니다 🙌
학습 목표
- Identify the
key components
of the ML Lifecycle. - Define “
concept drift
” as it relates to ML projects. - Differentiate between
shadow deployment
,canary deployment
, andblue-green deployment
scenarios in the context of varying degrees of automation. - Compare and contrast the ML modeling iterative cycle with the cycle for deployment of ML products.
- List the typical metrics you might track to monitor concept drift.
- 머신러닝 학습 주기의 핵심 요소들에 대해 살펴봅니다
- ML project와 관련된 "concept drift"를 정의합니다
- 다양한 배포 시나리오에 대해 알아봅니다
- shadow deployment
- canary deployment
- blue-green deployment
- ML Modeling 반복 주기(iterative cycle)와 ML Product 배포 반복 주기를 비교·대조합니다
- "concept drift"를 모니터링하기 위해 추적할 수 있는 일반적인 매트릭(metrics)에 대해 알아봅니다
강의 목차
강의 목차는 다음과 같습니다
- A conversation with Andrew Ng, Robert Crowe and Laurence Moroney
- The Machine Learning Project Lifecycle
- Deployment
- Graded assesment
Upgraded Lab
(* Course 이수와는 별개로 추천하는 Lab)
A conversation with Andrew Ng, Robert Crowe and Laurence Moroney
- Specialization Overview
머신러닝 모델 빌드, 배포, 관리로 이어지는 MLOps에 대한 실질적인 hands-on skill을 학습하실 수 있습니다.
'A conversation with Andrew Ng, Robert Crowe and Laurence Moroney' 시간에는 MLOps Specialization Course에 대한 전반적인 개요를 다룹니다.
특화과정에서 집중적으로 다룰 머신러닝 모델 배포(Deployment)에 대한 한 가지 사례를 살펴보겠습니다.
스마트폰을 생산하는 공장에서 생상 공정 내 Edge device가 존재한다고 가정하겠습니다.
우리는 Edge device를 통해 생산된 스마트폰의 결함을 판별하고 싶습니다. 따라서 Edge device내에 Inspection Software를 설치하고 카메라를 통해 생산된 스마트폰의 사진을 촬영합니다. 위의 그림에서와 같이 촬영된 스마트폰 사진은 API를 통해 Prediction Server로 전송됩니다. 그리고 서버(Prediction Server)에서는 생산된 스마트폰의 결함을 탐지하여(Predict) Inspection Software로 전송해줍니다. 그러면 Inspection Software의 Control Software는 생산된 스마트폰을 그대로 진행시킬지 또는 치울지 선택하게 됩니다. (결함이 있다면 생성 공정에서 제외 시기키는 방법을 생각할 수 있을 것입니다)
다음으로 스마트폰을 판별하는 머신러닝 모델에 대해 살펴보겠습니다.
입력(X)은 스마트폰 사진이 될 것입니다. 출력(Y)은 스마트폰이 결함이 있는지 없는지를 나타냅니다.
- Concept drift or Data Drift
머신러닝 모델을 실제 프로덕트에 배포하게 된다면 위와 같은 문제에 직면할 수 있습니다.
왼쪽에서 보이는 첫 번째 사진과 두 번째 사진은 모델 학습 시 사용되었던 스마트폰의 사진입니다. 왼쪽에서 보이는 첫 번째 사진에서와 같이 스마트폰에 스크래치가 없으면 정상 스마트폰이지만 두 번째 사진과 같이 스크래치가 있을 경우 불량 스마트폰으로 분류되는 것입니다. 하지만 실제 프로덕트 환경에서는 오른쪽 끝의 사진처럼 어두운 사진이 입력값으로 들어올 수 있습니다.(모델 학습시 보지 못했던 데이터가 입력 값으로 들어올 수 있는 것입니다)
이처럼 머신러닝 모델을 실제 프로덕트에 배포했을 때 입력 데이터가 다른 경우를 concept drift 또는 data drift라고 합니다. MLOps Specialization Course를 통해 해당 내용들을 학습해 나가실 수 있습니다.
한편 머신러닝 프로덕트에서 머신러닝 코드(Machine Learning Code)는 머신러닝 프로젝트 코드의 일부분에 불과합니다.
PoC(Proof of Concept)에서 프로덕션 배포로 확장시키기 위해서는 여전히 많은 작업이 필요할 수 있습니다. 위의 그림에서 ML Project Code의 상당 부분에 대해 Code를 작성해야 할 수도 있습니다.
기계 학습 코드 외에도 많은 구성 요소가 있습니다. 특히 데이터 관리를 위한 구성 요소, 데이터 수집, 데이터 검증, 특징 추출 등이 있습니다.
(위의 작업들을 모두 수행하는 것이 쉽지만은 않아 보입니다... 앞으로 어떻게 해결해나가는지 학습해 나가도록 하겠습니다...!)
The Machine Learning Project Lifecycle
- Step of an ML Project
- Case study: speech recognition
- Course outline
- Connect with your Mentors and Fellow Learners on Discourse!
Step of an ML Project
The major steps in Machine Learning
Product 배포를 위한 머신러닝 생애 주기(ML project Lifecycle)는 위와 같습니다.
- Scopoing: 문제를 정의하는 단계
- Data
- 데이터에 대한 정의와 베이스라인 설계
- 데이터 레이블링 및 정리(organize)
- Modeling
- 모델 선택 및 학습
- error분석을 통한 모델 성능 검증
- Deployment
- 배포 단계
- 프로덕션으로 배포
- 모니터링 및 시스템 유지
Case study: speech recognition
Course outline
MLOps 특화과정은 앞서 살펴보았던 ML project lifecycle을 역순으로 학습합니다.
또한 과정을 통틀어 MLOps에 대해 학습합니다.
Connect with your Mentors and Fellow Learners on Discourse!
MLOps 특화과정을 수강하면서 여러 질문이 생기실 수 있습니다. 이 부분을 해소하기 위해 Discourse에서 DeepLearning.AI community를 만들었습니다.
Deployment
- Key challenges
- The Machine Learning Project Lifecycle
- Deployment patterns
- Monitoring
- Pipeline monitoring
- Wee 1 Optional References
Key challenges
머신러닝 모델 배포에 있어서 두 가지 주요한 문제들이 있습니다.
1. machine learning or statistical issues
2. software engine issue
Summary
Key challenges를 들어가기 앞서 이번 시간에 대한 요약을 하고 넘어가겠습니다.
Key challenges에서는 concept drift 및 data drift와 같은 기계 학습 또는 통계 관련 문제 중 일부를 보았습니다. 배치(batch) 또는 실시간 예측(real-time prediction) 서비스가 필요한지 여부, 고려해야 할 컴퓨팅 및 메모리 요구 사항과 같은 일부 소프트웨어 엔지니어링 관련 문제도 함께 살펴보았습니다.
concept drift 및 data drift 그리고 software engineering issue에 대해 살펴보도록 하겠습니다
머신러닝 모델 배포에 있어서 어려운 점은(challenge) 크게 두 가지입니다. 첫째, 머신러닝 또는 통계적인 이슈(machine learning or statistical issues), 둘째, 소프트웨어 엔진 이슈(software engine issue)입니다. 성공적인 배포를 위해 고려해야 할 두 가지 이슈들을 살펴보도록 하겠습니다
대부분의 배포에서 마주하는 문제는 바로 concept drift와 data drift입니다.
쉽게 말해 머신러닝 시스템이 이미 배포된 후 데이터가 변경된다면 어떻게 해야 할까요?
앞서 우리는 스마트폰 제조 과정에서 스마트폰에 스크레치가 발생하는지 탐지하는 학습 모델을 살펴봤습니다.
모델을 학습시킬 때는 조명이 밝았었는데 공장에 이상이 발생하여 조명이 어두워진다면 어떤 일이 발생할까요?
이러한 사례가 바로 data drift 사례입니다.
다음으로 Software engineering issues입니다.
소프트웨어 엔지니어링과 관련된 이슈로는 위와 같은 요소들이 있습니다.
- 머신러닝 모델을 배포할 때, Realtime(실시간)으로 배포할 것인지 또는 Batch(배치 단위)로 배포를 할 것인지에 대한 고려
- Cloud 환경에 배포를 할 것인지 Edge/Browser로 배포를 할 것인지에 대한 고려
- 컴퓨팅 리소스는 얼마나 사용할 것인지에 대한 고려
- 모델 응답 지연 시간은 얼마나 고려해야하는지, query 시간에 대한 throughput(처리량)에 대한 고려
- Logging: 최대한 많은 데이터를 고려하면 좋음
- 보안 및 privacy를 어떻게 고려해야 할지
등 다양한 이슈들을 고려해야 합니다
The Machine Learning Project Lifecycle
Deployment patterns
다음으로 Deployment pattern에 대해 알아보도록 하겠습니다.
개인적으로 1주차 강의에서 흥미로웠던 파트로 기억이 됩니다.
머신러닝 모델을 학습시킬 때, 배포를 하기 위한 최선의 방법은 모델을 작동시키고 모델이 최선을 다해 결과를 도출해주기를 기다리는 것이 아닙니다.
머신러닝 모델을 학습시킬 때 우리는 모델이 최선을 다해 최적의 결과값을 도출해줬으면 하는 바램일 것입니다. 하지만 모델이 잘못되면 어떻게 될까요?
머신러닝 시스템을 배포하기 위한 일반적인 사용 사례부터 사용 사례에 따른 배포 방법 등 다양한 패턴이 있습니다. 이번 시간에는 머신러닝 모델을 배포하는 다양한 패턴에 대해 학습하도록 합니다.
Shadow mode Deployment
shadow mode deployment의 목적은 학습 알고리즘이 수행되는 방식과 그것이 인간의 판단과 비교되는 방식에 대한 데이터를 수집 할 수 있도록하는 것입니다. 좋은 결정을 내리는 시스템이 이미 있고 그 시스템은 인간 검사자(human inspectors)이거나 학습 알고리즘의 이전 구현(older implementation of a learning algorithm) 일 수 있습니다.
Canary deployment
Canary Deployment에서는 초기에 트래픽의 5% 정도, 즉 전체 트래픽의 더 적은 트래픽으로 모델을 롤아웃(Roll out)하고 알고리즘이 실제 결정을 내리도록합니다. 이렇게 하면 모델이 트래픽의 작은 비율에서만 실행될 수 있으며 만에 하나 모델 알고리즘이 실수를하면 트래픽의 작은 부분에만 영향을 미치게 되기 때문에 모델의 문제를 조기에 발견할 수 있습니다.
다시말해 Canary Deployment를 사용하면 학습 알고리즘을 배포하는 공장이나 기타 상황에 지나치게 큰 결과가 발생하기 전에 문제를 조기에 발견 할 수 있습니다.
Why it is called Canary?
The History of Canary Deployments
The term “canary deployment” comes from an old coal mining technique. These mines often contained carbon monoxide and other dangerous gases that could kill the miners. Canaries are more sensitive to airborne toxins than humans, so miners would use them as early detectors.
“canary deployment ”라는 용어는 오래된 석탄 채굴 기술에서 비롯되었습니다. 광산에는 종종 일산화탄소와 광부를 죽일 수 있는 기타 위험한 가스가 포함되어 있습니다. canary는 인간보다 공기 중 독소에 더 민감하므로 광부들은 이를 초기 탐지기로 사용합니다.
Blue green deployment
용어에서와 같이 Old Version software는 Blue version, New version software는 Green version으로 이해하시면 됩니다.
Blue green deployment에서 해야하는 것은 무엇일까요?
학습자가 원하는 방식으로 라우터를 연결하여 입력 값에 대한 결정을 내릴 수 있습니다. 오래된 모델부터 최신 모델에 이르기 까지 쉽게 롤백이 가능한 장점이 있습니다.
Degress of automation
지금까지 배운 배포 전략들을 한 번에 살펴보도록 하겠습니다.
가장 왼쪽인 Human only(인간에 완전 의존적인) 방법부터 Full automation(완전 자동화?)에 이르기까지 다양한 정도가 있는 것을 확인하실 수 있습니다.
머신러닝 시스템이 우리가 설정한 기대치를 만족시키는지 어떻게 확인할 수 있을까?
Monitoring
이번 시간에는 머신러닝 시스템을 모니터링 하는 방법에 대해 살펴보도록 하겠습니다.
앤드류 응 교수님께서는 세 가지 방법을 추천해주셨습니다.
하나, 팀원들과 함께 모여앉아 가능한 모든 요소들을 고려합니다
둘, 문제를 탐지할 수 있는 few statistics/metrics를 살펴봅니다.
마지막으로 모니터링 초반에는 다양한 지표들을 살펴보는것이 괜찮다고합니다. 점차 지표들을 줄여나가면 된다고 합니다.
소프트웨어 metrics, Input metrics, output metrics의 종류는 위와 같습니다.
메트릭을 선택한 이후에는 alarm을 설정합니다.
모니터링의 핵심은 시스템 모니터링을 통해 더 심층적인 오류 분석을 수행할 수 있다는 것입니다.
따라서 모니터링을 통해 시스템 성능을 유지하거나 개선하기 위해 모델을 업데이트 할 수 있습니다.
Pipeline monitoring
그렇다면 파이프라인 모니터링을 위해서 어떤 지표를 살펴봐야할까?
다양한 지표들이 있겠지만 Software metrics, Input metrics, Output metrics 등을 모니터링 하면 좋다고 한다.
한편 머신러닝 모델에서 사용되는 데이터는 얼마나 빠르게 변화할까?
사용자 데이터는 일반적으로 느리게 변화하지만 B2B application의 데이터는 빠르게 변화하는 것을 확인할 수 있다.
Graded assessment
- Deployment
1주 차에 배운 내용을 리마인드 하는 시간입니다. 문제를 통해 지식을 점검하고 놓친 개념을 다시 한번 확인하실 수 있습니다.
Upgraded Lab
(* Course 이수와는 별개로 추천하는 Lab)
Upgraded Lab에서는 사용자의 로컬 PC에서 MLOps 파이프라인을 학습할 수 있는 Lab을 진행합니다. 현재 Upgraded Lab을 수행하지 못한 상태이기 때문에 이 부분은 실습 후 수정하도록 하겠습니다.
Wrap up (Lessons to learn)
- What is Machine Learning Production
- The ML project lifecycle
- The requirements surrounding ML infrastructure
끝으로 MLOps Specialization Course 1의 첫 주차 강의를 마무리하도록 하겠습니다.
이번 시간에는 Machine Learning Production에 대한 개요부터 ML project의 생애주기(Lifecycle)에 대해 살펴보았습니다.
Machine Learning Product를 구성하기 위해서는 Machine Learning Modeling뿐만 아니라 ML Model을 둘러싼 다양한 인프라에 대한 이해가 필요하다는 것을 확인할 수 있었습니다. 앞으로 환경 설정, 데이터 수집. 검증, Feature 추출, 학습 및 평가, 모델 서빙, 모니터링 등 다양한 인프라에 대해서 하나씩 깊이 학습해나가도록 하겠습니다.
이상으로 오늘의 포스팅을 마치도록 하겠습니다.
감사합니다. Steve Lee였습니다.
'MLOps > MLOps Specialization' 카테고리의 다른 글
[Course 1] Week 3: Data Definition and Baseline I - Define Data and Establish Baseline (0) | 2021.06.25 |
---|---|
[Course 1] Week 3: Data Definition and Baseline - Overview (0) | 2021.06.14 |
[Course 1] Week 2 - Summary Note: Select and Train a Model (0) | 2021.06.14 |
Motivation - Why did I start MLOps? (0) | 2021.06.05 |
댓글