System Compleat.

AWS re:Invent 2016 - Keynote 2 신규 서비스

Techs


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

어제에 이어 오늘도 새로운 서비스들이 쏟아져 나왔다. re:Invent 첫째날은 아마존 웹 서비스의 사장인 Andy Jassy 가 발표를 했고, 두번째 날에는 아마존의 CTO인 Werner Vogels 박사님이 또 새로운 서비스들을 쏟아내었다. 죽 보면서 느끼는건데, 대체 각 서비스별로 Amazon 과 AWS의 이름 규칙은 무엇인가. 알수가 엄쏭. 

Keynote 첫날 발표된 내용은 여기로. : http://kerberosj.tistory.com/231


http://venturebeat.com/2016/11/30/aws-reinvent-2016/

2일 동안 발표된 서비스 및 추가 기능은 무려 24개에 달하는데 이는 역시 아마존이 시장의 선두를 유지하기 위해 박차를 가하는 모습이다. 대부분의 서비스들은 기존 고객의 요구 또는 고객들이 아마존 웹 서비스에서 주로 직접 구현해서 사용하는 것에 어려움을 겪는 문제를 해소하기 위해 매니지드 서비스로 만들어 배포하고 있다. 


두번째 날에 공개된 서비스들은 주로 개발자들이 관심을 가질만한 내용들로 보인다. 아래에 간단히 그 용도와 링크를 적어본다. 한국에 대한 아마존 웹 서비스의 투자가 늘어나 re:Invent 에서 발표된 내용이 실시간으로 한글 블로그로 번역되어 나오는것에 신기할 따름이다. 


AWS X-Rayhttps://aws.amazon.com/ko/blogs/korea/aws-x-ray-see-inside-of-your-distributed-application/  

