Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

100% Serverless big data scale production Deep Learning System

608 vues

Publié le

- BigData Sale Deep Learning Training System (with GPU Docker PaaS on Azure Batch AI)
- Deep Learning Serving Layer (with Auto Scale Out Mode on Web App for Linux Docker)
- BigDL, Keras, Tensorlfow, Horovod, TensorflowOnAzure

Publié dans : Données & analyses
  • Hi there! Essay Help For Students | Discount 10% for your first order! - Check our website! https://vk.cc/80SakO
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • 엔지니어와 현실 사이에서 많은 고민이 있었을 것 같습니다. 좋은 강연 감사합니다.
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

100% Serverless big data scale production Deep Learning System

  1. 1. SSG.COM 김훈동 100% Serverless 로 구성해 보는 BigData Scale Deep Learning AI -Production Service Use Case-
  2. 2. I am … • 김훈동 Chief Partner • 신세계 그룹 온라인 포털 SSG.COM 빅데이타파트 리더 • 스사모(Korea Spark User Group) 운영진 • Hadoop, Spark, Machine Learning, Azure ML 분야 Microsoft MVP(Most Valuable Professional) • Major in BigData RealTime Analytics & NoSQL • http://hoondongkim.blogspot.kr • https://www.facebook.com/kim.hoondong
  3. 3. 오늘의 주제 Front Service & Serving Layer Public Cloud Microservice DevOps Serverless PaaS Production AI Service
  4. 4. 우리 팀이 하는 일 Substantive Expertise / Domain Knowledge / Business Strategy Math & Statistics / Data Analytics Traditional Research /Business Analytics BigData Analytics /Distributed Parallel Computing /NoSQL /DevOps & MicroServices Statistical Learning Machine Learning BigData Scale Deep Learning /Realtime Inference /Deep Learning Serving Layer Engineering Art Successful AI Project AI Production & Develop & Training & Serving Front Service For AI Tech. Infra. For AI Deep Learning
  5. 5. 차례 • Our Goal • Strategy • Tech Pyramid • Traditional Architecture • Serverless BigData + AI Architecture • Conclusion
  6. 6. Our Goal! 우리가 목표하는 것들…
  7. 7. 우리가 목표 하는 것! 1. 평균 이상 그저 그런 사이트 No! 2. First Mover 는 아니더라도, Fast Follower… 3. 국내 중상 말고…(긍정의 힘!) 4. 국내 최상 or 글로벌 중상.. 정도..
  8. 8. Strategy! 그것을 이루기 위한 전략
  9. 9. 혹자는 말한다! 1. BigData 거품론! 2. AI 거품론! 3. 그런 기술은 실제 돈을 벌어주는 기술이 아니다???
  10. 10. 지피지기(知彼知己)! 우리 경쟁사들의 기술의 위치를 줄 세워 보고 우리를 가늠해보자.
  11. 11. 1. 글로벌 선두 권 - First Mover (Google, Amazon, Alibaba, Facebook, etc) 2. 글로벌 상위권, 국내 최상위권 - Fast Follower 혹은 차별화 선두 권(Naver, Kakao, etc) 3. Local(국내) 상위권 4. Local(국내) 중위권 5. Local(국내) 하위권 Technology Comparison(예시) Web/DB/App [기본기술] BigData/NoSQL/ 샤딩DB/DataAnalytics [차별기술] 개인화/ML/DL/MAB DevOps/Microservice BigData Scale AI [고도화선도기술] (절대적인 수치는 아님. 편차 설명을 위한 주관적 예시 수치 임) 100% 100% 100% 98% 95% 100% 100% 95% 60% 98% 90% 70% - 안 중요 한 것이 아님. - 그냥 이것은 기본임. - 이걸 잘해야 하는 것은 당연한 일. - [필요조건 or 필수조건] - But, 차별요소가 아님. - 오늘 말하고자 하는것 - [충분조건의 부분집합] - 차별요소를 극대화 하 고… - 고도화 선도기술을 쉽 고 빠르게 도입해보는… - Fast Follwer 전략에 관 한 내용 임…
  12. 12. • 우리는 배고프고… (국내의 경우, 앞선 언급한 국내 2~3곳을 빼고는 해당 연구에 대한 지원이, 빠방한 곳이 거의 없다. 인력 리소스 불균형도 심하다.) • 우리는 시간도 없고… (지금 시작하는 건 Fast Follower 라기보다는, 이미 Late Follower 에 가깝다.) • 기회를 여러 번 주지도 않고… 다급한… (4차산업혁명 이야기 한지 1~2년 만에 거품론 이야기 나온다.) Tech 에 대한 위와 같은 상황은, 회사 Top Level 에서 인지해 주고, Top Down 정책이 내려오는 곳은 많지 않다… 우리는… Top Down 이 아니더라도… 우리는 기술과 도전에 대한 열정을 포기하지 않고, Try 하고자 한다. (Bottom Up 으로라도) 이 상황에 맞는 기술전략은?
  13. 13. 적은 인원과, 적은 기회와, 적은 시간으로… Fast Follow 해보기.
  14. 14. Motive 및 우리가 목표하는 것들…
  15. 15. 유통 – 국외 현황 • 유통기업들 – Amazon (챗봇)
  16. 16. 유통 – 국외 현황 • 챗봇 및 유통 플랫폼 – FaceBook (챗봇) 1-800 Flowers.com 챗봇 서비스 on FaceBook Messenger Many NLP, NLU API & Open Source Library Shopspring.com 개인화 챗봇 서비스 on FaceBook Messenger - 현재 3만4000여개의 챗봇이 구축 - 항공권 예약부터 날씨 정보를 주고받거나, 상품 구매ㆍ결제도 가능
  17. 17. 아마존 개인화 김** 로그인 박** 로그인 동일 시점 아마존 첫 페이지는 각 영역들의 순서 가 개인화 되어 있고, 해당 영역에 노출 되는 Item 도 개인화 되어 있음. 광고 위치 광고 종류 또한 다름.
  18. 18. Youtube 개인화 김** 로그인 박** 로그인 동일 시점 유튜브 첫 페이지 또한 각 영역들의 순 서가 개인화 되어 있고, 해당 영역에 노 출되는 Item 도 개인화 되어 있음.
  19. 19. YouTube Recommendation Deep Neural Networks for YouTube Recommendations Serving Layer Scalability Freshness
  20. 20. 실무 Production 에서의 Chatbot 이란? • Google Smart Reply (이메일 문의 처리) 시스템의 예 • https://arxiv.org/abs/1606.04870 • Smart Reply: Automated Response Suggestion for Email (by Google) • LSTM • 10% 정도를 커버.(2016년 기준) • Production 상황의 Pain Point 를 잘 설명. • Diversity • Scalability • 25% 가 20 token 미만 • Coherent • Response Quality • Utility • Privacy Semi-supervised Learning 방식 채용
  21. 21. 실무 Production 에서의 Chatbot 이란? • Sequential Model + Semi Supervised Learning Model 챗봇 • Smart Reply • https://arxiv.org/abs/1606.04870 • Smart Reply: Automated Response Suggestion for Email (by Google) • LSTM Semi-supervised Learning 방식 채용 • Large Scale Distributed Semi- Supervised Learning Using Streaming Approximation (by Google) • https://arxiv.org/pdf/1512.01752.pdf
  22. 22. Production 에서 중요한 것! Sample Data, Selected Feature 정교한 모델 주1회 or 일1회 모두에게 적용하는 정교 한 단일 모델 최고 정확도 VS 더 많은 Data(or 전수 Data) 에 적용하는 Simple 모델 최신성 (매 시간 or 준실시간) 개인화 모델 덜 정확해도 빠르고, 다수에게, 실시간으로…
  23. 23. Google Did! • 구글 년도 별 주요 발표 내용 년도 Google 발표 기술 OpenSource 진영 기술 2003년 GFS Hadoop HDFS 2004년 MapReduce Hadoop MapReduce 2006년 Chubby Zookeeper 2006년 BigTable HBase 2010년 Pregel Neo4J, Spark Graph-X 2010년 Dremel Spark 2011년 Tenzing Hive, Spark SQL 2012년 Spanner, F1 RDB Sharding + Kafka + Redis : RDB 분산 Scale Out 및 동기화 시스템 2013년 Omega Docker(Mesos) 2014년 Word2Vec 외 다수 Word2Vec (NLP 요소 기술) 외 다수 2015년 Tensorflow 외 다수 Tensorflow (Deep Learning Framework) 외 다수 2016년 AlphaGo, DeepQN 외 다수 복합문제를 해결하는 다수의 Deep Learning 방법론 2017년 PathNet 외 다수 PathNet(Deep Learning 학습의 진화방법) 외 다수 BigData 기술 NoSQL 기술 분산 RDB 기술 MicroService & DevOps 기술 Deep Learning & AI 기술 Deep Learning 기술 이전에 BigData, NoSQL, MicroService 등에 대한 Core 기술 경쟁력이 뛰어남.
  24. 24. Production 에서는 Model 개발 외에도 많은 부분의 Engineering Art 가 필요함. Model 개발에 소요되는 시간 및 난이도는 오히려 다른 부분에 비하여 쉬운 편.(예외도 있음) 다수 동접자 Serving Layer 나 고객의 반응을 실시간 학습 시켜 반영 하는 Realtime inference, 모델의 무중지 Rolling Upgrade 및 각종 BigData Scale Data Pipelining 은 매우 어려운 문제.
  25. 25. Google 따라하기! + 알파 + TensorFlow
  26. 26. We Did! (BigData Scale Computing)
  27. 27. We Did! (RealTime Data Analytics)
  28. 28. Amazon 따라하기! + 알파 Amazone 의 사례(for Personalized Deep Learning Approach) Large Scale Parallel Deep Learning Example • https://aws.amazon.co m/ko/blogs/big- data/generating- recommendations-at- amazon-scale-with- apache-spark-and- amazon-dsstne/ • https://github.com/am zn/amazon-dsstne
  29. 29. We Did! (BigData Scale AI) Public cloud Hadoop / NoSQL Spark / Anaconda Spark ML Mahout Sk-learn/gensim Tensorflow/CNTK TensorflowOnSpark Keras On-Premise Spark On-premise Azure Function Serverless PaaS Microservices Web/Was Web App Web App for Container Azure Batch AI PaaS App Container PaaS GPU Container Hadoop/Spark (HDInsight) Application Insight 4~5년 전 2~3년 전 최근
  30. 30. 하는 일에 단계를 밟아가고 있음! – 과거 현재 미래 • 과거를 분석 한다. (BigData Eco System Infra) • 트래킹 로그를 남긴다. • 빅데이타 수집 저장 분석을 위한 인프라를 만든다. • 빅데이타 배치로 과거 시계열 분석을 하고 시각화를 한다. • 현재에 반응 한다. (RealTime Layer / Spark Streaming / ELK) • 실시간으로 데이터 스트림을 분석한다. • FDS, 보안관제, 모니터링 등 즉각적으로 현재 상황에 대처하여 현재를 능동적으로 대비한다. • 미래를 예측 한다. (Mining / Machine Learning / Deep Learning) • 고객이 관심 갖고 있고 곧 살 것 같은 것을 추천한다. • 미래에 집행할 광고 및 제휴 채널 예산을 보다 ROI 높게 배분한다. • 발주를 예측한다. • 최적의 트럭 경로를 예측한다. • 가격을 올릴지 말지 얼마나 세일할지 최적의 가격을 예측한다. • 미래를 대비 한다. (Machine Learning / Deep Learning) • Chatbot • 자연어 활용, 이미지 활용 -> 검색 및 추천 고도화 • BigData Scale Deep Learning. • 다중 접속자를 위한 개인화 Deep Learning 서비스. • Auto Scale Out, 무중지 AI 모델의 진화 및 원순환 배포. 4~5년 전 2~3년 전 요즘
  31. 31. BigData Scale Deep Learning! Drill down~~ [차례] 1. Production Deep Learning Pain Point 2. 기존에 시도해본 방식(on-premise) 3. 최근에 시도한 방식(serverless public cloud)
  32. 32. BigData Scale Deep Learning! Drill down~~ 1. Production Deep Learning Pain Point
  33. 33. Enterprise Chatbot의 예 by SSG Top Level classifier Model #4 Sequential Classifier Model #5 사전, 일상어, CS용어, Domain용어 Word Embedding Model #1 크롤링 크롤링 크롤링 크롤링 1 -> 1 / Class N Context Manager Model #6 NER Model #7 Word2Vec, GloVe, Swivel Flow Designer Rule Manager API Manager 세션관리 Tracking Log 채널 I/F API Handling 상품 속성 Semantic Embedding Model #3 제목 태그 상품 상세 OCR Model #2 댓글 Item2Vec, Doc2Vec Item2Vec Word2Vec 속성 카테고리 Tag Item 명 속성 Tag 일반단어 N -> 1 / Class M Semantic Search Rule Base CS Bot FAQ/QNA Pair Generative Bot Flow Designer Rule Manager API Manager 일상어 Pair Extreme multiclass Wide Pair Model #9 Semantic Search Model #8 Seq2seq Model #10 크롤링 history 대화 Sequence 1 : 1 Pairs
  34. 34. 무엇이 문제 인가? - 우리는 논문을 쓰는 것이 아님. - 우리의 문제는 한두가지가 아님.
  35. 35. Enterprise Chatbot 하나의 문제 만 보더라도, 논문으로 치면, 10개 이상의 주제 영역이 결합한 복합 문제임.
  36. 36. 10개 Model 중 1개 – Model#4 (Top Intent Classifier 정확도) 예시 1. Word2Vec + CNN (Batch Normalize + Augmentation) 2. Word2Vec + LSTM 3. Word2Vec + CNN + LSTM 4. Word2Vec + Bidirectional GRU 5. Word2Vec + Bidirectional GRU + Attention Network 6. FastText 7. Glove + LSTM (BigDL on Spark Cluster) 72.30% 73.94% 72.97% 74.36% 73.15% 72.50% 75.25% 450여개 Multiple Class , Top 1 문제. 8. 다양한 Approach 의 조합 최종. 89.6% Data도 달라짐. 정제, 클린징, Argumentation, Data 원본 품질 재 정비
  37. 37. 하나의 주제를 논문 쓰듯 파고 들 어서는 안됨. 그럼 어떻게 접근해야 하는가? 그 주제에 대한 현존 State of The Art 논문 중 반년 이상 시간이 지난(구현체가 검증이 필요한 최소 기간) 알고리즘을 최소 3개 ~ 5,6개(적당) 정도를 선정하고, 빠르게 구현 -> Our 데이터로 테스트 -> 최적의 알고리즘 선정 With 검증된 DataSet 으로… Custom Parameter Tuning 각종 전처리, Data 뿔리기, 후처리
  38. 38. 빠른 구현 및 테스트 능력 중요! 적합 모델 선정 단계에서는 Keras 등 High Level Deep Learning 스킬 사용 권장 ~~~~ (for Agile…) 대용량은 어떻게? 멀티 GPU, 멀티 Host 로의 Deep Learning 확장은?
  39. 39. 그 과정을 10번 정도 거쳐야 함. 10개 문제 * 5개(State Of the Art) = 50개 정도 알고리즘 테스트
  40. 40. 하나의 Deep Learning 알고리즘은, Hyper Parameter 나 각종 옵션을, 최소 6번 정도 Test 하고 검증 하며 최적화 한다고 할때. 10개 문제 * 5개(State Of the Art) * 6개(Hyper Parameter 최적화) = 300번 정도 Deep Learning 수행
  41. 41. Deep Learning 은 고행인가? • One of the Good Score is Word2Vec + Bidirectional GRU • Tesla M40 GPU • Training Data 165만 건 • Learning Rate 0.0005 • 5 Epoch 에 50000초 = 833분 = 약 14시간 • seq2seq • Tesla K80 * 2 • 180만 건 • 약 24시간
  42. 42. • 이미지와 달리 Text NLP 등은 오픈 된 Pre training Set 이 거의 없음. • 이미지의 경우에도 실무에서는 정확도를 올리기 위해 Fine Tuning 하는 경우 가 많음. • 깊은 층의 모델로 학습시키는 경우 어마어마한 시간이 걸림. • 게다가 다양한 Model 의 Mesh Up 필요. • Live 상품갯수 500만건, 이미지 4000만 건?? 게다가 매일 매일 유입되는 수 천건의 이미지?? 매일 매일 바뀌는 수천건의 상품들…. Training 속도에 대하여
  43. 43. BigData Scale Deep Learning! Drill down~~ 2. 기존에 시도해본 방식(on-premise)
  44. 44. BigData진영 대표주자 Spark의 진화 => BigData 에서 BigData + AI 로… Spark Summit 2017 에서도 이미…
  45. 45. 우리가 해본 시도 들…
  46. 46. R on Spark 7 Machine on Spark Cluster Y축 : Elapsed Time 낮을 수록 성능 좋음. 8Core – 65GB Memory. 7 Machine. • SparkR • Sparklyr • RevoScaleR(MS R)
  47. 47. Python Machine Learning on Spark
  48. 48. Zupyter on PySPark, Zupyter on Hadoop Jupyter Notebook 도 BigData Scale 로
  49. 49. SSG.COM BigDL GPU Memory Resource 가 문제될 때는 BigData Scale Large Cluster Parallel Deep Learning Approach with BigDL • BigDL Deep Learning Job on Hadoop Yarn Manager (by Spark Job)
  50. 50. SSG.COM BigDL GPU Memory Resource 가 문제될 때는 BigData Scale Large Cluster Parallel Deep Learning Approach with BigDL • BigDL Deep Learning Text Classification
  51. 51. SSG.COM BigDL GPU Memory Resource 가 문제될 때는 BigData Scale Large Cluster Parallel Deep Learning Approach with BigDL • BigDL Deep Learning Job on Hadoop Yarn Manager (by Spark Job)
  52. 52. SSG.COM BigDL GPU Memory Resource 가 문제될 때는 BigData Scale Large Cluster Parallel Deep Learning Approach with BigDL • BigDL Deep Learning Text Classification
  53. 53. SSG.COM TensorflowOnSpark Tenosrflow 의 Legacy 를 활용한 BigData Scale Deep Learning은? • TensorflowOnSpark 수행 결과
  54. 54. BigDL vs TensorflowOnSpark
  55. 55. Batch Size에 대하여(무조건 mini Batch가 좋은가???) Sigle Host GPU vs Multi Host GPU vs Super Multi Host CPU - Single Host GPU : 64 batch size. 71초 * 22 epoch(Auto Early Stopping) = 1562 초 - Multi Host GPU : 1024 batch size. 6초 * 58 epoch(Auto Early Stopping) = 348 초 그렇다면, Super Mult Host CPU 클 러스터는?
  56. 56. 그런데… BigData Scale Deep Learning Training Batch System 으로는 적당할 것 같은데… TensorflowOnSpark 는 Parallel Inference 도 제공하지만…
  57. 57. 그런데… Parallel Inference 의 Production 에 대한 고민… 개인화는? (Not batch, On the fly Model) Model 에 즉각적인 최신성 반영은? 운영 중 즉각적인 무 중지 배포는? Auto Scale Out / Auto Scale Down 은?
  58. 58. BigData Scale Deep Learning! Drill down~~ 3. 최근에 시도한 방식(serverless public cloud)
  59. 59. 국내 상위 쇼핑몰 정도 트래픽, 요즘 트랜디한 개인화 추천 정도 하려고 해도… • 더 이상 Analytics 자체는 경쟁력이 아니다. • 더 이상 Machine Learning 자체는 진입 장벽이 아니다. • Deep Learning 은 아직까지는 경쟁력이나, 점점 툴이 막강해지고, 쉬워지고 있다. • BigData Scale Machine Learning 도 경쟁력이다. (최신성 + Big Scale + 개인화) • 더 더 어려운 문제는 Advanced Analytics 의 결과물을 개인화 하여 노출하고, 그 반응을 다 시 실시간으로 모델에 리턴 하여, 그로부터 즉각적인 선순환 시스템을 만든 것 이다. (예, 고 객 실시간 검색 히스토리, 클릭 스트림 에 반응하는 Dynamic 한 개인화 추천. 개인화 된 Dynamic Pricing 모델, Enterprise Full Stack Chatbot 등) • Machine Learning / Deep Learning 시스템에 있어서 Serving Layer 의 중요성 BigData + MicroService + DevOps + Auto Scale Out Training + Auto Scale Out Serving 은 목표 Motive 를 달성하기 위해서는, 선택이 아닌 필수
  60. 60. 국내 상위 쇼핑몰 정도 트래픽, 요즘 트랜디한 개인화 추천 정도 하려고 해도… • RDBMS -> 현존 최고 HW 로 Oracle 5 Node 로도… • MariaDB 샤딩 시스템. 수천대. Select 부하분산. • 큰 테이블 Data 는? Insert & Update 는? • NoSQL + RDBMS 샤딩(R) + RDBMS Master for (CUD) + Kafka (Message Queue for Data Sync) • 복잡한 RDBMS 로직 SQL => NoSQL 로 마이그레이션 불가??? • NoSQL + RDBMS 샤딩(R) + RDBMS Master for (CUD) + Kafka (Message Queue for Data Sync) + Redis(Memory Cache) + MicroService (Scale Out WAS for 복잡한 Business Logic 의 Application layer 처리 ) + Machine Learning/Deep Learning Training/Serving Layer Auto Scale Out Infra 구성 (예, Tensorflow Serving PaaS 혹은 flask Serverless Microservice) + 기타(Docker, DevOps…) Training Layer 와, Serving Layer 는 아키텍처가 또 다름.
  61. 61. 우리가 추가로 했던 시도 들…
  62. 62. Horovod(by uber) with Tensorflow, Keras
  63. 63. Keras Scale Up vs. Horovod Scale Out http://hoondongkim.blogspot.kr/2018/01/deep-learning-multi-host-multi-gpu_11.html
  64. 64. Deep Learning Online Inference CPU vs GPU (1 time Inference. BatchSize=1) http://hoondongkim.blogspot.kr/2017/12/deep-learning-inference-serving.html CPU Serving : 1 Machine 265 TPS GPU Serving : 1 Machine 16 TPS CPU 1000 Times Serial Execution GPU 1000 Times Serial Execution 동접 테스트
  65. 65. Deep Learning Online Inference CPU vs GPU (1 time Inference. BatchSize=1) http://hoondongkim.blogspot.kr/2017/12/deep-learning-inference-serving.html 1. Async + Auto Scale Out 을 추가! 2. 속도가 받쳐주면, Model 을 Fix 하지 않아도 된다.
  66. 66. Engineering Art! Async & Auto Scale Out for 양방향 Inference Layer! Inference Layer 가 사용자 세션 타임 내에 원순환 구조로 Online Training??? 을?
  67. 67. Engineering Art!
  68. 68. Auto Scale Out Deep Learning Training On Cloud PaaS Tensorflow + Keras + Horovod + Azure Batch AI http://hoondongkim.blogspot.kr/2018/01/deep-learning-multi-host-multi-gpu.html
  69. 69. Auto Scale Out Deep Learning Inference On Cloud PaaS • Azure Batch and Batch AI : 딥러닝 모델 트레이닝을 위한 운영 환경 • Azure Logic App : 트레이닝 모델이 변경되었음을 관리자에게 통지 • Web App for Container on Linux : AI inference 서비스의 호스팅 환경 • Azure Container Registry : 사설 도커 이미지 저장소 • Container WebHook을 사용하여 Azure Container Registry에서 Web App for Container로 Continuous Deployment 적용 • Deployment Slot : Web App for Container의 스테이징/운영 간에 전환(Swap) 을 위해서 배포 슬롯을 사용 • Azure Functions : API 를 위한 서버리스 플랫폼 • Team Service : CI/CD 를 자동화 및, DevOps. • Cosmos DB (SQL) : Scale Out Web/Was 의 상태 저장소 • Azure Storage Queue : Azure Function 간 통신 매개 • Application Insight : 게이트웨이의 성능과 사용 통계를 모니터링
  70. 70. Public cloud Hadoop / NoSQL Spark / Anaconda Spark ML Mahout Sk-learn/gensim Tensorflow/CNTK TensorflowOnSpark Keras On-Premise Spark On-premise Azure Function Serverless PaaS Microservices Web/Was Web App Web App for Container Azure Batch AI PaaS App Container PaaS GPU Container Hadoop/Spark (HDInsight) Application Insight 4~5년 전 2~3년 전 최근 Auto Scale Out / 무중지 배포 Deep Learning Training & Serving On Cloud PaaS Serverless 의 의미에 대하여 …. Azure Function, AWS lambda 만 serverless 인가?
  71. 71. Serverless Architecture 란? • 서버리스(Serverless)를 직역하자면, “서버가 없다” 라는 의미가 있습니다. 하지만, 사실상 서버가 없는 건 아닙니다. 그저, 특정 작업을 수행하기 위해서 컴퓨터를 혹은 가상머신에 서버를 설정하고, 이를 통하여 처리 하는 것이 아님을 의미합니다. • 그 대신에, BaaS (Backend as a Service) 혹은 FaaS (Function as a Service) 에 의존하 여 작업을 처리하게 됩니다. BaaS 를 제공하는 서비스 중에선, Firebase, Parse (지금은 서 비스종료 됨), Kinvey 등이 있고, FaaS 를 제공하는 서비스 중에선, AWS Lambda, Azure Functions, Google Cloud Functions 등이 있습니다. 출처 : https://velopert.com 혹자는 Serverless 에 VM과 Container 를 완벽하게 배재하고 FaaS 만을 생각하기도 하지만, Container 를 활용한 BaaS(Backend as a Service)도 Docker 등 Container 의 관리를 PaaS에 위임할 수 있는 경우, Serverless 로 보는 것이 중론 임.
  72. 72. Serverless Architecture AI Service 구성 • BaaS (Backend as a Service) • Web App : Web 및 Admin 관리 • Web App for Linux Container : Container 를 커스터마이징 할 수 있으나, Container 관리는 위임. • Azure Batch AI • Azure Batch • FaaS (Function as a Service) • Azure Function • Logic App • 기타, Serverless PaaS 및 SaaS • Cosmos DB • Application Insight • Container Registry • Conatiner Web Hook • CI/CD PaaS • Team Service • Github Enterprise Serverless Architecture ( For BigData Scale Deep Learning AI Production On Azure )
  73. 73. Auto Scale Out / 무중지 배포 Deep Learning Training & Serving On VM (for Dev/QA)
  74. 74. Auto Scale Out / 무중지 배포 Deep Learning Training & Serving On VM (for Production) Azure Web App For Linux Docker
  75. 75. Why Not Tensorflow Serving? 1.Over the GRPC 1.이를 Web Service 화 하기 위해서는 별도의 Tier 가 필요하다. 2.이에 대한 방법론은 뒤에서 다시 언급… 2.Over the Tensorflow. ( Keras , CNTK , Spark ML , BigDL, Deep Learning 4j, etc …) 1.물론 Keras 를 Serialize 및 Tensorflow Graph 로 Model Export 하고, 이를 로딩하는 Client 를 만드는 경우 Keras 를 Tensorflow Serving 하는 것이 불가능 하진 않음. 3.Tesorflow Serving is only published for Python2 1.물론 수동 빌드로 Python3에서 구동하는 것이 불가능하진 않지만… 4.Training 과 Serving 을 동시에?? 1.물론 이 시나리오는 Serving 최적화를 포기해야만 가능. 2.Scale Out 모델에서, 성능이 어느 정도 나온다면… On-premise Docker 가 아닌 Serverless PaaS 상의 자동 관리 Docker 라고 한다면, 구성이 무겁 거나 복잡한 것보다, 가볍고 단순하며, Debug가 유리한 것이 더 현실적임.
  76. 76. 챗봇 - Near RealTime Training & 무중지 Auto Scale Out Deployment
  77. 77. 성능에 대하여 … http://hoondongkim.blogspot.kr/2017/12/deep-learning-inference-serving.html
  78. 78. Conclusion! 결론!
  79. 79. 우리가 벤치마크 했던 Google • Google 의 목표 • 인공지능을 이끄는 3대 수장. 1) 제프리 힌튼 – 딥러닝 이론 전문가. 캐나다 토론토대 교수 2) 제프 딘 – 빅데이타 창시자. BigData & MapReduce 창시자 3) 데미스 하사비스 – 인공지능 전문가 및 뇌신경과학자. AlphaGo 개발자 Google (DeepMind)의 목표! 1. 지능의 비밀을 푼다. 2. 그것이 알아서 모든 걸 풀게 한다. First Mover 들은 약 AI 분야를 개척하며, 강 AI 를 지향하고 있다.
  80. 80. 강 AI 가 되기 위해서는? - 혹은 성공적인 AI 서비스를 만들기 위해서는 • 수많은 약(Weak/Narrow) AI 의 결합. • 그리고, 그로부터의 또다른 지능이 만들어 져야 함. 우리 사이트의 트래픽이 BigData 가 아니더라도…. 복수의 Model 이 Mesh Up 되는 경우… 다양한 인터넷의 데이터를 수집하고, 고객 반응에 따른 원순한 구조를 만들게 되면…
  81. 81. [1]~[3] 각 레이어의 관계는? • [1] RDB Sharding, Web, App, Front Tech… 는 기본 중에 기본. • [2] BigData, NoSQL, Microservice, Analytics 는? • [3] AI(Machine Learning, Deep Learning) 는? 각각 경쟁관계가 아님. 상호 보완 관계이고, 장단점이 극명 함. [1] RDB, Web, App [2] BigData, NoSQL Microservice, Analytics [3] AI BigData NoSQL/Spark NoSQL/ Spark Streaming/ MicroService/ RDB Sharding AI Serving 고로, 종합 예술이다! Engineering Art 다!
  82. 82. 다 직접 개발하는 것이 능사는 아니다! 집단 지성의 힘! 검증된 것들을 Mesh Up! 핵심경쟁력이 아닌 것은 빠르게 하는 것이 더 좋음…. (Open Source + Cloud PaaS) 요즘 가장 Hot 한 Develop 방식이 추구하는 것들… • No-Ops (or Dev Ops) • Scale • Low Cost • Performance
  83. 83. AI 시대에 임하는 자세! • Think Big. • 길게 보고 Plan을 세우자. • 당장의 효과에 연연하지 말자. • Bottom Up! ( Not Top Down! ) • 유행에 편승해서, 혹은 윗 분들의 지시에 의해서가 아닌, • 실무자들에 의해 기획하고, • 내부 개발자 내재화를 고려하며 개발하도록 하자. • 작게 그리고 빠르게 시작하자. • 금년에 시작한다면, 10살 수준이고, 2~3년이 지나야 15살 수준이 될 수 도 있지만, 1~2년 뒤에 시작하면, 평생 경쟁사보다 동생일 수 있음. • Mesh Up 하고, 결합 Merge 하고, 반복 개선 시키자. Serverlsee PaaS , Cloud 의 많은 기술을 응용하면, AI도 BigData 도, BigData가 결합된 AI도, INFRA, Framework 의 많은 부분을 추상화 하여, 빠른 진입이 가능하다.

×