System Compleat.

'2016/03'에 해당되는 글 4건

  1. bosh.io
  2. HPC on AWS
  3. Cloud9 IDE 에서 Cloud Foundry 로의 애플리케이션 배포 1
  4. 세월 빠르네 2

bosh.io

Techs


(younjin.jeong@gmail.com, 정윤진)


아마 Cloud Foundry 에 관심이 있는 분이라면 bosh.io 를 한번 정도는 방문 했을 것으로 생각된다. 그리고 개인적인 생각인데, OSS Cloud Foundry 를 설치 시도했다가 입을 쩍 벌리고 포기하신 후, 어머 이건 우리가 사용할 수 있는 물건이 아니야 라고 생각했던 분들도 많지 않을까 한다. 사실 이해가 당연히 되는것이, 나도 어디가서 뭐 설치는 정말 많이 해봤다고, 삽질 좀 해봤다고 자부하는데 이거 Cloud Foundry 는 처음 설치를 시도할때 정말 많이 애를 먹었다. 마치 2011년에 오픈스택을 설치하는 느낌. 문서는 버전별로 다르고, 각 문서에 소개된 도구가 다르고, 그 도구별로 또 다른 repository 가 존재하는건 정말 지옥중에 지옥이 아니었을까 한다. 





인터넷에 찾아보면 수많은 OSS CF 설치에 대한 글을 찾아 볼 수 있는데, 이 역시도 굉장히 out date 된 내용들이 많아서 참조하기가 매우 곤란한 경우가 많다. 그리고 거기에 나온 내용을 하나 둘 이렇게 저렇게 따라하다 보면 어느새 랩탑은 너덜너덜 거지꼴을 못면한다. 이 대표적인 이유가 bosh 는 아직 현재까지는 ruby 와 ruby gem 을 사용하여 구현 된 것을 사용해야 하기 때문이다. 


어쨌든 이놈의 bosh 라는 도구가 사용하기 와이리 힘드노 하는 이유를 간략하게 정리해 보자면 아래와 같다. 

  • 일단 ruby 기반이다. 뭐 하나 시키면 더럽게 느려서 결과를 볼 때까지 시간이 매우 걸린다. 
  • 기본적으로 그 구조를 이해하는 것이 매우 쉽지 않다. 처음 접하면, CF 와 bosh 가 무엇이 다른지도 잘 감이 오질 않는다. 
  • YAML 지옥이다. 간단한 환경 설정이나 properties 정도를 적어두는 것이 아니라, 그 배포 대상의 용도에 따라 어마어마한 내용을 살펴야 할 때가 많다. spiff 라는 YAML merge 도구를 사용하다 보면 OSS CF 배포에 사용되는 YAML 은 보통 1800 줄 정도 된다. 
  • 문제가 발생할때 까지도 시간이 오래 걸리고, 문제를 확인 하는것도 오래 걸리고, 문제를 고쳐서 잘 돌아가는 것을 확인하는데도 오래 걸린다. 즉, 문제가 생기면 골때리게 시간을 오래 잡아 먹을 가능성이 높다. 

