2018년 10월 10일 수요일

강화학습(Reinforcement Learning)으로 접근하는 E-commerce Dynamic Pricing 논문리뷰

요즘 취미생활중인 강화학습!
강화학습의 코딩 Deep Dive 를 하기 위한 Play Ground 를 뒤지던 중, 우리 파트, deep learning specialist 한성국파트너가 좋은 논문을 소개해 주었다.

일단, 나의 기준으로 좋은 논문
(1) Goal 이 Practical 한지,
(2) 구현 가능할 것 같은지,
(3) Goal 뿐 아니라, 구현 난이도 등에서도 현실성을 갖추고 있는지(너무 두리뭉실하게 표현하고, 많이 숨기고 있으면 탈락이다.)...

에 가중치를 높게 두고 있음을 알려둔다. (물론 저 기준은 산업계에 몸담고 있는 나의 지극히 개인적인 기준일 뿐이다. 저런 류의 Practical 한 논문 또한 Ideal 한, Research 논문을 바탕으로 그 위에 등장할 수 있으므로, 모든 Research 논문들이 결국은 뿌리이며, 진화의 시작이라 할 수 있다.)

이 논문은 아직 학술적으로는 검증된 논문이 아니다. ICLR 2019 에 제출되었으나, 아직 Review 중인, 그래서, 저자가 누구인지도 모르는 상태의 논문이기 때문이다.

하지만, 내용을 읽다 보면, 실무에서 바로 적용하기 위한 연구를 진행하였고, 그 과정에서의 시도와 결과 그리고 인사이트 등을 경험을 통해 공유하고 있음을 알수 있다. 더군다나 Tmall.com (By Taobao) 이라고 하는 걸출한 E-commerce 플랫폼 위에서 꽤 많은 양의 데이타와 기간으로 실험한 결과를 보여주고 있어, 검증 자체에도 강한 신뢰가 가는것이 사실이다.

이런류의 논문은 학술적인 가치를 논외로 치더라도, 그 실험 방법, 문제의 정의, 그리고, 그것을 적용한 결과 자체가 매우 Practical 하여, 이런류의 문제를 동일하게 Real World 에서 접근 시 매우 큰 참고가 될 수 있어서 좋다.
(아마도 저자는 Taobao 의 직원일 것이다. 꼭 그렇지 않더라도, 해당 플랫폼 위에서의 실험 자체가 Real World 를 많이 반영하고 있어서 맘에 든다.)

본론으로 들어가서 내가 읽은 부분을 요약해 보겠다.

  1. 논문 제목
    1. DYNAMIC PRICING ON E-COMMERCE PLATFORM WITH DEEP REINFORCEMENT LEARNING
  2. 논문 위치
    1. https://openreview.net/pdf?id=HJMRvsAcK7
  3. 서론부에 등장하는 타사 사례
    1. Uber 사례
      1. Uber 는 'surge' 라고 하는 dynamic pricing 전략을 구현하고 발표한바 있는데, driving time 을 늘리는데 있어 매우 큰 기여(significant impact)를 줬다고 한다.
      2. [사족] @김상우 님. 저희 예전에 쏘카에서 Reinforcement Learning 으로 dynamic Pricing 적용 시의 파급효과및 구현 가능성에 대한 대화를 잠시 나눈적 있었죠? 딱 그 모델이네요. 물론 Uber 는 다른 알고리즘을 사용했을지도 모르지만요...
      3. Chen & Sheldon (2016) 에서 소개되었다.
    2. Zara 사례 
      1. systematic 한 dynamic pricing 모델을  구현 적용하였으며, Markdown pricing strategy 에  적용.
      2. Caro & Gallien (2012) 에서 소개.
      3. [사족] Markdown은 좀 옛 방식이긴 하지만, 여전희 Off-line 등에서 Human 에 의해 직관으로 대부분 수행되고 있으며, 국내 E-commerce 에서는 이 조차도 Model 화 되지 않은 곳이 대부분이다.(2018년 현재 기준). 기술이 어렵다기 보다는 실행력이 어려운 분야가 또 이 분야일 것이다. 가격과 관련된 프로젝트는 장고를 뒤따르게 만들기도 하거니와, 책임, 위험부담 등등, 넘어서야 하는 것들이 많은, 기술 이외의 것들이 더 어려운 분야가 또 이 분야이다. Zara 방식 소개 논문이 2012년 인것으로 보아, 벌써 6년 전 이므로, Zara 는 지금 이 분야가 매우 진화 되어 있을 것으로 추측 된다.
    3. Kroger 사례
      1. Offline 에서 Dynamic Pricing 을 적용하고 개선하기 위해, Electronic price tag 를 스토어에 적용 개선 중.
      2. Nicas (2015)
      3. [사족] 매우 오래전, 벌써 3년전에 Off에서조차 이런시도를 했으니, 그때부터 Kroger 는 매우 발빠른 유통기업이었던거 같다. 현재(2018년)의 Kroger  는 Google에서 무인자동차를 하던 핵심멤버들이 나와서 창업한 실리콘벨리의 무인자동차 관련 Startup 과 제휴하여, 무인배송자동차를 통한 유통 혁명을 실험하고 있고, 아마존 월마트 못지 않게 Data 를 잘 다루는 선진적인 유통기업의 면모를 다양한 곳에서 보여주고 있다. 아니나 다를까... 2015년 부터 이런 시도를 했었넹....  
    4. Amazon.com 상품수
      1. 2017년 기준 562 million = 5억 6천 2백만 상품이 있다고 함.
    5. Wallmart.com 상품수
      1. 4.2 millon = 420만 상품이 있다고 함. ([사족] 뭐 별거 아니네....물론 온라인전용 상품 포함이 아닌 오프라인 상품 수가 저 정도라고 한다면, 말이 다르지만...)
    6. Taobao.com 상품수
      1. 2 billion = 20억 상품.
      2. ([사족] 중국이 대단한건 알고 있었지만, World Top Level 아마존이 5억 6천인데.... 2017년이라고 하더라도, China Top Level 타오바오가 20억 상품 이라뉘.... 물론 Tmall 은 이미 Global 화가 많이 진행되고는 있지만...)
    7. Amazon.com 사례
      1. Automatic Pricing System 을 만들었음.
      2. 매 15분 마다 Price를 갱신. (2016년 기준)
      3. Chen et al. (2016)
    8. 학계의 Approach 
      1. 기존연구들
        1. Statistical Learning. 
        2. price optimization.
        3. stochastic model.
        4. Bayesian dynamic pricing policies.
        5. non-parametric approaches.
      2. 위 연구들은 큰 한계가 있었음.
      3. 그 한계를 뛰어 넘는 최신 연구.
        1. MAB(multi armed bandit) 을 이용. Misra et al. (2018) 
        2. 본 논문은 MAB 를 그래서, base model 비교군으로 삼았음.
  4. 본 논문의 알고리즘 요약
    1. Dynamic Pricing Problem 을 Deep Reinforcement Learning 으로 접근.
    2. E-Commerce 플랫폼에 적용하여 evaluation. (taobao 의 Tmall.com)
    3. 주요접근 방법
      1. Markov Decision Process 를 이용한 D.P. 의 첫 논문이라고 밝힘.
        1. [사족] 이 시점 부터 AlphaGo-Lee(이세돌버전)가 강하게 떠오른다. Alphago-Lee 는 Markov Decision Process 를 활용한, Monte Carlo tree search , 그리고 마찬가지로 Deep Reinforcement Learning 이 주요 알고리즘들 중 하나이다.
      2. discrete and continuous 한 price 액션 스페이스 에서 다양한 보상 functions 을 정의.
        1. discrete pricing action model
          1. deep Q-networks (DQN) 이용.
        2. continuous pricing action model
          1. (DQN) 과 함께 Deep Deterministic Policy Gradient (DDPG) 가 이용.
      3. historical data 로부터 pre-train 모델을 적용.
        1. pre-training 의 중요성이 길게 언급되었었음.
    4. pricing period d 는 하루나 한주가 될 수 있음.
    5. 보상(reward) function 은 revenue 혹은 sales. 수익 혹은 매출로 가능하지만...
      1. 그러나 위 두 값은, 요일, 계절, 행사 및 이벤트 여부 등 다양한 외부 변수에 의하여 매우 가변적인 값이다.
      2. 그러한 값들에 독립적인 measure 가 필요.
      3. 본 논문에서는 이를 revenue conversion rate 로 칭하였고, 다음과 같이 정하였다.
        1.   dividing revenuei by uvi -> 이를 시간에 따른 변화량으로 표현.
    6. 다양한 features
      1. price features
      2. sales features
      3. customer traffic features
      4. competitiveness features
        1. [사족] 경쟁사의 동일 상품의 상태는 중요하고 상관도 높은 feature 일 수 있는데, 유일한 외부 feature 이기도 하다.
        2. [사족] 그래서, 크롤링이 동원되어야 하고, 크롤링 해서 가져올 내용은 경쟁사 가격, 행사 및 이벤트 여부, 그리고 댓글 달리는 속도(이는 조회 수를 유추 할 수 있어서...)
        3. 저자 역시 이런 언급을 했다.  
          1. The comments and the states of the similar products contribute to competitiveness features. 
  5. 실험결과
    1. Offline 결과
      1. 4만개의 서로 다른 fast moving consumer product 를 사용
      2. 60일 판매데이타 사용
        1. 59일을 가지고 pre-training 
        2. 마지막 1일을 가지고 evaluation
      3. 240만 튜플이 이용되었다.
      4. offline policy evaluation 에서 MAB 알고리즘 구현체로 LinUCB 를 사용. 이는 Deep Reinforcement Learning 을 앞도했음.
        1. MAB 는 즉각적인 reward 를 maximize 하는 경향 있음.
        2. DRL 은 long-term reward 를 maximize 하려는 경향 있음.
        3. 이는 offline 의 특성에 기인.
        4. 하지만, E-commerce 플랫폼에서는 이 optimal policy 는 적합하지 않음.이는 뒤이는 online 결과에서 입증 됨.
      5. 서로다른 accuracy 모델(error rate, rate of right estimation, etc)에서는 DRL 이 더 높은 accuracy 를 보임.
    2. Online 결과
      1.  revenue  conversion rate 와  profit conversion rate 모두 DQN 이 사람의 manual 판단을 앞도 했음.
      2. 유사 상품 그룹은 유사 결과를 보여준다는 것(a)과 DQN과 LinUCB 를(b) 그리고 다시 DQN과 DDPG 를(c) 비교하였음.
  6. 결론
    1. DDPG와 DQN 로 구현한 pricing policies는 기존의 다른 pricing policies 를 앞도하였다.
    2. markdown pricing 에 있어서도 deep reinforcement learning approach 가 기존 manual markdown pricing strategy 를 앞도하였다.
    3. 본 연구에서는 각각 개별 상품별로 pre-training 을 수행했다.
    4. 그러므로, 잘 팔리지 않는 상품에 대하여는 별도의 처리를 해주어야 하며, 이 부분은 transfer learning 및 meta learning 기법이 이용될 수 있다.
    5. 향후 promotion pricing feature 와 membership pricing fetures 를 추가할 예정이다.
    6. [사족] 본 논문은 다이나믹 프라이싱을 Markov Decision Process 를 사용하여 가장 최신의 기법인 MAB 기법보다 낳은 결과를 보여주었음을 보여주었다.
    7. [사족] 이 논문이 읽는 독자의 시각에서 크게 기여하고 있는 바는 아래 정도일 듯 한다. 내가 느낀 바 이다.
      1. Pricing 문제를 RL 로 접근함에 있어, 문제정의 그리고 접근 방법에 충실한 가이드라인을 제공하고 있다.
      2. 시간단위별 revenue conversion rate 를 가지고 reward function을 만든 부분은 간단하면서도 꽤 reasonable 한 approach 였다.
      3. 중요 feature 들을 잘 정리해주었고, 유사상품 그룹의 특성까지 실험해 주었다.
      4. 어느정도의 데이타로 어느정도의 결과에 도달하는지 가이드를 제시해 주었다. 향후 이 수치는 우리가 맞게 접근하고 있는지 가늠하는데 큰 도움이 될 수 있다.
      5. 접근한 DQN 과 DDPG 의 hyper parameter 도 제시하고 있다. 유레카~~ ^^
    8. [사족] 내가 이런류의 Practical 한 논문을 좋아하는 이유는 이를 그대로 구현해 보는 것이 최초의 Base line 모델 구축 이후 다음 2번째 혹은 3번째 시도 정도로서 매우 빠르고 유용한 접근 가이드를 제시하기 때문이다. 

2018년 8월 29일 수요일

Production Deep Learning 서비스 Pain Point 에 대한 단상 - E-Commerce Product Overview 기능을 통한 분석