- 웹 애플리케이션에서 클라이언트로 부터 서비스로 들어온 요청이 내부에서 어떻게 처리되는지에 대한 가시성을 확보하는 것은 매우 중요하다. 특히 마이크로 서비스와 같은 구조를 구현하고 있는 경우라면 더더욱 그러한데, 이를 AWS에서 사용할 수 있는 것이 X-ray 라는 서비스로 발매 되었다. 트위터가 만든 오픈소스 Zipkin (http://zipkin.io) 의 AWS 버전으로 보인다. 


AWS CodeBuildhttps://aws.amazon.com/ko/blogs/korea/aws-codebuild-fully-managed-build-service/ 

- 아마존의 코드 삼형제라는 별명을 붙여서 한참 발표하고 다녔는데 이제 코드 4형제가 되었다. AWS가 만든 Jenkins 라고 이해하면 되겠다. AWS CodeCommit, AWS CodePipeline, AWS CodeDeploy 와 연동 가능하며 특히 CodePipeline 에서 빌드 서비스 공급자로 CodeBuild 를 추가할 수 있어 유용하겠다. 사실 CI/CD 파이프라인 및 컨테이너 레벨의 빌드와 테스트를 수행하는 도구를 직접 설치해서 운영하는 것은 매우 피로도가 높은 일인데, 이렇게 서비스로 제공되면 사용이 편리하겠다. 


AWS Shieldhttps://aws.amazon.com/ko/blogs/korea/aws-shield-protect-your-applications-from-ddos-attacks/

- 많은 사람들이 아기다리고기다리던 기능이 아닐까 싶다. 아울러 이쪽 분야에 솔루션을 판매하던 보안회사들 몇몇은 곡소리가 날지도... 아무튼 AWS 의 DDoS 방어 서비스다. 설명에 따르면 Standard 서비스는 모든 사용자가 무료로 사용할 수 있으며, 지원을 받고자 하는 경우에는 Advanced 를 선택 가능한 모양이다. DDoS 방어의 경우 도메인 부터 서비스 엔드포인트까지 다계층에서 감지 및 조치를 취해야 할 필요가 있는데, Shield 서비스의 경우 Route53 의 도메인, CloudFront 의 CDN edge, 그리고 ELB의 밸런서의 다계층에서 DDoS를 방어한다. 모든 사용자가 살펴볼 필요가 있는 서비스. 


AWS Pinpointhttps://aws.amazon.com/blogs/aws/amazon-pinpoint-hit-your-targets-with-aws/

- 마케팅에서 선별된 고객에게만 메세지를 보내는 기능은 매우 중요하다. AWS Pinpoint 는 Mobile analytics 에서 제공하는 몇몇 간단한 지표를 바탕으로 특정 조건에 부합하는 고객들에게 SNS(Simple Notification Service) 를 통해 푸시알람이나 이메일등을 보낼 수 있는 마케팅 그룹용 매니지드 서비스라고 할 수 있겠다. 어떠한 모바일 서비스건 꼭 구현해야 하는 기능이지만 직접 구현하려면 시간과 노력이 필요한 기능을 서비스로 만들었다. 


AWS Batch : https://aws.amazon.com/ko/blogs/korea/aws-batch-run-batch-computing-jobs-on-aws/ 

- 배치 작업의 종류는 다양하지만, 그 기본 구성요소는 거의 대부분 비슷하다. 작업을 위한 클러스터와 이 클러스터를 통제하는 메인 노드 (또는 서버) 그리고 클러스터가 수행할 작업을 분배하고 결과를 수집하는 작업 큐, 그리고 그 클러스터의 수행 목적에 따라 결과를 저장하는 데이터베이스 또는 파일 시스템으로 보통 구성한다. Batch 서비스는 이전 MIT의 StarCluster 와 같은 도구가 하던 일을 아예 서비스로 만들고, 데이터 소스 및 결과물 저장을 위한 DynamoDB, S3 등과의 연동 및 작업을 위한 클러스터 노드 생성과 큐를 만들어 그야말로 뚝딱 사용할 수 있는 서비스다. 예를 들면 렌더링이나 분자화학식 계산, 각종 산업 시뮬레이션 등에 사용 가능하겠으며, 아마도 GPGPU 가 달린 또는 Elastic GPU 등을 사용해 OpenCL 등을 사용하는 클러스터도 제공할 것 같다. 


AWS Personal Health Dashboard : https://aws.amazon.com/ko/blogs/korea/new-aws-personal-health-dashboard-status-you-can-relate-to/ 

- AWS에서 서비스를 운영하다 보면 관리를 위한 정보를 각 서비스 콘솔에서 별도로 확인해야 하는 등의 불편함이 있었다. 예를 들면 메인터넌스를 위한 AWS의 EC2 인스턴스 재부팅 대상이라던가, RDS 데이터베이스의 업데이트 또는 CloudWatch 를 통해 확인해야 하는 각종 알람과 같은 정보들이다. 이런 정보들을 이제 여기저기 돌아다닐 필요 없이 하나의 대시보드에서 확인할 수 있도록 제공하는 서비스로 보인다. 


Blox, OSS Container scheduler  : https://aws.amazon.com/ko/blogs/korea/blox-new-open-source-scheduler-for-amazon-ec2-container-service/ 

- 어째서 ECS에서 사용하는 컨테이너 스케줄러를 서비스로 제공하지 않고 오픈소스 도구로 처리하라는지는 잘 모르겠지만, 어쨌든 그렇다. 아마존 웹 서비스를 사용하다 보면 EC2도 그렇고 현재 내가 어떤 인스턴스들 또는 컨테이너를 동작하고 있는지 Describe 관련 API 를 호출하는 경우가 많다. 이는 각 컨테이너의 "State - 상태" 를 그때그때 조회해야 하기 때문에 여간 불편한 것이 아닌데, 이 Blox 라는 도구는 CloudWatch 등을 통해서 상태를 추적하고 사용자가 원하는 수량 또는 작업을 SQS 를 통해 처리하도록 하는 오픈소스란다. 난 피보탈 직원이니까 컨테이너를 클라우드에서 돌리고 싶은 엔터프라이즈라면 그냥 피보탈 클라우드 파운더리를 살펴보는걸 권고. 데헷 


AWS Lambda@Edgehttps://aws.amazon.com/ko/blogs/korea/coming-soon-lambda-at-the-edge/ 

- AWS 람다는 함수 단위의 코드를 서버 없이 실행해 주는 서비스다. 이 서비스가 이제 CloudFront의 Edge에서 돌아간단다. 그러니까 즉, CDN에 컴퓨팅 파워를 부여해서 외부에서 들어오는 요청에 대해 더 스마트한 통제를 구현할 수 있게 된다. 현재는 자바스크립트 코드만 동작 가능한 것으로 보이는데, 정리하면 웹 서버 또는 NginX 와 같은 리버스 프락시에서 구현하는 다양한 웹 요청에 대한 조작을 CDN 엣지에서 내가 원하는 대로 자바스크립트를 사용해서 처리할 수 있겠다. 다양하게 응용이 가능하므로 웹 서비스를 수행한다면 꼭 살펴 보아야할 기능. 


AWS StepFunctionshttps://aws.amazon.com/ko/blogs/korea/new-aws-step-functions-build-distributed-applications-using-visual-workflows/

- 서버리스가 점점 발전하고 있다. Lambda 에서 작성한 각각의 함수 레벨의 애플리케이션을 서로 엮어 개발자가 원하는 조건에 따라 원하는 동작을 처리할 수 있는 일종의 "람다 함수를 묶어 하나의 서비스로" 와 같은 컨셉. 아마존에서 주창하는 서버리스와 람다에 열광하는 사용자라면 반드시 살펴볼 것을 권고한다. 


AWS Gluehttps://aws.amazon.com/ko/glue/ 

- 아마존의 공식 블로그 포스팅은 아직 없는 모양. 서비스 홈 페이지를 링크. 간단히 말해서 ETL as a Service. JDBC 로 연결 가능한 모든 데이터 저장소와 S3, RDS, Redshift 간의 데이터 이동등을 편리하게 처리할 수 있겠다. 또한 이렇게 만들어진 ETL을 Python, Spark, Git 또는 IDE 등을 사용해서 다른 Glue 사용자들과 공유를 할 수도 있단다. 따라서 Kinesis firehose 등을 사용하여 인입된 데이터를 서비스간 원하는 대로 편리하게 쪼물락 할 수 있다는 말. 


몇가지 서비스가 더 있기는 하지만, 일단 영문과 국문 블로그에 소개된 서비스들을 우선으로 정리 했다. 어차피 다들 시간을 두고 차근차근 살펴보아야 할 서비스들이므로, 몇개월 재미지게 생겼다. 

매번 느끼는 거지만 최근의 비지니스들은 모두 인터넷과 소프트웨어 그리고 데이터를 사용하지 않는 경우는 드물다. 더 중요한 것은 동일한 작업의 반복, 예를 들면 주로 테스트나 빌드, 그리고 배포등 과 같이 사람이 하면 오래걸리거나 실수가 발생하여 장애로 발전하는 형태의 것들이 클라우드 시대에 더더욱 많아진다. 금번 아마존 웹 서비스의  re:Invent 를 보면 인프라는 내게 맡기고 너는 서비스에 집중하라 는 메세지가 매우 강하다. 탄탄한 기본 서비스들을 바탕으로 점점 발표되는 신규 서비스의 양이 가속화 되는 것을 보면 굉장하다. 

나 역시 아마존 웹 서비스의 강렬한 팬이지만, 아마존 웹 서비스를 사용한다고 아마존 닷 컴을 만들 수 있는 것은 아니다. 결국 핵심 역량은 서비스에 필요한 애플리케이션과 데이터 코드를 얼만큼 빠르게 개발하고 테스트해서 배포할 수 있는가 하는 것이 아닐까.  


아마존 웹 서비스의 시장과 고객에 대한 집착이 보이는 굉장한 2일의 키노트였다. 

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


저작자 표시 비영리
신고

AWS re:Invent 2016 - Keynote 1 신규 서비스

Techs


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

오랜만에 아마존 웹 서비스 관련 내용. 아마존 웹 서비스는 매년 10월-12월 사이의 겨울에 글로벌 규모의 행사를 진행한다. 이 행사는 re:Invent 라고 불리며 매년 참가자가 늘어나고 있다. 올해 2016년에는 3만 5천명 규모의 행사로 라스베가스의 베네시안에서 진행된다. 여러해 동안 아마존 웹 서비스와 이렇게 저렇게 인연을 쌓아왔지만 re:Invent 에 참석하는 것은 처음이다. 어마어마한 사람들, 해를 거듭할 수록 쏟아지는 새로운 서비스들, 그리고 이 서비스들을 사용한 다양한 경험의 공유와 더 잘 사용하기 위한 팁 등이 발표된다. 

2016년 올해도 다양한 서비스들이 발표 되었다. 전반적인 서비스 개선의 흐름을 보자면 사용성의 개선을 통한 신규 사용자의 진입 장벽을 낮추고, 데이터 분석과 관련된 신규 서비스들이 발표 되었으며 특히 아마존 에코를 통해 축적된 음성 인식 기술을 보편적으로 사용할 수 있도록 하는 서비스들, 이미지 분석, 그리고 대량의 데이터 이전 등 첫날의 발표는 다소 데이터에 집중하는 모습이다. 

아마존 웹 서비스는 탄탄한 기반의 EC2와 S3를 바탕으로 지속적으로 서비스 포트폴리오를 확장해 왔는데, 이번에도 역시 아마존의 서비스를 지원하기 위해 필요했던 다양한 기술, 그리고 아마존의 경험이 녹아있는 기술들이 아마존 웹 서비스로 발표 되었다는 느낌이다. 


아래는 발표된 서비스에 대한 간략한 설명과 자세한 사용을 위한 링크다. 


EC2 확장 기능, Elastic GPU : https://aws.amazon.com/ko/blogs/korea/in-the-work-amazon-ec2-elastic-gpus/

- EC2 서버 인스턴스에 GPU를 붙였다 떼었다 할 수 있도록 디자인된 EC2 확장 기능 


F1 인스턴스 패밀리https://aws.amazon.com/ko/blogs/korea/developer-preview-ec2-instances-f1-with-programmable-hardware/ 

- FPGA를 사용할 수 있는 새로운 인스턴스 타입 


Amazon Athenahttps://aws.amazon.com/ko/blogs/korea/amazon-athena-interactively-query-petabytes-of-data-in-seconds/

- S3에 저장된 데이터에 표준 SQL을 사용할 수 있는 서비스 


Amazon LEXhttps://aws.amazon.com/ko/blogs/korea/amazon-lex-build-conversational-voice-text-interfaces/ 

- 음성 인식 및 자연어 이해를 통해 채팅봇 또는 애플리케이션에 음성 인터페이스를 추가할 수 있도록 하는 신규 서비스. 아직 한국어 지원은 되지 않는 듯 


Amazon Pollyhttps://aws.amazon.com/ko/blogs/korea/polly-text-to-speech-in-47-voices-and-24-languages/ 

- 다양한 음색과 언어를 지원하는 문장 -> 음성 인터페이스 서비스. 지원하는 언어에 사용되는 다양한 어휘를 상황에 따라 올바르게 읽는 능력을 제공, 따라서 LEX 와 함께 사용할때 애플리케이션에서 처리한 내용을 음성으로 사용자에게 전달할 수 있음 


Amazon Rekognitionhttps://aws.amazon.com/ko/blogs/korea/amazon-rekognition-image-detection-and-recognition-powered-by-deep-learning/ 

- 이미지의 내용을 분석해 주는 서비스. 이미지의 사람 표정에서 감정을 추출하거나, 이미지의 내용을 딥러닝에 기반하여 리턴 


Amazon Aurora - Posgresql : https://aws.amazon.com/ko/blogs/korea/amazon-aurora-update-postgresql-compatibility/ 

- 아마존 오로라는 아마존이 만든 오픈소스 기반의 데이터베이스 서비스인데, 종전에는 MySQL 호환만 존재 하였으나 이번에 Postgres 엔진도 발표 됨. 기존의 RDS Posgres 로 부터의 손쉬운 마이그레이션 등을 제공하며, 일반적으로 두배 정도의 성능 향상을 기대할 수 있다고 함 


AWS Greengrass : https://aws.amazon.com/ko/blogs/korea/aws-greengrass-ubiquitous-real-world-computing/ 

- IoT 관련 서비스를 만들다 보면 데이터를 클라우드로 전달하는 과정에서 누락등이 발생하기 때문에 이를 보완하기 위해 Sensor 게이트웨이 같은 장치를 구현하는 경우가 많은데, 이를 클라우드로 직접 전달하는 대신 센서등이 위치한 로컬의 하드웨어에서 Lambda 기반의 Greengrass Core 를 실행하여 작업을 처리하는 도구. 즉, IoT 데이터 처리를 위한 로컬 람다 소프트웨어. 


AWS Snowball Edgehttps://aws.amazon.com/blogs/aws/aws-snowball-edge-more-storage-local-endpoints-lambda-functions/ 

- 내용을 보다 보면 기존의 Storage Gateway 와 Snowball 을 합친 모양새. Snowball 은 로컬의 데이터센터에서 아마존으로 데이터의 이동이 필요한 경우 제공되는 일종의 운반용 디스크 세트였는데, 이를 아예 센터의 로컬에 설치하여 연동할 수 있도록 구현한 것으로 보임. 인터페이스는 10G, 25G, 40Gbps 를 제공하며, 심지어 Zigbee 역시 지원한단다. S3의 API 가 달려있으며 멀티파트 업로드 등으로 데이터 전송을 빠르게 처리할 수 있고, 몇개를 더 묶어서 클러스터링까지 가능한 모양. 람다를 사용한 컴퓨팅 기능까지 포함 하고 있는 로컬 스토리지 + 컴퓨팅 머신  


AWS Snowmobilehttps://aws.amazon.com/blogs/aws/aws-snowmobile-move-exabytes-of-data-to-the-cloud-in-weeks/ 

- 엑사 바이트 규모의 데이터 이전에 사용한다. 데이터센터에 아무리 빠른 네트워크가 있다고 하더라도, 엑사바이트 규모의 데이터를 아마존으로 전송하기 위해서는 수개월-1년 이상의 시간이 필요할 수 있다. 이에 아마존은 스노우모바일이라 불리는 서비스를 출시 하였으며, 거대한 컨테이너가 달린 트럭을 사용한다. 

http://venturebeat.com/2016/11/30/aws-unveils-snowmobile-truck-for-moving-data-to-its-cloud/


오늘 나온 서비스들이라서 더 자세한것은 써봐야 알겠지만 어쨌든 클라우드 서비스 시장에서의 맹주로서 무서운 속도로 서비스를 내어 놓는 것 만은 분명하다. 새롭게 늘어난 인스턴스 종류, 직접 구현하기 힘든 다양한 음성 및 데이터 관련 서비스들은 아마도 다양한 스타트업들에서 다양한 형태로 사용될 것으로 생각된다. 

놀라운 점은, 이미 시장에서 선두를 달리고 있는 회사가 이런 속도로 또 다시 신규 서비스들을 발매 한다는 점이다. 아울러 최근의 모든이가 알겠지만, 1.0 버전의 발매는 거기서 끝이 아니라 지속적인 개선을 필요로 한다. 수십개가 넘는 각각의 아마존 웹 서비스의 제품들이 저마다 또 다른 속도로 개선될 것을 생각해 보면, 2017년에는 아마도 일주일에 50개씩 업데이트가 생길지도 모르겠다. ㅎㅎ 

아울러 피보탈의 클라우드 파운더리에서 Amazon Service broker 를 통해 다양한 신규 서비스를 애플리케이션 개발자가 손쉽게 연동해서 사용할 날이 오기를 기대한다. 

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

저작자 표시 비영리
신고

Deploy your application to every cloud - Azure

Techs


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


제목과 같은 내용의 설명을 원하는 경우라면 섹션 4로 바로 점프. 



1. 멀티 클라우드, 그리고 인프라? 


클라우드에 관심이 있다면 멀티 클라우드 라는 말을 한번쯤은 들어 보았을 것이다. AWS에 오토 스케일링 이라는 기능조차 없던 시절, RightScale 이라는 회사가 있었다. 이 회사는 인프라 레벨에서 템플릿의 구성과 배포를 멀티 클라우드에 할 수 있도록 해 주었던 기업이다. 물론 대부분의 인스턴스 consume 은 AWS에서 발생했다고 알고 있고, 그리고 전술했듯 AWS의 오토스케일링이 없던 시절 AWS의 API를 와 별도의 모니터링 에이전트를 사용해 부하를 측정, 특정 시점에 정밀한 오토스케일링의 구현이 이 회사가 가졌던 장점이었다. 사실 생각해 보면 매력적인 제안인데, 단 하나의 클라우드 서비스 공급자를 사용하는 것이 아닌 다양한 클라우드 공급자를 탄력적으로 사용함으로서 부하 및 장애에 대해 효율적으로 분산할 수 있다는 개념은 지금도 구성만 잘 할 수 있다면 뛰어난 운영 전략이 될 수 있다. 



http://www.rightscale.com/


다만 현재 이 회사가 오늘날 그다지 성공적(?) 이라고 말하기 힘든 이유는, 당시의 이 회사의 주요 자금원이었던 오토스케일링 기능이 AWS의 EC2에 기본 기능으로 제공이 되면서 부터였고, 또한 당시의 다른 클라우드 서비스 공급자들의 서비스가 AWS에 비해 매력적이다 라고 말하기는 다소 힘든 상황이었기 때문이다. 사실 말이야 바른말이지 몇년 전 까지만 해도 Virtual Machine 의 구동 및 관리 자체가 힘든 서비스들은 널리고 널렸었다. 따라서 이 오토스케일링의 매력 저하와 멀티 클라우드라는 컨셉 두개가 모두 잘 동작하지 않으면서 전략적으로 힘든 위기 상황을 맞이 하지 않았나 싶기도 하고 말이다. 물론 이 외에도 다양한 요인이 있었겠지만, 가장 핵심적인 사안은 이것 두가지가 아니었을까 한다. 


시대는 이제 가상화를 넘어 컨테이너를 향하고 있다. 그것이 팬시하건 좋건 나쁘건 그리고 현 상태에서 그 사용의 방법과 범위를 오인하는 사람들이 많건 적건 어쨌든 컨테이너는 Docker를 중심으로 빠르게 발전하고 있다. 이 말인 즉 인프라 레벨에서의 멀티 클라우드 사용에 장점이 있었던 RightScale은 앞으로 조금 더 힘들어 지지 않을까 하는 개인적 견해와 맞물려, '인프라'만으로서의 장점은 이제 원한다면 바로 어디에나 배포할 수 있는 컨테이너가 있기 때문이다. 


인프라 레벨에서의 접근에는 사실 다양한 선택지가 있을 수 있다. 하지만 그 모든 선택지에는 각 클라우드 서비스에 대해 아주 잘 알아야 실제 서비스에 도입 할 수 있다는 이면이 숨어있기도 하다. Docker 를 사용하면 물론 이론적으로는, 그리고 실제적으로도 다양한 클라우드 서비스 공급자 또는 심지어 데이터센터에 구축 가능한 환경에도 애플리케이션을 배포할 수 있다. 하지만 이 애플리케이션의 배포 주기가 매우 자주 발생한다면, 그리고 이걸 다양한 클라우드 위에서 동작시켜야 한다면 추가적으로 처리해야 할 일이 보통 많은것이 아니다. 이 '보통 많은 것이 아닌' 부분을 처리하기 위해 Docker 는 다양한 eco를 지속적으로 개발 및 개선하고 있지만, 프로덕션 레벨에서 사용하고 있다는 엔지니어링 블로그를 본 적이 별로 없다. 


정리해 보면, 컨테이너의 장점은 분명 '플랫폼과 상관없이'에 있지만 그 프로덕션 레벨에서의 구현이 기술력 높은 회사라고 하더라도 아직 많지 않다 라고 할 수 있는 것이다. 각 클라우드 서비스 공급자에서 docker 를 지원하잖아요 라고 말은 할 수 있겠지만, 그래서 그 docker image 를 각 클라우드에 직접 배포하고 동작하는 환경을 만들겠다는것은, 완전히 다른 이야기라는 점이다. 아, 물론 하지 말라는 말 아니다. 시간과 기술과 환경이 허락하는 한 하고 싶으면 할 수 있다. 대한민국은 기술 스택 선택의 자유가 있는 나라니까. 



2. 컨테이너가 필요한거야 docker가 필요한거야? 


먼저 이 블로그 포스팅에서의 컨테이너 사용의 언급 범위는 '애플리케이션이 동작하는' 부분만을 포함한다. 무슨 말인고 하니, '서비스를 동작하기 위한 용도'로서의 컨테이너 기술은 제외한다. MySQL이나 카산드라, PgSQL, 하둡 스파크 기타 등등의 수많은 서비스들을 컨테이너에 동작시키고자 하는 시도가 많이 있는줄로 안다. 하지만 여기서는 애플리케이션을 동작시키기 위한, 이를테면 NodeJS, Spring, Java, PHP, Python, Go, Ruby, Linux binary, .NET 과 같은 도구로 제작된 것들 말이다. 





특정 버전의 애플리케이션의 라이프사이클을 살펴보면, 먼저 프로덕트 매니저를 통해 해당 기능의 구현 및 추가가 요구된다. 이는 이슈 트래커를 통해 등록되고, 각자 조직의 입맞에 맞게 구성되어 일감으로 엔지니어에게 할당된다. 이렇게 할당된 일감은 코드로 구현되고, 그것이 다른 사람으로 이루어진 팀이건 자동화 된 도구건 어쨌든 테스트를 거쳐 다음번 릴리즈 배포를 위해 준비된다. 릴리즈 타이밍이 오면, 그 동안 차곡 차곡 모아온 기능들의 커밋을 주워담아 프로덕션에 배포한다. 그렇게 배포된 버전은 다음번 릴리즈가 오기 전까지 열심히 동작하다가, 때가 오면 다음 버전에 그 자리를 물려주고 은퇴한다. 


컨테이너의 사용은 먼저 개발자의 랩탑에서 시작될 수 있다. 개발자는 구현 시점에서 컨테이너를 사용한다. 이것이 잘 동작하려면 지난 버전의 애플리케이션 코드를 바탕으로 내가 개발하고자 하는 기능을 지속적으로 구현 및 테스트를 시도한다. 따라서 랩탑에 컨테이너 구동의 환경이 필요하다. 개발자 스스로 테스트도 하지 않고 배포할 수야 없지 않은가 말이다. 두번째로, 만약 테스트를 자동화 구성했다면 신규로 코드 저장소에 반영된 코드를 가져다가 지정한 테스트 작업을 돌릴 것이다. 아니면 별도의 빌드 작업이 여기서 처리 될 수도 있겠다. 새로 업데이트 된 기능이 반영된 커밋을 가져다가 지지고 볶고 테스트 하는 것을 VM으로 하면 그거 제법 돈 낭비일 수 있다. 개발팀이 하나 있거나 하루에 두세개 코드가 신규로 생성되고 테스트 된다고 하면야 그것이 무슨 상관이겠냐마는, 하루에 십수개, 또는 수십개의 팀이 지속적으로 코드를 생성해 내고 이렇게 생성된 코드가 지속적으로 빌드 되고 테스트 되는 환경이라면 VM은 분명히 낭비다. 특정 클라우드 공급자를 사용하는 경우라면 시간당 리소스 사용 비용을 지불해야 할 것인데, 이것이 매 테스트마다 새로 켜지고 테스트 하고 꺼지고 한다면 돈이 쏠쏠하게 요구된다. 그래서 컨테이너를 쓰면 좋다. 테스트 및 빌드에서 컨테이너를 사용하는 것은 사실 좀 쿨한 아이디어라고 할 수 있다. 따라서 테스트 환경을 어떻게 컨테이너로 구성해야 하는지에 대한 아이디어와 또, 구현이 필요하다. 마지막으로는 서비스의 배포인데, 당연한 말이지만 원하는 클라우드 사업자 환경에 컨테이너 기반의 배포 환경을 구성해야 한다. 물론 그것이 꼭 컨테이너가 되어야 하는가에 대한 이의가 있을 수 있겠지만, 만약 멀티 클라우드 라는 꼭지를 생각했다면 반드시 docker를 함께 생각하고 있을 것이라고 예상 되므로, 그렇다고 할 수 있다. 그래서 다시 프로덕션 환경에 어쨌든 docker를 준비한다. 



https://bitcontainer.wordpress.com/2015/09/18/scaling-microservices-with-docker-compose-interlock-and-haproxynginx/

코드를 쓸 것인가 인프라 놀이를 할 것인가. 그것이 문제로다. 10초만 봐도 질문이 10개는 생김. 



한문단이 매우 길었다. 어쨌든, 이 글을 읽고 계신 분이 docker 를 매우 사랑한다면 위에 말한 문단의 사이클과 각 단계에서 필요한 구현에 대해 매핑이 금방 이루어질 것이라고 믿어 의심치 않는다. 이 의심치 않는 부분에 있어, 몇가지의 질문에 대해 생각해 보면 어떨까 싶다. 그것은 첫째로, 만약 전체 서비스 시스템 수준의 라이브러리 업데이트가 필요한 상황은 어떻게 대처해야 할 것인가, 이를테면 CVE와 같은 것들 말이다. 두번째로, 지속적으로 발생하는 수많은 애플리케이션의 커밋 별로 이미지를 제작할 것인가. 그렇지 않다면 그 이미지와 애플리케이션 업데이트의 상관 관계는 어떻게 되는가. 셋째로, 애플리케이션이 녹아있는 docker 이미지가 신규로 배포되거나 서비스에서 삭제 되었을때, 서비스-인, 서비스-아웃 처리는 어떻게 할 것인가. 만약 HAproxy 를 사용할 것이라고 답한다면, 매번 오토스케일링 트리거로 인해 이벤트가 발생했을때 마다 설정을 변경하고, 서비스를 리로드 할 것인가. 넷째, docker 이미지 원본이 변경되어야 할 필요가 있을 경우, 기존 배포된 컨테이너들은 어떻게 처리할 것인가. 이를테면 Go_lang의 alpine 버전을 사용하다가 의존성, 보안, 기타 등등의 문제로 업데이트가 필요한 경우에는 어떻게 대처할 것인가. 다섯째, 실제로 docker를 AWS, OpenStack, Azure 등 다양한 환경에 프로덕션에 올릴 것이라면 앞서 말한 네가지를 역시 다양한 프로덕션에 준비해야 할텐데 실제 구현까지 얼마나 걸리겠는가. 


이의가 있을 수 있다. 처리하는 기술이 있을 것이라고 말하고 싶을 것이라는 것도 잘 안다. 그리고 필드에서 실제로 내가 듣는 답변은, 어쨌든 우리의 to be는 거기에 있기 때문에 가야 한다고 말한다. 그래서 when 의 질문과 함께, how 를 함께 던지면 그 답변이 요원한 것도 항상 자주 목도하는 것이기도 하다. 



3. Tracker - Github - Concourse - Cloud Foundry 의 링크 


본 블로그에서 여러번 소개하긴 했지만, 위의 체인이 Pivotal Labs 에서 사용하고 있는 방법이다. 이들 중 Concourse 와 Cloud Foundry 는 Docker 를 지원한다. 그리고 Cloud Foundry 는, docker 가 시장에 풀리기 이전부터 lxc 를 사용한 컨테이너를 사용해 왔으며, docker 가 없더라도 컨테이너 사용성을 제공한다. 뭔말이냐면, 개발자는 코드 저장소에 commit 만 하면 클라우드에서 컨테이너로 알아서 돌려준다는 말이다. 테스트 및 빌드 도구로 사용할 수 있는 Concourse 는 docker 를 이미 지원한다. 다양한 스크립트를 제작하고, 빌드, 테스트, 배포 파이프라인을 만들어 자동화 테스트를 구현하는데 이미 docker 를 사용할 수 있도록 제공 한다는 말이다. 어쨌든 이 체인에 대한 연동은 지난번 포스트에서 설명 했으므로 더 깊이 가지는 않기로 한다. 


위에서 제시한 다양한 질문에 대한 답으로, 아래와 같은 환경을 상상해 보기로 한다. 이슈 트래커인 피보탈 트래커에서 일감이 생성된다. 생성된 일감을 코드로 만든다. 만들어진 코드는 코드 저장소에 업로드 된다. 업로드 된 코드는 Concourse 도구를 통해 docker 기반의 빌드 테스트, 배포 작업을 한다. 테스트 환경에 배포까지 완료가 되면, 일감을 할당한 사람이 해당 기능이 잘 동작하는지 리뷰한다. 잘 돌아가면 승인하고, 승인된 코드는 다음번 릴리즈에 반영되도록 추가된다. 그리고 다음번 릴리즈의 배포는 특정 시점에 역시 Concourse 에 구성된 '프로덕션 배포 파이프라인' 을 통해 Cloud Foundry 에 배포된다. 





개발자는 랩탑에 컨테이너 구동을 위한 환경을 구성할 이유가 없다. 안그래도 설치할 거 많은데 docker 건 lxc 건 그런 구성환경 docker 개발자가 아니라면 설치할 필요가 애초에 없다. 그냥 스프링이건 노드건 루비건 파이썬이건 원하는 개발 환경을 준비하면 된다. 그렇게 커밋된 코드는 데이터센터나 클라우드 환경에서 테스트 된다. 그리고 테스트 된 코드는 데이터 센터건 AWS, Azure, OpenStack 어디든 배포된다. 각 환경에 수많은 개발자들이 한꺼번에 커밋하더라도 별 문제 없이 업데이트 된 코드는 각각 가져다가 테스트 된다. 공장의 라인이 돌아가듯, 일단 커밋되면 나머지는 빙글빙글 돌아간다는 말이다. 그것이 가능하도록 하는 것이 바로 이 체인이다. 


구성과 배포에는 얼마나 시간이 걸리나. Cloud Foundry OSS 버전이라면 아마도 공부도 좀 하고, 복잡한 bosh 도 공부하고, 몇번 설치 실패도 경험하고 하면 보통 한달 정도면 구현 하는 것 같다. 물론 그 한달은 보통 하나의 클라우드 서비스 공급자에 제한된다. 이를테면 AWS에 배포 방법을 알게 되었다고 해서 Azure에 당장 똑같이 할 수 있는 것은 아닐 것이다. 완전 다르지는 않지만 별도의 설정이 필요하고, 관리 방법에 대해 학습할 필요가 있다. 만약 Pivotal Cloud Foundry 의 상용 버전이라면, OpenStack, AWS, Azure 등의 환경 배포에 1일-3일 정도면 끝난다. 필요한 다른 다양한 데이터 서비스, 이를테면 MySQL이라던가, PgSQL, Redis, RabbitMQ 등등등의 도구와 함께. 



https://ritazh.com/deploy-and-run-concourse-ci-on-azure-2fc9fec1f8a8#.zc3cnssdj



Concourse 를 사용한 테스트 파이프 라인의 구현 역시 어렵다고 보기는 힘들다. 오히려 어려운것은 테스트 자동화 그 자체라고 볼 수 있는데, 이것은 조직의 DevOps들이 지속적인 경험을 통해 테스트 방법을 개선해 갈 수 있다. 그리고 이런 테스트들은 보통 해당 서비스의 유지 기간과 함께 지속적으로 증가하기 때문에, 시간이 지날수록 견고한 테스트 파이프라인을 구성할 수 있다는 장점이 있다. 자주 받는 질문이 꼭 사람이 테스트 해야 하는것은 어떻게 해요 인데, Pivotal Labs 에서는 이것이 코딩을 통한 구현 단계에서 확인 된다. 두사람이 앉아 개발하고 새로운 코드에는 반드시 테스트를 위한 코드가 따라 붙는다. 여기에는 현장에서 사용되는 다양한 방법과 룰이 있는데, 이런 것들이 바로 조직이 세월이 지나며 쌓아야 하는 기술 노하우라고 볼 수 있다. 아울러 각 서비스 별로, 각 회사별로 테스트 항목이 같은 것도 있지만 다른 부분도 많기 때문에, 어쨌든 시간을 들여 견고하게 만들어야 한다고 볼 수 있다. 뭐 썰이 길었지만, 정리하면 이 컨테이너 기반 파이프라인 환경을 사용하기 위한 준비 역시 1일-1주일 정도면 구성한다. 나머지는 코드의 영역이다. 


'언제까지' 는 아마 지겹도록 듣는 말일 것이다. 특정 클라우드 서비스 공급자에 종속을 받고 싶지 않다는 것은 그 나름대로 타당한 이유라고 볼 수 있다. 현재로서는 거대한 여당 하나가 있는데, 그 여당이 매우 참 잘하고 있다. 운영도, 개발도, 그리고 심지어 고객 응대 방법과 규모 및 가격 요소까지 두루 훌륭한 여당이다. 반대로 다수의 야당이 존재하는데, 처음 시작할때도 언급 했지만 지난 세월 동안 많은 발전을 이룩하여 이제 많은 서비스들이 사용에 불편함이 없는 정도로 제공되고 있는 것으로 보인다. 이 말에 주의해야 할 필요가 있는데, 클라우드 서비스 공급자의 선택이 단일화 되어야 하는 경우와 다수의 클라우드 서비스 공급자를 선택해야 하는 경우는 다르다. 단일 서비스 공급자 선택시에도 중요하지만, 다수 서비스 공급자를 함께 사용할때의 전체 아키텍처는 도메인 부터 스토리지 레벨까지 준비해야 할 것이 많다. 즉, 멀티가 훨씬 복잡한 작업이 될 수 있지만, 그것을 잘 준비할 수 있다면 - 바로 이부 부분이 PCF/CF의 매력 - 좀 아름 다울걸. 


Concourse 를 Azure 에서 사용하고 싶다면 여기 링크를. - https://ritazh.com/deploy-and-run-concourse-ci-on-azure-2fc9fec1f8a8#.zc3cnssdj  AWS나 OpenStack 등에서 사용하고 싶은 경우에도 검색을 쌔우면 금방 나옴. 



4. Pivotal Cloud Foundry on Microsoft Azure 


사실은 이 부분을 간단하게 포스팅 하고 자려고 했는데 망했다. 사설이 매우 길었다. 내 손꾸락도 노동을 많이... 


Amazon Web Services 에서 Cloud Foundry 를 동작하는 것은 사실 쉬운일이다. 그것이 오픈소스건, 상용 버전이건간에 관계없이 다양한 경험들이 있고, 조금 찾아보면 - 물론 날짜가 지나 유효성이 떨어지는 답변도 많지만 - 어쨌든 레퍼런스나 해답에 대한 아이디어를 얻을곳은 많다. 그리고 특히 상용 버전은 https://network.pivotal.io 에서 가입후 그냥 다운로드 받아서 문서대로 따라해 보면 쉽다. 문서 링크는 여기. https://docs.pivotal.io/pivotalcf/customizing/cloudform.html 


최근 Pivotal 과 Microsoft 는 Pivotal Cloud Foundry 를 Azure 의 Marketplace 에 배치하고, PoC 를 위한 용도로 편리하게 사용할 수 있도록 제공하고 있다. 따라서 Azure 의 고객이라면 누구나 쉽게 PCF 를 준비하고, 함께 제공되는 몇가지 데이터서비스와 함께 파일럿으로 사용해 볼 수 있겠다. 그리고 이 부분에서는 어떻게 하면 설치가 가능한지, 물론 영문 문서가 있기는 하지만 단계별로 좀 쉽게 설명 하고자 한다. 원하는 분들은 위의 1~3 섹션에서 언급되었던 '컨테이너 기반의 오케스트레이션', '코드를 커밋하면 클라우드위에서 컨테이너로 동작하는', 및 기타 등등 로깅 등의 다양한 기능을 Azure 위에서 활용할 수 있는데 테스트로 사용해 볼 수 있겠다. 


Pivotal 이 제공하는 다양한 서비스들은 PCF를 포함하여 bosh 라는 설치 도구를 사용하게 되어 있다. bosh 에는 CPI 라는 부분이 존재하는데, 이는 Cloud Provider Interface 의 약자로 보면 된다. 그리고 이 bosh 자체는 오픈소스 프로젝트이며, Pivotal 이 주도하기는 하지만 CPI 와 같은 인터페이스 부분은 각 클라우드 서비스 공급자들이 참여한다. 이는 Microsoft Azure 의 경우에도 마찬가지며, 아래의 github 그래프를 보면 AdelHu 씨와 Bin Xia 씨가 수고해 주고 있음을 확인 가능하다. https://github.com/cloudfoundry-incubator/bosh-azure-cpi-release/graphs/contributors 그래서 뭔말이냐고? Microsoft 가 Cloud Foundry 발전에 이바지하고 있다는 것. 


다시한번 언급하지만, 상용에서의 멀티 클라우드 사용을 위해 PCF를 AWS, Azure, OpenStack 과 같은 환경에 준비하는 경우에는 도메인부터 스토리지까지 저와 함께 이야기 하시면 됩니다. (쿨럭..) 



아무튼 고고씡. 



a. 사전 준비 사항. 

- Microsoft Azure account : 가입해야 한다. 당삼 빠따루. 카드 정보 필요하다. 으헝 

- Subscription : 가입 후에는 프리로 사용할건지, msdn 플랜을 사용할 것인지, 아니면 사용한 만큼 지불할 것인지 등의 옵션을 선택해야 한다. 본인의 경우 마이크로소프트의 신현석 차장님께서 지원을 해 주셨다. 소주 사야 함. 

- https://network.pivotal.io 의 계정. 없다면 그냥 가입하면 된다. 

- 매뉴얼 :  https://docs.pivotal.io/pivotalcf/customizing/pcf_azure.html 

- Core 리밋 해제 요청 : https://portal.azure.com 에 로그인 하면 대시보드가 나타나는데, 여기서 도움말 + 지원을 클릭하면 아래와 같은 화면을 볼 수 있다. 



AWS와는 다르게 화면이 좀 이쁘다. 리소스 사용의 컨셉이 약간 다르기 때문에 AWS web console 이 편리한 분들께는 아마 처음에 매우 낮설지도 모르겠다. 어쨌든 새 지원 요청을 누르면 오른쪽에 기본 사항이 나타나고, 만약 한글이라면 '할당량' 을 선택하고, 할당량 유형에서 '구독당 코어' 를 선택한다. 




Azure 를 전문으로 하시는 분들은 알겠지만, 본 PCF의 Azure 배포는 Marketplace 를 사용한다. 이 경우 리소스 그룹으로 배포되므로 배포 모델에서 '리소스 관리자'를 선택하였다. 심각도의 경우 각 지원 요청이 비지니스에 미치는 영향을 기준으로 등록하는데, 보통 AWS에서는 Serverity 로 표기되고 구매한 서포트의 등위에 따라 선택 가능한 범위가 정해지는데 Azure 도 그런지는 잘 모르겠다. 어쨌든 중요한 것은, 어느 위치에 반영할 것인가 라는 문제다. Azure Marketplace 에 등록된 기본 템플릿에 정의된 VM size 는 Standard D2 타입이다. 궁금하신 분들은 Azure 홈페이지 참조. 아무튼 이 VM size 가 일본 서부에 없기 때문에, 본 설치에서는 East Asia 를 선택했다. 배포 템플릿은 AWS 의 CloudFormation 과 유사한 사용성을 지니는 것으로 보이는데, 역시 JSON 타입으로 되어 있어 일부 수정을 하면 일본 서부에서도 배포가 가능할지 모르겠다. 


아무튼 East Asia 를 선택하고, 기본 20인 할당량을 100 정도로 늘려 달라고 요청한다. 요청의 처리는 보통 업무일 기준으로 2-3일 정도 걸린다고 나오는데, 본인의 경우 아래의 채팅 창을 사용해서 조금 징징댔더니 빨리 처리해 주었다. 


이렇게 준비가 끝나면, 이제 본격 설치 단계로 진입하자. 별로 안어렵다. 



b. Azure CLI 의 설치. 


되게 당연한건데, CLI 가 존재한다는 사실에 살짝 놀랐다. 왜 놀랐을까는 나도 모르겠다. 아무튼 아래의 링크 내용을 참조하여 CLI 를 설치하자. 역시 AWS CLI 와 마찬가지로, 쉽게 설치가 가능하고 사용성도 좀 유사하다. 뭐 CLI 가 다 그렇지... 


https://azure.microsoft.com/en-us/documentation/articles/xplat-cli-install/



c. 아래의 Github 에 있는 쉘 스크립트를 로컬에 준비한다. 


https://github.com/cf-platform-eng/bosh-azure-template/blob/master/create_azure_principal.sh 


이 스크립트는 Azure 에 PCF 를 배포하기 위해 필요한 기본 정보를 생성해 주는 역할을 한다. 스크립트의 구동은 간단한데, ARGV1 으로 구독 형태를 넣어주면 된다. 본 경우에는 msdn 구독이므로, 뒤에 msdn 을 써 주었다. 그렇게 스크립트를 실행하면 지혼자 일을 알아서 하지 않고 뭔가를 기다리는 것처럼 뱅글뱅글 돈다. 멍잡고 있으면 안되고, 잘 읽어보면 https://aka.ms/devicelogin 이라는 페이지에 가서 인증 코드를 넣어주란다. 그렇다. CLI 가 계정 정보 접근을 위해 웹을 통해 OAuth 인증하고 있는거라고 보면 된다. 


스크립트 실행. 인증을 위한 URL과 코드가 주어진다. 



위의 화면에서 콘솔에 제공되는 코드를 입력하도록 한다. 코드를 입력하면 어떤 계정과 연결할 것인지 묻고, 만약 사용중인 메인 브라우저가 다르다면 다시 한번 로그인 해야 할 것이다. 어쨌든 브라우저 창을 닫아도 좋다는 메세지를 확인하면, 스크립트가 다음 단계로 진입하는 것을 확인할 수 있을 것이다. 



개인정보 보호를 위해 사방팔방 빵구가 보이는데, 아무튼 중요한 정보는 제일 아래 나오는 tanantID, clientID, CLIENTSECRET 의 세 부분이다. Azure CLI 사용에 관심이 많다면 역시 해당 홈페이지를 살펴보면 되겠다. 사전에 서비스 이해는 필수~ 



d. https://network.pivotal.io 에서 계정 API 토큰 확인 


Pivotal의 제품 다운로드 페이지인 network.pivotal.io 에 가입후 로그인을 하면, 우측 상단에 내 ID가 보인다. 클릭하면 드랍다운 메뉴가 나오는데, 여기서 "Edit Profile" 을 클릭하면 계정 정보 페이지로 이동한다. 페이지의 제일 하단으로 이동하면 API TOKEN 이 보이는데, 여기 나오는 토큰 정보를 준비해 두면 되겠다. 




e. Marketplace 검색, 그리고 해당 정보 입력 


https://portal.azure.com 으로 돌아와 로그인을 하면, 기본 화면 좌측에 +새로 만들기 버튼이 있다. 클릭하면 제일 상단에 검색이 가능한데, 여기에 Pivotal Cloud Foundry 를 입력하면 우측에 탭이 확장되며 관련 정보가 나타난다. 



마켓 플레이스에서 Pivotal Cloud Foundry 검색 




만들기 버튼까지 오면 된다. 설명을 살펴보면, Pivotal Cloud Foundry 와 MySQL, Redis, RabbitMQ, Spring Cloud Services, Apps Manager 가 설치될 것이라고 안내 된다. 다른건 아마 익숙할 테니 Spring Cloud 와 Apps Manager 만 설명하면, Spring Cloud Services 는 Netflix OSS 중 Circuit Breaker, Eureka, Config Server 의 세가지를 별도의 설치 없이 바로 애플리케이션에 사용할 수 있도록 준비한 것이라고 보면 되겠다. 이 세가지에 대해 처음 들어 보았다면, 각각의 이름으로 검색해 보자. 마이크로 서비스 아키텍처 라던가 클라우드에 맞는 확장성 및 고가용성을 구현하고자 할때 반드시 필요한 도구의 형태로 볼 수 있으며, 현재는 Spring Cloud 에 녹아있다. Pivotal 의 동료 중 한명이 Tip Toe 인가 하는 이름으로 닷넷에서도 사용할 수 있도록 하는 프로젝트를 하고 있단다. (Pivotal 공식 프로젝트는 아님) 



어쨌든 만들기 버튼을 클릭하면 위의 리소스가 다 뾰로롱 생긴다. 물론 이전의 필요한 내용을 다 이상 없이 준비한 경우에 말이다. 무언가 문제가 생겼다면 로그를 확인할 수 있으므로 반드시 참조하여 원인을 파악하도록 한다. 경험상 할당량이 충분하지 않다던가, CLI 에서 Oauth 를 통한 로그인 뒤 한참 있다가 (수시간 후) 만들기 버튼을 통해 배포를 수행한다던가 하면 세션 만료등과 같은 이유로 배포가 실패하는 것 같다. 그 이외에는 별다른 문제는 없었다. 



f. 필요 정보 입력 



위의 화면에 나타나는 정보 기입만 문제가 없다면 이후 배포는 알아서 자동으로 스뭇쓰 하게 된다. 각각의 항목에 대해 설명하면 다음과 같다. 


- Storage Account Name Prefix : Blob Storage, 이를테면 아마존의 S3와 같은 형태의 저장소를 준비한다. 아마존의 S3를 사용해 보신 분들은 알겠지만, 버켓의 이름 자체가 FQDN 이 되거나 또는 그렇지 않더라도 오브젝트 스토리지는 보통 global 하게 유일한 이름을 요구하는 경우가 일반적이다. 따라서 본 배포에 사용할 스토리지 이름의 prefix 를 주어야 하는데, 이것을 유일하게 지정하지 않으면 배포 중 에러를 보게 될 것이다. 즉, pcf, pivotal, superman 과 같은 아주 흔한 이름을 사용하면 실패할 확률이 높다는 뜻이다. 유일할 가능성이 높은 본인의 이름과 같은 것을 사용하면 된다. 즉, 어디 사이트 가입할때 아이디 만드는 느낌적인 느낌으로 기입하면 된다. 


- SSH public key : 모두 그런것은 아니겠지만, 배포 후 생성되는 자원에 접근하기 위한 SSH 인증 정보를 넣으면 된다. 보통 ssh-keygen 커맨드로 사용해서 생성되는 ~/.ssh/id_rsa.pub 정보를 넣어 주면 된다. 맥이나 리눅스 사용자라면 매우 쉽겠지만, 윈도우 사용자라면 아래의 Azure 링크를 살펴보도록 하자. https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-ssh-from-windows/


- TenantID : 스크립트 수행으로 나오는 STDOUT 에서 tenantID 내용을 붙여 넣는다. 

- ClientID : 스크립트 수행으로 나오는 STDOUT 에서 clientID 내용을 붙여 넣는다. 

- Client Secret: 스크립트 수행으로 나오는 STDOUT 에서 CLIENTSECRET 내용을 붙여 넣는다. 

- Pivotal Network Token: network.pivotal.io 의 계정 페이지에서 얻은 API TOKEN 을 넣는다. 

- 새로 만들기 후 리소스에 이름을 지정한다. 이를테면, Younjin-PCF-Azure 와 같은 느낌으로. 



모든 정보가 올바르게 기입 되었다면, 확인 버튼을 누른다. 이후 템플릿이 자동으로 생성되는데, 이 템플릿의 유효성을 검사하는 페이지가 나타난다. 1분 내외의 시간에 검사가 종료 되면, 배포 버튼으로 PCF 를 배포 한다. 그리고 아무 문제가 없다면, 이 시점으로 약 2-3시간 정도 후에 PCF 를 사용할 준비가 된다. 이 과정 동안 배포 정보를 확인하면 현재 어떻게 배포가 되고 있는지를 확인할 수 있는 인터페이스를 제공하는데, 해당 링크는 아래 g 섹션의 스크린샷의 '마지막 배포' 아래의 하늘색 링크를 클릭하면 나오는 페이지에서 확인할 수 있다. 





왜 3시간이냐면, PCF 는 배포될 때마다 각 배포 버전에 맞는 리소스들을 컴파일 한다. PCF 자체가 마이크로 서비스 아키텍처로 이루어져있기 때문에, 여기에 사용되는 다양한 도구들이 모두 컴파일 되고, 필요한 VM을 생성한 이후 컴파일 된 패키지가 설치된다. 따라서 컴파일 + 리소스 준비 + 업데이트 시간이 소요되는 것이라고 이해하면 된다. 그럼 업데이트 할때마다 이렇게 오래걸리겠네? 라고 하면 맞다. 좀 걸린다. 다만, PCF 는 다운타임이 없이 업데이트 되므로, 서비스에 지장 없이 사용하면 되겠다. 물론, 배포 준비는 확실하게. 



g. 배포 완료 후 확인 사항 


배포가 완료되면, 아래와 같은 화면을 볼 수 있다. 대시보드에 새로 로그인을 했다면, 새로운 배포의 단축 타일을 확인할 수 있을 것이다. 



무언가 무지하게 많이 배포가 되었다. 이 리소스들이 PCF 를 동작시키는 각각의 서비스 컴포넌트이며, 추가적으로 MySQL 과 같이 설치전에 명시된 서비스들도 함께 동작하고 있다. 만약 할당량이 부족하다면 배포에 에러가 발생하며 중지 될 것이다. 만약 배포가 중지 되었다면, 원인을 알아낸 후 리소스 페이지의 상단에서 '삭제' 버튼을 눌러 반드시 쓸데없는 과금이 발생하지 않도록 주의 하자. 


'마지막 배포' 아래의 하늘색 날짜 링크를 클릭하면 배포의 STDOUT 페이지로 이동하는데, 여기에는 JUMPBOX 의 주소, 현재 어떻게 배포가 진행 되고 있는지에 대한 tail log 를 볼 수 있는 링크가 주어진다. JUMPBOX 로 로그인 하고 싶다면 ssh-keygen 을 수행한 머신 또는 해당 키를 가지고 있는 머신에서 pivotal 계정으로 ssh 접근하면 바로 붙는다. 


한가지 더 확인해야 할 것은, 바로 Pivotal Cloud Foundry 의 IP 다. 위의 리소스 페이지에서 배포된 머신들을 살펴보다 보면, 끝에 -cf 라는 이름이 할당된 머신이 있을 것이다. 이를 클릭하면, 우측에 세부 정보가 표시 되는데 여기에 IP 를 확인 할 수 있다. PCF의 배포는 반드시 도메인이 필요하기 때문에, 이 경우에는 https://apps.system.[IP_ADDRESS].xio.ip 의 도메인으로 접근이 가능하다. 이 주소는 APPS Manager 라 불리는 PCF 의 웹 관리 도구라고 보면 된다. 



새로 배포된 여러분의 CF IP 주소를 사용해 접근하면, HTTPS 경고가 나타난다. 이는 임시 도메인에 대한 임시 인증서를 사용한 것이기 때문에 그러하며, 향후 프로덕션의 사용을 위해서는 회사의 멀티 도메인 인증서를 사용하면 사라지는 문제 되겠다. 로그인을 하면, Pivotal Web Services 에서 보던것과 동일한 환경을 확인할 수 있다. 


앗차. 로그인 정보는, 반드시 JUMPBOX 에 SSH 로 로그인을 해서 확인해야 한다. 방법은, 

ssh pivotal@[YOUR_JUMPBOX_DOMAIN]
cat manifests/elastic-runtime.yml | grep admin
admin_user: admin
admin_password: "0a0d2a13b6521ee2bf8b"

따라서 로그인 할때 계정은 admin, 패스워드는 위의 grep 결과로 나온 패스워드를 사용한다. 


로그인을 하고 Marketplace 항목을 살펴 보면, 바로 애플리케이션을 배포해서 연결할 수 있는 서비스의 목록이 나타난다. 




이후에는 PCF / PWS 사용 방법과 완전히 동일한데, 다만 한가지 주의 할 것은 기본 계정은 관리자인 admin 밖에 만들어져 있지 않다. 따라서 Cloud Foundry CLI 로 로그인 한 후, create org / create space / create user 등과 같은 기본 사용자 계정 생성 및 조직 생성 작업은 처리해 주어야 할 것이다. 이는 어드민 작업이며, 처음 설치 후 한번만 해 주면 되므로 너무 부담갖지 않도록 한다. Cloud Foundry 의 어드민 작업에 대해서는 아래의 링크를 참조 한다. 


https://docs.pivotal.io/pivotalcf/adminguide/index.html



h. 이후 할 일. 


- cf client 를 설치하고 애플리케이션을 배포 해 본다. 샘플 애플리케이션이 없다면 아래의 링크를 참조해 본다. 

https://github.com/cloudfoundry-samples  이들 중, MSA에 관심이 많다면 아래의 링크를 수행해 보자. https://github.com/spring-cloud-samples/fortune-teller


- 서비스 바인딩 및 구성. : 간단한 MySQL 애플리케이션을 작성하고, 플랫폼 환경 변수로 부터 endpoint 를 참조하여 코드를 작성 및 배포 하는 방법을 살펴 보자. 정보는 요기 참조  https://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html


- Spring Cloud Services 도 사용해 봅시다. 

http://docs.pivotal.io/spring-cloud-services/ 



i. Docker 이미지 배포. 


Pivotal Cloud Foundry 1.6 버전 이후 부터는 Diego 라는 새로운 런타임을 사용하여 닷넷과 다커를 지원한다. 이들 중 docker 이미지의 배포는 무지하게 쉽게 처리할 수 있다. 어떻게? cf 도구에 -o 커맨드 로 이미지를 지정해 주면. 


아래는 Docker Hub에 있는 Jenkins 를 Azure 에서 동작하는 Pivotal Cloud Foundry 에 올리는 모습이다. 

cf enable-feature-flag diego_docker # Admin 계정에서 수행해 주어야 한다. cf push jenkins-test -o jenkins ...

별 문제가 없다면 Docker 이미지가 Pivotal Cloud Foundry 로 그대로 배포되어 동작 할 것이다. cf apps 와 같은 커맨드로 엔드 포인트를 알아내고 접근하면, jenkins 동작을 확인 할 수 있다. 




Docker 버전의 jenkins 를 사용해 보신 분들은 알겠지만, 처음 접근 후에 Admin key 를 넣어 주어야 한다. 이를 위해서는 컨테이너에 ssh 로 접근할 필요가 있는데, Cloud Foundry 에서는 이를 매우 쉽게 처리할 수 있다. 바로, cf ssh 커맨드를 사용해서. 


$ cf ssh [APP_NAME]


컨테이너 내부에 접근해서 /var/jenkins_home 디렉토리에 가면 원하는 Key 를 찾을 수 있을 것이다. 사실 이와 같은 도구는 매우 유용한데, 왜냐 하면 개발 중 (프로덕션 아님에 주의) 개발 환경에 배포된 애플리케이션이 동작하는 컨테이너에 ssh 터널을 구성하고 각종 원격 디버깅 툴을 연결할 수도 있기 때문이다. 이에 대해서는 아래의 링크를 참조해 본다. 


https://blog.pivotal.io/kr/pivotal-cloud-foundry/products/%EC%83%88%EB%A1%9C%EC%9A%B4-cloud-foundry-java-%EB%B9%8C%EB%93%9C%ED%8C%A9-%EA%B0%9C%EB%B0%9C-%EC%A7%84%EB%8B%A8%EB%8F%84%EA%B5%AC



적절한 정보를 넣고 나면 다음과 같이 jenkins 가 동작하는 모습을 확인 할 수 있다. 




당연한 말이지만, 이대로 Jenkins 를 사용하라고 소개하는 것은 아니다. 중요한 것은 바로, Docker image 가 있다면 바로 PCF에 배포해서 사용할 수 있다는 것이다. 즉, 코드를 그대로 전달해도 컨테이너화 해서 동작하며, Docker 이미지가 있다고 해도 PCF 에서 사용이 가능한 것이다. 물론 편의를 위해서 전자를 선택하라고 하고 싶지만, 워낙 docker 사랑꾼들이 많으니까... 




5. 결론. 


Azure 에서의 PCF 는 매우 쉽게 배포할 수 있고, 잘 동작한다. 현재로서는 PoC 를 위한 정도이며, 프로덕션의 사용을 위해서는 지원이 필요하다. 그리고 PCF 는 현재 AWS 에서 매우 잘 동작하며, VMware 의 vCenter, vCloud Air, 그리고 최근 버전의 마이크로바이저인 Photon 역시 지원하고 있다. 향후 로드맵에는 이미 GCE 가 포함되어 있다. OpenStack 역시 지원한다. 이 의미는 무엇인가. 


"애플리케이션을 클라우드에서 동작하고 싶다면, 개발 부터 배포까지 Pivotal Cloud Foundry 를 통해 내일 당장 동작하는 컨테이너 오케스트레이션 / 계정, 조직별 권한 관리 / 레거시 저장소 연동 - 이를테면 유닉스 기반 오라클 /  각종 클라우드 서비스 연동 / docker 오케스트레이션 / 컨테이너 ssh 접근 / 로그 애그리게이션 / 애플리케이션 별 로그 스트림 / 빅 데이터 서비스 연동 / APM 구성 이 가능하다는 것이다." 



짧게 쓰고 싶었는데 뭐가 많이 써지고야 말았.. 



어쨌든 모두 즐거운 Azure, 그리고 멀티 클라우드, 아울러 Pivotal Cloud Foundry! 

물론 시간이 더 되시면 Concourse 를 보셔도 됩니다요.  https://concourse.ci 




(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, 정윤진) 



저작자 표시 비영리
신고

Amazon Web Services is hiring in Seoul, Korea

News


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





AWS는 서울에서 채용을 진행중 입니다. 

현재 채용중인 포지션과 각 포지션에 대한 자세한 설명은 아래의 링크에서 참조 해 보실 수 있습니다. 


http://www.amazon.com/gp/jobs/ref=j_sq_btn?jobSearchKeywords=&category=*&location=KR%2C+Seoul&x=24&y=7 


저는 현재 솔루션 아키텍트로 근무하고 있으며, 궁금하신 사항에 대해서는 개인 메일로 문의 주시면 답변 드릴 수 있도록 하겠습니다. 


Amazon 에서 가장 중요하게 생각하는 인재상에 대해서는 아래의 Leadership principal 을 참조 해 보세요. 

http://www.amazon.com/Values-Careers-Homepage/b?node=239365011



물론, 한국 외 다른 지역에도 채용이 진행중이므로 관심 있으신 분들께서는 많이 지원 해 주세요. 



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



저작자 표시 비영리
신고