About TensorMSA

TensorMSA

Importance of pipe line

딥러닝은 기본적으로 데이터에 기반하여 해당 데이터를 최대한 잘 설명할 수 있는 어떤한 모델을 만들어 내는 것에 그 목적이 있다.
이러한 목적을 달성하기 위해서 무엇이 필요한 어떤 점이 어려울까? 데이터에 대한 Insight 를 가지고 데이터를 분석하고 모델링하기 위한 인력의 부족? 분석하기 위한 데이터가 수집되어 있지 않은 경우? 데이터에 레이블링을 사람이 해야하는 경우? 데이터를 수집하고 분석하기 위한 환경의 구성? 하이퍼파라메터 튜닝을 위한 반복작업? 딥러닝 알고리즘에 대한 이해와 모델 프로그램의 개발? 딥러닝 모델을 실제 가동시스템에 서비스하는 일? 모든 내용이 사실 어려울 것이다. 우리는 여러가지 문제 중에서 시스템 관점에서 해결 가능한 문제에 집중하고자 하였다.

(1) 딥러닝을 위한 환경의 구성
대부분의 Legacy System 은 Java 기반으로 구성되어진 경우가 많다. 하지만 머신러닝, 딥러닝 시스템 구축을 위해서는 Python 기반 환경을 구성하는 것이 유리하다. 그렇다고 모든 기존 시스템에서 하이브리드 형태의 deep learning 환경을 구성할 수 있는가?
(2) 모델 훈련 및 서비스를 위한 노력 과다 소요
우리가 하나의 비지니스를 위해서 데이터 수집 가공, 모델링, 평가, 서비스하는 전체 아키택쳐를 구성한다고 하면 이를 위해서 필요한 노력은 너무나도 클 것이다. 실제로 각각의 Step 에서 사용하는 기능들은 일정부분 공통화가 가능하다. 그럼에도 프로젝트 혹은 시스템 단위로 별도의 로직을 계속해서 개발하는 것이 효과적인가?

그렇다면 위와 같은 문제를 해결하기 위한 방법은 무엇일까? 공통화하여 재사용할 수 있는 부분은 없을까? 데이터 수집이라고 하면 데이터의 형태, 데이터 저장소의 종류에 따라 데이터를 가지고오기 위한 로직이 달라질 수 있지만, 어느 정도는 공통화하여 재활용이 가능하다. 데이터를 전처리 또한 데이터의 형태가 이미지, 음성, 자연어, 정형 데이터 등에 따라서 어떠한 알고리즘을 사용해야 하는지가 달라질 수 있지만 분명히 공통화하여 재활용 할 수 있다. 모델 생성을 위한 알고리즘 또한 딥러닝 알고리즘인지, 기존 머신러닝 알고리즘인지에 따라 달라질 수 있지만 특수한 경우가 아니면 파라메터로 커스터마이징 할 수 있는 형태로 공통화 할 수 있다고 볼 수 있다. 평가하기 위한 방법도 마찬가지로 n-fold, random, extra 등의 형태로 충분히 공통화 할 수 있다. 서비스 제공 또한 마찬가지로 생성한 알고리즘에 대한 서비스를 위한 아키택쳐 또한 일반화하여 제공이 가능하다.

Let’s talk about our framework

우리는 위와 같이 공통화하여 재사용할 수 있는 프로세스가 많이 존재한다는 것에 착안하여 일반적인 프로세스를 공통화하여 체계적으로 관리할 수 있도록 파이프라인을 구축하고 서버간에 유기적으로 통신을 할 수 있도록 Micro Service Architecture 기반으로 서비스를 제공하는 방향으로 FrameWork 의 설계를 고민하였다.

우리는 모듈의 공통화와 MSA 개념의 서비스 아키택쳐 구축을 포함하여 아래와 같은 문제들을 해결하기 위한 기능들을 제공합니다.
(1) 모듈화를 통한 공통 컴포넌트의 개발
(2) Micro Service Architecture 기반의 연동 서비스
(3) GraphFlow – Node 기반의 가변성 높은 파이프라인 구성
(4) AutoML 기법을 적용한 자동화된 최적의 Hyper Parameter Search
(5) UI/UX 기반의 손쉬운 사용자 환경 제공
(6) 각종 딥러닝, 머신러닝 알고리즘 모듈 제공
(7) Docker 간편한 설치 및 배포 제공
(8) 스케줄러를 통한 주기적인 모델 자동 업데이트
(9) 어플리케이션 레이어 플러그인을 통한 복합적인 서비스 프레임 제공
(10) 훈련한 모델을 직접 서비스 할 수 있는 서비스 관리 기능 제공

Easy to use – AutoML & UI/UX

딥러닝에서 가장 노력이 많이 필요한 부분은 모든 데이터 기반 시스템이 그렇듯이 데이터를 수집하고 가공하는 작업이다. 그 다음으로 많은 노력이 필요한 부분이 알고리즘을 선택하고 선택한 딥러닝 알고리즘으로 주어진 데이터를 가장 잘 설명할 수 있는 하이퍼파라메터의 조합을 찾는 일일 것이다. 우리의 프레임웍은 데이터 가공과 같이 비지니스에 대한 사람의 인사이트가 필요한 부분을 제외한 나머지 부분을 Genetic Algorithm, Hyper Parameter Random Search, GPU Clustring 등을 통해 자동화하였다. 이러한 반복적인 작업의 자동화를 통해 사용자가 데이터에 대한 인사이트에만 집중할 수 있도록 해준다.

Easy to service – Micro Service Architecture

프레임웍을 통해서 훈련되고 평가된 모델을 모델을 실행하기 위해 필요한 데이터 전처리를 포함하여 모든 과정을 간단한 Configuration 과정을 통해서 Rest API 형태로 손쉽게 서비스 디바이스 혹은 서버로 연동하여 사용할 수 있는 기능을 지원한다.
이는 모델별 버전관리, 배치버전관리, 활성화 버전 관리 등 모델에 대한 정보관리와 서비스에 접근가능한 유저에 대한 권한관리 등을 포함하며 빠른 반응 속도록 위하여 사용하는 모델에 대해서 Caching 처리를 지원하며 Caching 처리를 위한 메모리 자원을 서버별로 관리하는 기능을 포함한다. 기타 서비스를 위한 Key 발급 및 사용량 제한 등 기능도 지원 예정이다.

Easy to MainTain – Continuous Training

처음 프로젝트를 수행할때 좋았던 모델이 시간이 흐르고 그 성능이 나빠지는 현상을 많이 경험해 보았을 것이다. 이는 주어진 환경과 데이터의 변화에 따라서 피할 수 없는 것으로 우리는 이러한 문제의 해결을 위하여 주기적으로 신규 데이터를 수집하고 모델을 평가하여 최선의 모델을 갱신하는 기능을 제공한다. 이를 통해 업무 환경의 변화에 따른 미묘한 차이를 계속해서 모델에 반영할 수 있도록 하고자 한다.