(이미치 출처: https://lh3.googleusercontent.com/-FZftK6jFru8/UC1OtbbRb6I/AAAAAAAADqI/D-8bbqzCjug/w640-h400-p-k/mario-yamld.png)



bosh 에 대해 설명해 보자면, 바로 배포 도구다. 어떤 배포 도구냐면, 예를 들어 MySQL 이나 PostgreSQL, Gemfire, Hadoop 과 같은 도구들에 대해서는 잘 알고 있을 것이다. 이러한 도구들을 각 클라우드 서비스에 '설치' 하는 도구를 바로 bosh 라고 할 수 있다. 당연하지만 이 설치에 필요한 설정이 바로 manifest 파일이고, 이는 YAML 을 사용하도록 되어있다. 따라서 설치 하려는 대상이 복잡하면 복잡할 수록, 구성해야 하는 내용이 많으면 많을 수록 YAML 파일의 길이는 안드로메다로 간다. 어쨌든, bosh 는 클라우드 서비스에 뭔가를 설치하려는 경우 사용할 수 있는 설치도구로 보면 된다. 

현재 bosh 의 repository 를 살펴보면 CPI 라고 해서 클라우드 서비스 프로바이더 인터페이스를 bosh-core 와 분리해 놓은 것을 볼 수 있다. 현재로서는 VMWare vSphere, vCloud Air, Amazon Web Services, Azure, OpenStack 을 지원하고 있다. 이전에는 bosh-core 와 CPI 인터페이스가 덩어리로 뭉쳐 있어 새로운 IaaS의 지원 속도가 좀 떨어졌다면 2015년 부터는 이 부분을 좀 개선해서 새로운 클라우드 서비스의 지원이 조금 빨라지고 있는 모양이다. 

개발자 분들이라면 아래의 링크들을 살펴보면 bosh 의 개발이 어떻게 이루어지고 있는지 눈으로 확인하실 수 있겠다. 

Bosh CI on Concurse: https://main.bosh-ci.cf-app.com/ 


일단 어떤 도구인지는 알았으니, 그 사용할때 어떤 점을 알아두면 좋은가 하는건 아래와 같이 대략 정리가 가능하겠다. 

  • Bosh 에서 말하는 jobs 는 각 용도별 Virtual Machine 을 일컫는다. 즉, YAML에 jobs: 하위에 consul 이 정의되어 있다면 이것은 consul 을 배포하는 작업이다. 
  • Stemcell 이라는 방법을 사용하여 VM 위의 OS 레이어를 추상화 한다. AWS 로 치자면 사전에 패킹된 AMI 를 지정한다고 보면 된다. 따라서 bosh 를 사용함에 이로운 점은 CVE 와 같은 긴급 패치가 발생한 경우 배포한 서비스들에 AMI 를 바꿔치기 하는 방법으로 전체 서비스의 업데이트가 가능하다. 물론, multi-AZ 와 같은 구성은 필수겠다. 
  • 보통 bosh micro 라는 VM 을 배포하고 여기를 director 로 연결해서 사용한다. Jumpbox 를 만들면 편리한데, 이는 클라이언트와 디렉터간에 간혹 무거운 파일 전송이 발생하는 경우가 있기 때문이다. 
  • bosh 는 매번 배포를 진행할때, 이전에 했던 모든 동작을 다시 반복한다. 물론 전체를 매번 재배포 하는것은 아니지만, manifest 의 설정대로 작업을 진행하며 이미 있는건 검사하고 넘어간다. 이러한 특징 때문에 신규 작업을 위해서 해당 배포는 시간이 엄청나게 오래 걸리는 단점이 있다. 
  • 문제를 해결해야 하는 경우가 상당히 자주 발생한다. 그것이 YAML 자체의 문제이건, 중간에 나오는 설정의 문제이건 간에 아무튼 엄청나게 자주 발생한다. 따라서 이러한 문제를 해결하기 위해서는 STDOUT 의 메세지만으로는 턱없이 부족한데, 다음과 같은 것들을 알아두면 좋다.  

경험상 필요했던 도구들 
  • bosh task [task number] --debug | egrep -i error   특정 bosh 작업에서 어디의 어떤게 문제였는지 빠르게 확인할 수 있다. 보통 ruby 에러 메세지 및 output 이 담겨있으므로 모든 내용을 보는것은 좀 짜증 날때가 많음 
  • 뭔가 더이상 진행되지 않거나 진행되다가 롤백 된다면, 꼭 ngrep host 나 tcpdump 를 사용해 볼 것을 권고한다. 어느 포트에서 어느 포트로 통신이 필요한데 이것이 제대로 되지 않으면, 그러니까 이를테면 NATS bus 와 같은 메세지 통신이 기존 bosh director 와 bosh 의 job 으로 생성된 vm 간에 허용되지 않으면 두 VM 모두 멍때리는 경우가 많다. 덤프 떠 보자. 
  • 구글 검색에서 사실 cloudfoundry.org 의 문서를 참조하는것이 도움이 된다고 말하기 힘들때가 많다. 문제를 해결하는 가장 빠른 방법은 bosh 나 cf-release 디렉토리 내에 있는 코드와 템플릿, 스크립트를 참조하는 것이다. 그렇다. 나는 지금 에러 메세지를 통한 검색 방법 보다 코드를 보면서 문제를 해결하는 것이 빠르다고 말하고 있는것 맞다. 
  • Manifest 파일 안에서 실수하기 좋은 것들이 static ip 설정이나 이에 따른 subnet 할당이다. multi-az 로 배포한다면 이것이 뒤바뀌면 문제가 많다. 
  • AWS 의 Security Groups, Routing Table, VPC 와 같은 설정들은 아무리 본인이 전문가라해도 항상 의심해서 확인에 확인을 거듭하는 것이 좋다. 
  • 한 2일 정도 붙들고 있으면 대략 윤곽이 보인다.
  • 의외로 Ruby 와 Ruby Gem 이 상당히 짜증을 유발한다. 뭔가 여기 저기서 권고하는 도구를 설치하다가 버전이고 뭐고 다 이상하게 되었다는 생각이 든다면, 아래의 doctor 를 써보자. 나름 잘 고쳐줌.  --  

    https://gist.github.com/mislav/4728286/raw/rbenv-doctor.sh  




정리해 보면, 전체적으로는 다음과 같은 과정이다. 

1. bosh 및 bosh micro 클라이언트 설치 
2. bosh director 준비를 위한 stemcell, manifest.yml 파일 준비 
3. bosh micro deploy 를 사용하여 bosh director 준비
4. Cloud Foundry 또는 다른 bosh 를 통해 배포할 manifest 준비 
5. bosh target x.x.x.x 로 로그인 
6. bosh create release 
7. bosh upload release 
8. 배포될 서비스에 필요한 버전의 Stemcell 업로드 : bosh upload stemcell [스템셀링크 또는 스템셀] 
9. 대망의 bosh deploy 


YAML 은 매우 엄격하다. 그리고 spiff 도구를 통해 필요한 YAML 을 합체하다 보면 순서가 뒤죽박죽 합체되어 뭐 하나 찾으려면 골치가 아프다. 막상 배포에 뭐가 잘못 되면, 그 해당 에러와 YAML 의 어느 부분이 문제인지에 대한 상관 관계 확인 또는 매핑이 매우 어렵다. 아울러 이러한 에러에 대한 정보가 아예 없거나 너무 구버전의 정보이거나 아니면 케이스바이케이스로 풀리는 것도 많이 봤다. 따라서 정리하면 현재로서 사용하려면 매일 이것을 업으로 삼고 있는 사람이 아니면 쉽지 않은 것이다. 

그래도 OSS Cloud Foundry 가 매력적인것은 당연하다. 괜히 I 사나 H 사가 가져다가 자사의 IaaS 에 올리고 있는것이 아니다. 클라우드는 결국 애플리케이션의 구동을 위해 필요한 것이며, 이 애플리케이션의 구동을 더욱 쉽게 해 주는 도구이기 때문에. 

Cloud Foundry 의 Product Manager 의 말에 의하면, 조만간 공개될 새로운 버전의 BOSH 는 YAML 이 지옥에서 현실적인 수준으로 바뀐다고 한다. 아울러 Cloud Foundry 에서 서비스 연결을 할때 원하는 "기존의" 서비스를 연계하도록 하는 것이 아니라, 원하면 BOSH 를 통해 "새롭게 배포된" 서비스를 할당할 수 있도록 더욱더 강화할 예정이라고도 한다. 

CF release 211 때 한번 격렬하게 삽질했다가 이번에 밋업 준비하면서 233 release 에 또한번 격렬한 삽질을 하고 보니 이거 지속적으로 한번씩은 해 줘야 감을 유지하겠구나 싶다. ㅎ 

엔터프라이즈라면 OSS 말고 PCF 를 씁니다. 거기에는 OpsManager 라는 매우 편리한 GUI Bosh 가 있거든요. 

아래는 클라우드파운드리 밋업 주소. 

만약 설치 버전이 아니라 경험만 하고 싶은 경우라면 이런 심한 고생 하실 필요가 없습니다 여러분. http://run.pivotal.io 

AWS 에 배포하는 경우라면 반드시! EC2 limit increase 가 필요합니다. 이것은 각 EC2 콘솔의 대시보드에 있으니 미리 미리 늘려두어 어머 하는 당황스러운 사태를 피합시다 그려. 집에 놀고 있는 vSphere 가 있다면 도전! 

클라우드 때문인지 오픈소스가 날이 갈수록 복잡해짐. ㅋ  

(younjin.jeong@gmail.com, 정윤진) 



HPC on AWS

Techs


(younjin.jeong@gmail.com, 정윤진) 


이전에 아마존 웹 서비스에 취직하고 나서 아주 잠깐! 아아아아주 잠깐! 남는 시간이 약 일주일 정도 있어서 재미로 시작했던 개인 프로젝트 중 위의 제목과 같은 것이 있었다. 스스로도 2013년 요맘때였던 당시에는 뭔가 서비스에 대해 배워야 할 것도 많았고 또 그걸 어디다가 생산적으로 써먹지 하는 생각에 진행했었던, 그런 재미 위주의 개인 프로젝트였다. 결과적으로는 이것이 특정 파트너가 이 아이디어를 차용하여 서비스로까지 만들어서 서비스를 진행 했으며 그쪽 엔지니어에 의해 성능이 몇군데 더 가다듬어졌던 것으로 알고 있다. 지금 쓰면서 찾아보니 아마존 웹 서비스의 파트너인 이안시스 라는 회사에서 아직 서비스를 진행하고 있다. 자세한 정보는 다음의 링크에서 얻으시면 되겠다. http://iaansys.com/hpc-high-performance-computing/  본 문서의 내용을 서비스로 사용하고 싶으신 경우라면 위의 링크에서.  아울러 여기서 소개되는 VASP 과정의 경우 인텔의 상용 컴파일러를 사용해 구현하였으므로 만약 상용 컴파일러가 없는 경우라면 대체할 수 있는 오픈소스 컴파일러를 찾아보거나, 아니면 위의 아마존 파트너에서 제공하는 솔루션을 사용하면 편리하겠다. 


이제 소개될 내용에서는 MIT 에서 개발한 STAR: Cluster 라는 도구를 사용한다. 라이센스는 LGPL 이며 클러스터 구성을 매우 쉽게 할 수 있는 도구로서 비단 VASP 와 같은 DFT 뿐만 아니라 렌더팜, 수학 및 기타 '베오울프' 스러운 클러스터 구성에는 모두 사용이 가능하겠다. 뭐 이따위 것을 EC2 를 배우는데 썼나 하는 분들도 계시겠지만 어린시절 클라우드가 아직 세상에 없거나 알려지지 않았던 2006년 쯤에 PC GAMESS 와 용산발 PC 기반 리눅스 박스 300 대를 공장 창고에서 엮어 구성했던 아련한 기억이 떠올라서 덜컥 일을 저질렀지 싶다. 



위의 다이어그램은 당시에 그렸던 STAR:Cluster 의 동작에 대한 것이다. 구성은 매우 간략한데, 별도의 HPC 솔루션이 설치된 AMI 를 지정한 Placement Group 에 10G 인스턴스를 사용하여 배포한다. 엊그제 한국 리전에서도 Spot 인스턴스 사용이 가능해졌으므로 필요하다면 구성해서 사용하면 되겠다. 단, 이것이 2013년도의 내용이기 때문에 스타클러스터가 현재도 최신의 AMI 를 지원하는지의 여부 등은 현재로서는 잘 모르겠다. 아울러 당시 이 구성을 시험할 때에는 VPC 가 아직 정식 서비스로 나오기 전이었다. 따라서 이제는 없어진 EC2 Classic 의 기반이었고 현재는 아마도 VPC 구성하는 부분까지 포함이 되었지 않았나 싶다. 




지금은 EFS 라는 서비스가 있지만, 당시에는 역시 없었으므로 원본 파일의 공유를 위해 NFS 볼륨을 구성했었나 보다. HPC 의 경우 그 동작의 방식에서 아주 크게 보면 하둡과 유사한 Map Reduce 방식으로 일을 쪼개서 각 클러스터의 노드에서 동작하게 하지만 궁극적으로 노드간 통신은 발생하지 않는 경우가 있다. 또 다른 방식은 일을 처리하는데 있어 각 노드간 매우 고속으로 통신해야 하는 경우가 있을 수 있는데, 이는 보통 MPI 라고 불리는 인터페이스를 사용한다. MPI 에 대한 자세한 설명은 위키피디아가 대신한다. (https://en.wikipedia.org/wiki/Message_Passing_Interface) 이 노드간 성능을 매우 고속으로 구성하기 위해 실 하드웨어 기반 구성에서는 아주 오래전 부터 10G 이상의 별도 프로토콜을 사용하는 네트워크를 사용하곤 하는데, 어쨌든 AWS 에서는 이 속도가 10G 로 제한되겠다. 일반적으로 노드의 숫자가 늘어날 수록 성능은 노드의 숫자에 비례해 증가해야 하지만, 노드의 숫자가 너무 많은데 통신 속도나 프로세스 속도가 받쳐주질 못하면 어떤 지점에서 성능 저하가 발생한다. HPC만을 전문으로 하시는 분들께서는 그래서 클라우드의 HPC 사용에 있어 부정적인 견해를 가지는 경우가 많기도 하다. 


뭐 요새는 GPGPU 가 달린 인스턴스도 있으므로 다양한 인스턴스를 입맛에 맞게 사용하면 되겠다. 기억에는 10G 를 지원하는 인스턴스의 경우에 Para-vitual 기반의 AMI 는 동작하지 않았던 것 같으므로 인스턴스 켜기전에 확인이 필요함. 


전체 구성의 순서는 다음과 같다. 지금도 그렇게 동작하는지는 확인이 필요. 

  1. STAR: Cluster 에서 제공하는 AMI 의 버전을 확인한다. 사용하려는 인스턴스의 타입에 따라 HVM 기반의 AMI 인지 확인이 필요. 
  2. 마스터 노드를 먼저 켜고 설정을 한 뒤에 마스터 노드에서 컴퓨트 클러스터를 켜는 과정을 가진다. 
  3. 경우에 따라서 사전에 설치된 OpenMPI 도구를 제거할 필요가 있다. 
  4. 필요한 패키지를 다운로드 받아 설치한다. 
  5. 추가적으로 소스를 받아 컴파일해야 하는 도구를 준비한다. 
  6. OpenBLAS 나 LAPACK, ScaLAPACK 과 같은 도구가 필요하다면 역시 준비한다. 
  7. VASP 라이브러리를 준비한다.
진행하다 보면 Makefile 의 수정, 컴파일 테스트 다시 수정 이런 과정이 지속적으로 반복될 것임을 믿어 의심치 않는다. 

아래는 당시에 진행했던 과정이다. 



1. Start a Star: Cluster EC2 for VASP compute node Setup


a. Check latest version of StarCluster AMI  http://star.mit.edu/cluster/ 

b. Use HVM to use cc level instances for compute node, In my case, ami-4583572c, us-east-1 

c. Launch cc2.8xlarge instance by Spot request

d. Change root volume size to 12G


2. Delete pre-installed OpenMPI tool 


apt-get pruge libmpich2-3 libmpich2-dev mpich2 

rm -f /usr/bin/mpi*  



3. Download packages 


Download files shown as below: 

  • Intel Fortran Compiler   ( l_fcompxe_2013.5192.tgz ) 
  • VASP 4.lib tarball   ( vasp.4.lib.tar.gz ) 
  • VASP 4.6  tarball   ( vasp.4.6.tar.gz ) 
  • OpenMPI 1.6.5   /  MPICH2 


4. Package setup 


Here’s a list of packages. 

  • build-essential 
  • gfortran
  • libblas-dev
  • libblas3gf
  • liblapack3gf
  • liblapack-dev
  • libblas-dev
  • tmux
  • default-jre
  • gcc-multilib
  • libstdc++6-4.6-dev 
  • libstdc++6
  • lib32stdc++6-4.6-dbg 
  • libgcc1 
  • libgcc1-dbg
  • unzip

apt-get update && apt-get install build-essential gfortran libblas-dev libblas3gf liblapack3gf liblapack-dev libblas-dev tmux unzip default-jre gcc-multilib libstdc++6-4.6-dev libstdc++6 lib32stdc++6-4.6-dbg libgcc1 libgcc1-dgb -y 


5. Install Intel Fortran Compiler 


Untar l_fcompxe_2013.5192.tgz 


mkdir -p /root/tmp && cd /root/tmp 

./install.sh 




You will complete the steps below during this installation:

Step 1 : Welcome

Step 2 : License

Step 3 : Activation

Step 4 : Intel(R) Software Improvement Program

Step 5 : Options

Step 6 : Installation

Step 7 : Complete 



Follow the instructions.


I installed IFC at /opt/intel. Don’t forget to add PATH environment and library path to /etc/ld.so.conf 


export PATH=$PATH:/opt/intel/bin

cat >>/etc/ld.so.conf<<EOF

/opt/intel/lib/intel64

/opt/intel/mkl/lib/intel64

EOF


6. Install MPI tools 


You can choose MPI library by your performance needs, or any other packages currently use. In this document, OpenMPI and MPICH2 will be introduced. 



6.1 Compile and install OpenMPI 1.6.5 (Option #1)


Untar openmpi-1.6.5.tar.gz 


tar xvzf openmpi-1.6.5.tar.gz && cd openmpi-1.6.5 

export OMPI_MPIF90=ifort 

./configure --prefix=/opt/openmpi --with-sge F77=/opt/intel/bin/ifort MPIF90=mpif90 F90=/opt/intel/bin/ifort FC=/opt/intel/bin/ifort 

  

This command will compile mpif77 and mpif90 with IFC, and OpenMPI will support SGE. 


make && make install 


Check mpif77, mpif90 

Don’t forget to add OpenMPI bin path to PATH, and library path to /etc/ld.so.conf as usual. 


/opt/openmpi/bin/mpif77 -v 

ifort version 13.1.3

/opt/openmpi/bin/mpif90 -v

ifort version 13.1.3 


 

6.2 Compile and install MPICH2 (Option #2)


Untar mpich-2-1.5.tar.gz & configure


tar xvzf mpich-2.1.5.tar.gz 

./configure --prefix=/opt/mpich2/ FC=ifort F77=ifort 

make && make install 


Setup PATH environment and library path. 


export PATH=$PATH:/opt/mpich2/bin/

cat >>/etc/ld.so.conf<<EOF

/opt/mpich2/lib/

EOF

ldconfig -f /etc/ld.so.conf 


7. Compile and install performance packs



7.1 Compile OpenBLAS 


# Compile OpenBLAS on same type of instance. If you want to run the cluster with cc2, then compile OpenBLAS on cc2 instance. 


git clone git://github.com/xianyi/OpenBLAS

make FC=ifort

make PREFIX=/opt/openblas install  


7.2 Compile LAPACK 


wget http://www.netlib.org/lapack/lapack-3.4.2.tgz

tar xvzf lapack-3.4.2.tgz && cd lapack-3.4.2 

cp make.inc_sample make.inc 

cat >>make.inc<<EOF

SHELL = /bin/bash

FORTRAN = ifort

OPTS = -O3

DRVOPTS = $(OPTS)

NOOPT = -O3 -fltconsistency -fp_port

LOADER = -O3 

TIMER = INT_CPU_TIME

CC = gcc

CFLAGS = -O3 

ARCH = ar

ARCHFLAGS = cr

RANLIB = ranlib 

XBLASLIB = 

BLASLIB = /opt/openblas/lib/libopenblas.a 

LAPACKLIB = liblapack.a 

TMGLIB = libtmglib.a

LAPACKELIB = liblapacke.a 


7.3 Compile ScaLAPACK 


wget http://www.netlib.org/scalapack/scalapack-2.0.2.tgz 

tar xvzf scalapack-2.0.2.tgz && cd scalapacke-2.0.2

cp SLMake.inc_sample SLMake.inc 

cat >>SLmake.inc<<EOF

CDEFS = -DAdd_ 

FC = mpif90

CC = mpicc

NOOPT = -O0

FCFLAGS = -O3 -xAVX 

CCFLAGS = -O3 

FCLOADER = $(FC)

CCLOADER = $(CC) 

FCLOADERFLAGS = $(FCFLAGS)

CCLOADERFLAGS = $(CCFLAGS) 

ARCH = ar

ARCHFLAGS = cr 

RANLIB = ranlib

BLASLIB = -L/opt/openblas/lib/ -lopenblas

LAPACKLIB = -L/opt/lapack/ -llapack 

LIBS = $(LAPACKLIB) $(BLASLIB) 


8. Compile VASP 4 library 


Untar vasp.4.lib.tar.gz 


tar xvzf vasp.4.lib.tar.gz && cd vasp.4.lib

cp makefile.linux_ifc_P4 Makefile 


diff makefile.linux_ifc_P4 Makefile 

19c19

< FC=ifc

---

> FC=mpif77 


make 

 


Any errors should not be happened. 




9. Compile VASP 4.6 


Download VTST (Vasp TST tools) from http://theory.cm.utexas.edu/vasp/downloads/ 

prompt> wget http://theory.cm.utexas.edu/vasp/downloads/vtstcode.tar.gz


Visit the site for latest version of VTST. 

Untar vasp.4.6.tar.gz


 tar xvzf vasp.4.6.tar.gz && cd vasp.4.6 

cp makefile.linux_ifc_P4 Makefile 


Untar VTST tarball 


tar xvzf vtstcode.tar.gz 


Changes for vtst extension 


diff vasp.4.6-vtst/main.F vasp.4.6-normal/main.F 

vi Makefile 


Follow the instructions at  http://theory.cm.utexas.edu/vasp/downloads/ 


2 additional changed needed. 


#1. Remove “bbm.o” from Makefile. This will generate “no rule for make target” error. 

#2. Remove below section from “dimer.F”. 



Summary about major changes to make it work. 


For OpenMPI setup. 

a. Compiler changes 

  - FC=/opt/intel/bin/ifort   # first section 

  - FC=/opt/openmpi/bin/mpif77   # MPI section 


b. Compile flag changes by version specific compiler options 

  - FFLAGS =  -FR -names lowercase -assume byterecl 

  - OFLAG=-O1 -names lowercase -msse2  

  - BLAS=-L/opt/intel/mkl/lib/intel64 -lmkl_intel_lp64 -lmkl_scalapack_lp64 -lmkl_blacs_openmpi_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread

  - etc. 



For MPICH2 setup 

a. Compiler changes 

  - FC=/opt/intel/bin/ifort   # first section 

  - FC=/opt/mpich2/bin/mpif77   # MPI section 


b. Compile flag changes by version specific compiler options 

  - FFLAGS =  -FR -names lowercase -assume byterecl 

  - OFLAG=-O1 -names lowercase -msse2  

  - BLAS=-L/opt/intel/mkl/lib/intel64/  -lmkl_intel_lp64 -lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread

  - etc. 



모든 구성이 준비 되었으면, VASP Sample 파일로 정상 동작하는지 확인한다. 

mkdir -p /home/vasp-sample 
cd /home/vasp-sample && unzip ../vasp_sample.zip 
/opt/mpich2/bin/mpirun -np 16 /usr/bin/vasp 

문제 없이 동작한다면 이제 작업한 EC2 를 기반으로 AMI 를 만든다. 


다 준비 되었으면, STAR: Cluster 를 설정한다. 설정 예제는 아래와 같은 형태였다. 아마 지금은 좀 바뀌었겠... 

[global] 
DEFAULT_TEMPLATE=vasp 

[aws_info] 
AWS_ACCESS_KEY_ID= 
AWS_SECRET_ACCESS_KEY=
AWS_USER_ID= 

[key vasp] 
KEY_LOCATION=~/.ssh/vasp.rsa

[cluster vasp] 
KEYNAME=vasp 
CLUSTER_SIZE=4
CLUSTER_USER=sgeadmin
CLUSTER_SHELL=bash
NODE_IMAGE_ID= [준비된 AMI ID] 
NODE_INSTANCE_TYPE=cc2.8xlarge
SPOT_BID=0.210 

starcluster createkey vasp -o ~/.ssh/vasp.rsa

다 준비 되었다. 이제 클러스터를 켜고 잘 동작하는지 보자. 



워크로드를 관리하기 위해 Sun Grid Engine queue 를 사용하였다. 




 

정상적으로 동작한다면 아래와 같은 아웃풋을 볼 수 있다. 





이후 각 구성 부분에 대해 조율하면서 성능을 개선하면 되겠다. 


이렇게 시간도 지나고 구성해 본지도 오래된 내용을 굳이 포스팅하는 이유는, 여기에 쏟은 시간이 그래도 적지 않았고 다양한 HPC 의 부분 중 클라우드의 사용이 매우 용이한 도구들이 있다는 점을 알리기 위해서이다. 물론 많은 대학에서는 하드웨어 기반의 클러스터를 운용하고 있지만, 해외의 예일이나 하버드와 같은 학교에서는 유전체 연구라던가 물리, 수학등 자연과학 분야등 다양한 곳에서 클라우드를 사용중이다. 학교뿐 아니라 이런 내용은 기업의 연구소에도 필요할 것이며, 그 사용이 매우 편리하고 쉽다는 점에서 원하는 성능이 나온다면 매우 유용하겠다. 



이전에 서울대학교 의대에 예일에서 교환 교수님으로 오셨던 분의 말씀이 생각난다. 

"이게 돈이 문제가 아니라 물리적으로 설치할 공간이 없어서 클라우드를 생각중입니다. 예일에서는 써 봐서 S3랑 EC2는 다룰줄 알아요." 



즐거운 주말~ 

(younjin.jeong@gmail.com, 정윤진) 



Cloud9 IDE 에서 Cloud Foundry 로의 애플리케이션 배포

Techs


(younjin.jeong@gmail.com, 정윤진) 


원래는 페이스북에 간단한 담벼락 포스팅이었는데, 아무래도 다시 사용하게 될 것 같아서 블로그에도 포스팅. 

Cloud9 이라면 Node.js 개발자 분들께는 추억의 이름일지도 모르겠다. 이제는 Coda 라던가, Brackets 라던가 MS 에서도 만들어 내어 놓는 아주 좋고 심플한 툴들이 많이 나왔으니까. 하지만 당시에는 "협업" 이라는 타이틀 때문에 많이들 관심이 있었고, 그 C9 자체의 구현방법이나 로컬 또는 우리회사 내부에서 돌리면 좋겠다는 생각에 실제로 그렇게도 돌릴 수 있었으니까. 


그런 C9의 장점들을 살펴보면, 대략 이런것들이 있었다. 

  1. Github 와 같은 온라인 repo 와의 연동이 매우 좋았다. 
  2. 웹 브라우저 기반의 IDE 였기 때문에 어디서나 접근 가능하고, 테스트가 가능했다. 
  3. 하단에 쉘로 연결되는 콘솔을 제공해서 매우 편리했다. 
  4. 온라인에서 협업해서 개발된 애플리케이션의 배포를 테스트 도구에 연동한다거나, Heroku 와 같은 클라으드에 배포가 매우 편리 했다. 

그러한 장점들을 살려, 아련한 기억속에 다시 생각나는 C9 IDE 에 Cloud Foundry 배포를 살짝 테스트 해 봄. 물론 당연하지만, 실제 개발 및 배포에서는 중간에 자동화 된 테스트와 이슈 트래커의 연동, 그리고 스테이징 배포가 개발자의 랩탑에서 바로 진행되지 않고, 보통 지정된 repository 와 연동 되도록 하는 것은 잘 알고 계실 것이다. 하지만 이러한 구성이 의미가 있는것은, 내가 지금 로컬에서 동작하도록 만든 애플리케이션이 과연 프로덕션 환경에서도 이상없이 동일하게, 즉 코드 변경없이 구동 될 것이냐 하는 테스트에 그 의미가 있다고 하겠다. 

아래의 내용을 진행하기 이전에 작업이 필요한 것이 있다. 
  1. https://c9.io 의 계정, 그리고 기본 Node.js 애플리케이션 프로젝트 구성. - 퍼블릭으로 만들면 돈 안듦 
  2. PWS 의 계정. Pivotal 이 제공하는 60일간 무료 사용 가능 Cloud Foundry. Log Stream, APM, 컨테이너 스케일링 등 다양한 기능을 제공, 무엇보다 배포가 매우 간단. 
  3. 크롬이나 사파리와 같은 "모던" 웹 브라우저 

그다지 친절한 블로그도 아니긴 하지만 그렇다고 가입 화면까지 스크린샷 찍으면 그것은 매뉴얼이지. 

프로젝트를 처음 만들어서 구성하면, 아래와 같은 이쁜 화면이 보인다. 


당연한 말이지만, 여기서 코드 수정도 하고 소스 레포 연동도 하고 커맨드 라인도 날려보고 만들어진 코드가 동작하는지 테스트도 가능하다. 즉, 개발에 매우 편리한 환경. 우리는 여기에 Cloud Foundry 클라이언트 도구를 설치하고, 작성된 코드를 즉시 배포해서 동작하는지 확인 할 것이다. 


혹시 입맛에 맞게 코드를 변경했거나 하는 경우라면 녹색 Run 버튼으로 잘 동작하는지 브라우저 내의 로컬에서 바로 확인이 가능하시겠다. 


이후에는 일반 x86_64 기반의 리눅스에 cf 클라이언트를 설치하는 방법과 동일한 방법으로 클라이언트를 설치. 이는 하단의 탭 중 "bash" 로 지정된 탭에서 수행 가능하다. 설치시에는 원하는 별도의 디렉토리를 구성해도 되고, export PATH 로 설치된 CLI 를 편리하게 사용하도록 구성하는 것도 가능하겠다. 


커맨드는 


cd ~

wget -O cf.tgz 'https://cli.run.pivotal.io/stable?release=linux64-binary&source=github'

tar xvzf cf.tgz




그러면 위와 같이 주르륵 주르륵 진행된다. 

cf 가 잘 설치 되었는지 확인하려면 cf 쳐보면 된다. cf help 쳐도 된다. 


디렉토리 구조를 보면, ~ 아래에 workspaces 라는 디렉토리가 보인다. 그리로 들어가서, 이제 배포 하면 끝. 

tree 가 들어있나 쳐봤는데 오오오 있다. 



원한다면 이후 cf 로의 배포를 위해 manifest.yml 를 넣을 수 있다. 빌드팩의 정보라던가, 필요한 데이터베이스의 바인딩이라던가, 컨테이너에 지정할 메모리 크기라던가 하는 것들. 


이제는 다음의 커맨드를 사용해 애플리케이션을 배포한다. 기본적으로 방법은 git push 와 아주 유사하다. 아울러, cloud foundry 에는 빌드팩이라는 용어를 많이 사용하는데, 이는 코드나 컴파일된 파일에 맞게끔 동적으로 합체되는 런타임, 더쉽게 말하면 설치할 필요 없는 미들웨어 패키지와 그 친구들로 이해하면 편하다. 뭔말이냐면, cf push 로 업로드 되는 파일이 jar 라던가 war 라면, java 빌드팩이 뿅하고 합체되어 톰캣이라던가 그런게 자동 구성. 클라우드 파운더리가 기본 지원하는 빌드팩은 cf buildpacks 커맨드로 확인이 가능하고, 원한다면 구글에서 cloud foundry buildpacks 로 검색하면 nginx 라던가, elarng, 애플의 swift 등 다양한 빌드팩으로 런타임을 구성할 수 있겠다. 아물론 커스터마이징도 가능. 




cf push -b 스위치로 온라인에 있는 다양한 빌드팩을 사용하는 것도 가능하지만, 이것들이 엔터프라이즈에서 오프라인으로 필요한 경우라면 PCF 라는 설치 버전에서 빌드팩을 오프라인으로 등록해 사용하는 것이 매우 가능하다. 따라서 보안상의 이유로 인해 런타임 환경에서 인터넷으로의 접근이 막혀있는 경우에서도 동작이 가능하다는 말. 

이제는 진짜로 배포를 한다. ㅋ 

cf push [app-name] -m 256M -c "node server.js"

# 이경우에는

cd ./workspace

cf push yjeong-nodejs -m 256M -c "node server.js"

여기서 지정된 app-name 은 클라우드 파운더리가 설치된 메인 도메인의 서브 도메인으로 동작한다. 무슨말이냐면, 만약 PCF 가 mycorporate.com 으로 되어 있다면 이때 app-name 으로 배포된 애플리케이션은 app-name.mycorporate.com 의 FQDN 을 자동으로 가지게 된다는 말. 물론 당연하지만 애플리케이션은 여러개의 이름을 가질 수 있고, 실제 서브 도메인의 이름은 다른것을 사용할 수 도 있으며, 해당 서브 도메인은 다른 애플리케이션으로 동적으로 라우팅을 변경할 수도 있다. 물론 본 예제에서는 PWS 라는 피보탈 제공 서비스를 사용하기 때문에 기본 도메인인 cfapps.io 가 붙는다. 물론 원한다면 본인 소유의 도메인을 여기에 CNAME 매핑하셔도 되겠으며, 원한다면 AWS 의 Cloud Front 와 같은 CDN 연결 가능하시겠다. 


아무튼 위의 커맨드를 날리고 보면 뭔가 막 바쁜것을 확인할 수 있다. 이는 도메인을 생성하고, package.json 에 명시된 패키지들을 다운 받아서 준비하고, 뭐 그런 내용들이 주르륵 나온다. 별 문제가 없다면 1개의 컨테이너에서 애플리케이션이 정상 동작하고 있다는 메세지를 확인 할 수 있다. 



뭔가 막 바쁜 모습.jpg 

App started 라는 메세지를 보면 일반적으로 문제가 없이 배포가 완료 되어, 애플리케이션이 up & running 상태라고 보면 되시겠다. 





cf a 커맨드는 cf apps 의 알리아스로 현재 나에게 할당된 org 안의 space 에서 동작하고 있는 애플리케이션의 전체 리스트를 보여준다. cf app [app-name] 은 해당 애플리케이션의 디테일을 보여준다. 현재는 별도의 명시가 없었기 때문에 1개의 컨테이너로 동작하고 있지만, -i 스위치를 사용해 동적으로 수량을 변경해 줄 수 있다. 아래는 -i 5 를 사용해 컨테이너를 확장한 모습. 당연한 이야기지만, 이 컨테이너들은 모두 동적 라우팅 경로에 추가되어 밸런싱 되고 있다. 


cf scale yjeong-nodejs -i 5


 

아무튼 애플리케이션이 잘 동작하는지 확인하려면? 해당 도메인에 접근해 보면 되겠다. 


http://yjeong-nodejs.cfapps.io 


현재 사용가능한 PWS 는 AWS 의 동부 리전을 사용중이므로, 만약 속도가 다소 느리면 거의 대부분 네트웍 문제로 보시면 된다. 만약 한국에서의 접근이 폭발적으로 많게 되면, 제가 한국 AWS 리전에 PWS 운영을 건의해 보도록 하겠습니다 여러분~ (선거 코스프레) 



별 문제가 없었다면 위와 같은 기본 프로젝트의 페이지가 나온다. 하단이 공백이라 허옇게 뜨는... 

뭐 어쨌든 잘 돌아가시겠다. 


이번에는 PWS 사이트, https://run.pivotal.io 에서 로그인 해서 보면 해당 페이지가 문제없이 동작하고 있는것이 보인다. 



어! 쿼타가 나랑 다르네 하시는 분들께서는 제가 그 저기 피보탈 직원이라 이런 혜택은 조금 있습니다. 음. 

아무튼 yjeong-org 라는 조직 내에 2개의 space 가 있는데 하나가 development 고 다른 하나가 labtest. 여기 중 development 에 해당 애플리케이션이 배포 되었다고 보시면 된다. 이러한 조직 구성과 권한의 관리가 있다는 것은, org 로 할당된 하나의 마이크로 서비스 조직에서 운영하는 애플리케이션의 개발 / 스테이징 / 프로덕션으로 ORG 내에서 Space 로 나누어 낼 수 있다. 그리고 이 각 Space 에는 별도의 권한을 할당하여, 개발 환경에는 개발 팀의 권한을, 나머지 환경에는 테스트 및 배포 자동화 도구에만 권한을 주는 방법을 사용할 수 있다. 


PWS 를 사용하는 경우에는 오른쪽에 Billing 내역을 확인하여 내가 지금 얼마를 사용하고 있는지 (유료 계정이라면) 확인이 가능하다. 이는, 엔터프라이즈의 설치 버전인 PCF 의 경우 각 조직에 할당된 리소스에 대해 청구를 할 수 있는 메커니즘을 가지고 있어, 그룹사의 각 조직에 할당된 사용량에 대해 빌링이 가능하다. 이는 많은 그룹사가 원하시는 꽤 아름다운 기능. 


애플리케이션이 배포된 Space 에 들어가 보면 아래와 같이 나온다. 



이전에 구성한 바와 같이, 배포한 애플리케이션의 이름, 각 컨테이너에 할당한 메모리, 컨테이너의 갯수 같은 정보들이 나오며, 해당 애플리케이션으로 한 뎁스 더 들어갈 수 있다. 아래에 보이는 Add Service 버튼을 누르면, 해당 스페이스나 애플리케이션에 필요한 각종 서비스를 바로 바인딩 하여 사용할 수 있는 다양한 서비스들을 확인할 수 있다. Cloud Foundry 에서는 이런 사용성을 marketplace 라고 부르는데, 이는 cf marketplace 라는 커맨드 라인도구를 사용해서도 확인이 가능하겠다. 


설치버전인 PCF 에서는 운영자 또는 조직의 요구에 따라 다양한 서비스를 PCF 와 연동하도록 구성할 수 있다. Redis, RabbitMQ, MySQL, MongoDB, New Relic, PostgreSQL, Memcached, Elasticserch 등 이미 제공되는 도구를 다운로드 받아 연동을 구성할 수도 있으며, 종전의 기업에서 사용중인 다양한 On-premise 도구를 연동하는것도 가능하다. 이를테면 Oracle DB 라던가 DB2, 또는 하둡 클러스터등과 같은 도구를 Service Broker 라는 방식으로 애플리케이션에 할당하고, 환경변수에 등록하여 참조해서 사용할 수 있는 방법을 제공한다. 여기에는 조금 더 설명이 필요하긴 한데, 이후 버전에서는 더 개선된 방식으로, 즉 서비스가 필요할때 AWS 나 Azure, 또는 오픈스택에 bosh 라는 도구를 통해 배포해서 할당하는 방법이 준비되고 있다. 


뭐 말이 복잡한데 정리하면 필요한 서비스를 할당 받아서 애플리케이션에 바인딩 하면 환경 변수로 참조해서 사용 가능하다. 이말인즉, 12factor.net 에서 이야기 하는 Code 와 Config 의 분리, 그리고 각 환경간의 이질성 최소화가 지원이 되어 애프리케이션의 배포와 테스트 그리고 프로덕션 반영의 속도가 빨라질 수 있다는 말. 



마켓 플레이스. 이런 도구가 주는 강점은, 만약 AWS 와 같은 클라우드를 선택해서 DynamoDB 라던가 RDS 와 같이 CSP 가 제공하는 서비스를 사용하는 경우에도 연동이 가능하다는 것이다. 즉, 애플리케이션에 필요한 데이터 소스 또는 스토어, 이런 것들에 대한 접근이 각 환경별로 독립적으로, 그리고 자유롭게 주어질 수 있다는 것. 물론 이러한 서비스 바인딩에 대한 권한 역시 통제 할 수 있겠다. 


아래는 배포된 애플리케이션의 디테일이다. 



인스턴스의 수량 조절, 애플리케이션의 메모리 변경등이 가능하고, 아래의 내용을 보면 탭으로 구분된 다양한 내용을 볼 수 있다. 여기에는 해당 애플리케이션에 대한 히스토리, 로그, 라우팅 정보, 연결된 서비스와 애플리케이션에 필요한 환경 변수 등을 지정할 수 있다. 당연한 말이지만 이러한 기능들은 모두 커맨드 라인 도구에서 사용이 가능하고, 특히 로그와 같은 기능은 애플리케이션의 문제 분석에 매우 유용하다. 또한 Cloud Foundry 자체가 별도의 로그 분석 도구와 연동하고 있다면 여기에 하둡이나 HWAQ, GreenPlum 과 같은 도구의 연동도 가능하겠다. 3rd 파티로는 DataDog 와 같은 도구를 연동할 수 있는 것도 물론 가능. 




로그 스트림 



아마, 현재 근무하고 계신 회사에서 동작하는 모든 애플리케이션의 로그가 한꺼번에 저장되서 스트림으로 처리 되거나, 또는 그렇게 모여진 애플리케이션 로그를 애플리케이션 별로 수집해서 보는곳은 많지 않을것이라고 생각된다. 하지만 반드시 필요한 기능이고, 문제가 생겼을때 추적을 하는 것 뿐만 아니라 분석에 필요한 기본 자료가 되기도 하기 때문이다. 하지만 이를 실제로 구현하기 위해서는 배포된 모든 서버에 별도의 에이전트를 넣는다던가, 또는 분산 로깅 구성을 반드시 해야 할 필요가 있다. 이것이 쉬운 작업이 아닐 뿐만 아니라, 그것을 애플리케이션 개발자 입장에서 편하게 접근하는 것은 또 다른 이야기다.  특히 Node.js 개발자 분들이 항상 로그를 검색해야 할 필요가 있는 경우를 생각해 본다면 이런 도구가 제공하는 장점이 매우 매력적이지 않을 수 없다. 


이런 로그 연동에 더하여 만약 애플리케이션 성능 효율까지 같이 볼 수있다면 어떻게 될까? 이후 로드맵에서는 일종의 Splunk 와 유사한 뷰를 제공할 예정이지만, 현재 PCF Metrics 라는 이름으로 애플리케이션이 어떤 상태로 동작하는지 실시간으로, 그리고 히스토릭하게 확인이 가능하다. 이는 애플리케이션 대시보드의 오른쪽에 있는 "View in Pivotal APM" 버튼을 누르면 확인 가능하다. 




퍼포먼스 모니터링 대시보드 




컨테이너 모니터링 - 블로그 포스팅을 하는 와중에 기록이 남은게 별로 없... 




네트워크 상태 모니터링. 


위와 같은 메트릭을 제공하는데, 이게 이후에는 조금 더 발전해서 애플리케이션 로그와 합체된 그래프의 형태가 된다. 따라서 언제 새로운 애플리케이션이 배포가 되었고 이와 연동하여 언제 서비스가 어떤 상태인지 추적이 로그와 연동하여 보기 매우 편리해 진다는 말. 대부분의 클라우드 기반 애플리케이션 모니터링을 위해 Pager Duty, DataDog, New Relic 과 같은 도구를 사용하는데 여기저기서 다른 로그를 보고 분석하는 것 보다 훨씬 편리해 지겠다. 뭐 , 2016년에 지속적으로 확장 로드맵이 있으므로. 



시작은 C9 IDE 와 Cloud Foundry 와의 연동이었는데, 이게 어쩌다 보니 클라우드 파운드리에 대한 설명이 더 많아져 버린 느낌이다. 그리고 눈치 빠른 분들은 이미 아시겠지만, 이는 C9 뿐만 아니라 리눅스나 윈도우, 맥에서도 CF 클라이언트를 설치하면 cf push 한방으로 이 모든 것이 가능하다. 또한 테스트 도구와의 연동, 이를테면 Jenkins 를 사용한다면 함께 제공되는 Cloud Foundry 플러그인을 사용할 수도 있고, 아니면 테스트가 종료되면 실행할 내용에 cf push 를 적어주면 되겠다. 아울러 Spring 에 오너쉽을 가지고 Eclipse 에 심각한 수준으로 Contribution 을 하고 있는 회사가 바로 Pivotal 이므로, STS 와 같은 도구 또는 이클립스에서 플러그인으로 검색하면 바로 Cloud Foundry 에 애플리케이션을 배포할 수 있겠다. 



이 모든 것들이 시사하는 바가 무엇인가. 아마 컨테이너와 그 컨테이너들의 오케스트레이션, 로그 어그리게이션, 권한 관리, 자동화된 배포 및 테스트 연동, 이런것들이 필요해서 직접 구성하고 계신 시도가 매우 많이 관찰되고 있다. 하지만 잘 아시겠지만, 이런 서로 다른 회사의 서로 다른 스택을 한꺼번에 프로덕션에 반영하는 것은 매우 어렵고, 버전 관리나 업데이트, 배포 연동 이런게 보통일이 아니다. 아울러 서비스 전체에 심각한 보안 패치가 필요한 경우, 이것이 상상도 안되는 일이라는 말이지. 


우리 회사의 본 Pivotal Cloud Foundry 프로덕트 총괄이 발표에 이런 이야기를 한다. 


Here's my source code, 

Run it on the cloud for me, 

I don't care how


여기에 대한 답, cf push. 


정리하면,

  1. 컨테이너 기반의 애플리케이션 배포 가능 
  2. 컨테이너의 동적인 확장 및 축소 가능 
  3. 웹 애플리케이션 서버, 이를테면 런타임 구성의 자동화 
  4. 랩탑에서 프로덕션까지, 12factor 앱 구성에 필요한 실질적 환경을 제공 
  5. 컨테이너간 네트워킹이 필요하다면, - 조만간 지원 : MSA 애플리케이션간 통신의 유연화 
  6. 필요한 서비스를 인터넷이던 인트라넷이던 언제나 연동 가능 
  7. 멀티 클라우드. - 오픈스택에서 AWS, Azure, 이젠 GCE 까지. 물론 VMware 는 모회사 중 하나이므로 당삼 지원. 
  8. Docker? Docker 가 지원하는 (Endorse) 유일한 도구가 바로 Cloud Foundry.  cf push -o 를 통해 Docker 배포를 순식간에. 
  9. 그거 안전한가? - 특히 많이 사용되는 곳이 제조 및 금융, 중국에서는 바이두 같은 곳? 
  10. 권한 관리. 빌링. 로그 취합. APM. 

클라우드와 컨테이너의 구성에 대해 구상하고 계신 분들께 참조가 되었으면 한다. 
아울러 상용 버전도 있지만, 오픈 소스 버전도 있다는 거. 


물론 오픈 소스 버전도 거의 비슷한 기능을 제공하지만, 다른건 APM 같은것이 없다거나, 설치할때 보면 YAML 지옥이라는 정도? 
당연한 말이지만 개선중에 있습니다 여러분. 

그리고 우리 회사에서 설치 테스트 해 보고 싶은데 하는 분들은 아래의 주소로 가시면 클라우드 파운더리 및 관련 다양한 서비스를 받아 함께 구성해 보실 수 있겠습니다. VMware 에도 되고, AWS에도 되고, 아직 베타긴 하지만 Azure 에도 됩니다. 

설치 순서는 대략 
- OpsManager 
- ElasticRuntime (요게 PCF) 
- 기타 다른 타일을 다운로드 받아 OpsManager 에 등록하여 서비스 추가 가능. 
- 디테일은 매뉴얼 참조 

랩탑에서 구성하는 방법도 있는데, 내 랩답이 메모리가 좀 빵빵하지 후훗 하시는 분들 께서는 microPCF 검색 고고. 

끝내기 전에 한가지 주요 질문. - 여러분은 80포트 애플리케이션 구동과 배포를 위해 얼마나 많은 일을 하고 계십니까? 

그럼 오늘 포스팅은 여기서 끝. 
기승전피(보탈) 

(younjin.jeong@gmail.com, 정윤진) 








세월 빠르네

Techs


(younjin.jeong@gmail.com, 정윤진) 


회사를 옮긴지 벌써 10개월 정도 되어간다. 그동안 여러가지 일들이 많았지만, 역시 엔터프라이즈를 주로 상대하다 보니 이전보다는 업무의 밀도는 조금 낮아진 것 같은 느낌이 드는 것이 사실이다. 글쎄, 하고 있는 일과 해야 하는일, 그리고 그것들이 하고 싶은 일과 잘 맞물림에도 불구하고 뭔가 스스로 삐걱대는 느낌을 지울 수 없다. 그것은 현재 변하고 있는 기술의 패러다임 때문일까, 아니면 보다 편한것을 포기해야 직성이 풀리는 성격 때문일까, 아니면 새로운 도전의 즐거움 뒤에는 격한 스트레스가 있다는 것을 너무 잘 알기 때문일까. 





취미인 무선 조종은 점점 취미가 아닌것 처럼 되어간다. 60불 짜리 윙스팬 2.4미터 짜리 비행기에는 이제 라스베리 파이라던가, 아두이노라던가, 센서들 그리고 날아야 하는 숙명으로 비행기에 필요한 기본적인 것들까지 주렁주렁 붙어서 이제 무선 조종이라고 말하기도 뭐할 지경이 됬다. 거기에 2 axis 짐벌까지 하단으로 달아두고 생각해 보니 이게 과연 이렇게 계속 만들어도 좋을지 어쩔지 무선 통신기사 자격증이라도 확보해야 할 것 같은 느낌. 이거 더 만들다가 NASA Flight Research Center 에 취직하면 어쩌나 걱정할 지경. (은 농담) 





음... 일로서 최근에 많이 보고 있는 것이라면 아무래도 역시 기술이 소프트웨어로 많이 옮겨가고 있다는 사실인것 같다. 이전에는 그저 사서쓰면 되는 것들이 많았는데, 이제는 뭐 사업이 곧 소프트웨어 또는 소프트웨어 기반 서비스다 보니 개발자들 구인에 대한 이야기도 많고, 또 이런 개발자 분들이 일하는 문화, 도구에 대한 것들이 많다. 신사업은 곧 개발자 없이 하기는 불가능하니까, 이제는 SI 수준이 아닌 서비스, 즉 프로젝트 레벨에서 프로덕트 레벨로의 전환이 많이 이야기가 되고, 그 방법에 대해 물어오는 곳이 많기도 하다. 


아울러 이제는 누구나 이야기 하고 있는 마이크로 서비스 같은것들. 근데 이게 다들 이야기 하고 있는데 정작 중요한 것들을 이야기 하고 있지 않는것 같다. 마이크로 서비스가 좋기는 하지만, 일단 어떻게 만들어야 하는지 아는 사람이 거의 없고, 솔직히 국내에서 그것을 경험했을 만한 회사가 많지 않은데 너도나도 전문가 코스프레 하는것 같다는 느낌. 공부가 나쁜건 아니지만 그래도 그건 이렇게 해야 해요 하고 말할때는 경험이 있어야 하지 않나 싶고, 특히 마이크로 서비스의 구성 같은것은 그 키워드가 "재사용성" 에 기반해야 할 정도임에도 불구하고 그 경험을 말하는 이는 별로 없는 느낌. 죄 어디서 외국 블로그 주워다가 같다 붙이기나 하고. 하지만 뭐 그럴 수 밖에 없는것이 어디 국내에서 그렇게 만들려고 하는데가 있어야 경험도 할 것 아니겠냐 말이지. 


음, 주목할 만한 것으로는 뭐랄까 예전부터 팀을 구성할때는 서로 다른 역할이 모여야 한다고 생각한 적이 많았는데, 요새 들어서는 그 팀의 모양이 더 구체화 되는 느낌이다. UX 는 UX 끼리 DBA 는 DBA 끼리 서로서로 팀짜고 앉아서 일하면 더 잘된다고 생각하시는 분들이 많은것 같은데, 예전에 아마존의 Zocalo, 아 지금은 이름이 바뀌었지. Workdocs 같은거를 오픈스택 Swift 기반으로 만든적이 있는데, 기본은 Node.js, 사용자나 오브젝트 디비 같은건 몽고, 스토리지는 키스톤에 스위프트 정도로 엔터프라이즈용 파일 공유 솔루션 같은걸 만드는데 3달 정도 걸렸던것 같다. 그때 구성이 백엔드도 하는 프론트엔드, 프론트도 좀 하는 백엔드, 그리고 필요한 스택과 라이브러리 그리고 인프라를 준비하는 나님셀프. 똑똑한 사람들과 일하는 것은 아주 즐거운 일이다. 내가 삽질하지 않아야 다른 사람도 퍼포먼스가 나고, 개선이 필요한 부분에 어디를 손보면 좋을지 서로 퍼리가 팍팍 돌아가는 소리가 들리는 것은 좋은 경험이라는 것이지. 이제는 그런 팀의 모양이 마이크로 서비스와 맞물려서 Conway's law 같은 것으로 이야기가 되기도 하지만, 어쨌든 작은팀이 효율적이고 돌아가게 만드는 것이 요새 많은 조직에서 물어오는 내용이기도 하다. 이자리를 빌어서 파이어준과 성열형에게 좋은 경험 함께해줘서 감사. 


이제는 다들 회사를 옮기고 당시 프로젝트는 오픈소스화 되었는데 이젠 시간도 오래 지나서 보는 분들이 있을까 모르겠지만. 레포 주소는 여기. 

https://github.com/younjinjeong/thevelox 


그리고 이건 당시 오픈할때 준호형의 블로그 뽀스팅 

http://firejune.com/1771/The+Velox+%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8+%EA%B3%B5%EA%B0%9C+%EA%B7%B8%EB%A6%AC%EA%B3%A0+%ED%81%B4%EB%A1%9C%EC%A6%88+%EB%B2%A0%ED%83%80?stag=thevelox.com 


요새 보니까 누가 Node.js 의 콜백지옥이 어쩌니 async 가 어쩌니 하시던데 뭔가 알파고 나오니 빅데이터 전문가 한분 탄생하신 그런 느낌? ㅋ 


그리고, 요새 제일 많이 이야기 하고 있는 클라우드 파운더리. 

이게 참 뭐가 뭔지 모르겠다 어쩌고 하고 말이 많은데, 이게 무슨 문제를 해결하는 도구인고 하면, 바로 


"지금 80/443 포트에서 동작하는 웹 앱을 돌리기 위해 얼마나 많은 일을 하고 계심까?" 


에 더하여 


"그런 일을 계속 반복해야 할텐데, 그거 사고도 많이 나고 힘들지 않슴까?" 


의 문제를 해결하는 도구라는 점. 

기술 좋아 하시는 분들은 다커랑 큐버네티스 그런거 좋아하실테니 그 조합의 장점은 다 알고 계실 테지만 그거 어디 프로덕션에 돌리겠어요? 게다가 CVE 터지면 어쩔 것인지도 뭐 확실하지 않고, 내가 보니까 glibc 나 커널 업데이트 못해서 지금 난리가 날 것 같은 상태의 보안 취약점으로 돌아가는 서비스들이 한두개가 아닌데 말이지. 그러지 말고 클라우드 파운더리 써 봅시다. 뭐 설치하지 말고 뭐하지 말고 그냥 http://run.pivotal.io 가면 60일 계정 줌. 그리고 오픈소스 버전도 있는데 그것은 YAML 지옥이라 아직까지는 꽤 공부해야 사용이 가능할 것이란 말. 


거기에 자동화 된 테스트, 모바일 자동 테스트 그런것들도 주제가 많은데 언제고 시간이 되면 각각 디테일하게 써 보는 것으로. 


오랜만에 블로그 와서 여기저기 고장난것도 좀 고치고 방명록에 알 수 없는 러시아 말도 좀 지우고 포스팅도 한건 해줘야 할 것 같아서... 

누구든 조만간 소주 한잔 합시다용 


회사 블로그도 업데이트 해야 하는데... 

http://blog.pivotal.io/kr 


(younjin.jeong@gmail.com, 정윤진)