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. 수행결과
1. 
2. 클러스터 모니터링
1. 

[결론]

위 처럼 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 을 좀더 쉽게 하는 방법.