Easy to Extends – Application Layers

많은 현실 세계의 문제들은 단순하게 신경망하나로 해결할 수 없는 경우가 대부분이다. 이러한 문제들중에 챗봇과 같이 공용화하여 서비스 가능한 부분들을 어플리케이션 레이어라는 이름으로 관리하여 딥러닝 레이어에서 개발된 각각의 신경망을 어플리케이션 레이어에서 연동하여 사용하는 형태로 확장성있는 서비스를 제공하고한다.현재 Frame Based ChatBot 을 구성하기 위한 봇빌더와 딥러닝 연동을 통한 모델 훈련 그리고 API를 통한 실제 서비스 연동 등을 제공하고 있으며, 지속적으로 이러한 어플리케이션 레이어를 추가해 가고자 한다.

Easy to Deploy – Packaged with docker image

우리의 프레임웍은 여러가지 역할을 하는(마스터, 트레인,서비스,디비 등) 으로 구성되어 있으며, 각 서버들간의 유기적인 연동을 통해서 실제 시스템이 서비스된다. 이러한 환경을 구성하는 것은 매우 번거로운 작업이 될 수 있기 때문에 우리는 우리의 솔루션을 도커 형태로 지속적으로 업데이트하여 제공하고 있으며, 사용자는 이를 활용하여 손쉽게 시스템을 구성하고 활용할 수 있다.

딥러닝 교육 자료 (Deep Learning Lecture)

인터넷에 많은 Machine Learning, Deep Learning 자료들이 존재하지만, SungKim 교수님의 모두의 딥러닝 강의를 듣고나면 그 다음 중급 단계가 없이 바로 고수들의 논문을 중심으로한 너무 어려운 이야기들만 난무하다보니 단계적으로 학습을 이어가기가 어려운 경우들이 있다고 생각합니다.  그래서 Tensorflow 기초부터 이미지, 정형, 자연어 데이터 그리고 ChatBot 을 통한 실무 적용까지 조금더 접근할 수 있는 중급 교육을 기획하여 SK Planet 에서 8월 3주간 교육을 진행하였으며 그 교육 자료와 소스코드를 여러분들에게 공유합니다.

(1) Deep Learning & Tensorflow 기본

딥러닝을 접하기 위해 필요한 Python 필수 라이브러리(Numpy, Pandas 등)에 대한 설명 및 Tensorflow 기본 문법 그리고 딥러닝의 기초에 대해서 설명합니다.
딥러닝을 단편적인 시각이 아닌 전체적인 Work Flow 관점에서 이해하고 접근 할 수 있도록 큰 시각을 제공하고자 합니다.

이태영
managingc@gmail.com

Tensorflow for Deep Learning(SK Planet)

SK Planet 강의 자료 (2017.08.07/2017.08.09)

Source: www.slideshare.net/taeyounglee1447/tensorflow-for-deep-learning?from_m_app=android

(2) Docker 활용 DL 서비스 환경 구축 및 정형 데이터 분석

 Docker Compose 를 활용한 Deep Learning 개발 및 서비스 환경 구축을 통해 Python 기반으로 데이터를 수집, 전처리, 저장하고 모델을 생성하여 서비스하기 위한 전체적인 파이프라인을 구축 할 수 있도록 한다. 또한 정형데이터 분석을 통해 좋은 모델을 만들기 위한 Insight 와 최근 Kaggle 등에서 Hot 한 ML 알고리즘인 Bagging, Xgboost 를 활용한 정형데이터 모델링과 딥러닝 (Wide & Deep) 을 활용한 모델링을 소개하고 비교할 수 있도록 한다.

백지현
intwis100@gmail.com

Tensorflow service & Machine Learning

Django + Celery + Tensorflow Serving Machine Learning Bagging Boosing Deep Learning

Source: www.slideshare.net/JEEHYUNPAIK/tensorflow-service-machine-learning

 

(3) 실무에서 만나는 이미지 DL 분석을 위한 접근방법

 실제 업무에서 만나는 이미지 데이터는 우리가 예제로 많이 알고 있는 Mnist, Cifar 등을 분석할때와는 많은 차이가 있다. 생각처럼 좋은 모델이 나오지 않는 경우가 대부분일 것이다. 실제 이미지를 LMDB나 HDF5 같은 포맷으로 변환하여 저장하고 각종 Augmentation 기법을 사용하여 데이터를 보충하고 Object Detection, Denosing Auto Encoder 등을 활용하여 이미지를 정재하고 최적의 모델을 만드는 일련의 과정을 설명

김영재
youngjaekim0129@gmail.com

Image Deep Learning 실무적용

Image Deep Learning 실무적용 전처리 학습 평가 Service

Source: slideshare.net/YoungjaeKim42/image-deep-learning

(4) NLP 프로세스와 Deep Learning 적용

 자연어처리를 위해 우리가 해결해야 할 문제는 간단한 스팸분석부터 Sematic Search 와 같이 사람의 말을 의미적으로 이해해야하는 문제까지 다양하다. 여기서는 우리가 자연어분석하는 정석적인 프로세스에 대해서 이야기하고자 한다. 일반적으로 우리가 자연어를 분석할때는 Speech Recognition > Lexicical Analysis > Syntatic Analysis > Semantic Analysis > Discourse Analysis 의 단계로 분석이 이루어지게 되며각각의 Step 에서 또다시 다양한 문제와 해결 방법들을 제시하고 있는데 가장 핵심적인 방법들을 위주로 각각의 STEP 이 왜 중요하고 어떤 어려움이 있으며 DL 을 활용하여 어떻게 접근하는지 설명하고자 한다.

김승우
tmddno1@gmail.com

NLP Deep Learning with Tensorflow

Understand what is natural language process and how can we approach this problem with deep learning especially using google tensorflow

Source: www.slideshare.net/mobile/ssuser2294b5/nlp-deep-learning-with-tensorflow

 

(5) NLP 를 활용한 ChatBot 및 Ontology 실무적용

 NLP 자연어 처리 프로세스를 통해 기계가 이해할 수 있도록 사람의 언어를 분석하고 이것을 서비스 아키택쳐 측면에서 어떻게 응용하고 서비스에 접목하여 응용할 수 있는지
다양한 Step by Step 소스코드와 Docker Compose 환경 (Django, Celery, Neo4j) 등 다양한 실제 서비스에 활용되는 기술들을 활용하여 간단한 데이터 수집(Information Extraction) 부터 Frame Based Chat Bot 예제까지 직접 개발하고 설명한다.

김수상
healess@naver.com

Python과 Tensorflow를 활용한 AI Chatbot 개발 및 실무 적용