요즘 해외 배송이 빨라지고 저렴해 지면서, 전자 제품 및 노트북 액서서리 등등 은 거의 Amazon 및 Alibaba 를 이용하고 있다. 특히 고가의 IT기기의 경우 국내가격대비 20% 이상 저렴한 것을 감안하면, 가격 Save 도 큰 역할을 한다. 하지만 그 무엇보다, Amazon 및 Alibaba 의 IT 기기 Search와 상품상세 view에 있어서의 site 의 편리함과 Data Driven Overview 기능의 사용성은 그 모든것을 능가하는 쐐기를 박는 요소가 아닐 수 없다.
우선 alibaba 는 IT 기기들의 경우 카테고리별로 사용자들이 주로 보는 속성들을 Quick Details 라는 메뉴로 요약해서 보여준다. 사실 이 부분만 보면 거의 98%에 가까운 확인 사항을 모두 확인 할 수 있어서, 상품상세를 모두 봐야 할 필요가 없다.

우리나라 e-commerce 의 경우 무겁고 어마어마한 크기의 카탈로그 scan 이미지를 모두 봐야 제품 상세 정보를 알수 있는 경우가 많고, 요약 속성을 제공하는 경우에도, 업자가 자체적으로 제공하여, 상품마다, 노출 위치나 항목, 요약 정보의 제공 패턴이 모두 제각각이다. 불리한 속성은 일부러 언급하지 않는 경우도 있고, 그 경우에는 어마어마한 크기의 카달로그를 죄다 뒤져야 한다.
Amazon 은 한단계 더 진화 했다. 최근 보았던 2개를 포함하여 총 3개를 비교하여 한눈에 difference 의 요약 정보를 일목 요연 하게 보여 준다.

이는 비단, 사용성과 편리함의 문제로 그치지 않는다. 상품 카테고리별로 중요한 속성이 뭔지를 아는것, 그리고 각 상품별로 그 속성의 값이 무엇인지를 아는 것은 e-commerce site 에서 어마어마한 자산일 수 있다.
일반적인 e-commerce site 의 대부분이 상품별로 제목, 상품상세 text, 카테고리, 브랜드 등만을 관리하는 것과 달리, 위 선진 site 들 처럼 각각의 대표속성, 대표 키워드 등을 관리한다는 것은 Semantic Search , 자연어 기반 챗봇 검색, 속성기반 유사도 추천, 품절 대체 추천, 기타 검색 품질 관리에 있어서도 많은 유리함을 가져다 준다. 다차원의 속성이 있으면, 모든 상품을 N차원 공간에 배치할 수도 있다. 그리고, 그런 유사 상품의 공간 백터 상 관리는, 상품별로 가격, 배송,물류 관리 등 다방명의 Data Driven Model 을 만듦에 있어, 매우 큰 기초 Data 역할을 한다. 약간의 Deep Learning NLP 를 가미하면, 상품명을 몰라도 그 상품을 수식하는 형용사 만으로도 상품을 찾아들어갈 수 있다.
최근의 e-commerce Text NLP AI use case 관련 논문들은 자연어 문장에서 단순하게 NER 만 뽑아내는 것이 아닌, NER 을 뽑아냄과 동시에 이러한 중요 속성을 함께 뽑아내는 연구가 이루어지고 있음을 보여준다. 문장중에 언급이 없어도, 성별을 찾고, 어른용을 찾는지 아이들용을 찾는지, 선물용인지 등등의 중요속성 정보를 NER 뽑아내듯, 화자 혹은 검색 사용자의 일부 단서나 나열된 keyword sequence 로부터 뽑아준다는 의미이다.
해당 논문을 몇달 전부터 구현레벨에서 검토하였는데, 역시, 구현보다 어려운것이, 그 데이타의 Training 을 위한 Input Data 가 legacy 에 존재하지 않는 다는 점이다. 요즘 내가 alibaba 나 amazon 의 저런 제품 속성 기반 Generated(or Model Managed) Overview 기능에 관심을 갖는 이유라 하겠다.
그렇다면, 해당 속성 데이타가 없다는 것은 누구의 잘못인가? 의사결정자의 잘못인가? 기획자? 전략부서? 데이타부서? AI부서? 그 누구의 잘못도 아니다. 그걸 100% 수작업으로 만들어 내려는 시도는 10년전에도 많은 기획자들이 고민했던 ROI 답 안나오는(그래서 검색 Tag 정도만 최소로 관리하는) 문제 중 하나이다. 그래서 그런것을 만들어내는 것 또한, 요즘은 Deep Learning Model 로 접근하고 있다. 혹은 Model 이 95% 정도를 자동으로 해주고, 소수의 운영자 및 알바생들이, Accuracy 점수가 낮은 순으로 정렬하여, quick 하게 eye checking 만 하면서, click, drag 가 대부분 작업이도록 하면서 supervised learning 되도록 operation 관리자 페이지를 구성하여 구성하는 사례가 선진사례에서 등장하고 있다. 즉, ROI 안나오던 작업이 AI Assist 로 인하여, ROI 가 나오는 해볼만 한 작업이 된 것이다.
하루에 수천건의 신규 상품이 들어와도 자동 분류 되고, 자동 tagging 되고, 공간상에 자동으로 꼳혀 들어가야 하고, operator 에 의한 정교화 보정 작업은 후처리 사항이며 모든것을 전수 관리할 필요가 없어졌다. 이를 프로세스화 하고 입력시점에 업체들에게 위임 할 수도 있으나, 업체는 낚시성 Tag 를 다는데 더 최적화 되어 있으며, 이는 Noise 에 해당한다. 감지된 데이타에 대한 보정 작업은, Supervised Learning, 좀더 구체적으로는 online learning 의 재료로 쓰이며, 모델 진화에 기여 한다. 그것보다 더 잘 기획된 AI 서비스는 그 과정에서, 모든 training 진화를 Operator가 죄다 하는 것이 아닌, 사용자의 반응 및 행위가 model 의 진화에 기여 하도록 UI 기획을 하는 것이라 할 수 있다.(요즘 기획자들은 그래서 Deep Learning 개념을 좀 알고 있어야 한다.)

결론을 내 보겠다.
Production AI 서비스를 하다보면,
  1. Main Problem 의 model 을 만드는 일이 사실 제일 쉬운 문제이다. 연구도 많이 되어 있고, 논문 혹은 바로 쓸 수 있는 오픈소스나 github 구현체를 찾아서 활용할 수도 있다.
  2. 그보다 어려운 부분이 다수동접처리 및 빠른 서빙, 무중지 배포, Auto Scale Out 등의 문제이다. 여기서부터는 Lab 에서 연구하지 않는 분야이고, 참고 자료가 많지 않기 때문이다. 이를 위한 방법론은 여러차례 블로깅 한 적이 있었다.
  3. 그보다 더 어려운 부분은 만드는 AI Production 서비스에 Freshness 와 personalization 을 추가하는 문제이다. Freshness 는 병렬성이 핵심이며, realtime 인입이 필요하여 kafka, spark streamming 등의 도움이 필요할 수 있으며, 람다 아키텍처가 필요하고, 요즘 스타일로는 Serverless Microservice 기술이 필요하고, kubernetess 및 docker 를 끌여들여야 할 수 있다. Personalizaion 으로 가면, 모델의 차원이 커지고, 사람별로 혹은 상품별로 Training 을 하기 위해 BigData Scale 의 Computing 과 분산 Deep Learning 을 위한 BigData 기술 연계가 동원된다. (개발 생산성과 low level tensorflow 직접 분산처리보다 더 빠른 컴퓨팅을 위해서 이기도 하거니와, 수많은 heavy pre-processing 을 위해서이기도 하다.) 이를 위한 방법론은 여러차례 블로깅 한 적이 있었다.
  4. 그보다 더 어려운 문제는 양질의 Data 를 확보하는 문제이다. 결국은 Production 직전에 혹은 직 후에 이 부분에 직면하게 된다. Garbage in Garbage out 이다. 모델에 집중하면 정확도 3% 올리는데 반년이 걸릴 수 있지만, Input Data 에 집중하면 몇달을 투자하여 정확도가 10%가 올라갈 수도 있다. 국내에 AI Production Service 를 잘하는 곳도 여기까지 와서 주저 앉는 경우가 많다. 일반적인 IT 프로젝트 처럼 오픈 이후 바로 결과를 확인 하는 습관 때문이기도 하다. AI 프로젝트는 여기서부터 시작이라고 해도 과언이 아니다. 반응을 보지 않고, 상상으로 개발한 1차 결과물보다, 실 데이타가 3달 이상 쌓인 후 이를 보면서, 2차 3차 고도화를 통해, 상상 Training Data 와 Real Input Data 간의 괴리를 줄이는 작업이 이후에 지속적으로 투자 되어야 하는데, 이를 기달리지 못하고, 초기 결과를 보고 스폰을 받지 못하여 Operation 과 이와 맞물린 관리적 고도화가 되지 못하는 AI 서비스를 주변에서 많이 보았다.
  5. 그보다 더 어려운 문제는 양질의 Data를 수작업을 통해서가 아닌 자동으로 혹은, 자동80% 수동 20% 정도로 확보하게 만드는 일이다. e-commerce 를 예를 들자면, OCR, 댓글 텍스트, 크롤링 등등 다양한 방식으로 이런한 Data 를 Generation 화 할 수 있으며, 중요속성을 뽑아내는 다양한 알고리즘이 존재한다. 하지만, 이 부분은 경험해 보니, 모델이 어려운게 아니라, 이것 자체가 또하나의 프로젝트가 되어버리는 것이 문제였다. A 프로젝트를 잘하기 위해 B 프로젝트를 또 해야 해요! 가 조직에 잘 설득되지 않는 경우가 많았다. 사실 할일도 많고, 인력도 없는데, A 프로젝트도 겨우 인력 짜내서 하는 형국에 B 는 Minor 로 치부되는 것이, 당연한 현실 일 수 있다.
  6. 그것보다 더 어려운 문제는 양질의 Data 와 이후 Production 중 보정 후 재 Training 이 사용자들에 의하여 원순환으로 알아서 진화되도록 UI를 잘 만드는 일이다. 덧붙여 이에 맞는 원순환 맞춤 관리자 페이지도 나와줘야 한다. 덧붙여 모델 자체도 원순환 training 이 가능하도록, 람다 아키텍처 및 batch training, 그리고, 무중지 online training 이 삼박자가 잘 맞게 개발되어야 한다. 아쉽지만, 이는, R&R 지옥을 뚫고 기획을 개발자가 하거나, 기획자가 개발자가 되거나 하는 정도의 Mix 된 융합 Co-Work 이 필요하며, 딱 그 만큼(정말로 개발자가 기획을 하고, 기획자가 개발하는 것 만큼이나)이나 어렵다.
오늘 언급한 Production Deep Learning 서비스의 Pain Point 에 대한 단상은 결국, 기획과 모델링과 개발의 유기적인 결합이 중요한 Key 라는 결론으로 귀결 되었다.
경험해 보건데, 현실적으로 이를 위해 제일 쉬웠던 방법은....
  1. 끊임없이 개발자나 모델러들이, 기획자를, 윗분들을 설득하고 , 또 말하고, 또 설득하고... 그 과정에서 싸우기도 하고, 장문의 편지도 많이 쓰고.. 설레발도 많이 떨고, 페이스북에 기사같은것도 막 퍼 날라주고....TT 지난한 일이지만, 그래야....느린속도로 라도 둘 간에 혹은 셋간에(경우에 따라서 넷 이상이 될 수도 있는게 현실이다. TT) 바라보는 곳이 같아지고, Over lap 되어 일하는 부분이 늘어나는 것 같다.
  2. 그리고, 그들을 설득하고, 우리들의 가장 큰 약점인 말빨에서 밀리지 않기 위해서는, 우리들도 끊임없이 문과적으로 사고하고, 비지니스도 좀 가중치를 올려주고, 기획적인 사고도 더 연습하고 더 자주해야 한다는 점이다.
  3. 기획자에게 Deep Learning 에 대한 꿈과 밝은 미래를 자주 주입해주고, 공짜 컨퍼런스 티켓도 좀 사비로라도 사서 나 시간없어서 사놓고 못간다고 하면서 좀 던져 주고, 기획자에게 패스트캠퍼스나 모두의 연구소 같은것도 좀 추천해주고.... 이것이 은근히 정말 큰 도움이 된다. 기획자가 50%를 이해하면, 회의시간이 3배 이상 줄어 들고, 서로 딴이야기를 하지 않을 확률이 200% 이상 증가하는 듯 하다. 실제 경험담이다.
  4. 위 6단계를 warter fall 로 한다는 것은 말도 안되는 일이다. 외주에 맞기고, Production 시점부터 즉, 위 6단계의 4부터 외주업체가 나간체로 내부에서 한다는 것도 말이 안되는 일이다. 물론 협력하면서 프로젝트를 한 경우는 가능할 수 있다. 결국 초반엔 첫 프로젝트는 개고생을 감수해야 할지도 모르겠다. 역시 경험담이다. 개고생한만큼 기술도, 그리고 위를 이끌어 낼려는 간절함의 동인으로 부터 야기된 설레발 능력(1에서 많이 활용되는 능력이다)도 성숙해지는 듯 하다.
  5. 성공을 한번 맞보게 하는것이 매우 중요해 보인다. 그런데 매우 초기에 빨리 맛보게 해줘야 한다. 그렇지 못한다면 자멸할 수도 있다. 이후 그것을 발판삼아야 스폰도 받고, 시간도 얻고, 인력도 얻어서, 시간을 Parallel 화 시킬 수 있다.(초기에는 누구도 기달려주는 사람이 없다.) 결국 AI 서비스는 아이에게 말을 가르치듯, 단계를 하나하나 잘 밟고, 시간 투자를 해야 하는데, 그런데 시간을 기달려주지 않는다....그렇다면, 조직에서 스폰서쉽이라도 받아서 Parallel 하게 모델들을 개발 하는게 중요하다.
요즘 박항서가 2002년도 히딩크 만큼이나 베트남에서 축구 감독으로 활약을 하고 있다. 우리나라에서 AI 하기는 우리나라 대표팀으로 월드컵 16강 가기 정도로, 생각할게 많은 듯 하다. AI와 축구는 멀티플레이어가 매우 중요한것도 닮아 있다. 그리고, 골을 넣는것도 중요하다. 결국 골을 못넣으면, 과정이 어찌 되었든 비난 받는다. 수많은 시선과 실시간으로 쏟아지는 매우 short-term 의 비판을 뚫고서도, long term 의 전략을 세우지 않으면, 본질적으로 결코 쉬운일이 아니다. 너무 log term 의 전략은 자칫 Short-term 의 비판에 나가 떨어지거나, 포기하거나, 이직하거나, 인사고과 D 맞기 십상이다. 하지만...본질적으로 우리나라는 16강 가기 위해, Long term 의 전략과 본질적인 기본기 확충을 위한 시간 투자와, 시스템의 개편과, 축구 협회의 성찰과 혁신도 필요하다.

대한민국 AI 개발자 화이팅 합시다.!!!!

2018년 1월 11일 목요일

Deep Learning Multi Host & Multi GPU Architecture #2 - Keras 를 이용한 Scale Up, Horovod 를 이용한 Scale Out 성능 비교

Deep Learning Multi Host, Multi GPU 를 사용하고, BigData Scale 데이타를 처리하며, Auto Scale Out 확장 까지 고려한 아키텍처 구성에 대하여 연재 중이다.

개요는 이곳에서 확인 가능하다. [아키텍처 주안점 및 설계를 위한 고찰 : https://hoondongkim.blogspot.kr/2018/01/deep-learning-multi-host-multi-gpu.html ]

오늘은 두번째로, High Level 딥러닝 프레임워크 인 Keras 를 이용한 GPU Scale Up. 그리고 Horovod 를 이용한 Multi Host GPU Scale Out 의 성능에 대한 비교를 해보도록 하겠다.

우선 Tensorflow 나 pyTorch 나 CNTK , Caffe2 등에서 이미 GPU 나 Host 에 대한 확장을 이미 지원하고 있는데, 이러한 실험이 무슨 의미가 있는지 의아할 듯 하여, 그 의미에 대하여 다시 언급해 보도록 하겠다.
  1. 기존 Deep Learning 프레임워크에서의 Low  Level 병렬 수행 최적화 코드를 별도로 구현해야 하는 수고를 덜 수 있다.
    1. Keras 의 경우 Multi GPU 를 지원하기 시작한지 불과 3달도 체 지나지 않았다. 2017년 10월 경 버전 2.0.9 부터 지원되기 시작했다.
    2. 하지만, Keras는 단 1줄로 Multi GPU Scale Up 이 된다. (Horovod 와 함께 Keras 를 함께 실험한 이유이기도 하다.)
  2. Multi Host 는 훨씬 복잡하다.
    1. Keras 의 경우 Multi Host 는 아직 지원하지 않는 한계가 있다.
    2. Multi GPU Scale Up 은 8 GPU 가 Max 이다. 즉, BigData Scale 확장을 위해서는 Multi Host 도 동원해야 한다.
    3. Keras등은 자체적으로는 Multi Host 를 지원하지 않는데, Multi Host 까지 최소의 노력으로 사용가능 하도록 구성하기 위해서는 tensorflowOnSpark 나 Horovod, elephas 등을 이용해야 한다. 
  3. 개발 생산성 뿐 아니라, 성능 까지 더 좋았으면 한다.
    1. Horovod (made by Uber ) 의 official 페이지에는 Horovod 개발 배경을 다음과 같이 설명하고 있다.
    2. 이런 언급도 있다.
이제 위에서 언급된 (1) 병렬 코딩에 있어서의 개발생산성 , (2) 수행 시간 단축 효과가 어느 정도 인지 확인 해 보자. (맛보기 정도의 예제이기는 하지만, 느낌을 공유 하고자 한다.)

테스트는 아래 환경에서 수행되었다.
1. GPU Scale Up Test
=> Azure DSVM Image NC-Series .
=> K80 GPU.
=> Tensorflow + Keras
2. GPU Scale Out Test
=> Azure Batch AI Cluster with NC-Series vm.
=> K80 GPU.
=> Tensorflow + Keras + Horovod + Azure Batch AI

  1. Keras 를 이용한 Multi GPU Scale Up 코드
    1. 아래 코드 1줄이면 된다.
    2. 위에서 사용한 메소드를 호출하기 위해 필요한 package import 는 아래처럼 해주면 된다.
    3. 여기서 매우매우 유의해야 할 점이 있다.
      1. Keras 는 Multi GPU 사용 시 epoch 가 나눠져서 수행되는 것과 유사하게 동작한다.
      2. 즉, Epoch 를 GPU 갯수로 나누는 코드 적용이 필요하다.
      3. 이론적으로는 이 경우 GPU 갯수가 2배가 되면, Training 속도가 2배 빨라져야 할 것이다. 그러나, 실험을 해보면 그정도 까지 개선되지는 않는다. 그것은 GPU 가 증가 시 GPU 간 Data 의 동기화 Copy 등에 부가적인 Overhead 가 소요되기 때문이다.
  2. Keras 를 이용한 Multi GPU Scale Up 성능 비교
    1. General 한  LSTM 모델이다. 실험을 위해 Training Data Size 는 줄여놓은 모델이다.
    2. GPU 1개 (NC6)
      1. 150초 정도가 소요되었다.
    3. GPU 2개 (NC6)
      1. 127초가 소요되었다.
      2. 그리고 약간 성능도 개선되었다.
      3. 이 시점의 nvidia GPU 사용량은 다음과 같다.
      4. 위 처럼 2번째 GPU 는 보편적으로 Fully 일하지는 못한다. (그러나, 모델 및 알고리즘에 따라 그 양상에는 차이가 있었다.)
    4. GPU 4개 (NC12)
      1. 82초가 소요 되었다.
      2. 성능도 좀더 향상 되었다.
      3. GPU 갯수와 성능과의 관계는 뒤에서 다시 언급 토록 하겠다.
  3. Horovod 를 이용한 Multi GPU Scale Out 코드
    1. Keras 의 Scale Up 코드 만큼 심플하지는 않지만, Horovod 의 경우도 몇줄 코드만으로 Deep Learning 을 Multi Host 로 Scale Out 가능하다. 중요한 것은 Keras와 달리 Scale Up 도 되고, Scale Out 도 된다는데 있다.
    2. import 패키지
      1. import horovod.keras as hvd
    3. horovod init 코드
      1. hvd.init()
    4. Process 당 GPU 하나씩 할당하기 위한 코드
      1. config = tf.ConfigProto()
      2. config.gpu_options.allow_growth = True
      3. config.gpu_options.visible_device_list = str(hvd.local_rank())
      4. K.set_session(tf.Session(config=config))
    5. Epoch 분산 용으로 변경
      1. EPOCH = 200.0
      2. epochs = int(math.ceil(EPOCH / hvd.size()))
    6. Optimizer 분산용으로 변경
      1. opt = optimizers.Adadelta(1.0 * hvd.size())
    7. Callbacks 추가
      1. hvd.callbacks.BroadcastGlobalVariablesCallback(0)
    8. 아래는 위 코드 Example 이다.
      1. epoch 를 본 예에서는 직접 입력하였다. 이후 Optimizer 와 Callbacks 관련 2줄만 각각 model compile 과 model fit 전에 수행해 주면 된다.
  4. Horovod 를 이용한 Multi Host Scale Out 성능비교
    1. Node 1개
      1. Jupyter 를 통해 Azure Batch AI 클러스터 위로 Training Job 을 구동하였다.
      2. Node 1개에서 166초가 소요되었다. 
    2. Node 2개
      1. Node 2개 에서 멀티 Host 모드로 수행하자 아래처럼 로그가 2번씩 찍힌다.
      2. Horovod Cluster Size 가 2가 되자 initial epoch가 200 이었지만, 각 노드별 병렬 epoch 는 100으로 줄었다.
      3. 143초로 수행시간이 단축 되었다.
    3. Node 4개
      1. Horovod 는 계속 NC6 으로도 병렬 확장 테스트가 가능하나, Keras Scale Up 과의 비교를 위해 , 이 시점에 NC12로 바꾸었다. 왜냐하면, Scale Up 의 경우 NC6 은 GPU 2개 까지밖에 지원하지 않아서, GPU 4개를 테스트하는 시점 NC12로 바꾸었었기 때문이다. 
      2. 동일한 테스트를 위해 이시점은 NC12 이미지 4대에서의 테스트 이다. 각 멀티 노드에서 GPU 는 1개씩만 사용하였다.
      3. 즉, 4 Host * 1 GPU = 4GPU 환경이다.
      4. 예상했던 것처럼 로그가 4번씩 나오고 있다.
      5. 수행속도는 89초로 줄어 들었다.
[결론]

Keras 의 Scale Up과 Horovod 의 Scale Out 모두 Epoch 를 나눠가졌다. 이런 양상은 TensorflowOnSpark 와는 조금 다른 양상이다. TensorflowOnSpark 는 Epoch 를 나눠갖지 않고, Multi Node 의 Multi Job 들이 Mini Batch 를 1/N 로 나눠 갖는다. 각 특성이 갖는 양상에 따른 차이도 그 차이점을 고려해볼만 한 주제인듯 하다.(향후 시간이 허락한다면 이 부분도 파 보도록 하겠다.)

우선 오늘 실험해본 내용의 종합 결과는 아래와 같다.


앞에서도 언급 했던 것처럼 Keras 를 사용하면, Tensorflow Backend 의 GPU Scale Up 은 우선 매우 매우 쉽다. 성능 또한, 기본적인 initial time 을 제외 하고는 어느정도 선형적인 증가를 보여 준다. 좀 더 특이한 양상이 발견되었던 점은, (적은 양의 데이타에서 특히) GPU 갯수가 늘어나자 좀더 성능이 빨리 좋아지는 양상이 발견되었다는 점이다. 이는 앙상블 효과 처럼 보인다. 그리고, 마치 가끔 Mini Batch Size 를 키웠더니, 정확도가 오히려 개선되었을 때와 비슷한 양상이다.(일반적으로 그 반대가 더 많지만...) 모든 weight 의 실시간 공유가 꼭 좋은것 만은 아니다. 4개의 독립적인 GPU 가 어느정도는 독자적인 local minigma 를 찾고, 각 GPU 가 1번씩 epoch 가 끝났을때, 지연 동기화를 하게 되면, local minigma 에 빠질 확률이 훨씬 줄어들기 때문에, 분산 지연 weight 동기화가 오히려 training 에 긍정의 효과를 준 것으로 보여진다.

Horovod 를 통한 Scale Out 형태의 GPU 확장은 예상 했던 것 처럼, Scale Up 모드보다는 무거운 연산임이 실험을 통해서도 확인 되었다. 노드 갯수가 작을때에는 Single Node 의 멀티 GPU 보다 더 느린 양상을 보였다. 이는 노드갯수가 4개 정도로 늘어나면 큰 차이가 나지 않는다. (이 곳에 언급하진 않았지만, 노드 갯수가 많아질수록 성능은 역전된다.) 즉, Horovod 시나리오는 좀더 BigData Scale Deep Learning 에 가깝다. 

Production 시스템에서 Training Data 가 쌓이고, 그 크기가 점점 커지기 시작하면, 점점 training 전에 전처리 단계에서 부터, 1대 머신의 물리 Disk 를 모두 동원해도 감당이 안될 정도로 Data가 커지는 경우가 있다. 이 경우 Scale Out 시나리오에서는 해당 노드에 간단하게 Hadoop 정도를 설치해주면, 데이타는 복수 Node 에 펼쳐져 저장되게 되고, Disk IO 는 분산되어, 훨씬 성능도 좋아진다. ( Tensorflow 의 공식 github 에는 이러한 경우를 위해hadoop 에 저장된 Training Data를 핸들링 할 수 있는 Hadoop Connector 유틸리티가 제공되고 있다. Spark Connector 도 있다. TensorflowOnSpark 는 내부적으로 해당 유틸리티를 활용하고 있다.) Data 의 크기는 크지 않지만, Disk IO 를 20~30배 이상 성능적으로 개선해보고자 할때는 Hadoop 대신에 해당 노드에 Spark 나 Tachyon (이름이 바뀌긴 했으나, original 이름으로 더 알려진) 이나, Apache ignite 를 설치하고 수행할 수도 있다.

위 실험에서도 알 수 있는것처럼, 데이타의 크기가 1대의 머신에 담을 수 있는 크기이고, GPU는 8개 미만만 사용해도 되는 수준이라고 한다면, Scale Up 이 더 유리하다. ( Deep Learning Infra 설계시 참고하기 바란다. 작은 데이타는 1Node 4GPU 가 1GPU 4Node 보다 성능이 더 좋음을 위해서 보여 준 바 있다.)

하지만, Scale Up 은 Nvidia 의 dependency 로 대부분의 Deep Learning 프레임워크들이 8개 까지만 지원하는 경우가 많다. 하지만, Scale Out 은 그런 한계를 극복 할 수 있다. Horovod 는 그래서, 1대 Node 에 GPU 를 4개씩 꼳아서 8대를 클러스터로 묶어서 수행하는 경우 Scale Up 과 Scale Out 의 성능을 동시에 활용할 수 있다. 즉, 그 경우 4*8 = 32개 GPU 를 사용할 수 있다. Keras 는 8개가 한계 이지만, Horovod 그리고, Horovod + Cloud PaaS (본 실험에서는 이 부분을 Azure batch AI 를 이용했다.) 를 사용하는 경우 수백대 이상 까지도 Node 및 GPU를 동원하여, 분산 Training 의 장점을 몇번의 클릭으로 수행 해 볼 수 있다.

Keras 는 1줄 코드 수정으로 Scale Up 이 되었지만,  Horovod 는 6~8 줄 정도의 수정이 필요하였다. 하지만, 익숙해지면, 1분안에 적용 가능한 수준이었다. 때문에, 발생산성 향상은 검증되었다고 본다.

Horovod  의 위키에는 다양한 Horovod 성능 수치 비교자료들이 존재한다. 아래는 그중에 어떤 사용자의 경험을 보여주는 성능비교 수치이다. Scale Out 이 아닌 Scale Up 의 경우에도 8개 GPU 이상일때는 Horovod 방식이 성능이 더 잘 나오는 것을 표현해주고 있다. 내가 했던 실험 데이타 또한 처음에는 Horovod 가 느리다가 Node 4개를 기점으로 역전되는 모양을 보여주었었다.

Scale Out 부분에 있어서도, 대부분의 벤치마크 자료나, 대다수의 비교 자료에서 Horovod 는 Tensorlfow 에서 자체적으로 제공하는 Parameter Server 를 활용한 방식 보다, 수행 속도 측면에서 성능이 더 잘 나오는 것을 확인 해 볼 수 있다.

즉, 성능 적인 개선도 검증되었다고 여겨진다.


개발이 훨씬 쉬워지면서 성능이 뒤쳐지지 않는다면... 아키텍처링 입장에서는 마다할 이유가 없다.


2018년 1월 3일 수요일

Deep Learning Multi Host & Multi GPU Architecture #1 - 고찰 및 구성 with tensorflow, cntk, keras, horovod, Azure Batch AI

지난번 Deep Learning Serving Layer 아키텍처 수립을 위한 고찰(http://hoondongkim.blogspot.kr/2017/12/deep-learning-inference-serving.html) 이후 , 이번에는 Deep Learning Training Layer 아키텍처 수립에 대하여도 고찰해 보았다.

아키텍처 수립에서 고려한 주요 주안점은 다음과 같다.

  1. Training 은 Fine Tuning 이 이루어지는 주기적인 Batch Training 이 있을 수 있고, 시시각각 혹은 실시간으로 수행후 바로 반영될 필요가 있는 RealTime & Online Training 이 있을 수 있다. 
    1. Online Training 은 Fine Tuning 을 하는 시나리오는 아니지만, 기존의 Fine Tuning 된 weight 값을 불러 들여, 빠르게 변경분에 대하여 반영하는 로직이다.
    2. 이 경우 부분적으로 해당 Data 로 약간의 overfit 이 발생될 소지는 있다. 하지만, 변경분 Data 는 크기가 매우 작고, 변경 분 Data 의 왜곡을 최소화 하기 위해 일정량의 랜덤 sampling 데이타를 전 class 에 대하여 부분 추출후 섞어 주는 기법을 사용, 왜곡 현상을 줄일 수 있다.
    3. RealTime Training 시나리오를 Production 에 반영하는 경우 가장 중요한 고려 점은 
      1. 긴급한 Training 변경 요건을 빠르게 수행하여 운영중 모델에 적용할 수 있는가? 그리고,
      2. 다수의 Model 관리 Operator 가 실시간적으로 Training Data 를 손보는 경우 이를 받아들일 만큼 시스템이 유연한가? 일 것이다. 
  2. 우리가 구상하는 시스템은 BigData Scale Data 를 포함하고 있다. 1대의 GPU 로는 Disk 에 담기 힘든 규모의 Large Scale Data 로 확장 가능하다.
  3. 주기적으로 수행되는 다수의 Deep Learning 모델이 Pipe Line 을 통해 구성될 수 있으며, 일정 시간안에 모두 완료되어야 한다.
  4. 일시적으로 Deep Learning 모델 프로젝트가 다수개 동시 수행되는 경우 On-Premise GPU 리소스 로는 부족한 경우도 있다. Production Batch Training 을 위해 구성한 GPU 클러스터 시스템은 내부 모델 개발의 유연한 확장에도 활용가능 했으면 한다.
  5. Multi GPU 그리고 Multi Host 를 지원하는 Deep Learning 모델을 만드는 것은 불가능하지 않지만, Tensorflow 에서는 너무 Low level 접근이 필요하고, Keras 에서는 한계가 크다. GPU Cluster 가 그런 부분을 프레임워크 레벨에서 보완해주는 아키텍처가 필요하다. (예, BigDL , TensorlfowOnSpark , Horovod , Azure Batch AI ...) 예를 든 솔루션에 대하여 뒷 부분에서 설명토록 하겠다.)
위 4번, 5번 때문에, 우리는 경험상 On-premise 보다는 Cloud 에 GPU 리소스가 존재하길 원했다. 프로젝트 시작 초기에는 모델개발에 굉장히 많은 GPU 리소스가 필요하다. 운영중에는 오픈 초기 여러번의 on-line Training  이 운영자에 의해 시시각각 수행될 수 있으며, 매 새벽 배치를 통해 fine tuning 배치가 수행될 필요도 있다. 이 경우 GPU 1대 혹은 1대의 single 머신에서 모델이 Training  되는 경우 최고의 성능에 도달하기 까지 매우 많은 시간이 소요 될 수도 있을 것이다.

이러한 이유로 우리는 아래와 같은 환경을 고려하게 되었다.
  1. 운영상의 효율성. 안정성. 모델개발 시점의 시간 및 투자비용 Save 를 위해 Cloud GPU 인프라가 효율적이다.
  2. BigData Scale Data 를 통한 Training 및 빠른 Training 퍼포먼스를 위해 GPU Cluster 구성이 필요하다.
  3. GPU 클러스터는 다양한 Deep Learning 프레임워크를 지원해야 한다.
    1. 우리가 사용하는 Deep Learning 프레임워크는 다음과 같다.
      1. Tensorflow
      2. Keras
      3. CNTK
  4. 다수의 Operator 가 관리자 페이지에서 online Training 을 동시에 여러 Job 을 수행 시킬때, 혹은 다수의 Deep Learning 모델러가 복수의 Job을 수행할때, 유연하게 자사의 GPU 클러스터가 반응할 수 있는 플랫폼이 필요했다.
우리는 이를 위해 최종 적으로 다음과 같은 사전 시스템을 구성 및 테스트 해 본 적이 있다.
  1. Hadoop + Spark + BigDL
    1. Data Pre Processing 에 강점이 크며, 기존 Machine Learning 배치와도 잘 결합 가능하다.
    2. 기존의 Spark Job 과 한몸처럼 구성이 가능하다.
    3. BigDL 이 아직은 구현된 모델이 많지 않다는 가장 큰 단점이 존재한다. 속도도 GPU 클러스터 보다는 떨어진다. 
    4. 내부에 기존 BigData 클러스터가 충분히 많고 Spark 를 중요 Machine Learning 개발 도구로 사용하는 경우 활용할 가치가 있다. (참고로 BigDL 은 Intel 이 주도하는 Open Source 이며, Spark 에 내장 라이브러리 처럼 활용 가능하다.)
    5. 이 시스템은 이미 On Premise 에 구축하여 일부 모델의 검증에 활용하고 있다. 하지만 최종 시스템으로 선정하지는 않았다.
    6. 이 시스템에 대한 경험은 아래에 블로그 했었다.
    7. http://hoondongkim.blogspot.kr/2017/08/deep-learning-text-nlp-with-spark.html
  2. Hadoop + Spark + tensorflowOnSpark
    1. 위 장점을 수용하면서 Tensorflow 를 사용할 수 있다.
    2. BigDL 과 달리 CPU 뿐 아니라 GPU 도 사용 가능하다.
    3. Tensorflow 에서 Multi GPU, Multi Host 병렬 확장을 10줄 미만의 간단한 코드 수정으로 수행할 수 있다.
      1. VGG, inception 등 널리 알려진 모델은 이미 multi gpu 및 multi host 지원이 내장 구현되어 있다. 이런 경우는 tensorflow 만 쓰거나, 혹은 high level api 를 쓰더라도 큰 문제가 되지 않는다.
      2. 그러나, 대부분의 custom 모델이거나, 특히 RNN, LSTM 의 수많은 공개된 변종 알고리즘들은 병렬성이 구현된 구현체들이 거의 존재하지 않는다.
      3. 이를 직접 병렬성 구현해 주는 것은 매우 지난한 작업이다.
      4. 즉, tensorflowOnSpark (made By Yahoo) 는 이런 부분을 보완해 주는 Deep Learning 확장 도구이다.
      5. 이 시스템은 또한 On Premise 에 구축하여 Tensorlfow 모델의 일부 검증에 활용한 바 있다. 하지만 Main Production 시스템으로 선정하지는 않았으며, Dev 및 모델링 시점에 활용하는 용도로만 사용중이다.
        1. 가장 큰 이유는 내부에 CPU 클러스터는 수천 코어 동원이 가능하지만, GPU 클러스터는 리소스가 부족하기 때문이다.
        2. Cloud 에 구성하기에도 Hadoop 및 Spark  디펜던시, 그리고, Legacy 가 Tensorlfow 보다도 훨씬 무거워, 유연한 시스템으로 사용하기에는 다소 Over Spec 인 느낌이 커보였다.
      6. 이 시스템을 아직 Production 으로 사용하지 않는 가장 큰 이유는 Keras 가 아직 완벽하게 지원되지 않고 있다는 점이다. 우리는 많은 모델을 빠르게 실험해보고 적용해 보기 위해 Keras 를 상당한 비중으로 사용중에 있다.
        1. 논문 쓸 목적이 아니라면, 그리고, Agile 한 Deep Learning Approach 를 위해서는 Keras 는 최고의 툴이다.  
      7. 이 시스템에 대한 경험 그리고 세팅 방법은 아래에 블로그 했었다.
      8. http://hoondongkim.blogspot.kr/2017/09/bigdata-distributed-deep-learning.html
  3. Tensorflow + Keras + CNTK + Horovod + Azure Batch AI
    1.  최종 아키텍처로 선정한 시스템이다.
    2. TenosrlflowOnSpark 와 마찬가지로 CPU 와 GPU 모두 사용 가능하다.
    3. Production 용 배치 프레임워크의 아키텍처로 더 적당하다.
      1. 즉, 모델 개발 및 Dev 시스템은 꼭 이 구성일 필요는 없다. 아니, Dev 시스템은 이 구성이 오히려 개발 생산성에 저해가 될 수 있다.
      2. Dev 에서는 위 1,2가 사용될 수 있다.
      3. 모델 개발 시점에는 Cluster 보다 Scale Up된 High End 장비 혹은 GPU VM이 더 편할 수 있다. 
      4. 단, 다양하게 하이퍼 파라미터를 실험 적용해보는 단계에서는 Scale Out 가능한 이 구성이 더 유리하다.
    4. 앞 4개는 Open Source Deep Learning 도구들이며 각각 장단점이 있고, 때로는 보완 도구로서 함께 사용해야 한다.(특히 Keras)
    5. CNTK 는 보완 및 대체제로 경우에 따라 사용이 가능하다. CNTK 는 Keras 환경에서 기존의 Keras Source Code를 거의 수정하지 않고(우리의 Production 코드는 1~2줄 미만의 수정으로, 때로는 0줄 수정으로 가능하였다.) Backend 를 Tensorlfow 에서 CNTK 로 바꾸어 모델마다 선별적으로 선택하여 사용할 수 있다. 그리고, 다음과 같은 장점이 있다.
      1. Keras 와 함께 사용시 기존 코드를 그대로, CNTK 적용이 가능하다.
      2. RNN 계열에서 Tensorflow 보다 빠르다고 알려져 있다.
      3. 대부분의 병렬 Deep Learning 수행에 있어, 훨씬 적은 노력으로 확장이 가능하다.
    6. Horovod 는 Uber 가 만든 Deep Learning 분산 프레임워크로 Tensorflow 와 Keras 를 지원한다.
      1. Tensorflow 및 Keras 의 Low Level 코드 접근 없이 Multi GPU , Multi Host 사용이 가능하다.
      2. 위는 BechMark  자료이다.
    7. Azure Batch AI
      1. Azure 가 제공하는 Deep Learning 프레임워크의 병렬 확장 및 Auto Scale Out 을 지원하는 PaaS 이다.
      2. Tensorflow , keras, cntk , horovod(Manually) 등을 지원한다.
      3. CNTK 를 Backend 로 사용 시 병렬확장성에 대한 Code 접근을 추상화 할 수 있다.
        1. 즉, 이 때문에 tensorflow + keras 코드를 CNTK + keras 코드로 수정한 후, 이를 Azure Batch AI 에 호스팅 하는 경우 Auto Scale Out 의 장점을 극대화 할 수 있다.
        2. 모든 것이 Compute Parallel 이 되지는 않을 수 있다.(Horovod 와는 다른 방식이다.) 모델에 따라 Data Parallel 만 될 수도 있다는 의미이며, 이 부분에 대해서는 추후 좀더 실험을 해볼 예정이다.
      4. Tensorflow + Horovod  + Azure Batch AI 구성 시 native tensorflow 코드를 Low Level 코드 접근 없이 multi Gpu, multi host 확장이 가능할뿐 아니라 Auto Scale Out 이 가능하다.
      5. 비용에 대한 Limit 을 위해 Min Node 수와 Max Node 수 설정이 가능하다.
      6. 하나의 Job 의 확장 뿐 아니라, 복수 GPU 클러스터 Node 에 복수의 Deep Learning  Job 을 분배 및 할당하는 Cluster 로도 활용 가능하다.
      7. 이는 Production 용 Training 시스템 뿐 아니라, 다수의 Deep Learning Model 개발자들이 있는 경우 모델 개발이나 하이퍼파라미터의 빠른 튜닝을 위해서도 활용 가능한 시스템 이다.

여기서부터는 위 최종 선정 시스템을 이용 실제 Production 용 Legacy Deep Learning 모델을 Azure Batch AI 위에서 병렬 구동한 모습이다.

  1. Tensorlfow + Keras 로 작업된 Legacy 코드를 CNTK + Keras + Azure Batch AI 로 포팅하여 Multi Host + Multi GPU 로 수행한 화면.
  2. Tenosrflow + Keras 로 작업된 Legacy 코드를 Tenosorflow + Keras + horovod + Azure Batch AI 로 포팅하여 Multi Host + Multi GPU 로 수행한 화면.
  3. 수행 이후 수행 결과를 PaaS 상에서 확인


    1. 수행결과
    2. 클러스터 모니터링

[결론]



위 처럼 Tensorflow + Keras 로 작성된 Legacy Deep Learning Training 코드는 코드 수정을 거의 하지 않고, Single GPU 에서만 돌던 코드가 Azure Batch AI 위에서 Mulit GPU 와 Multi Host 로 병렬 구동됨을 확인 하였다.

위를 위해서 CNTK + Keras + Azure Batch AI 환경에서는 Legacy 코드를 단 1줄도 수정하지 않고, Backend 설정만 Tensorflow 에서 CNTK 로 변경하여 Azure Batch AI 위에서 병렬 수행됨을 확인 하였다.

하지만, 모든 Legacy 코드가 Keras  코드로만 구성된 것은 아니다. Keras 가 지원하지 않는 최신의 기법을 사용하는 경우. (예를 들어 2017년 여름경 까지 Keras 는 LSTM 에 Attention 을 포함하는 것을 지원하지 않았었다.) Tensorlfow 코드와 Keras 코드가 섞여 사용하는 경우가 실제로 우리의 경우도 존재 한다.

때로는 github 에 구현체가 공개된 잘짜여진 open source  코드가 keras 가 아닌 tensorflow 로만 구성된 코드일 수도 있다.

이를 위해 우리는 Horovod 를 이용한 Multi Host + Multi GPU 구동도 함께 테스트 했었다.
Tensorflow + Keras + Horovod + Azure Batch AI  구성은 그러한 시나리오를 위한 추가 확장 환경 구성이었다.

tensorflow + Keras + Horovod + Azure Batch AI 환경에서는 기존 Legacy 코드를 약 4~5 줄 정도를 추가하고, 2줄 정도를 변경하였으며, 변경을 하는데 들어간 시간은 최초 작업이었을 때에도 3~5분 미만으로 매우 쉬운 편이었다. 익숙해지면, 1~2분 안에 코드 수정이 가능한 수준이다.

단, CNTK + Keras + Azure Batch AI 와는 다르게, tensorflow + Keras + Horovod + Azure Batch AI 는 공식 github 에 example 도 존재하지 않으며, 다소 초기 세팅시 Debug 후 수동 설정 변경 사항이 많이 필요하였다.( 최초에 한번만 수행해주면 된다. ) 이 복잡한 초기 세팅 부분은 별도로 블로깅 예정이다 . 해당 부분을 따라한다면 어렵지 않게 Legacy 코드를 수행할 수 있을 것이다.

이번 블로깅에서는 고찰 및 구성 결론 만 다루었다. 다음 연재에서는 실제로 구성하는 방법과 구성 과정에서 구성을 debug 하는 방법, trouble shutting 하는 방법에 대하여 다루도록 하겠다.

연재 순서는 다음과 같다.

연재 1. 이번글.

연재 2. Deep Learning Multi Host & Multi GPU Architecture #2 - Keras 를 이용한 Scale Up, Horovod 를 이용한 Scale Out 성능 비교

연재 3. CNTK + Keras + Azure Batch AI 구성 방법

연재 4. Tensorlfow + Keras + Horovod + Azure Batch AI. Mnist 간단 버전 구성 설정 방법

연재 5. Tensorlfow + Keras + Horovod + Azure Batch AI. Legacy Code Advanced 버전 구성 설정 방법.

연재 6. Azure Batch AI 를 이용한 Custom Deep Learning 모델 구동 시 Trouble Shutting 을 좀더 쉽게 하는 방법.



2017년 12월 27일 수요일

Deep Learning Inference & Serving Architecture 를 위한 실험 및 고찰 1 - GPU vs CPU

최근 Production을 위한 Deep Learning Serving 레이어의 아키텍처를 구성하기 위해 몇가지 실험을 했던 내용을 정리해 보았다. 몇번에 걸쳐 연재 될 수 있을 듯 한데...

우선 오늘의 주제는 Inference 에 있어서도 정말 GPU 가 CPU보다 유리한가? (결론이 유추 되는가???)


아키텍처를 구성함에 있어, 다양한 Use Case 가 있을 수는 있으나, 정답이 존재하지는 않는다고 생각한다. 다양한 비지니스로직, 데이타의 양이나 성격, 사용하는 기술들, 개발 언어, 목적하는 바, 동시접속자 수, On-premise , Cloud 여부 등에 따라 다양한 조합이 있을 수 있을 것이고, 각각이 장단점이 존재할 것이기 때문이다.

여러 참고 자료로 사전 조사를 해본것은 사실이지만, 우리의 Deep Learning 모델과 우리의 데이타, 우리의 로직으로 후보 아키텍처에서 직접 실험을 하고 아키텍처를 확정하고자 아래와 같은 실험을 진행하였다.

실험에 앞서, 주안점은 다음과 같다.

  1. 우리는 Keras , Tensorflow (일부 CNTK) 등의 Deep Learning Framework 로 만들어진 Deep Neural Network 모델을 이용, 대국민 서비스를 준비하고 있다.
  2. 다수의 동접이 있을 수 있고, 이벤트나 행사 여부, 광고 및 홍보 여부에 따라, 트래픽이 매우 가변적일 수 있고, 다수의 동접 및 다수의 inference 가 일어날 수 있다.
  3. 많은 동접의 경우에도 응답은 1초 이내를 목표로 한다.
  4. Deep Learning 모델은 RNN, LSTM 류와 간단한 류의 CNN 이 주를 이룬다.(우리의 모델은 vgg, inception 류의 heavy CNN  은 아니다.)
  5. 우리의 모델이 특이한 점은 주기적인 Fine Tuning 과 시시 각각의 RealTime on-line Training 이 운영중인 Model 에 시시각각 이루어진다는 점이다. 이는 Serving Layer 설계에 있어 중요 고려 사항 중 하나인데, Serving 되는 모델의 Size 를 줄이고 응답 속도를 빠르게 하기 위한 알려진 기법들을 적용하는데 방해가 되는 요소이기 때문이다. 
  6. Tensorflow 의 Serving 은 써본 사람들은 알겠지만, Web Service 로 만들어 배포하기에는 몇가지 제약이 느껴진다. 이 실험은 Tensorflow Serving 전용 엔진을 통한 실험은 아니며, 보다 High Level 로 접근하여 Inference Layer 를 직접 구현했을 때의 실험이다.
일반적으로 Inference 전용 Model Optimization 을 할 때는 주로 아래의 방법들이 사용된다.

  1. check point 등 training 에서만 사용되는 operation 을 없앤다.
  2. batch normalization ops 도 제거한다.
  3. 도달하지 않는 graph 영역 제거
  4. Check Numeric 제거
  5. 각종 variable 값 들은 constant 로 바꾸어, 크기를 줄이고 속도를 빠르게 하며, Thread Safe 하게 변경한다.
위 기법들은 Model 이 Freezing 된 경우에 한하여서이다. realtime training 과 inference 가 동시에 일어나는 경우는 
  1. training  model 과 inference  model 을 분리하고, 지연 동기화 시키거나
  2. 둘을 하나로 가져가되 constant 화 하고 freezing 하는 것을 포기해야 한다.
위 둘의 중간도 가능할 수는 있다. Node 가 복수개인 경우 Training  중인 Node 가 잠시 Serving Node 에서 빠져 있는 경우가 그 경우에 해당 할 것이다. 후에 우리는 Serving Layer 에 있어, Auto Scale Out 가능한 Docker PaaS나 Microservice Serverless PaaS 를 중요 고려 요소로 낙점하고 추가적인 실험을 하였는데, (아마 이 연재가 좀더 계속되어진다면, 다시 상세하게 다루어 보도록 하겠다. ) 이 시나리오 에서는 Training Layer 와 Serving Layer 를 각각의 장점을 극대화 시키고, Model 파일의 경우만 지연 공유시키는 또다른 시나리오가 나올 수 있다.


우선 오늘 다룰 내용은 위에서 언급된 다양한 방법론의 첫단추로서, 우리 모델이 과연 CPU 에서 더 잘 inference 되는 지, GPU 에서 더 잘 inference 되는지 의 여부에 대하여 실험 해본 결과이다. (ps. 실험에서 사용된 모델은 실험용으로 실제 모델이 다소 단순화된 General Model 임)
다수 동접 Inference 테스트 전 training 퍼포먼스 또한 실험한 결과를 함께 정리 하였다.

[1] 실험에 사용된 딥러닝 모델 및 모델 크기

- 일반적인 Language Model 용 LSTM 모델
- categorical_cross_entropy 사용
- Top 1 분류 모델
- Word Embedding Layer 차원 수 : 300차원
- Total Parameter 수 : 80,656,435 개

- [특이사항] Language Model 특성상 Total Parameter 에서 앞부분이 많은 부분 차지.
- [특이사항] LSTM 이 번역등의 문제가 아닌 Text Classification 문제에 적용된 경우 이므로, 층이 복잡하지는 않음. 층을 복잡하게 하여도 성능 향상 없었음. 그러나, 일반적인 word2vec + cnn 보다는 3% 정도 성능 향상된 모델임.


[2] 실험에 사용된 hyper parameter

- epochs=4 , batch_size=64 , optimizer=adam
- learning Rate=0.001, beta_1=0.9 , beta_2=0.999, epsilon=1e-8

- [특이사항] CPU Training 은 GPU 와 달리 batch size 를 4096등 훨씬 큰 수치를 주어도 memory resource 고갈 에러가 발생하지 않음, drop out 이나 batch bormalize 를 적절히 쓰는 경우 batch size 를 크게 주는 경우, 정확도는 비슷한데, 더 빨리 Training 이 될 수 있음.
- 즉, CPU vs GPU 트레이닝 퍼포먼스는 실무에서는 batch_size 를 달리 주어, CPU가 아래보다 더 빨리 응답하는 것도 가능하나, 동일 hyper parameter 값에 대한 성능 비교를 위해 아래에서는 동일 값으로 수행한 결과 이다.

[3] 실험에 동원된 HW 장비 Spec

- cpu : 12 vcore , 112gb Memory ( On Azure Cloud VM )
- gpu : K80 GPU * 2개 , 12 vcore , 112GB Memory ( On Azure Cloud Data Science GPU VM ) (단, 모델 inference 시에는 1개 GPU 만 사용하여 실험하였음)

[4] Training Data 크기

- training data row 수 : 1,649,415 건

[5] Training 속도 및 성능


  1. CPU Training Performance
    1. epoch1 : 23,790 초
    2. epoch2 : 24,071 초
    3. epoch3 : 24,026 초
    4. epoch4 : 24,100 초
  2. GPU Training Performance

    1. epoch1 : 8,612초
    2. epoch2 : 8,370초
    3. epoch3 : 8,377초
    4. epoch4 : 8,360초
[6] Single Inference 성능

      

예상과 달리 CPU가 Wall Time 이 더 빠르다. Wall Time 은 벽걸이 시계 시간을 의미한다. 즉 실제, 걸린 시간이다. CPU 의 경우 user time 은 150에 육박하는 경우가 있는데, 그래도 wall time 은 일정하게 30에서 40 사이의 값을 보여준다. 여기에서 다음과 같은 가정을 해볼 수 있다. CPU 는 멀티코어를 써서 더 빠른가??

[7] Multiple Sequential Inference 성능

이번에는 1개 Inference 가 아닌 1000번의 inference 를 sequencial  하게 (Not 병렬) 수행해보았다. 그리고, 위 (6)의 가정이 맞는지 cpu 및 gpu 의 usage 상황을 확인해 보았다.

사용된 코드도 아래에 참고로 넣어 보았다.

1000번을 연속하여 serial 하게 수행해보자 위와 같은 속도가 측정되었으며, 평균을 내 보면, CPU는 20ms , GPU는 60 ms 정도가 걸렸다.

특이한점은 , 처음 예상과 비슷하게, CPU는 멀티코어를 쓰고 있고,(코어 전체를 쓰진 않았음, 위 스크린샷 시점에는 420% 정도가 동작하고 있음.), GPU 는 GPU 1번 코어만을 50~70% 정도 사용하고 있으며, CPU 는 1개 CPU만 100% 사용하고 있다는 점 이었다.

여기에서 한가지 의문이 생겼다. 그렇다면 혹시 CPU가 병목인가?
그리고, 그렇다면, 혹시 위 코드에서 사용된 유일한 Pre Processing 인 Tokenizer 가 영향을 주고 있는 것인가?

그래서 위 실험에 사용된 코드에서 Tokenizer 전처리 Pre Processing 부를 1000번의 loop 바깥으로 빼보고 성능 향상 정도를 측정해 보았다.

[8] CPU  에서 Tokenizer 가 주는 영향


위 처럼 CPU 실험에서는 Pre-Processing 영역인 Tokenizer 가 주는 영향은 5% 정도에 지나지 않았다.

[9] GPU에서 Tokenizer 가 주는 영향


GPU에서도 마찬가지로 Pre-Processing 부분이 주는 영향은 2% 정도에 지나지 않았다. %는 줄었고, 절대치는 비슷하다. 즉, CPU에서이든 GPU에서이든 Pre-Processing 은 CPU 를 이용하기 때문에 절대치는 비슷한것이 이치에 맞다.

위 상황에서 CPU와 GPU  의 USAGE 도 확인해 보았다.



여전히 CPU 는 1Core 만 100% Full로 일하고 있고, GPU 는 50%에서 70%를 왔다갔다 하였다. 그러므로, CPU 는 전처리 때문이 아닐까 하는 가정은 False 라고 할 수 있을 것이다. 해당 가정에 대한 의문은 해소 되었다.

[10] 이제 실제 Inference 테스트를 위해 모델을 flask microservice 형태로 배포하였다. 


위 구동은 CPU 전용 머신과 GPU 전용 머신에서 각각 해 주었다.
실제 Production 에서는 성능 극대화를 위해 하나의 머신에 port 를 달리하여 여러 Process 를 띄우고 앞에 웹프록시 등을 두는 것이 일반적이지만, 이 실험은 상대적인 비교를 위함이 목적이므로, 그런 작업을 해주지는 않았다.

[11] 이제 실제 운영 Production 환경과 유사한 환경에서 동시접속수행 Test 를 해보겠다.

이곳에 따로 기재하진 않았으나, 앞선 시점에서의 비교는 Jupyter Notebook 에서 이루어졌다. 모두가 아는 바와 같이 Jupyter Notebook 위에서의 구동은 단일 Python 독립 프로세스보다 훨씬 느리다. 즉, 동일한 실험이 flask 위에서 구동된 경우 Jupyter 위에서 구동된 경우보다 훨씬 빠르다. 그리고, flask 는 경량의 비동기 웹 프레임워크 이기 때문에, 병렬 수행이 위의 경우보다 훨씬 빠르게 일어난다.

위에서는 Serial 하게 한번에 하나씩만 Job 을 수행하였다. 이번 flask 에서의 수행은 다수 User 에서의 Parallel 동접 수행이다. 때문에 Serial 하게 수행했을 때보다 더 많은 병렬 Job 이 수행되었고, 그 결과 Jupyter 에서의 serial 수행보다 성능이 훨씬 더 좋게 나오고 있다.

(1) CPU 에서의 최종 결과

[Run User]      [TPS]   [Time Per Request : millisec]   [Transfer rate: Kbytes/sec]     [Complete Request]      [Failed Request]
1       200.35  4.991   30.13   201     0
11      273.97  3.650   41.20   274     0
21      245.21  4.078   36.88   246     0
31      265.94  3.760   39.99   266     0
41      265.97  3.760   40.00   266     0
51      265.95  3.760   40.00   266     0
61      258.76  3.865   38.92   259     0
71      260.95  3.832   39.24   262     0
81      244.99  4.082   36.84   245     0
91      251.80  3.971   37.87   253     0

[Run User]      [TPS]   [Time Per Request : millisec]   [Transfer rate: Kbytes/sec]     [Complete Request]      [Failed Request]
300     274.39  3.644   41.27   275     0
310     233.33  4.286   35.09   234     0
320     173.71  5.757   26.12   174     0
330     133.75  7.476   20.12   134     0
340     142.73  7.006   21.46   143     0
350     130.86  7.642   19.68   131     0
360     128.93  7.756   19.39   129     0
370     280.45  3.566   42.18   281     0
380     267.97  3.732   40.30   268     0
390     278.43  3.592   41.87   279     0
400     200.84  4.979   30.20   201     0

Apach 오픈소스 부하테스트 도구를 이용하여 동시접속 수행 성능을 측정하였다.
하나의 단일 User 가 비동기로 여러개의 병렬 수행을 요청하며, 그러한 User 또한 1에서 최고 400까지 늘려가며 측정 하였다.

CPU는 TPS 가 270 정도씩 나와 주고 있다. 그 시점 flask  의 로그를 보면, 실제 초단위로 동일한 log 가 270여개 실제로 모두 200 응답으로 존재함을 확인 할 수 있다.




(2) GPU 에서의 최종 결과

[Run User]      [TPS]   [Time Per Request : millisec]   [Transfer rate: Kbytes/sec]     [Complete Request]      [Failed Request]
1       16.47   60.735  2.48    17      0
11      16.24   61.565  2.44    17      0
21      15.69   63.740  2.36    16      0
31      11.60   86.215  1.74    12      0
41      4.98    200.914         0.75    5       0
51                              0       0
61      17.80   56.186  2.68    18      0
71                              0       0
81      17.47   57.242  2.63    18      0
91                              0       0

[Run User]      [TPS]   [Time Per Request : millisec]   [Transfer rate: Kbytes/sec]     [Complete Request]      [Failed Request]
1       15.87   63.014  2.39    16      0
11      17.28   57.886  2.60    18      0
21      15.69   63.744  2.36    16      0
31      12.46   80.263  1.87    13      0
41      5.76    173.748         0.87    6       0
51                              0       0
61      17.33   57.706  2.61    18      0
71                              0       0
81      12.42   80.529  1.87    13      0
91                              0       0



GPU 는 TPS 가 16 정도밖에 되지 않는 저조한 결과를 보여 주었다.

[결론]

(ps. 동시수행 과정에서의 cpu , gpu 사용량은 serial 1000건 수행의 경우와 매우 유사했다.)

CPU 의 경우 특징은 느려질 지언정 400동접까지도 Fail Request 가 하나도 없었다는 점이다.
그리고 Serial 하게 1000개를 수행했을때, 개당 20 ms 이던것이 병렬로 수행했을때에는 약 5배정도 빠른 성능을 보여 주었다. 

하지만 GPU 의 경우는 동접자가 많아지면, Fail Request 가 매우 많아 졌고, TPS 자체도 CPU 에 비하여 매우 느렸다. Serial 수행에서 3배 느렸으나, 동접 수행은 거의 10배 이상 느렸다. CPU 코어가 여러개인것도 그렇지만, 메모리 등도 한몫을 했을 것으로 보여진다. GPU 의 경우는 serial 하게 측정했을때나 parallel 하게 측정했을때 모두 개당 응답 속도가 60ms  정도로 일정하다는 특징도 보여주었다. 즉, 동시 처리가 좀 매우 취약해 보인다. 동시 수행하는 속도 개선 효과가 거의 없었다.(CPU 와는 전혀 다른 양상이다.)

또한 GPU inference 의 경우 단일 CPU 가 GPU 한개와 함께 힘들게 일하고 있었던 양상 또한, 병렬 동시접속 능력을 떨어뜨리는 계기가 된듯 하다.
(이는 Tensorflow 에서의 실험 내용이다. CNTK  로도 동일한 모델을 수행할 수 있는데, 그 비교 결과는 다음 기회에 Posting 해보도록 하겠다.)

일단 CPU Inference 의 경우는, 메모리 사용량, CPU 사용량, 모두 저정도의 traffic 에 대하여는 안정적인 결과를 보여주는 것을 확인 할 수 있었다. GPU 의 경우는 Production 으로 대국민 서비스를 하기에 매우 위험한 수준이었다.

Developer 입장에서, 우리에게 CPU는 사실 GPU에 비하여 상대적으로 너무나 친숙하고 풍족한 리소스 이다. 게다가, 우리는 Docker , Microservice , Spark on Hadoop Yarn, Mesos  등 다양한 CPU + in-Memory 병렬 cluster 솔루션이 있다. 그리고 Public Cloud 에도 Auto Scale Out  이 가능한 Docker PaaS 나 Serverless MicroService PaaS 가 GPU 보다는 훨씬 저렴한 가격으로 구비되어 있다.

AI Serving Layer 는 이렇게 일단 우리의 시나리오와 우리의 모델에 있어서는 GPU 를 제끼고 고려할만 한 실험 결과가 나왔다. ( 물론 VGG, Inception 등 층이 깊은 Deep Learning 모델은 이것과 다른 양상이 나올 지도 모른다. TensorRT 등 Nvidia 는 Inference 전용 솔루션도 내놓은 것으로 알고 있다.) 

지금 담담하게 결론을 적고 있지만, 사실 실험결과가 이렇게 나왔을때 나는 흥분을 감추지 못했다. 하마터면 수억원짜리 GPU가 6~8개씩 꼳 힌 장비를 수대 구매하는 프로세스를 태울 뻔 했기도 했지만.... 무엇보다, 대용량 서비스와 다수 동접자를 위한 아키텍처에, 위 결론에서는 많은 솔루션과 오픈소스 그리고 public cloud 를 쓸 수 있는 풍부한 가능성이 생겼다는 점에서 안도의 한숨을 쉴 수 있었다.

PS. 위 실험 결과와 결론 유추 과정에서 제가 범한 논리적 오류가 있었다면 지적해주시기 바랍니다. 공유 이후 컴멘트는 곧 저에게는 배움이기도 하다는 자세로 공유를 실천 하고 있습니다.

2017년 9월 7일 목요일

BigData와 결합한, 분산 Deep Learning 그 의미와 접근 방법에 대하여

딥러닝의 대부이신 제프리 힌튼 교수님은, 머신러닝의 수십년간 암흑기가 극복될 수 있었던 계기로 3대 난재가 풀렸기 때문이라고 언급하신 바 있다. 바로 아래와 같다.
  1. 알고리즘적 혁신 ( Deep Neural Net 이 가능해진,  Relu, DropOut, 발견 등등..)
  2. 하드웨어 혁신 ( GPU 를 이용한 컴퓨팅 파워 Scale Up )
  3. 소프트웨어 혁신 ( BigData Cluster 를 이용한 분산 컴퓨팅 파워 Scale Out )
이 중 1은 우리가 너무나 많이 알고 있고, 곁에서 접하고 있고, 심지어 사랑하고 있는 분야이다.
2는 약간 비싸지만, 회사에서 안사주면, 자비를 털어서라도 집 Desktop에 2개 정도 꼳아주고, 그 날개 돋힌 파워를 충분히 느껴 볼 수 있는 분야이다.

하지만, 3은 좀 말이 다르다. 힌튼 교수님이 말씀 하셨지만,  Lab 에서든 기업에서든, 섣불리(아직까지는) 시도되지 못하는 경향이 있고, 관련된 자료도 많지 않다. 무엇보다도, Popular 한 오픈 Data 를 통해 논문에서 통용되는 수십만 혹은 수백만건의 데이타는 그다지 Big 하지 않기 때문에, 1+2 만 가지고도 꾸엮 꾸엮 실험하고 돌려보고, 논문을 완성해갈 수도 있는 수준일 수 있다. 때문에, 구글, MS 등 몇몇 회사등을 제외하고는 수십층 짜리 Very Very Deep 류의 모델을 밑바닥부터 적합한 Neural Networks 구조를 발견하고, 이를 초기값부터 시작하여 새롭게 학습시키는 등의 작업은 일반 소규모 Lab 등에서는 하기가 매우 힘들고, 그러다 보니, 그에 대한 학계의 연구가 보편화 되어 있지는 않는 듯 보인다. 

그래서인지 3의 접근은 일부 공룡 기업들에 의하여 자체 구축 혹은 오픈소스화 되어 일부 만이 오픈된 상태이다. 

기업의 Production Deep Learning 프로젝트의 경우, 우선 보유 Data 의 크기가 논문에서 사용되는 Data 의 크기보다 수십배 ~ 수백배인 경우가 많다.(아닌경우도 많지만...) 그리고, 복수의 모델을 함께 쓰거나 좀더 Fine Tuning 을 위해, Online Learning , Transfer Learning  보다는  초기부터의 Learning 을 시도하는 경우가 훨씬 많다.(특히, 한글 Deep Learning Text NLP 등은 기 학습되어 있는 Pre training Set 도 존재하지 않는다.)


오늘은 그런 부분 즉, Deep Learning 을 Big Data Scale Data 를 가지고 수십대 수백대의 GPU 클러스터를 가지고서 병렬 Training 을 하기 위한 BigData Platform + deep Learning Platform 구성에 대하여 이야기 해보고자 한다.

[1] GPU 만으로 하는 Deep Learning Approach의 한계

가장 Popular 한 Deep Learning  프레임워크 중 하나인 Tensorflow 는 사실, 이미 멀티 GPU 를 지원하고, 멀티 노드도 지원하며, 아직 미흡하지만, 자체 Serving Layer 도 가지고 있다. 하지만, Tensorflow 가 지원하는 수준의 분산 컴퓨팅, 분산 GPU 는 마치, 분산 데이타 컴퓨팅을 Map/Reduce 로 하는 경우와 유사하게 너무 Low Level 접근을 필요로 하는 경우가 많다. 하나의 Simple 한 Neural Network 모델이 Data Parallel 이 되거나 Compute Parallel 이 되는것 특히, 그것이 High Level 로 저절로 되는 것은 아직 그 어떤 Deep Learning 프레임워크도 완벽하게 지원하고 있지는 않는 영역이다.
Caffe나 Tensorflow , Torch, CNTK 등의 deep learning  프레임워크는 그 자체만으로 은총알은 아니다. High Level Scale Up 된 장비 한두대로 논문에서 다루는 크기의 데이타를 처리하는데에는 문제가 되지 않으나, 실무 데이타, 특히 클릭 스트림을 RNN이나 LSTM 분석하는 정도의 시나리오만 되도, 데이타의 크기나 GPU 머신의 Memory 문제로 금방 문제가 드러나기 십상이다.
다중 사용자에게 Deep Learning Serving(Service Request 대응) 을 하는 도중에, Model traing 갱신이 일어나고, 실시간 업데이트가 되면서, 무중지로 Model 배포되는 시나리오는 또 다른 고급 기술을 요구하기도 한다.
GPU 만으로 하는 Single Scale Up, Deep Learning Approach의 한계를 정리해 보자면 아래정도 일 것이다. 
  1. Hyper Parameter Tunning 노가다
  2. Training 속도 한계있음
  3. 멀티 GPU 코딩의 거시기함.
  4. GPU의 협소한 메모리로 인한 ResourceExhaustedError. 
  5. 강제된 작은 Batch Size
  6. RealTime Inference, 다수 동접자 Serving Layer, 모델의 무중지 Rolling Upgrade
  7. BigData Scale Data 들을 접근 하기 위한 Data Pipe lining  
  8. 모델 태우기 전, Python 레벨 데이타 전처리와 후처리의 한세월...

[2] Open Source 진영 BigData Scale Distributed Deep Learning Approach 
하지만, 오픈소스 진영에서는 그러한 것들을 주로 hadoop + Spark (PySpark) 를 통해 해결 시도 하고 있고, 어느정도 Production 레벨까지 활용 가능한 수준의 결과물들이 나오고 있다. 즉, 서두에서 언급했던 3(BigData 혁신)의 시도가 되고 있는 것이다.
BigDL, elaphas , caffeOnSpark  등 그런류의 몇가지 오픈소스를 실제 Production Level Deep Learning 배치 시나리오를 이용 Training 해보고 테스트 해보았는데, 아래 소개하는 TensorflowOnSpakr (made by Yahoo) 오픈소스는 그중 가장 가능성이 보이는 Approach 중 하나라 할 수 있을 것이다. (참고로, Yahoo 는 TensorflowOnSpark 을 만들기 전 CaffeOnSpark을 먼저 만들었고 테스트 하였다.)
아래는 Inception-v3 모델을 spark 멀티 노드위에서 worker 노드 갯수를 달리해가면 분산 Training 한 속도 비교 이다.

위처럼 1대에서 48시간을 돌려도 정확도가 0.73 % 정도인게, 8대에서는 7시간만에 도달되고 이후로, 85%가 넘는 정확도에 훨씬 빠른 시간에 도달 되는 것을 확인 할 수 있다.
[3] TensorflowOnSpark 설치 및 세팅 사용방법 
아래는 그런 Producion Level 에서 BigData 분산 Traing 과 RealTime Traing 부분에 강한 강점을 가지고 있는 시스템 구성으로 Tensorflow + Spark + Hadoop 구성을 설정 하고 세팅 한 후, 간단하게 사용하는 방법이다. ( Hadoop 과 Spark  는 Yarn Cluster 모드로 이미 설정이 기 완료 되어 있다고 가정하고, 그 이후의 세팅 방법만 언급 하였다.)
  1. Python3 관련 설정 및 설치
    1. 우선 SSL 관련
      1. yum install openssl openssl-devel -y
    2. Anaconda 설치
      1. https://repo.continuum.io/archive/ 위치에서 Linux 버전 최신 설치 파일 Download
      2. 각 노드에 모두 복사
      3. chmod 755 Anaconda3-4.4.0-Linux-x86_64.sh
      4. sudo ./Anaconda3-4.4.0-Linux-x86_64.sh
      5. 설치 완료 시 화면
        1. 설치 완료 화면
      6. bin 경로에 심볼릭 링크 연결 (Source 경로는 각자의 경로를 따를 것!)
        1. sudo ln -s /home/moneymall/anaconda3/bin/python3 /bin/python3
      7. 기존 python 을 un link
        1. sudo unlink /bin/python
      8. 새로 설치한 python3 로 다시 link
        1. sudo ln -s /bin/python3 /bin/python
      9. pip 도 설정
        1. sudo ln -s /home/moneymall/anaconda3/bin/pip /bin/pip

  2. Anaconda 설치에 관하여.
    1. Tensorflow 등의 기본이 되는 Python Dev 환경을 설치하는 여러가지 방법이 있지만, 내가 선호하는 방법은 우선 anaconda 를 깔아주는 것이다. 공간차지 등등 부수적인 단점이 있긴 하지만, 여러가지 추가적인 기능들이나 필수 모듈들이 동시에 깔려서 편하고, 이후 anaconda 가 제공하는 여러가지 관리 도구들을 이용하여 다양한 장점을 꽤할 수 있다.
    2. Root 로 설치시 실제 사용하는 계정으로 수행하는데 불편함이 많음.
    3. 실제 사용하는 계정으로 설치하는 것이 더 편함.
  3. Tensorflow 및 TensroflowOnSpark 설치
    1. pip install tensorflow
      1. CPU 모드일때는 그냥 간단히 저렇게 해줘도 됨.
      2. virtual env 등에 설정할 수도 있고, conda create 한 다음 설정할 수도 있으나, spark 와 연동을 위해서는 바깥에서 전역적으로 저렇게 설치하는 것이 좋음.
      3. 설치 완료 화면
    2. pip install tensorflowonspark
      1. 설치 무지 빨리 끝남.
      2. 설치 완료 화면
    3. 참고로 위 설치 방법은 Simple 설치 방법을 공유하기 위한 목적의 설치 Guide 이므로, RDMA 를 사용하는 Advanced 설정 방법은 아님.
      1. RDMA 사용 시 훨씬 성능을 극대화 할 수 있음.
  4. Spark및 Hadoop 에서 Tensorflow 의 Records 를 직접 읽고 쓰기위 한 Jar 라이브러리 설치
    1. 아래 주소에 Spark 용 해당 Open Source 가 있음.
      1. https://github.com/tensorflow/ecosystem/tree/master/spark/spark-tensorflow-connector
      2. git clone 후 spark 디렉토리로 이동.
      3. git clone https://github.com/tensorflow/ecosystem.git
      4. sbt build
        1. build.sbt 파일이 존재하는 위치까지 이동.
        2. sbt clean assembly
        3. 위 빌드 명령어 입력 하면 아래처럼 sbt 빌드 완료 되고, target 디렉토리 하위에 jar 파일 생성 됨.
        4. Jar 파일 위치
    2. 아래는 Spark 이 아닌 Hadoop 용 InputFormat/OutputFormat 모듈 for Tensorflow Records Direct Read/Write
      1. https://github.com/tensorflow/ecosystem/tree/master/hadoop
      2. 위 git clone 소스에서 Hadoop 경로로 간다.
      3. $TF_SRC_ROOT 는 Tensorflow 소스 루트.
      4. protoc 가 설치되어 있지 않다면, https://developers.google.com/protocol-buffers/ 에서 3.3.0 버전 설치 필요 함.
        1. git clone https://github.com/google/protobuf.git
        2. cd protobuf
        3. ./autogen.sh
        4. ./configure
        5. make # 무지오래걸림.
        6. make check # 더 오래걸림. 커피 먹으러 갔다 오길 추천.
          1. make check 완료시 화면
        7. sudo make install # 금방 끝남.
        8. sudo ldconfig
        9. 완료 후 확인
          1. protoc 명령어를 수행하면 저런 화면이 떠야 함.
      5. protobuf java 버전도 설치 필요
        1. 소스 위치는 앞에서 다운받았던 protobuf 소스에서 java 경로 밑에 있음.
        2. mvn test (maven 이 기 설치 되어 있어야 함.)
          1. 완료시 이런 모양.
        3. mvn install
      6. protoc --proto_path=$TF_SRC_ROOT --java_out=src/main/java/ $TF_SRC_ROOT/tensorflow/core/example/{example,feature}.proto
        1. $TF_SRC_ROOT 는 tensorflow 소스가 미리 받아져 있어야 하고 해당 경로로 set 되어 있어야 함. (.bashrc 등에...)
        2. tensorflow 소스는 https://github.com/tensorflow/tensorflow.git 이곳에 있음.
      7. mvn clean package
        1. 처음 default pom.xml 로 수행시 아래같은 에러 잔뜩 남.
          1. Cannot find symbol 이라는 문구들이 error 로그에 보이는 걸로 봐서...이건 version 오류로 추정됨.
          2. pom.xml 을 열어서 보면... version 이 1.6 으로 되어 있음. 이걸 1.8로 수정(내 환경에서의 Java 는 1.8 이었으므로...)
            1. Java 버전 1.8로 수정했음.
            2. protobuf 버전도 3.3.1 에서 내가 설치했던 버전인 3.4.0  으로 수정해 주었음.
        2. jar 생성
          1. 위 pom.xml 수정 후 빌드 성공하면 jar 생성됨.
          2. 빌드 성공시의 화면
            1. jar 파일은 target 디렉토리 아래 존재
      8. 해당 jar 를 HDFS 에 업로드
        1. hadoop fs -put tensorflow-hadoop-1.0-SNAPSHOT.jar /user/moneymall/
  5. Parallel MNIST 돌려보기
    1. 우선 데이타 준비
      1. mkdir ${HOME}/mnist
        pushd ${HOME}/mnist >/dev/null
        curl -O "http://yann.lecun.com/exdb/mnist/train-images-idx3-ubyte.gz"
        curl -O "http://yann.lecun.com/exdb/mnist/train-labels-idx1-ubyte.gz"
        curl -O "http://yann.lecun.com/exdb/mnist/t10k-images-idx3-ubyte.gz"
        curl -O "http://yann.lecun.com/exdb/mnist/t10k-labels-idx1-ubyte.gz"
        zip -r mnist.zip *
        popd >/dev/null
      2. 위 mnist.zip 파일은 local 에 존재 시키고, spark-submit 할때 인자로 넘길 예정이다.
    2. Pyspark 를 이용한 Data 병렬 전처리 후 CSV 포맷으로 저장
      1. Pyspark 를 이용해서 MNIST 데이타를 traing 셑과 test 셑으로 나누는 부분을 병렬로 수행 해보자.
      2. 여기에 사용되는 example 코드는 tensroflowOnSpark github 에 존재하는 코드이다.
        1. https://github.com/yahoo/TensorFlowOnSpark/blob/master/examples/mnist/mnist_data_setup.py
        2. 위 코드를 사용하였다.
      3. pySpark  로 data 전처리를 병렬로 수행하고 CSV 결과는 Hadoop 에 쓸 예정이다.
      4. 수행 Script 는 아래와 같다.
      5. ${SPARK_HOME}/bin/spark-submit \
        --master yarn \
        --deploy-mode cluster \
        --queue ${QUEUE} \
        --num-executors 13 \
        --executor-memory 22G \
        --archives ./mnist/mnist/mnist.zip#mnist \
        ./mnist/mnist_data_setup.py \
        --output mnist/csv \
        --format csv
        
      6. 위는 official manual 문서와 다소 다르다. 처음 수행을 하면 에러가 나는데, spark yarn cluster 를 이용하였으므로, hadoop job 모니터링 페이지를 통해 에러 로그를 확인 할 수 있다.
        1.   즉, mnist 다운로드한 파일의 경로 참조를 정확히 해주지 못해서 에러가 발생하고 있음을 알수있다.
        2. 경로를 수행한 python 파일과의 상대경로로 정확히 지정하고 나면, 에러가 나지 않고, pyspark yarn cluster 모드로 잘 동작이 된다.
      7. 또 official manual 과 내가 수행한 스크립트의 다른 부분은 아래 옵션을 나는 삭제 했다는 점이다.
        1. --archives hdfs:///user/${USER}/Python
        2. 우리는 앞서 모든 노드에 동일하게 Python 환경을 이미 세팅해 주었고, Path 에도 포함시켜 줬다. 때문에, 굳이 Python을 배포를 통하여 공유되게 하지 않아도 에러없이 수행이 가능하다.
      8. 최종적인 결과 메시지는 아래와 같다.
      9. hadoop 에 CSV  파일이 잘 Write 되었는지도 확인해 보자.
        1. 하이라이트 한 부분 처럼 Hadoop 에 mnist 데이타에 대한 전처리 후 결과 output 이 train 과 test 데이타로 나뉘어 잘 적재 된 것을 확인 할 수 있다.
        2. 이는 앞으로 대용량 데이타에 대한 Python 전처리를 병렬로 수행할 수 있음을 확인 한 부분이다.
    3. Pyspark 를 이용한 Data 병렬 전처리 후 Tensroflow Records 포맷으로 저장
      1. CSV 로 파일을 저장하지 않고, Tenssorflow Records 포맷으로 바로 저장할 수도 있다.
      2. 우리는 이를 하기 위해 윗부분 설치 시점에, 4.2.8 에서 protobuf 까지 설치해가며, tensorflow ecosystem github 의 소스를 내려 받아 maven 빌드 후 tensorflow-hadoop-1.0-SNAPSHOT.jar 파일을 생성한 바 있다.
      3. 해당 jar 를 pyspark submit 시 인자로 넘겨주고 해당 jar 라이브러리를 이용 아래 내용을 수행 할 예정이다.
      4. 수행 스크립트는 아래와 같다.
      5. ${SPARK_HOME}/bin/spark-submit \
        --master yarn \
        --deploy-mode cluster \
        --queue ${QUEUE} \
        --num-executors 13 \
        --executor-memory 22G \
        --archives ./mnist/mnist/mnist.zip#mnist \
        --jars hdfs:///user/moneymall/tensorflow-hadoop-1.0-SNAPSHOT.jar \
        ./mnist/mnist_data_setup.py \
        --output mnist/tfr \
        --format tfr
        
      6. 앞서 CSV 로 HDFS에 저장해보았던 예제의 수행 스크립트 내용과 매우 유사하지만 대표적으로 --jars 옵션을 사용한것이 큰 차이점이다.
      7. 그리고, 소스 내부에서 format 인자로 로직이 분기하므로 --format 값으로tfr 을 넘겨 주었으며, output 경로 또한 csv 가 아닌 tfr 로 변경해 주었다.
      8. hadoop 에 tensorflow 포맷 records 가 잘 저장되었는지 살펴보자.
        1. 스크립트를 수행해주자 위처럼 tfr 폴더가 생성 되었다.
        2. tfr 디렉토리의 상세내용을 살펴보면 아래와 같다.
          1. 역시 test 와 train 으로 구분되었으며, spark job 이 생성하는 파일 명명 규칙으로 파일이 생성 되었다. (파일 내용은 TFRecords 포맷이다.)
    4. MNIST 모델 돌려보기
      1. 위 전처리 및 아래 Tensorlfow 병렬 모델 수행에서의 수행 스크립트는 Dev Zone 에서 테스트 된 관계로 GPU 관련 옵션이 빠져 있다. GPU 모드 병렬 수행을 위해서는 아래 옵션들이 추가되어야 한다.
        1. --queue GPU
        2. --conf spark.executorEnv.LD_LIBRARY_PATH=$LIB_CUDA:$LIB_JVM:$LIB_HDFS \
          --driver-library-path=$LIB_CUDA \
        3. #infiniband 에서의 성능 향상을 위해서는 아래 옵션도 추가하는 경우 
          # 큰 성능 향상을 가져올 수 있다. (설치시에도 옵션 설정 필요)
          --rdma 
      2. Training (using feed-dict)
        1. feed-dict 을 이용한 Traing 용 수행 스크립트는 아래와 같다.
        2. # 재 수행시에는 아래 주석을 풀어주어야 한다. Overwrite error 방지.
          # hadoop fs -rm -r mnist_model
          ${SPARK_HOME}/bin/spark-submit \
          --master yarn \
          --deploy-mode cluster \
          --queue ${QUEUE} \
          --num-executors 13 \
          --executor-memory 22G \
          --py-files ./mnist/spark/mnist_dist.py \
          --conf spark.dynamicAllocation.enabled=false \
          --conf spark.yarn.maxAppAttempts=1 \
          --conf spark.executorEnv.LD_LIBRARY_PATH=$LIB_JVM:$LIB_HDFS \
          ./mnist/spark/mnist_spark.py \
          --images mnist/csv/train/images \
          --labels mnist/csv/train/labels \
          --mode train \
          --model mnist_model
          # to use infiniband, add --rdma
          
        3. 아래는 위 병렬 Training 이 수행되는 동안의 Yarn Batch Job 모니터링 페이지의 모습이다. 일반 Spark Yarn Cluster Job 과 동일한 모양이다.

        4. 최중 수행 뒤 결과 메시지는 아래와 같다.

      3. inference (using feed-dict)
        1. training 이 끝났으므로, inference 즉, 모델의 학습 결과를 확인 해 보자.
        2. 수행 스크립트는 아래와 같다.
        3. # hadoop fs -rm -r mnist_model
          ${SPARK_HOME}/bin/spark-submit \
          --master yarn \
          --deploy-mode cluster \
          --queue ${QUEUE} \
          --num-executors 13 \
          --executor-memory 22G \
          --py-files ./mnist/spark/mnist_dist.py \
          --conf spark.dynamicAllocation.enabled=false \
          --conf spark.yarn.maxAppAttempts=1 \
          --conf spark.executorEnv.LD_LIBRARY_PATH=$LIB_JVM:$LIB_HDFS \
          ./mnist/spark/mnist_spark.py \
          --images mnist/csv/train/images \
          --labels mnist/csv/train/labels \
          --mode inference \
          --model mnist_model \
          --output predictions
          # to use infiniband, add --rdma
          
        4. mode 부분과 output 부분만 차이가 있다.
        5. 주의할 점은 앞에서 mnist_model 을 training 과정에서 이미 수행하였다면, 상단 hadoop 명령어로 mnist_model 을 지우고 수행해야 한다는 점이다. (hadoop 에서의 경로는 적절히 수정 할 것)
        6. 결과는 아래와 같다.
          1. 최종 결과는 output 으로 지정해준 predictions 안에 존재한다.
          2. 아래 명령어로 내용을 살펴보자.
            1. hadoop dfs -cat predictions/part-00000
            2. 결과는 아래와 같다.
      4. training (using queueRunners)
        1. feed-dict 대신 I/O 병목에 더 강점이 있는 queueRunners 모드를 사용해 보자. 여기서는 TFRecords 를 이용하여 좀더 Tensorflow Low Level training 을 할 예정이다.
        2. 수행 스크립트는 아래와 같다.
        3. # hadoop fs -rm -r mnist_model
          ${SPARK_HOME}/bin/spark-submit \
          --master yarn \
          --deploy-mode cluster \
          --queue ${QUEUE} \
          --num-executors 13 \
          --executor-memory 22G \
          --py-files ./mnist/spark/mnist_dist.py \
          --conf spark.dynamicAllocation.enabled=false \
          --conf spark.yarn.maxAppAttempts=1 \
          --conf spark.executorEnv.LD_LIBRARY_PATH=$LIB_JVM:$LIB_HDFS \
          --jars hdfs:///user/moneymall/tensorflow-hadoop-1.0-SNAPSHOT.jar \
          ./mnist/spark/mnist_spark.py \
          --images mnist/tfr/train \
          --format tfr \
          --mode train \
          --model mnist_model
          # to use infiniband, add --rdma
          
        4. CSV 대신 tfr 즉, TensorFlow Records 를 직접 사용할 예정이다.
        5. 기존 hadoop model output 을 제거한 후 수행하자.
        6. 여기서 주의할 점은 2017년 8월 기준 official manual 에 --jars 옵션이 빠져 있어 에러가 난다는 점이다. 위처럼 jars 옵션으로 앞서 만들었던 tensorflow-hadoop-1.0-SNAPSHOT.jar 파일을 포함해 주어야 위 스크립트가 정상 동작 한다.
        7. 최종 결과는 아래와 같다.
[결론]

우선,  PySpark 와 Tensorflow 를 섞어 쓸 수 있는게 매우 편하다. Python 전처리 수시간 걸리던게 PySpark 로 수분안에 끝나는 묘미를 맛보면, 이전으로 돌아가기가 쉽지 않다.
익숙한 Jupyter Notebook 이나 Zepellin Notebook 환경 모두 tensorflowOnSpark 연동이 가능한 것도 장점이다.


그리고, 대부분의 기존 Tensorflow 모델을 10줄 미만으로 수정하여, 병렬화 가능하다는 장점이 돋보인다. Spark 클러스터는 Yarn Cluster Mode 만을 지원하고 있다. 그리고, CPU 병렬 뿐만 아니라 GPU 병렬도 지원한다.

또한, Spark Streaming Mode 도 지원한다. 즉, 앞에 Kafka Cluster Queue 등을 놓으면, site 전체의 Click Stream 등 초 Heavy 트래픽에 대한 input 을 염두하며, 실시간 realtime inference가 되는 사이트 실시간 개인화 모델등을 만든다고 할때, 그러한 연산에 있어서의 Spark-streaming Layer 의 강점을 Deep Learning 모델에도 적용가능하리라 여겨진다.

설치는 Official Document 가 그런데로 상세히 나와 있는 편이지만, Legacy 가 최신 버전일때는 약간의 에러들이 발견되었고, 그래서 위처럼 설치 과정이 좀 길어졌다, 그 경우 소스 레벨 debub 및 log 를 확인해가며 설치를 해야 마무리가 되었던 부분은 약간 아쉬웠다. 즉, 너무 최신 Legacy 버전이 아닌 Official 버전을 사용하여 설치하면 좀더 쉽게 설치가 가능 할 것이다. 그리고, github 에 답변이나 issue 해결 commit 이 거의 매일 올라오고 갱신되는 편이라, 믿음이 간다. elaphs 는 설치해서 테스트 하다가 포기한게, issue 에 대한 대응이 너무 느렸다.

BigDL  역시 SparkML 과 유사한 패턴으로 딥러닝을 할 수가 있어, general 한 모델을 만들때는 더 편할 수 도 있다. 그리고, 자사의 BigData Cluster 가 아직 GPU 는 없고,  intel cpu 기반이라고 하다면, BigDL 이 tensorflowOnSpark 보다 좀더 성능이 잘 나올 수 있다.
하지만, 다양한 고급 모델을 지원하지 못한다는 단점이 분명히 존재한다.

BigData + Deep Learning 콜라보레이션 아키텍처에 대한 고민은 거의 반년 이상 했던거 같다. 여러가지를 실험해 보았고, 결론은 BigDL 과 TensorflowOnSpark 두개로 거의 확정하였다. 둘은 장단점이 극명하여, 어느 하나로 치우칠 필요 없이, 선택적으로 사용하려고 한다.

좀더 실무레벨에서 많은 경험을 한 후 다시 한번 포스팅 해볼 기회가 생겼으면 하는 주제였다.