Deployment
Key Challenges
개발한 Model을 Deploy하는것은 매우 신나는 일이지만, 이 과정을 어렵게 하는 Statistical Issue 와 Software Engine Issue 라는 두가지 Key challenges 가 존재한다.
Statistical Issue
System을 deploy한 상태에서 data의 형식이 Train 할 때와 달라진다면 어떨까? 당연히 model은 degrade될것이다.
이 때 중요한 것은, Data가 어떻게 바뀌었는지 파악하고, 이에 따라 Model을 조정하거나 Data를 추가해야할 지 잘 파악하는 것이다.
Data의 변화 방식에 따라 Data Drift, Concept Drift로 나눌 수 있다.
Data Drift는 Data의 Input Distribution이 바뀌는 것이다. 예를들어 어떠한 사건, 정치인, 연예인이 사회에서 급 부상함에 따라 이전에는 없던 데이터가 대량으로 발생하는 경우가 있을 수 있다.
반면 Concept Drift는 원래 있던 x->y에 대해서 x는 변하지 않았지만 y의 값이 변하는 경우다. 예를 들어 같은 평수의 집이지만 시간이 지남에 따라 집 가격은 올라가는 경우를 생각할 수 있다.
Software Engine Issue
Prediction Service를 설계한다고 할 때, 고려할 수 있는 설계에는 여러가지가 있다. 막상 아무런 설계를 도입하는것 보다는, 몇몇 Checklist를 따져보면 올바른 결정을 하는데에 도움이 될 수 있다.
첫번째 고려사항은 Service의 Prediction이 Realtime을 요구하는가 혹은 Batch단위도 괜찮은가를 생각하는것이다.
만약 Speech Recognition같이 실시간으로 음성을 듣고 수 초 안에 응답을 주어야 한다면 당연히 Realtime이 요구될 것이다. 반대로 병원에서 환자들의 기록을 받고, 특이사항을 찾아내는 예측을 한다면 하룻밤 동안 Batch단위로 예측해도 상관없을것이다.
두번째 고려사항은 Prediction Service가 Cloud에서 동작하는지 혹은 Edge device나 Broswer에서 동작하는지다. 예를 들어 Speech Recognition 같은 경우 Cloud기반의 계산이 좀 더 빠르고 정확한 결과를 내지만, 경우에 따라 자동차의 음성인식 시스템 처럼 Edge device안에 존재할 수도 있다. 자동화 공장 같은 경우에는 Internet이 끊기는 경우가 있어도 공장을 중지하지 않기 위해 Edge device안에 구현하는것이 더 나을수도 있다.
세번째 고려사항은 Compute resources다. Model을 Train하고 Test할때는 매우 성능이 좋은 GPU환경에서 시행할 수 있지만 Deploy 후 실제 사용되는 환경은 그렇지 않을 수 있다. 이 경우에는 Model의 Complexity를 줄이거나 압축해야 할 것이다.
네번째 고려사항은 Latency, throughput(QPS) 이다. Prediction을 수행하고 유저에게 응답을 주기까지의 제한시간이나, 처리속도(Query Per Second) 등을 고려하여 알맞은 Compute resource를 선택해야한다.
다섯번째 고려사항은 Logging 이다. System을 설계하는 과정에서 가능한 한 많은 Log를 남기는 것은 추후에 Analysis 과정에서 큰 도움이 될 수 있다.
마지막으로는 Security, Privacy 이다. Service에 따라서 민감한 개인정보를 다룰 수도 있기 때문에 보안을 철저히 하고, 수집되는 Privacy Data에 대한 명시를 정확히 해야한다.
이처럼 Deployment에는 수많은 고려사항과 변동사항이 존재한다. 따라서 모델을 개발하고 Deploy했다고 Task가 끝나는 것이 아니라, Data를 바꾸고 Model을 업데이트 하는 등 지속적인 Maintenece가 필요하다.
Deployment Patterns
Deploy type중 하나는 새로운 Product/Capability를 배포하는것이다. 만약 이전에 제공된적이 없는 새로운 Product를 deploy한다면 작은 양의 Traffic으로 시작해 점진적으로 키워나가는것이 일반적이다.
두번째 이미 배포된 적이 있는 서비스를 Learning algorithm을 사용하여 자동화(automate) 하거나 돕는(assist) 경우이다. 예를 들어 공장에서 불량품을 검사하는 사람의 역할을 Learning algorithm을 통해 학습시킨 Model을 통해 자동화하거나 도울 수 있다. 중요한 점은 이전에 일하던 사람이 어떻게 Service를 Deploy할까에 대한 몇가지 option을 제공할 수 있고, 그중 하나는 Shadowmode Deployment 이다.
세번째는 이미 있는 ML system을 더 나은 system으로 교체하는 경우이다.
이런 Type들에서 볼 수 있는 두가지 반복적인 개념은 Gradual ramp up with monitoring 과 Rollback 이다. 처음부터 방대한 traffic을 사용하는것 보다는, 작은 양의 traffic부터 사용하며 monitoring하고, 점진적으로 traffic을 늘려 나간다. 그리고 만약 Algorithm이 작동하지 않는다면, 이전의 시스템으로 Rollback 하면 될것이다.
Shadow mode Deployment
예를 들어 공장에서 휴대폰 액정의 흠집을 검사하는 사람의 일을 자동화 해주는 System을 도입한다고 생각해보자. 이렇게 미리 그 일을 하는 사람이 있는 경우에 우리는 'Shadowmode Deployment'라는 Deployment pattern을 사용할 수 있다.
이는 ML system이 사람의 일을 그림자 처럼 따라하게 만들고, 사람과 함께 동시에 작동시키는 것이다.
초반에는 ML system이 어떤 결정을 내리던 작업에 아무런 영향을 주지 않게 하고 무조건 사람의 결정을 따른다.
Shadowmode Deployment은 우리로 하여금 Learning algorithm이 사람과 비교하여 어떠한 수행을 하는지에 대한 Data를 얻게해준다. 그리고 이 결과를 이용해서 Learning algorithm의 예측이 올바른지 검증함으로 System 미래에 도출할 결과를 보증할 수 있다.
위와 같이 사람이나, 혹은 기존에 존재하는 ML system을 통해 Shadowmode Deployment를 사용하는 것은 System이 상용화 되기 전에 Performance를 검증하는 아주 좋은 방법이다.
Canary Deployment
이제 Learning algorithm이 실용화되어 실제 결정을 내린다고 할 때 도움이 될 수 있는 Deployment pattern은 Canary Deployment 이다.
바로 모든 결정을 System에 맡기는 것이 아니라, 작은 범위부터 예를 들면 5%만큼만 System에게 결정을 내리게 하는것이다.
이런 방식을 사용하면 만약 System이 잘못된 결정을 내렸다고 하더라도 traffic의 작은 범위에만 영향을 미칠것이다. 이런 방식은 System을 Monitoring할 수 있는 기회를 더 많이 제공해주고, 좋은 성능을 지속적으로 낼 때 점진적으로 traffic의 퍼센트를 늘려가면 된다.
Blue Green Deployment
Blue/Green Deployment는 Input과 Model 사이에 Router 가 존재한다. Router는 Input을 Preidiction Model로 넘겨주는 역할을 한다.
Blue version은 기존에 있던 Old한 Model이고, Green version은 새로 도입하는 New model을 나타낸다.
Router는 Input을 Blue 혹은 Green으로 넘기도록 빠르게 Switching이 가능하다.
예를 들어 기존의 모델을 쓰다가 새로운 모델을 테스트하고싶으면, Router에서 경로를 바꾸어 Green으로 넘기면 된다. 그러다가 만약 Green version이 잘 작동하지 않는다는것을 알게되면, 다시 Blue version으로 Routing을 바꿀 수 있다.
이처럼 Blue Green Deployment의 장점은 재빠른 Rollback이 가능하다는 것이다. 더불어 100%의 traffic을 다 바꾸는것이 아니라, 일정한 비율만 넘기는 등 점진적인 Routing또한 가능하다.
Degrees of automation
Automation은 Deploy를 하냐 마냐에 따라서 0과 1으로 극단적으로 나뉘는 Process가 아니다.
처음엔 Shadow mode로 Learning Algorithm을 검증해보고, 판단이 유효하다고 생각되면 예측 결과가 사람들이 작업하는데에 참고할 수 있도록 도움을 줄 수 있다.
거기서 더 나아가 traffic의 일부를 온전히 System에 맡길 수 있고, 애매한 경우는 사람에게 전달해 feedback을 받아 성능을 더 개선할 수 있다.
최종적으로는 모든 작업을 System에 맡겨 Full automation을 구현할 수도 있을 것이다.
보통 Automation process는 왼쪽에서 오른쪽으로 진행되며, 상황에 따라 최적이라고 생각되는 단계에서 멈출수도 있다.
Monitoring
Monitoring을 하는 가장 일반적인 방법은 Dashboard를 추적하는 것이다. ML system이 어떤 application이냐에 따라서 Dashboard는 다른 metric을 가진다.
따라서 어떤 것을 Monitor 해야할지 결정할때에는, 팀원들과 brainstorming을 하여 잘못될 수 있는 모든 요소들을 생각해보는 것이 좋다.
그렇게 찾은 Metric들을 통해 어디에서 문제가 일어날 수 있는지 파악할 수 있게 될 것이고, 추후에 점차 사용하지 않는 Metric들을 줄여나가면 필요한 Metric만을 사용하여 Monitoring 할 수 있다.
tracking 해야하는 Metric들의 예시 중 하나로 Software metric이 있다.
- Software metrics : Memory, Compute, latency, throughput, server load , etc...
Software metric들은 Software가 잘 작동하고 있는지에 대한 확신을 줄 수 있으며, 이미 많은 MLOps tool들은 해당 지표를 tracking해준다.
이 외에 Input의 통계적 안정성이나 Learning algorithm의 성능을 Monitor 할 수 있는 metric들을 몇개 더 생각해볼 수 있다.
- Input metrics : Avg input length, Num missing values, Avg volume, Avg brightness, etc...
Input metrics는 System으로 들어오는 Input의 Distribution 변화를 보여준다.
- Output metrics : #times return null, #times user redoes search, #times user switches to typing, CTR, etc..
Output metric은 System에서 나온 output의 변화를 보여주거나, output이 나온 후 user의 행동을 관측해서 Insight를 줄 수 있다.
Input, Output metrics는 Application마다 측정해야할것이 다르기 때문에, MLOps tool에서 따로 설정하여 추가해주어야 할 것이다.
ML modeling이 매우 반복적인 작업인 것 처럼, Deploy 또한 그렇다.
완성된 Service를 Deploy하고 Monitoring을 위한 Dashboard를 만드는것은 Deployment process의 끝이 아니라 반복의 시작에 불과하다.
System을 running 하는것은 real user data와 traffic을 수집하게 해주어 Model의 Learning algorithm이 실제 데이터에도 잘 작동하는지 Performance analysis를 할 수 있게 한다.
그리고 그 결과에 따라, 새로 Update하여 Deployment를 할지 혹은 계속 Monitoring을 할지 판단한다.
Monitoring에 적절한 metric set를 찾는것은 대게 여러번의 시도를 요구한다. 초기의 metric을 가지고 Monitoring을 하다가 예상치 못한 문제가 발생하면 기존의 Metric을 추가/제거 하는 과정을 거칠것이다.
해당 과정을 거쳐 metric set를 정하게 되면 다음으로 할 일은 Threshold를 정하는 것이다.
어떠한 Metric에 Threshold 알람이 울리는지를 통해 어느 부분에서 문제가 발생했는지 보다 쉽게 파악하여 다시 돌아가 좀 더 깊은 Error analysis를 수행할 수 있다.
Pipeline Monitoring
많은 AI system은 Prediction service를 위해 단 한개의 Model을 가지고 있지 않다. 대신, multiple step의 pipeline을 가지고 있다.
예를 들어 핸드폰에서의 음성 인식 시스템은 Audio -> Speech Recognition -> Transcript 의 단순한 구조를 가지고 있지 않다.
사용자가 목소리를 내면 VAD(Voice Activity Detection module)가 핸드폰 마이크에 목소리가 들리고 있는지 판단한 후 Cloud서버 내에 있는 Speech Recognition Model에 해당 음성 파일을 잘라서 전송한다.
이처럼 VAD, Speech recognition 모두 Learning algorithm을 이용한 Module로 구성이 되어있을 때, 만약 첫번째 module을 바꾼다면 두번째 module에게도 직접적인 영향이 있을 것이다.
위와 같은 문제를 방지하고, 빨리 알아채기 위해서는 Multiple Pipeline에서의 Monitoring metric은 각각 module에 관련된 metric들과 pipeline의 전체적인 metric을 모두 포함하고 있으면 좋다.
또한 Data가 얼마나 빨리, 자주 바뀌는지에 대한 정보도 도움이 될 수 있다.
Additional References
A Chat with Andrew on MLOps: From Model-centric to Data-centric
Papers
Konstantinos, Katsiapis, Karmarkar, A., Altay, A., Zaks, A., Polyzotis, N., … Li, Z. (2020). Towards ML Engineering: A brief history of TensorFlow Extended (TFX). http://arxiv.org/abs/2010.02013
Paleyes, A., Urma, R.-G., & Lawrence, N. D. (2020). Challenges in deploying machine learning: A survey of case studies. http://arxiv.org/abs/2011.09926
Sculley, D., Holt, G., Golovin, D., Davydov, E., & Phillips, T. (n.d.). Hidden technical debt in machine learning systems. Retrieved April 28, 2021, from Nips.c https://papers.nips.cc/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf