Auto Scalable 한 Deep Learning Production 을 위한 AI Service Infra 구성
및 AI DevOps Cycle
(Feat. 10 Docker 로 1만 TPS Inference 구축해 보기)
SK Telecom / AI Center / AI Product DevOps Team
김훈동,박찬엽

We are …
• Chan Yup Park
- SK Telecom , AI Center , AI Product DevOps
Team, AI DevOps Engineer
- 툴링에 관심이 많아 docker, kubernetes의
운영/관리/배포등의 과정을 개선하는 일을
맡고 있습니다.
- R로 개발 경험을 시작해서 관련 생태계에
기여하기 위해 노력하고 있습니다.
http://hoondongkim.blogspot.kr [블로그]
https://www.slideshare.net/ssusere94328/ [슬라이드 쉐어]
https://www.facebook.com/kim.hoondong [SNS]
• Hoon Dong Kim.
- SK Telecom , AI Center , AI Product DevOps Team Leader.
- Microsoft BigData MVP(Most Valuable Professional) :
2016년 ~ 2017년
- Microsoft AI MVP(Most Valuable Professional) :
2018년 ~ 2019년
- Korea Spark User Group (스파크 사용자 모임) 운영진
https://mrchypark.github.io/[블로그]
https://github.com/mrchypark [github]

Agenda
1. Production AI Serving Infra 구성 및 방법론
2. Production AI Open Source Eco System
3. Production AI DevOps

1. Production AI Serving Infra 구성 및 방법론

Pain Point 1 – DL Serving Dilemma
• [방법1] Tensorflow Serving
• bazel 빌드 , C++ code, gRPC.
• python serving performance 좋지 않음.
• 요즘은 pytorch, mxnet 하시는 분들도 급격히 늘고 있음.
• Scikit learn 전처리 모델은?
• [방법2] Cloud PaaS
• Azure Machine learning Service , AWS SageMaker , GCP CloudML
• 3사가 다 10%가 부족한 부분이 있음.
• 매우 비쌈.
• [방법3] Flask 등을 이용한 범용 서빙 아키텍처 구성
• 빠르고 쉽게 prototype 할 수 있으나, production을 하기 위해선 험난한 Engineering Art 가 필요함.
• Python 은 너무 너무 * 10 느린 언어 임.
• [방법4] Full 사양 GPU 서버 혹은 VM 이용. Tensor-RT !!!
• 월 4만원 짜리 CPU Docker vs 월 1000만원 짜리 최신 GPU VM
• 미지원 Layer 들은 어떻게??
• Nvidia Docker 활용 시 활용성은 점점 좋아지고 있음.
• Model 종류, batch Size 갯수, 동접 Variation 패턴
• [방법5] cloud serverless + cloud NoSQL, 기타
• 초저렴, 안정적, 글로벌 스케일 트래픽
• Deep Learning 의 Output 바로 전단계 Layer 를 주로 활용.
• 차원 축소 이후 Vector Embedding Mapping , approximate KNN , Top N Cosign Similarity Item 을 Graph DB 에 넣어 네트워크 구성,
• Tensorflow.js , grpahQl, PMML

Pain Point 1 – ML Serving Dilemma
Tensorflow Serving 만 가지고는…
• ML Serving for Lots of Frameworks

Pain Point 1 – 해결 팁 1

Pain Point 1 – 해결 팁 2
초 저렴 vCPU Docker (월 4만원)
Vs
Avengers 급 GPU Docker (월
1000만원)
• [방법1] Tensorflow Serving
• bazel 빌드 , C++ code, gRPC.
• python serving performance 좋지 않음.
• 요즘은 pytorch, mxnet 하시는 분들도 급격히 늘고 있음.
• Scikit learn 전처리 모델은?
• [방법2] Cloud PaaS
• Azure Machine learning Service , AWS SageMaker , GCP CloudML
• 3사가 다 10%가 부족한 부분이 있음.
• 매우 비쌈.
• [방법3] Flask 등을 이용한 범용 서빙 아키텍처 구성
• 빠르고 쉽게 prototype 할 수 있으나, production을 하기 위해선 험난한 Engineering Art 가 필요함.
• Python 은 너무 너무 * 10 느린 언어 임.
• [방법4] Full 사양 GPU 서버 혹은 VM 이용. Tensor-RT !!!
• 월 4만원 짜리 CPU Docker vs 월 1000만원 짜리 최신 GPU VM
• 미지원 Layer 들은 어떻게??
• Nvidia Docker 활용 시 활용성은 점점 좋아지고 있음.
• Model 종류, batch Size 갯수, 동접 Variation 패턴
• [방법5] cloud serverless + cloud NoSQL, 기타
• 초저렴, 안정적, 글로벌 스케일 트래픽
• Deep Learning 의 Output 바로 전단계 Layer 를 주로 활용.
• 차원 축소 이후 Vector Embedding Mapping , approximate KNN , Top N Cosign Similarity Item 을 Graph DB 에 넣어 네트워크 구성,
• Tensorflow.js , grpahQl, PMML

초 저렴 vCPU Docker (월 4만원)
Vs
Avengers 급 GPU Docker (월 1000만원)
• 이는 마치 …
• 100 저글링 vs 20 시즈탱크 의 대결. 그 결과는?
https://youtu.be/IKVFZ28ybQs

DL Serving 에 대한 고려 사항들…
• 처리량(Throughput)
• 응답속도(Latency)
• 비용
• 개발 생산성
• Real World 에서는 DL 만 있는 것도 아님(Pandas 연산, 전처리, Scaling , Ensemble…)
• 확장성(다양한 DL 프레임워크, 다양한 최신 Model 들…)
• Real World 에서는 On-line Serving 의 경우 batch size 가 1인 경우가 많음.
• Python 의 Thread 성능은 최악 임을 고려해야 함.(대안 및 해결방법은 있음)
• 처리 속도와 정확도 간의 Trade Off (Real World 에서 BERT Model 이란…)
• 모델압축 (Quantization, Binarization, Weight Pruning, Precision Calibration, etc…)

소개 페이지에 나온 성능 그래프는
모든 상황을 반영 하진 않는다!
• 왜 항상 ResNet 가지고 비교하는가?

Real World에서 많이 쓰는 모델들은…
• GPU 에 있어서, MLP, LSTM 의 반전
자료출처 : https://cloud.google.com/blog/products/gcp/an-in-depth-look-at-googles-first-tensor-processing-unit-tpu

실제 Real World 데이타로 Inference 실험해
보자.
• Bidirectional-LSTM (1.5기가 모델)
• Bach Size = 1 , 랜덤 질의.

실제 Real World 데이타로 Inference 실험해
보자. ( CPU – serial 1000번 수행)

실제 Real World 데이타로 Inference 실험해
보자. ( GPU – serial 1000번 수행)

LSTM + Tensorlfow + Flask + CPU
1~400 동접 부하 테스트 for Inference
• 250 TPS 정도가 나와주고 있음.

LSTM + Tensorlfow + Flask + GPU
1~400 동접 부하 테스트 for Inference
• 16 TPS 정도가 나와주고 있음.
http://hoondongkim.blogspot.com/2017/12/deep-learning-inference-serving.html
상세 실험 내용은 제 블로그 참고

Deep Learning Inference
1만 TPS
Microservice 구현하기

TensorRT 를 이용하는 방법1
• TensorRT 를 이용하는 Restful API 만들기
Pytorch Code 예KERAS on Tensorflow Code 예
참고자료 : Nvidia 자료 참고

TensorRT 를 이용하는 방법2
• Flask 로 TensorRT Engine 호출하기
Flask 에서 TensorRT 엔진
로딩 ,
But, 싱글 프로세스 임.
여전히 병목 생길 수 있음.
참고자료 : Nvidia 자료 참고

Pain Point 2- Poor Python Performance

Pain Point 2 – 해결 팁
§ Pandas 를 쓰지 않는다.
-> Data Copy 과정에서의 병목.
-> Thread , Multi Process 에서 Thread Safe 하지 않음.
§ 함수형 언어 처럼 가상함수를 사용…(Data Copy 병목 줄인다.)
-> Python 에서 Map, Lambda를 : functionstools.partial
§ Python Thread 를 쓰지 않는다.
->GIL 때문에 엄청나게 느림.
-> 차라리 muti-process 가 낫다. Go 의 Goroutine 쓰듯이 쓰고자 한다면… : cotyledon
• MemoryView 활용
§ Data 핸들링 시, pointer 접근 하듯…
§ 대용량 Data Memory 복사 방지
• Microservice 로 잘게 쪼겐다.
• 모든 것은 비동기로…
• PMML + Java 컨버전…

Pain Point 2 – 해결 팁
• Nginx + Flask + WSGI + asyncIO + Tensorflow 만으로도 11529 TPS 를 달성한 바 있음. (2018년에 몇번의 Speaking 에서 사례 공유 한 바 있었음)
• 그러나, 위 조합이 가능하려면,Data 가 Function 에
전달 되는 모든 과정을 제거 해야만 가능.
• Python 의 순수가상함수 개념이 약함..
• 함수에 데이타 전달 시, Memory Copy
가 되면, 병목 발생.
• Singleton Pattern
• Member 변수 설정으로만도 효과가 보여 짐.
• 단, init 함수 밖, 전역 변수 설정은, Process가
경합하고, OS 한계의 Resource Limit 근접 시
Recent Process 에 의해, 메모리가 해제 됨.
• 다시 메모리가 설정될 때까지 Hang 현상 있음.
• 이 이유 때문에, Production 에서는
NginX + Flask + WSGI + 대용량 Data Function
조합은 안정적이지 못함.
• [대안] 속도를 50~60% 포기하고, 성능은 낮아지지만, 안정성이 좋은 gunicorn 을 써 왔었음.
• 극복 방법 없을까?

Pain Point 2 – 해결 팁
• 4 CPU * 10 Docker on Cloud
• 1.5GB LSTM Tensorlfow NLP 모델 실시간 Serving (batchsize = 1)
• 랜덤 쿼리 (캐쉬 의미 없음)
• Deep Learning Inference 1만 TPS 구현해 보기.
• NginX + ASGI + FastAPI + {asyncio + aiohttp + tornado} : 비동기는 ( pooling < streaming < web hook )
• Pandas 걷어내기, MemoryView 활용하기.
• Distributed Shared Session으로 Redis 사용.
• 여전히 함수에 큰 Data 전달은 병목 야기.
• 단순 전역 변수 사용은 Hang 현상에 매우 취약.
• Python Singleton Pattern with decorator
• Thread Safe Lazy initialization + Double checked Locking
• WSGI -> ASGI 가 큰 도움이 됨.
• 그러나, Hang 현상은 다양한 곳에서 발생. Low Level Debug 필요.
• cProfile , kCacheGrind, memory_profiler

2. Production AI Open Source Eco System

Pandas UDF
• Pandas : Poor Python Performance -> Pandas UDF

Horovod (Distributed Deep Learning at Scale)

Horovod (Distributed Deep Learning at Scale)

Petastorm (BigData Scale Data Deep Learning)

Horizon (Deep Reinforcement Learning at Scale)
• Open Source End-To-End Large-scale RL framework By Facebook
• distributed popular deep RL algorithms training.
• workflow management.
• data preprocessing.
• feature transformation.
• counterfactual policy evaluation.
• optimized serving.
• Reinforcement Learning & Contextual Bandits.
• PyTorch for Modeling and Training.
• Caffe2 for Model Serving.
• https://reagent.ai/
• https://github.com/facebookresearch/ReAgent

Horizon (Deep Reinforcement Learning at Scale)

ML WorkFlow

TFX

mlflow

mlflow

Serving at Scale

Rapids.ai
• End-to-End Data Analytics Pipeline with GPUs
• Apache Arrow , cuDF(on Spark) , cuML(like Pandas)

Clipper.ai
• low-latency prediction serving system for machine learning.
• Clipper with ML Frameworks (PyTorch, TensorFlow, XGBoost, etc.)

ONNX - Multiple ML/DL Framework Collaboration

3. Production AI DevOps

DevOps 란
• 지속적 통합과 배포
• 마이크로서비스
• 코드형 인프라스트럭쳐
• 마이크로 서비스를 위한 모니터링
• 커뮤니케이션
-> 코드형 인프라스트럭쳐까지 방법론이 성숙되면서 GitOps라는
용어도 발생
출처 : https://aws.amazon.com/ko/devops/what-is-devops/

도커가 해주는 것
• 지속적 통합과 배포
• 마이크로서비스
• 코드형 인프라스트럭쳐
• 마이크로 서비스를 위한 모니터링
• 커뮤니케이션
-> 코드형 인프라스트럭쳐까지 방법론이 성숙되면서 GitOps라는
용어도 발생
출처 : https://aws.amazon.com/ko/devops/what-is-devops/

개발자의 영역
• 지속적 통합과 배포
• 마이크로서비스
• 코드형 인프라스트럭쳐
• 마이크로 서비스를 위한 모니터링
• 커뮤니케이션
-> 코드형 인프라스트럭쳐까지 방법론이 성숙되면서 GitOps라는
용어도 발생
출처 : https://aws.amazon.com/ko/devops/what-is-devops/

슬랙?
• 지속적 통합과 배포
• 마이크로서비스
• 코드형 인프라스트럭쳐
• 마이크로 서비스를 위한 모니터링
• 커뮤니케이션
-> 코드형 인프라스트럭쳐까지 방법론이 성숙되면서 GitOps라는
용어도 발생
출처 : https://aws.amazon.com/ko/devops/what-is-devops/

이것을 위한 도구가 필요
• 지속적 통합과 배포
• 마이크로서비스
• 코드형 인프라스트럭쳐
• 마이크로 서비스를 위한 모니터링
• 커뮤니케이션
-> 코드형 인프라스트럭쳐까지 방법론이 성숙되면서 GitOps라는
용어도 발생
출처 : https://aws.amazon.com/ko/devops/what-is-devops/

자동 운영환경을 위한 kubernetes

Pod을 관리하는 상위 개념들

선언적 설정으로 인프라 관리

배포
• Azure Devops의 Pipelines의 기능을 활용

배포
• 새로운 이미지 배포를 위해 latest 태그 사용 지양

배포
• Kubectl 명령을 devops 내에서만 실행

배포
• 배포 기록 관리
• 기록 기반 롤백

환경별 변수 관리
• Library에 글로벌 변수 작성, 파이프라인 별 적용

환경별 변수 관리
• 코드 내에서는 env 호출로 사용

모델 서빙을 위한 패턴
• One fat image
• Model puller sidecar
• Attached volume

One fat image

Model puller sidecar

Attached volume

Q&A
김훈동 : https://www.facebook.com/kim.hoondong
박찬엽 : https://www.facebook.com/mrchypark