도입 AI Chatbot 소개 Chatbot Ecosystem Closed vs Open Domain Rule Based vs AI Chat IF Flow and Story Slot AI기반의 학습을 위한 Data 구성 방법 Data를 구하는 법 / Train을 위한 Word R…

Source: www.slideshare.net/mobile/healess/python-tensorflow-ai-chatbot

 

실습 소스코드

TensorMSA/tensormsa_jupyter

tensormsa_jupyter – Jupyter notes for education

Source: github.com/TensorMSA/tensormsa_jupyter

Build the RIGHT thing for Agile

Agile 개발을 위해 Things to keep doing

페어링, TDD (테스트기반 개발), 개발자 중심의 의사 결정 – 특히 기술적인 부분 관련 (개발 도구나 환경의 선택 등), 리펙토링 권장하기, 매일 아침 스탠드업, 주간 레트로 (레트로 스펙티브), 주간 IPM (이터레이션 미팅), PM의 피처 수락하기, 팀이 함께 앉기, 주간 사용자 인터뷰 및 테스트, 디자인 리뷰, 페이퍼 wireframe, epic을 작은 단위의 story로 나누기, Story의 난이도 및 스코어리에 대해서는 개발자들이 산정하기, 그리고 마지막으로 탁구(탁구대가 있다는 가정하에ㅋ)

대기업의 경우 사업 분야 자체가 굉장히 다양하고 복잡하기 때문에, 이를 고려하여 D&F (디스커버리 / 프레이밍)을 자주 실시하는 것이 중요합니다. 이를 통해서 팀 안에서 공통된 이해(shared understanding) 를 유지하고 사용자의 마음이 되어 이를 공감(empathy)하고 확산하는 과정이 중요합니다.

위험 요소들 (Risks)

조직을 변화시키고 교육시키는 부분 Organization transformation and enablement 큰 조직을 대상으로 프랙티스를 실시하고 프로세스를 바꾸려면 많은 시간과 노력이 필요합니다. 작은 팀부터 시작하세요. 작은 팀 안에서 프로젝트 및 프로세스등에 대한 자율성을 보장하고, 새로운 멤버들과의 pairing을 통해서 지식을 공유하는 것이 가장 효과적입니다. 이를 통해서 프로세스를 경험한 멤버들이 또다른 멤버들과 다시 pairing 함으로 점점 더 많은 사람들과 함께 지식을 공유할 수 있습니다.

지속가능한 페이스(속도) Sustainable pace

Pivotal labs의 프로세스는 굉장한 집중력을 필요로 합니다. 따라서 해당 프로세스로 업무를 진행하는 경우 해당 팀의 멤버는 담당 프로젝트만 집중할 수 있는 환경을 만드는 것이 중요합니다. 가능하면 다른 업무들로 인한 방해 없이 매일 정해진 시간 동안 일하는 것이 좋습니다. (예: 하루 8시간)

Balanced Team to your team

PM(프로덕트 메니져), 디자이너, 개발자는 지속적으로 팀을 유지해서 계속 일하는 것을 권장합니다. 지금까지 경험한 프로세스를 실제로 수행하기 위해서는 위의 세가지 업무가 긴밀하게 협동하는 것이 절대적으로 필요합니다. 서로의 도움 없이는 어느 누구도 제대로 임무를 수행할 수 없습니다. 더불어, 위의 각 업무를 담당하는 사람이 끝까지 자신의 업무에 집중해서 수행하는 것이 가장 효율적입니다.

새멤버 교육 Teaching process to others at team

가장 좋은 교육방법은 “같이 하는 것” 입니다. 각 업무 별로 (PM, 디자이너, 개발자) 새 멤버들을 영입하여 페어링을 시작하기를 권장합니다. 그렇게 함으로써 본인이 배운 것을 재확인하고, 또 널리 전파하는데 도움이 될 것입니다.

윈도우즈 환경 Windows

Windows를 이용하는 것에 대해서 다양한 방법이 있습니다. 각각의 안을 확인하기 전에 제한된 시간을 정해놓고 시작하세요. 윈도우즈로 해결이 되지 않는다면, 버츄얼머신에 리눅스를 운용하는 것도 방법이 될 수 있습니다. 각각의 방법에 사용한 시간을 기록해서, 윈도우즈로 통한 개발과 버츄얼머신을 이용한 개발의 비용을 비교하면 선택에 많은 도움을 줄 것입니다.

디자이너는 MAC으로 바꾸길 권장합니다. Sketch혹은 zeplin등의 어플은 디자인 작업에 걸리는 시간을 단축시켜 주며, 개발자 및 PM과의 협업 도 훨씬 유용하게 도와줍니다. Sketch같은 경우는 MAC에서만 동작하고 Zeplin의 경우도 MAC 어플에서 100퍼센트의 성능을 발휘할 수 있습니다.

CI plan

당장 씨아이(CI) 툴 한가지를 정하고 사용 시작하세요. Team City, TravisCI, CircleCI, Concourse 등 여러가지 옵션에 대해서 이미 논의했지만, 구체적인 계획은 정하지 않았습니다. 자체 호스팅 (예: Team City)을 하려면 서버 구성(configuring)을 해야하는 번거러움이 있지만 추가비용이 들지 않고, 외부호스팅을 (예:Travis CI) 하면, 서버구성의 번거로움은 없지만 비용이 듭니다.

샘플데이터 문제  currently using sample data

최대한 빠른 시일내에 앱과 실제데이터를 연결하세요. 샘플데이터를 기반으로 개발할 경우, 시간이 지날수록 나중에 실제 데이터소스 및 API를 연결했을 때 오작동이 발생할 리스크가 커질 수 밖에 없습니다. 앱과 그 API(실제데이타와 연동되는 API)를 연결하는 작업을 최우선으로 진행하십시오. 만약 해당 프로젝트의 진행 상의 이슈로 관련 API가 아직 준비되지 않았다면, 현재 가능한 다른 방법으로 실제 데이터를 연결하는 작업을 우선시 해야 합니다.

유저에 대한 “공감” 과 관심을 유지 Maintain empathy and concern for your user

프로젝트를 진행하면서 무의식적으로 언제나 “가설”을  만들어냅니다. 사용자를 대신해서 프로젝트 내부적으로 설정된 가설은 가능한 빨리 검증되여야 합니다. 그래야 사용자에게 필요한 제품을 만들 수 있기 때문입니다. 실제 문제를 해결할 수 있는 버전의 앱을 사용자들에게 가능한 빨리 릴리즈하십시오.

기술(테크놀로지) 선택 Technology choices.

언제나 최신이면서 안정된 버전의 개발 언어와 개발 도구를 사용하길 권장합니다. 모든 기능들에 대해서 보안 및 여러가지 이슈들 그리고 다양한 커뮤니티의 지원을 받기 위해서는 최신의 버전을 사용하는 것이 유리합니다. 또한 각 프로젝트마다 어떤 개발 언어 및 도구들을 사용할 지에 대해서는 프로젝트에 대해서 가장 많은 정보를 가지고 있는 개발자 들에게 선택 권한을 주세요.

DL Trend ‘17.7.9

Deep Learning 관련하여 요즘 관심있게 보는 기술들.. 시간이 없어서 정리는 못하지만, 이렇게 기록해 놨다가 천천히 하나씩 블로그에 작성할 예정 ..

1 . Android Tensorflow 
Java 버전 Tensorflow를 완벽하지는 않지만 링크와 같이 지원하고 있는데 [링크] 
역시 Android 에서 Tensorflow 도 지원한다  [링크]
Python 과 비교하여 완벽한 기능을 제공하지는 못할 것으로 예상되지만, Java 개발자들이 워낙 많기 때문에 가장 대중적인 신경망들 위주로 충부한 의미가 있을 것 같다.
찾아보니 아주 간단하게 Tensorflow 에서 훈련한 모델을 Android 에 심어서 개발하는 튜토리얼도 존재한다. [링크]

2. Quantize Neural Network 
훈련할때와는 다르게 예측할때에는 어짜피 내부적으로 잡음 (여기서는 소숫점 이하)는 버려버리는 특성이 있으니, 모델을 만들때 애초에 정수화해서 저장함으로써 용량을 줄이고 모바일에서의 속도와 관련된 이슈들을 해결해 보자이런 이야기 인듯 함 [링크]

3. Segmentation & Object Detection 
보통 CNN 을 보면 Input Matrix 의 사이즈가 정해져 있기 때문에 RCNN 같은 Object Detection을 해보면 결과물이 해당 물체와 그 주변을 포함한 사각형 이미지가 되기 마련인데 이러한 문제를 보완하여 해당 사물만 Pixel 단위로 정확히 추출하기 위해 나온 방법이 Segmentation 이라고 함.   [링크]
이러한 목적을 달성하기 위해 나온 신경만 구조가 있는데 U-Net 이라고 한다. [링크]

4. VAE (variational autoencoder)
코드 관점에서 보면 흔히 알고 있는 Stacked Auto Encoder 가 일반적인 Vector를 그냥 Input 에 넣는다고 하면, Variational Autoencoder 는 확률 분포를 Vector 로 표현해서 잡음처럼 추가하여 넣어준다. 이렇게 하면 Prediction 때 Input 의 확률 분포를 Random 하게 조작함으로써, 무언가를 Generation 하는 효과를 얻을 수 있다. [링크][링크]

5. YOLO (You Look Only Once) 
Object Detection 을 하는 방법에는 RCNN, Fast RCNN 등 여러가지가 있지만, 실시간성이 중요한 CCTV 나 자율자동차 등에서는 이미지 한장을 여러번 탐색하는 과정을 거치는 기존 알고리즘들의 속도가 만족스럽지 않다. 그래서 한장의 사진을 구획으로 나눠 단 한번만 각 구획단위 평가를 한후 , 구획간의 조합을 통해 Object Detection 을 하여 속도를 비약적으로 향상시킨 YOLO 같은 것이 유용하다. [링크] [링크]

6. AutoML
최근 Google 에서는 주어진 데이터에 알맞는 Neural Network 의 구조를 자동으로 탐색하는 알고리즘에 대해서 이야기하는데, 필요한 Computing Power 를 줄이기 위한 다양한 알고리즘들을 이야기 하고는 있지만 궁극적으로는 무지막지한 TPU(GPU 상위버전)을 통해 엄청난 반복을 통한 것으로 아직은 DL Engineer 의 자리를 위협할 수 있는 물건은 못된다. [링크] 
반면에 신경망을 최적화하기 위해 중요한 Hyper Parameter Tunning 작업 같은 경우 많은 연구가 이루어져 왔는데, Hyper Parameter Random Search [링크]
Genetic Algorithm 을 활용한 근사 최적 Hyper Parameter Set 의 탐색 [링크]
당연하게도 복수의 GPU 서버를 활용한 전체적인 작업 시간의 단축 등으로 자동화가 가능한 추세라고 볼 수 있다.  이미 Cloud 서비스로 제공하고 있는 Google 의 Cloud AI 에서도 보여지고 있는 기능이다. [링크]

7. GAN  (Generative Adversarial Model)
요즘 너무 Hot 에서 아마 모르는 사람이 없을 것 같은 슈퍼스타급 알고리즘
개인적으로 생성모델인데, 생성 모델을 만들기 위해서 너무 많은 데이터가 필요하다.
Classification 모델을 만들기 위해 부족한 데이터에 사용하기에도 애매하고, 실무에 사용하기에는 애매한 녀석이지만 우선 아이디어가 매우 Hot 하다. 생성하는 모델과 (Generator) 와 생성된 데이터를 검수하는 녀석(Adversarial)이 서로 경쟁하며 성능을 개선해 간다는 것이 주요 아이디어. [링크]

8. Deep Q Learning
통상적으로 Reinforcement Learning 이라고 하면 Q-Table 을 활용한 알고리즘을 생각하는데 최근(이제는 좀 오래전..)에 Google 에서 Q-Table 대신에 Deep Learning 을 활용하는 방법을 내놓았으며, 이것이 Deep Q Learning 이라 불리는 듯하다.  기본적인 Environment, Action, Reward, State 등으로 구성되는 사상은 유사지만, Deep Learning 을 Reinforcement 에 적용하려면 해결해야 하는 두 가지 문제 (1. Corellation / 2.Non Stationary Target 문제) 를 해결해야 하는데 각각 Buffer 와 Sampling 그리고 별도의 Network를 만들고 주기적으로 Copy하는 방법으로 해결한다. 자세한 내용은  역시 성킴 교수님의 모두의 연구소 자료가 좋겠다. [링크]

Collaborative hyperparameter tuning

– 논문 링크 : Link  (Collaborative hyperparameter tuning <2013>)
 – 적용 구현 : Link

1.Hyper Parameter Tunning 
HyperParameter Tunning 은 ML 에서 매우 중요한 Step이다. (Pintoet al. 2009, Coates et al. 2011, Bergstra et al. 2011,Snoek et al. 2012, Thornton et al. 2012)
논문에 따르면 새로운 알고리즘 없이 기존의 존재하는 알고리즘의 hyper parameter를 조정하는 것만으로도 성능향상을 가지고 왔다는 연구 결과도 있다.
이러한 Hyper Parameter 의 조정은 보통 사람이 수동으로 수행하고는 하는데, 이러한 과정들을 자동화 할 수 있는 방법들은 많이 연구 되어 왔고 이미 실제 적용이 가능한데 대표적인 방법으로 아래와 같은 것들이 있을 수 있겠다.
–  local-search based methods (ParamILS of Hutter et al. 2009)
– estimation of distribution methods (REVAC of Nannen & Eiben 2007)
– surrogate-based methods (Hutter, 2009)
– surrogate method deep neural network 에 적용 Bergstra et al. (2011)
– WEKA Package 적용 , Thornton et al. (2012)
이러한 자동화된 Hyper Parameter 튜닝 방법이 존재함에도 경험 많은 Engineer 들은 여전히 그들만의 방법으로 튜닝을 진행하는데, 예를 들면 성공적으로 MNIST 데이터를 튜닝한 Hyper Parameter set 을 보유하고 있을때, 약간 변형된 MNIST 에 기존에 성공적으로 MNIST 모델을 생성했던 Hyper Parameter 에서 Insight 를 얻어서 새로운 변형된 MNIST 데이터에 적용을 시작하는 등 방법이 있을 수 있겠다.
이 논문에서 제안하는 바는 surrogate 방법과 사람이 기존의 데이터에 대해 가지고 있는 Hyperparameter 에 대한 Insight 를 적용하는 것을 융합하는 방법이다.

About AI

  • AI 어디까지 왔는가?

도입-

“AI는 1950년대부터 존재하던 학문이다, 다만 최근에 들어 Google Deep Mind 의 효과적인 AlphaGo 마케팅으로 기존에 관심이 없던 많은 사람들도 주목하기 시작했다. 그렇다면 인류역사상 가장 복잡한 게임이라는 바둑마저 정복한 AI는 이미 사람을 넘어선 것인가? 많은 언론이 이야기하는 것처럼 AI 가 인간을 대체하는 날을 걱정해야 하는 수준에 온 것인가? AI 의 현주소와 우리의 대응에 대해서 이야기해보고자 한다. “

  • AI의 역사와 암흑기
    ai timeline에 대한 이미지 검색결과

현대 AI 의 연구는 1950년대부터 시작되었다. 그 당시의 AI 연구자들은 인간수준의 AI를 수십년안에 만들 수 있을 것이라고 생각했으며, 당시 선구자였던 Herbert A.Simon은 1965년에 “앞으로 20년안에 기계는 인간이하는 모든 일을 할 수 있게 될 것” 이라고 말했다. 하지만 1970년대에 들어 AI 연구자들은 인간수준의 AI를 만드는 일이 얼마나 어려운 일인지 과소 평가했다는 것을 깨닫게 된다. 시장은 점점 실용적인 AI 개발에 대한 요구를 하게 되고, AI 에 대한 기업과 사회의 시각이 점점 회의적으로 바뀌면서 AI에 대한 지원도 끊기게 된다. 1980년대 Expert System (Rule Base AI)를 통해 어느 정도의 성공을 거두면서 AI 에 대한 불씨를 살리는가 했으나, 결국 1980년대 AI시장은 완전히 붕괴하고, AI 는 암흑기에 빠지게 된다.

1-2 현대의 AI

21세기에 들어 AI 는 GPU가속을 이용한 연산속도의 비약적 발전, Big Data 처리 기술의 발달에 따른 Deep Learning(Deep Learning (Machine Learning <기계학습>의 한 분야로 2부에서 설명예정) 알고리즘의 재조명을 통하여 이미지 인식, 자연어 인식, 음성인식 등 기존에 잘 해결하지 못하던 문제를 해결하며, 제 2의 전성기를 누리고 있다.

[음성인식에서의 성능 향상]

deep learning voice recognition에 대한 이미지 검색결과

기존의 음성인식 알고리즘으로 애러율이 13% ~ 15% 에 달하던 성능을 Deep Learning 을 도입하면서 5% 미만으로 극적으로 개선하면서 그 우수성을 증명하였으며, 최근에는 Amazon Alex 와 같은 인공지능 스피커를 통해서도 AI를 실생활에서 느껴볼 수 있다.
이미지 인식에 있어서는 Deep Learning은 2016년 기준 사람의 수준에 근접한 인식률을 보여줄 정도로 발전되었다.

[AI 의 이미지 인식 정확도]

ILSVRC2016에 대한 이미지 검색결과출처 : ILSVRC2016 (http://image-net.org/challenges/LSVRC/2016/results)

또, 컴퓨터가 인간을 이길 수 없다고 알려진 바둑에서 세계 정상급 프로 선수인 이세돌 9단을 4:1로 이긴 AlphaGO 또한 MCTC(Monte Carlo Tree Search) 와 Deep Learning 을 복합적으로 활용하여 Game 에서의 AI 의 가능성을 증명하였다.

1-2현재 AI 의 수준은?

그렇다면 현재 AI 는 정말 인간을 대체할 만큼 발전한 것인가? 우리는 우리의 일자리를 두고 기계와 경쟁을 해야 하는가? 이 질문에 대답하기에 앞서서 AI 의 단계 구분에 대해서 설명하고자 한다.

(1) Narrow Artificial Intelligence
(2) General Artificial Intelligence
(3) Super Artificial Intelligence

Narrow Artificial Intelligence 는 특정한 분야에 주어진 일만 처리할 수 있으며, 그 일을 처리할 수 있는 똑똑한 AI 가 되기 위하여 많은 데이터 전문가, AI 전문가, 비즈니스 전문가가 많은 시간을 투자하여 좋은 AI를 만들어야만 하는 단계로 우리가 영화에서 보는 것과 같은 수준의 AI 와는 많은 거리가 있는 단계라고 볼 수 있다.

General Artificial Intelligence 는 컴퓨터가 인간처럼 스스로 학습하고, 생각하는 수준을 이야기하는 것으로 평균적인 인간수준의 지능을 갖춘 AI 단계라고 볼 수 있다. 기계의 사고 유무를 판단하기 위한 기준으로 1950년대 앨런튜링은 “컴퓨터로부터의 반응을 인간과 구별할 수 없다면 컴퓨터는 생각할 수 있는 것” 이라는 정의를 하고 Turing Test 라는 것을 고안하였으나, 현대에 와서는 기계의 사고유무를 판단하는 방법으로 부족하다는 의견이 대두되고 있다.

Super Artificial Intelligence는 영화 Avengers에서 아이언맨이 인공지능 비서인 자비스와 같은 수준을 생각하면 될 듯 하다. 가장 훌륭한 인간의 뇌보다도 더 뛰어난 수준으로 인간이 초월하는 수준의 인공지능으로 실질적으로 사람이 AI 에 지배 받는 것을 걱정해야 하는 수준이 바로 이 수준이 될 것이다turing test에 대한 이미지 검색결과

그렇다면 현재 AI 는 Narrow, General, Super AI 중 어떤 단계에 있는 것일까?
우선 General Artificial Intelligence를 판단하기 위한 테스트 방법으로 가장 유명한 Turing Test 의 결과를 한번 살펴보자

[그림. Turing Test 란?]

Turing Test 사람들 사이에 기계를 넣어 놓고, 온라인 통신 Chatting system을 통해 심판들이 5분간의 대화를 진행하여 30% 이상의 심판을 속일 수 있는가 없는 가를 테스트하는 것으로, 2014년 최초로 Eugene(우크라이나 13세 소년 역할 부여)가 Turing Test를 통과하였다. 그렇다면, 우리의 AI 기술은 사람처럼 생각하는 General AI 의 수준에 도달한 것인가?

아래는 2014년 테스트 당시의 대화 내용의 일부이다. 대화 내용을 보면 정말 Eugene 이 사람처럼 느껴지는가?

사실은 영어가 익숙하지 않은 13세 소년의 역할부여, 지속적으로 특정 주제로 유도하는 트릭 사용 및 어떠한 상황에도 사용할 수 있는 두리뭉실한 표현들을 주로 사용하는 등 테스트 자체를 통과하기 위한 수 많은 Trick 이 주요하였으며, 기술적으로 생각하는 AI를 만들어 Test를 통과한 것과는 거리가 멀다는 것이 대부분 관계자들의 생각이다.

[2014 Turing Test를 통과한 Eugene]turing test eugene conversation에 대한 이미지 검색결과

출처 : Times (http://time.com/2847900/eugene-goostman-turing-test/)

몇 가지 이야기를 더 해보자, General AI 정의에서 가장 큰 특징은 스스로 학습하고(사람이 데이터 수집, 모델링 등 개입 하지 않음), 상황에 맞는 다양한 일들을 수행할 수 있는 범용성에 있다. 그렇다면 최근에 가장 크게 화두가 된 AlphaGO 는 바둑을 스스로 배웠는가? 아니면 수많은 프로그래들의 노력이 투입되어 바둑을 학습 시켰는가? AlphaGO 는 바둑에서는 세계수준의 Player 인 이세돌을 격파할 정도로 뛰어난 능력을 가지고 있는 것은 분명하지만, 바둑 이외의 일도 할 수 있는가? AlphaGO는 Narrow Artificial Intelligence 의 전형이라고 볼 수 있으며, 결론적으로 현재 우리가 사용하고 있는 AI 는 모두 우리가 생각하는 General AI 와는 거리가 먼 Narrow AI라고 생각하면 된다.

1-3 Path to General AI

스스로 학습하고 생각하는 사람 수준의 AI가 언제쯤 어떠한 형태로 개발될 것인지 묻는다면, 정답을 말 할 수 있는 사람은 없을 것이다.
하지만, Weak AI 에서 Strong AI로 진화하기 위해 필요한 요소들을 도출해 보면 그 난이도와 소요 시간은 짐작할 수 있을 것이다.

(1)Computing Power

Artificial Intelligence 란 기본적으로 인간의 뇌가 사고하는 방식을 모방하는 것이기 때문에 인간만큼 복잡한 생각을 하기 위해서는 인간의 뇌만큼 복잡한 인공 신경망을 연산할 만큼의 Processing power 는 기본적으로 필요할 것이다. 인간의 뇌는 10^11의 뉴런을 가지고 있으며, 아기의 경우 10^15 의 뉴런을 가지고 있다고 한다.
인간의 뇌를 시뮬레이션 할 정도의 컴퓨팅 파워를 갖게 된다고 General AI를 달성할 수 있는 것은 아니지만 그 정도의 Computing Power는 필수 요건이라고 생각되며, 비용 및 H/W 최소화를 고려하지 않을 경우 원하는 Processing Power 를 달성하기까지 10년 정도의 시간이 소요될 것으로 예측하지만, 이 또한 소형화 전력소모 등을 고려하면 양자컴퓨터와 같은 다음 세대의 기술이 필요할 가능 성을 배제할 수 없다. Estimates of how much processing power is needed to emulate a human brain에 대한 이미지 검색결과

[Estimates of how much processing power is needed to emulate a human brain at various levels (from Ray Kurzweil, and Anders Sandberg and Nick Bostrom)]

(2) Self Learning & Reasoning

General AI로 가기 위한 방법은 크게 Top Down 방식과 Bottom Up 방식이 있을 수 있겠다. Top Down 방식이란 지금까지 AI를 틀을 완전히 깨고 새로운 시각에서 General AI를 바라보고 연구하는 것이고, Bottom Up 은 지금까지 우리가 해결해 왔던 수많은 문제의 해법들을 모아서 궁극적으로 General AI를 달성하는 방안이다.
AI 에 제 2의 전성기를 열어준 Deep Learning 이 General AI로 가는 문 또한 쉽게 열어줄 것인가? 아니면 또 다른 패러다임의 변화가 필요할 것인가
어떤 방향이던지 1950년대 인공지능 학자들이 20년이면 General AI 에 도달 할 수 있을 것이라 확신하였던 오판을 되돌아보면, 그리 쉽지 않을 길이 될 것이라는 것이 명확하다.

(3) Robot technology
진정한 General AI 의 완성은 외부 환경과 상호작용 가능한 물리적인 Robotic Body 와 Software 적인 AI 의 결합이라고 볼 수 있다.
결국 궁극적인 General AI는 Software Algorithm 의 발전만으로 달성할 수 있는 것이 아니며, 산업전반의 모든 연관 기술들이 전반적으로 발전되었을 때 달성 가능한 목표인 것이다.

1-4 우리의 대응은 ?  

진정한 AI로 가기 위해서는 산업 전반의 모든 기술들이 전반적으로 발전해야 하며, 너무 많은 기술적인 난관들이 존재하기 때문에 General AI 는 당장에 우리에게 다가올 현실은 아닐 것이다.
때문에 향후 몇 년은 누가 더 Narrow AI 를 잘 활용할 수 있는 CASE를 발굴하고 먼저 적용하는지가 관건일 것이다.

[우리가 준비해야 할 것들]

  • Infrastructure : 클라우드 서비스 등
  • Data Management : Big Data 관리 기술
  • AI Frame Work : 업무 특화 F/W 개발
  • Business Apply : 비지니스 적용을 위한 Insight

하지만, 얼마나 많은 노력과 시간이 소요되더라도, General AI를 향한 인간의 탐구는 멈추지 않을 것이며, 결국에는 도달할 미래라고 생각된다.
장기적으로는 당장은 AI 와 관련이 없는 것 같은 기술도 궁극적인 General AI 를 생각하면 결국에는 관련이 있다는 점을 염두하고 향후 General AI 도달에 중요하다고 생각되는 분야를 사전에 예측하고 투자할 필요가 있다.

Pair Programing in Pivotal Labs

# Pair Programing

– Programming 능력의 상향 평준화, 개발인력 변동시 에도 Project 영향도 적음
– Driver 역할의 개발자가 Test Code를 개발하고  이어서 다른 개발자 Implementation Code 개발
– 시스템 Error 감소 및 테스트 문서 최소화 가능

## 장점
– Test 문서대신 Script Code 로 대체가능
– Script 코드 품질향상 도모
– 시스템 변경 시 Test 코드로 이상여부를 Check 함으로써 Manual Test 필요없어 시스템의 유지보수 가능
– User Story에 집중하여 Outside-In 방식으로 개발
– 사용자 관점으로 개발, 테스트함으로써 시스템 수정을 줄임(BDD – Behavior Driven Development)
– 선진 Software 회사들은 대부분 TDD/BDD 방식 적용 (Test코드는 선택이 아닌 필수)

## 역량
– 집중력 향상
– 개인 역량 향상
– 능력의 상향 평균화
– 팀워크 향상
– 개인의 능력 투명(동료평가가 이루어짐)
– 핵심요원의 지식이 자연스럽게 전수

## 생산성
– 개발 집중력 향상
– 컴포넌트 형 개발(TDD Based)
– 소스 Re-factoring이 쉬움
– Test Automation
– 재작업 빈도 감소
– 결함 감소, 품질 향상

## 단점
– 초기 생산성 낮음(테스트 코드등 기본 뼈대 구축)
– 개발자 피로도 증가
– 갈등 회피 불가
– 적응 불가능 개발자 존재 시 원활한 진행 불가

deep learning cluster with aws -1-

Deep Learning Cluster를 구성하기

AWS GPU는 비싸다. 평소에는 CPU로 훈련하다가, GPU 자원을 활용하고 싶을때 어떻게 하면 좋을까?  GPU 인스턴스가 올라오면 자동으로 클러스터에 포함되고, 명령을 내리면 GPU에서 훈련하고,  훈련이 끝나면 모델은 공유디스크에 저장되고, GPU를 반납한다. Predict는 싼 CPU 인스턴스에서 하고, 필요할때만 GPU인스턴스를 사용하면 비용도 절감되고, 일석 이조이다.

개요는 디스크를 nfs로 공유하고(NAS나 Storage를 쓰면 좋겠지만 돈 없음), Job을 배분해주기 위하여 RabbitMQ와 Celery를 올리고, Rest를 통해 실행 명령을 내리면 Train  Job이 기동되는 형태로 구성할 예정이다.

TensorMSA Docker에는 기본으로 위 서비스들이 설치 되어 있기 때문에 TensorMSA Docker를 활용하여 구축하도록 한다.

<구성도 추가예정>

  • 목표와 작업순서
    Aws Instance 생성 cpu2개, gpu 2개
    Master Server에서 nfs 서비스 설치 및 Slave Server Directory Mount
    Cpu 인스턴스에 docker 설치, GPU 인스턴스에 Docker + Ndivia Docker 설치
    Cluster 연결을 위한 TensorMSA Docker 설정
    Cluster Test
  • AWS Instance 생성
    cluster를 구성하기 위하여 AWS에서 Instance를 생성한다.
    m2.xlarge  2대, P2.large 2대를 생성한다. 생성방법은 인터넷에 많이 있어요.
  • Nfs 서비스 생성
    우리는 훈련을 GPU Train서버에서 하고, Predict은 CPU서버에서 해야 하기 때문에 공유디스크를 설정해야 하는데 NAS나 SAN Storage를 쓰면 좋을텐데 돈이 없으므로 nfs서비스로 연결하도록 한다.
  • nfs 서비스 설치! 간단하게 설치 된다
sudo apt-get install nfs-kernel-server
  • /hoya_src_root /hoya_model_root /hoyai_playground 3개를 공유디렉토리로 설정한다. 디렉토리를 만들고, 소유권한을 바꾼다.
sudo mkdir /var/nfs/hoya_src_root -p
sudo mkdir /var/nfs/hoya_model_root -p
sudo mkdir /var/nfs/hoya_str_root -p
sudo mkdir /var/nfs/hoyai_playground -p


sudo chown nobody:nogroup /var/nfs/hoya_src_root
sudo chown nobody:nogroup /var/nfs/hoya_model_root 
sudo chown nobody:nogroup /var/nfs/hoya_str_root
  • /etc/exports 파일에 nfs 설정을 한다. RW(읽고 쓰고), sync(다 썼을때 회신)
    아무나 접속하는것을 막기 위해서 IP를 넣어서 지정된 IP만 접속하도록 설정한다.
    aws에서는 private ip는 고정 되므로 private ip를 사용하면 된다.
    public ip는 고정이 안될뿐더러 e-ip로 고정한다 할지언정 데이터를 쓰다가 트래픽이 인터넷구간으로 나가면 aws에서 network비용을 청구하므로 조심해야 합니다.
    예전 하둡 클러스터를 잘못 설정해서 network 비용이 100만원이 나온 기억이 나네요 ㅠㅠ
vi /etc/exports


/var/nfs/hoya_src_root   xx.xx.xx.xx(rw,sync,no_subtree_check)   xx.xx.xx.xx(rw,sync,no_subtree_check)
/var/nfs/hoya_model_root  xx.xx.xx.xx(rw,sync,no_subtree_check)   xx.xx.xx.xx(rw,sync,no_subtree_check)
/var/nfs/hoya_str_root   xx.xx.xx.xx(rw,sync,no_subtree_check)   
xx.xx.xx.xx(rw,sync,no_subtree_check)

  • nfs server설정이 끝났습니다. 다음에는 nfs를 gpu인스턴스에 연결하고 nvidia-docker를 설치해서 gpu instance를 올려보도록 하겠습니다 ^^service nfs-kernel-server reloadnfs service를 Reload한다.

Deep Learning Cluster with AWS for CPU

 

한국 지역 설정하기

sudo locale-gen ko_KR.UTF-8

tzselect

sudo apt-get install language-pack-ko

 

docker CE올리기

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

sudo apt-key fingerprint 0EBFCD88
sudo add-apt-repository \
  "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) \
  stable"


sudo apt-get update
sudo apt-get install docker-ce

도커를 ubuntu계정에서 실행하게 변경(리붓해야지 반영됨)

sudo groupadd docker
sudo gpasswd -a ubuntu docker

 

우리 도커를 다운 받는다.

docker pull hoyai/hoyai_dev_docker:squashed

 

1번 서버는 nfs server를 올린다.

sudo apt-get install nfs-kernel-server

 

nfs 마운트 포인트를 만든다

sudo mkdir /var/nfs/hoya_src_root -p
sudo mkdir /var/nfs/hoya_model_root -p
sudo mkdir /var/nfs/hoya_str_root -p
sudo mkdir /var/nfs/hoyai_playground -p


sudo chown nobody:nogroup /var/nfs/hoya_src_root
sudo chown nobody:nogroup /var/nfs/hoya_model_root 
sudo chown nobody:nogroup /var/nfs/hoya_str_root

nfs conf

vi /etc/exports


/var/nfs/hoya_src_root   xx.xx.xx.xx(rw,sync,no_subtree_check)   xx.xx.xx.xx(rw,sync,no_subtree_check)
/var/nfs/hoya_model_root  xx.xx.xx.xx(rw,sync,no_subtree_check)   xx.xx.xx.xx(rw,sync,no_subtree_check)
/var/nfs/hoya_str_root   xx.xx.xx.xx(rw,sync,no_subtree_check)   xx.xx.xx.xx(rw,sync,no_subtree_check)

nfs reload 한다

service nfs-kernel-server reload

 

AWS에서 nfs용 Security group을 설정한다.

 

TCPPort (Service) Source 111 0.0.0.0/0  2049 0.0.0.0/0  32768 0.0.0.0/0  44182 0.0.0.0/0  54508 0.0.0.0/0

UDPPort (Service) Source 111 0.0.0.0/0  2049 0.0.0.0/0  32768 0.0.0.0/0  32770-32800 0.0.0.0/0

 

  • gpu에서 ap1번으로 붙는지 테스트 해봄

 

Hoya Docker cluster용(AP용) seciruty group 설정

Port (Service) Source Port (Service) Source 4369 0.0.0.0/0  25672 0.0.0.0/0  5672 0.0.0.0/0  2266 0.0.0.0/0  5432 0.0.0.0/0  8000 0.0.0.0/0  6006 0.0.0.0/0  8888 0.0.0.0/0  5901 0.0.0.0/0  5555 0.0.0.0/0

도커를 실행하면서, nfs 포인트로 올리고, 부팅시 자동으로 올라가게 하고, vnc확인하고, host도 확인하고,

도커를 재부팅시 자동으로 올라가게 설정 도커 이름은 hoyai_dev로 설정한다

docker run -itd --env="VNC_RESOLUTION=1920x1080" --env="DISPLAY" --env="QT_X11_NO_MITSHM=1" --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" --volume="/var/nfs/hoya_src_root:/hoya_src_root" --volume="/var/nfs/hoya_model_root:/hoya_model_root" --volume="/var/nfs/hoya_str_root:/hoya_str_root" --name hoyai_dev -p 4369:4369 -p 25672:25672 -p 5672:5672 -p 2266:2266 -p 5432:5432 -p 8000:8000 -p 6006:6006 -p 8888:8888 -p 5901:5901 -p 5555:5555 hoyai/hoyai_dev_docker:squashed

 

도커가 자동으로 올라가게 설정한다.

cd /etc/systemd/system/
 vi docker_hoyai.service
[Unit]
Description=hoyai container
Requires=docker.service
After=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/docker start -a hoyai_dev
ExecStop=/usr/bin/docker stop -t 2 hoyai_dev

[Install]
WantedBy=default.target

도커 스타트업 스크립트

sudo systemctl enable docker_hoyai.service
   
   sudo systemctl start docker_hoyai.service

도커 서비스 삭제 스크립트

sudo systemctl disable docker_hoyai.service
  
  sudo systemctl stop docker_hoyai.service
sudo apt-get install nfs-common

 

도커 속에서 cluster 설정하기

hoyai/settings.py에서 DB를 AP1번을 보도록 설정

git에서 settings.py 추적 안하게 변경

git update-index --assume-unchanged hoyai/settings.py

 

각서버별로 장고가 뜨는지 확인

hosts파일을 만들어서 ap1, ap2, gpu1, gpu2에 배포

ssh를 활용해서 각각 서버에 붙는지 확인한다.

 

rabitmq cluster 연결을 위한 erlang cookie 맞추기

 

master에서 cooker를 보고, slave에 복사해준다

vi /var/lib/rabbitmq/.erlang.cookie

 

slave는 끄고

service rabbitmq-server stop

erlang cookie 복사하고

다시 스타트

service rabbitmq-server start

 

 

rabbitmq cluster를 확인한다.

rabbitmqctl cluster_status

 

hoya settings.py의 celery 설정 부분을 변경한다.

host는 master의 Docker id로 변경

CELERY_BROKER_URL = 'amqp://tensormsa:tensormsa@'+host+'//'

result_backend = 'db+postgresql://xxxxxxxxxxxxx'

 

entrypoint에 hosts파일 add하는것을 추가

echo "xxx.xxx.xxx" >> /etc/hosts

 

gpu1번을 ap1에 조인

rabbitmqctl stop_app

rabbitmqctl join_cluster --ram rabbit@16224139bcee


rabbitmqctl start_app

gpt2번을 ap1에 조인

rabbitmqctl stop_app

rabbitmqctl join_cluster --ram rabbit@16224139bcee

rabbitmqctl start_app

 

클러스터에서 빠지기

rabbitmqctl reset

 

 

 

 

 

 

 

client nfs 설치한다

sudo apt-get install nfs-common

 

부팅했을때 nfs가 자동으로 붙도록 설정

hoya_src_root, hoya_model_root, hoya_str_root 3개 디렉토리 설정

sudo mkdir /hoya_src_root -p
sudo mkdir /hoya_model_root -p
sudo mkdir /hoya_str_root -p

 

vi /etc/fstab
xx.xx.xx.xx:/var/nfs/hoya_src_root /hoya_src_root nfs hard 0 0
xx.xx.xx.xx:/var/nfs/hoya_model_root /hoya_model_root nfs hard 0 0
xx.xx.xx.xx:/var/nfs/hoya_str_root /hoya_str_root nfs hard 0 0

 

reboot 해서 df -h로 nfs가 잘 붙는지 확인한다

df -h

 

gpu Tensormsa Docker를 받는다

docker pull docker pull hoyai/hoyai_gpu_dev_docker:v1.0

 

gpu docker 를 실행한다.

nvidia-docker run -itd --env="VNC_RESOLUTION=1920x1080" --volume="/hoya_src_root:/hoya_src_root" --volume="/hoya_model_root:/hoya_model_root" --volume="/hoya_str_root:/hoya_str_root" --name hoyai_dev -p 4369:4369 -p 25672:25672 -p 5672:5672 -p 2266:2266 -p 5432:5432 -p 8000:8000 -p 6006:6006 -p 8888:8888 -p 5901:5901 -p 5555:5555 hoyai/hoyai_gpu_dev_docker:v1.0

docker 서비스를 올린다.

sudo gpasswd -a ubuntu docker

 

 

cd /etc/systemd/system/
 vi docker_hoyai.service

 

[Unit]
Description=hoyai container
Requires=docker.service
After=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/nvidia-docker start -a hoyai_dev
ExecStop=/usr/bin/nvidia-docker stop -t 2 hoyai_dev

[Install]
WantedBy=default.target

 

sudo systemctl enable docker_hoyai.service

sudo systemctl start docker_hoyai.service

 

sudo systemctl disable docker_hoyai.service

sudo systemctl stop docker_hoyai.service

 

AP1, GPU2, GPU2의 docker id와 IP를 찾는다.