CloudFoundry(그냥 줄여서 클파라고 써야지)는 VMWare가 주도해서 만들고 있는 오픈소스 PaaS다. 요즘 잘 나가는 클라우드 서비스의 하나인데, 그 중에서도 플랫폼을 제공하는 클라우드라고 해서 Platform as a Service라고 하고 PaaS(미국애들은 주로 패스라고 읽고, 나는 그냥 파스라고 한다)라고 줄여서 부른다. 클라우드도 그렇지만 플랫폼이라는 말도 워낙 느슨하게 정의되어서 여기저기다 마구 쓸 수 있는 말이라 플랫폼을 클라우드 스타일의 서비스로 제공한다는 PaaS도 마구 가져다 쓰는 경향이 있다. 그래서 그 중에서 애플리케이션을 배포하고 운영하는 런타임 환경을 제공하는 플랫폼을 다시 구분해서 애플리케이션 플랫폼(AP)라고 하고, 그런 플랫폼을 aPaaS라고 구분해서 말하는 사람도 있다. 클라우드와 PaaS 얘기하자면 끝이 없을 것 같으니 대충 접고.

아무튼, 클파는 오픈소스 프로젝트다. 그래서 원하면 클파 소스를 가져다가 맘대로 사용할 수 있다. 아파치2 라이선스니 수정해서 상용으로 다시 팔아먹어도 되고, 고친 소스를 공개하지 않아도 된다. 나름 참여도 활발하다. 처음부터 특정 언어와 서비스에 종속적이지 않게 설계되었기 때문에, 마음만 먹으면 자신이 사용하는 언어와 런타임환경, 각종 서비스 등을 추가할 수도 있다. 내가 처음봤을 땐 자바(톰캣), 루비(Rails, Sinatra), Node 정도의 런타임에 MySQL, MongoDB, Redis, RabbitMQ 정도의 서비스를 지원하는 구조였는데, 소스가 공개되고 오픈소스로 알려지니 다양한 커뮤니티와 기업에서 언어와 서비스 등을 계속 추가해서 지금은 PHP, Python, Scala(Lift) 등도 들어가고 PostgreSQL, MongoDB, Neo4J와 같은 서비스도 지원하기 시작했다. 각 언어 런타임과 서비스의 확장 모듈을 만들어서 클파 개발팀에 제공하면 일정한 과정을 밟아서 공식 소스에 반영하고, VMWare가 직접 운영하는 cloudfoundry.com이라는 클파 기반의 퍼블릭 PaaS에 올려주기도 한다. 최근에는 Iron Foundry라는 이름으로 닷넷을 지원하도록 확장한 클파도 나왔다.

오픈소스를 가져다 아예 독자적인 상용 서비스를 제공하는 곳(http://appfog.com/)도 있다. 여기서 클파에 php 런타임을 추가했고, 이를 다시 클파 프로젝트에 기증한 것으로 알고 있다. 또, SDS에서는 CAPE(Cloud Application Platform for Enterprises)라는 이름으로 클파 기반의 자체 PaaS 솔루션을 만들고 있다고 한다. 작년에 열린 애니프레임 오픈 세미나에서 발표된 자료(http://www.anyframejava.org/node/1322) 를 보면 PaaS와 클파에 대한 많은 정보를 얻을 수 있다. 최근에 CAPE을 오픈소스로 공개하기로 한 것을 철회한다는 공지가 떴는데, 그렇다는 건 원래 오픈소스로 공개할 계획이 있었나보다. 비공개로 전환한 건 이유가 있겠지만 쫌 아쉽네.

클파 자체에 관한 자료와 정보는 인터넷에 많이 있으니 찾아보면 된다.

클파는 4가지 정도 형태로 사용될 수 있다.

하나는 VMWare가 운영하는 cloundfoundry.com에서 제공하는 퍼블릭 PaaS 서비스다. 기본적으로 무료로 사용해볼 수 있다. 어느 단계가 되면 유료 서비스로도 제공될 것 같다. 과금방법에 대해서 논의가 있었던 것 같은데 어떻게 진행됐나 모르겠네.

다른 하나는 Micro Cloud Foundry라는 이름으로 제공되는 개발자용 클라우드 VM을 사용하는 것이다. 이건 cloudfoundry.com과 거의 유사한 환경을 가진 서버를 VMWare player나 vsphere 등을 통해서 개발 환경에서 손쉽게 클파를 경험해볼 수 있게 만든 것이다. 만약 퍼블릭 클파를 사용할 것이라면, 일단 로컬에 이 마이크로 클파(줄여서 마클파라고 부르는)를 설치하고 일단 여기에 애플리케이션을 배포하고 서비스를 구성해서 충분한 테스트를 한 뒤에 퍼블릭 클파에 배포하면 될 것이다.

PaaS을 만약 기업내부 시스템의 운영에 도입하고 싶다면 어떨까? 가상화 환경이나 기업내 IaaS처럼 애플리케이션의 런타임 환경도 간단히 구성해서 운영하는 데 사용하고 싶다면, 프라이빗한 PaaS를 도입해야 한다. 보통 PaaS는 DB나 메시징 시스템과 같은 서비스도 PaaS안에 두고 사용하도록 하는데, 규모가 큰 엔터프라이즈 서비스를 이미 운영한다면 PaaS에서 기업내 서비스 리소스로 연결하는 브릿징 기능도 필요하다. 이런 기능을 갖춘 PaaS를 프라이빗 PaaS라고 한다. 클파의 경우는 VMWare 주도로 오래전부터 프라이빗 PaaS가 개발되왔다. 작년 vForum에서 발표한 것에 따르면 올해 봄쯤 공식적으로 공개된다고 하는데. 아무튼 모든 클파 개발자들이 이 프로젝트에 매달리는지 요즘 몇달간 오픈소스 클파의 업데이트가 전혀 없다.

지금까지 말한 세가지는 모두 VMWare가 클파 프로젝트를 기반으로 다양한 형태의 서비스와 솔루션을 만든 것이다. 만약 프라이빗 PaaS를 구성한다거나, 독자적인 사용 퍼블릭 PaaS 환경을 구축하고 싶다면 이 때는 클파 프로젝트를 활용해서 독자적인 PaaS를 개발하거나 구성해야 한다. 이미 클파는 상당히 완성도가 높은 제품이기 때문에 이를 활용해서 실전에 사용하는 것도 별 무리는 없을 듯 하다.

얘기가 샜네.. – -;

그동안 클파.com이나 마클파의 사용에만 관심을 가졌는데, 지난 달부터는 클파를 이용해서 나만의 PaaS 환경을 꾸려서 개발할 때도 쓰고 고객에 필요에 맞게 프라이빗 PaaS환경을 구축해주는 데도 사용하려고 마음을 먹고 클파를 들여다 보기 시작했다.

클파 프로젝트는 github(github.com/cloudfoundry)에 모두 올라와 있다.

프로젝트가 여러개인데, 그 중에서 vmc는 클라이언트에서 클파를 관리하고, 앱을 배포하고, 모니터링하는데 사용하는 클라이언트 툴이다. vcap은 VMWare Cloud Application Platform의 약자로, 클파 서버의 핵심이다. vcap-services에는 각 서비스의 gateway와 node가 들어있는데 vcap의 submodule이다. vcap-java는 vcap의 자바버전이 아니고, 스프링 프레임워크 지원기능이다. 클파는 런타임과 서비스외에 프레임워크 모듈이 있는데, 사용 프레임워크에 따라서 부가적인 기능을 제공하게 해줄 수 있다. 자세한 건 스프링소스 블로그에 4개의 시리즈로 연재되어있으니 그거 참고. vcap-java-client는 아마 STS의 클파 모듈에서 사용하는 자바 버전의 클라이언트 모듈인 것 같은데 한번도 안 들여다봐서 확실치는 않다.

아무튼, 이 프로젝트들을 잘 활용하면 나만의 클파, PaaS를 만들 수가 있다.

가장 먼저 해볼 일은 이 소스를 가지고 서버에 클파를 설치하는 것이다. 그리고 나서 서비스도 바꿔보고, 클파 소스도 건드려가며 자기가 원하는 최적의 PaaS환경을 만들면 된다.

그런데 클파가 간단히 설치가 될까? 그렇지 않다. 클파를 설치한다는 말부터 다시 생각해봐야 할 것 같다.

클파랑 가장 비슷한 것을 꼽자면 APM 서비스를 제공하는 웹호스팅인 것 같다. APM이 설치되어있고, ftp로 앱을 올릴 수 있고, 각종 웹기반의 어드민 툴을 이용해서 DB설정도 해주고 그런 것. 물론 클파는 APM보다 100배쯤 더 강력하고 편리하지만.

그럼 APM을 설치하고 싶다는 건 무슨 의밀까? OS까지는 설치됐다 치면, 두가지 방법이 있을 것이다. 하나는 사람들이 만들어 놓은 APM 한방설치 패키지를 이용하는 것이다. 나는 써본적 없지만 그런 패키지를 이용하는 사람들은 주변에 많이 봤다. 인스톨러 하나 돌리면 Apache, PHP, MySQL에 설정 프로그램까지 다 한번에 깔리는 것이다. 가장 편하다. 하지만 내가 아파치의 모듈을 좀 다르게 구성하고 싶거나, PHP 버전을 달리한다거나, MySQL도 다른 걸로 바꾸고 싶다면? 그러면 APM 한방설치 툴보다는, 각각의 서비스를 독립적으로 설치하고 설정을 통해서 이를 손쉽게 사용할 수 있도록 만드는게 낫다. 거기에 APM에 올라가는 앱을 관리하는 편리한 툴이 있으면 그걸 마지막으로 얹으면 원시적인 PaaS가 하나 완성되는 것이다.

클파도 마찬가지다. 만약 한방 설치가 가능한 패키지가 있다면, 또는 아예 설치가 완료된 VM 이미지가 있으면 그걸 올리면 가장 편할 거다. 하지만 그런 패키지는 없다. APM과 비교하면 훨씬 많은 서비스가 필요하고, 그렇기 때문에 OS 종류와 버전도 많이 탄다. 그래서 한방 설치는 힘들다. Ubuntu 11.10에는 apt-get으로 한번에 설치할 수 있는 cloudfoundry-server 패키지가 있긴 하지만, 클파 자체가 옛날 버전이라 최신 VMC랑 연결해서 사용해보면 잘 안 맞는다.

VCAP 프로젝트 페이지(https://github.com/cloudfoundry/vcap)를 열어보면 하단 문서에 install 스크립트를 사용하는 방법이 나와있다. Ubuntu 10.04 64bit 서버 버전이라면 이 인스톨 스크립트로 설치가 가능한 것처럼 되어있지만, 설치할 패키지를 모두 따로 모아두었다 그걸 가져와서 설치하는게 아니라 각각 서비스와 관련 툴을 직접 해당 홈페이지에서 가져와 빌드하는 것도 많이 있기 때문에 시간이 지나면 이런 스크립트로는 한방 설치가 어려워진다. 최근엔 업데이트도 잘 안해줘서 더욱 그렇고. 사실 이 인스톨 스크립트는 그냥 설치에 대한 가이드 정도로 참고해야지, 이걸로 설치해보고 안된다고 클파 꼬졀다고 하는 건, 철지난 APM 한방설치 인스톨러 가져다가 해보고는 설치 안된다고 APM 꼬졌네 하는 거랑 다를바 없다.

결국 제대로 클파를 다뤄보려면 필요한 컴포넌트와 서비스 등을 직접 구성하고, 최종적으로 이를 모두 연결해서 PaaS 서비스를 제공해주는 클파 핵심 컴포넌트를 셋업하고 사용할 줄 알아야 한다.

많은 사람들은 클파가 VMWare의 vSphere에만 깔리는 벤더 종속적인 제품이라고 오해하기도 하는데, 마클파랑 프라이빗 클파라면 모를까 오픈소스 클파는 아니다. 또, VCAP의 설치 스크립트나 안내만 보고 Ubuntu에만 설지된다고 하는 사람도 있는데 역시 잘못된 얘기다. 클파는 인프라 종류와 OS, 버전등에 종속적이지 않다. 실제 사용할 서비스만 제대로 구성해주고 클파가 동작하도록 루비환경만 잘 잡아주면 된다. 클파는 루비로 만들어졌거든.

아무튼, 그래서 지난 한달간 틈틈이 클파를 설치해봤는데, 기본 스크립트를 이용해서 Ubuntu 10.04에도 설치해봤고, Ubuntu 자체 패키지로 11.10에도 설치해봤고, 패키지 없이 직접 필요한 컴포넌트를 구성해가며 Ubuntu 11.10과 CentOS 6.0에도 설치했다. 너무 오래되지 않은 Linux 계열 OS라면 별 문제 없이 설치할 수 있다. OS X에도 당연히 잘 될거고. 조금 손을 보면 윈도 서버에도 가능할 것이라고 본다.

일단 클파를 서버 한대에 설치해서 사용해보고, 그리고 멀티 노드로 확장해보는 것도 재밌을 것이다. 클파는 내부에 여러 서비스 컴포넌트들이 있는데, 실제 앱을 설치하고 관리하는 DEA 같은 경우는 서버를 계속 확장해서 늘릴 수 있다. 당연히 MySQL이나 MongoDB같은 서비스도 별도의 서버에 셋업해도 되고. 클파 아키텍처가 매우 유연하기 때문에 원하는맘큼 손쉽게 확장할 수 있다. 클파 아키텍처에 관해선http://www.springsource.org/node/3478 에서 잘 설명하고 있으니 이걸 보면 감이 잡힐 거다.

기본적으로 클파 서버 구성에 대한 가이드는 VCAP의 setup폴더에 있는 install과 vcap_setup 두개의 설치 스크립트를 참고하면 되는데, 이 두가지 다 좀 엉망이다. 현재 오픈소스로 공개된 vcap에서는 사용하지도 않는 서비스도 마구 깔고. 이리 저리 중복해서 까는 것도 있고. 아무튼 그대로 다 따라하면 쓸데없는 게 많이 깔린다. 클파를 기본적으로 구동하는데 필요로 하는 핵심만 골라서 설치하면 된다.

내가 구성해본 가장 기본 환경은 java, ruby(rails, sintra), node(0.4) 런타임에 mysql 정도인데, 일단 이정도로 시작하고 mongdo, rabbit, redis, neo4j 정도 붙여나가면서 만져보면 될 듯. staging plugin을 참고해서 django, grails, lift, php 등을 사용하도록 구성해봐도 좋을테고. 어쨌든 자기가 사용할 필요가 있는 서비스와 컴포넌트만 골라서 설치할 수 있으면 된다.

현재 vcap install 스크립트는 php, python도 설치하는데 아직 vcap에 바로 연결되는 것도 아니고, 당장 필요한 게 아니면 설치할 필요없다. 루비도 rvm으로 1.8.7과 1.9.2를 설치하고, 또 apt-get으로도 설치하는데. 그냥 rvm으로 1.9.2만 설치해도 충분하다. 나중에 staging 서비스 올라갈 때 manifests 보고 1.8을 찾는데 필요하지 않으면 그냥 manifests에서 1.8 항목을 지워도 그만.

Linux 서버를 어느 정도 다뤄본 사람이라면 install 스크립트 따라가면서 차근차근 설치해보면 어렵지 않을 것이다. 간혹 예전 버전을 설치한다거나, 앞에서 설치한 걸 또 깐다거나 하는 부분이 있는데 이런 건 상식적으로 생각해보고 생략하면 된다.

bin/vcap 실행 스크립트에서 Run 모듈의 self.services 메소드를 찾아서 서비스 항목을 빼주면 필요없는 gateway, node가 뜨지 않을 것이다. 또 스크립트에 버전이 명시된 것들도 있는데(erlang, redis, ruby 등등) 그냥 최신 버전 써도 아직은 별 문제되는 것을 못 봤다. 기본적으로 설치 스크립트는 Ubuntu 환경에서 돌아가는 것으로 작성되서, CentOS 등에서 설치하려면 필요한 라이브러리를 잘 찾아서 넣어줘야 한다. 빌드하다 에러나면 메시지 잘 보고 관련 패키지를(주로 –devel로 끝나는 라이브러리) 설치해주는 것으로 충분하다.

자기만의 클라우드 PaaS를 만들어서 사용해보고 싶은 사람이 있으면 한번쯤 서버환경을 꾸며 놓고(메모리만 넉넉하면 VMWare에 서버 설치하고 해봐도 될테고) 클파 깔아서 사용해보면 재밌을 것이다.

앞으로는 다양한 종류의 서비스와 런타임을 구성해보고 클파의 각 컴포넌트들이 어떻게 동작하는지 좀 더 연구해볼 생각이다.

혹시 비슷한 관심이 있는 분들이 있다면 작은 모임(클파사용자모임?)을 만들어서 서로 정보도 주고 받으며 교류해봐도 좋겠다.

Related posts:

1. 스프링소스가 Chris Richardson의 CloudFoundry 를 인수하다

출처 - http://toby.epril.com/?p=1183

Cloud Foundry의 모든 것들

Cloud Foundry가 실현된다는 것은 가상화를 통해 추상화된 하드웨어에서 개발, 배포 및 운영 자동화를 실현한 새로운 인프라라고 생각해도 될 것으로 보인다.
그래서 본 포스트는 Cloud Foundry에 대해 모든 것들을 정리해 보고자 한다.

Cloud Foundry 소개

Cloud Foundry는 VM웨어의 Open PaaS 전략에 따라 2011년 4월 발표된 오픈 소스 PaaS 소프트웨어(Ruby로 구현)에서 VM웨어가 인수한 SpringSource의 Java 플랫폼 "SpringSource Cloud Foundry"를 기반으로 시작했고 그이후 언어라든가 서비스, 프레임워크 등이 추가되고 발전되어 가고 있다.
거기에 WaveMaker(Java 통합 개발 환경을 제공하는 소프트웨어, 웹 브라우저에서 사용 가능) 인수하고, Mozy(온라인 백업 서비스) EMC에서 결합해 온라인에서 응용프로그램을 배포하고 백업까지 이어지는 부가가치 시장을 노리고 있다.

1) Cloud Foundry
Cloud Foundry는 오픈 소스 커뮤니티(CloudFoundry.org)와 β버전의 공용 PaaS 서비스(CloudFoundry.com)가 있다. Cloud Foundry는 오픈 소스 PaaS 프레임워크로 특정 IaaS에 의존하지 않고 여러 프로그래밍 언어 및 프레임 워크에 대응하고 있다. 또한. 퍼블릭 클라우드 및 프라이빗 클라우드 모두에게 배포할 수 있고 주로 응용 프로그램 개발자들을 대상으로 하고 있다. 현재는 β버전을 위해 무료로 제공되고 있지만, 정식 버전은 유료 제공을 예정하고 있다.
런타임 환경으로 Node, Ruby, Java를 지원하고 frameworks는 Spring, rails3, node, grails, play 등, 그리고 service들은 MongoDB, MySQL, PostgreSQL, RabbitMQ, Redis 등을 지원하고 있다.

2) Micro Cloud Foundry
Micro Cloud Foundry는 Cloud Foundry 환경을 개발자 데스크톱의 가상 머신상에서 재현해 개발자에게 개발 환경을 쉽게 구축하고 배포가 가능하게 해 준다.

3) Cloud Foundry for Enterprise
Cloud Foundry for Enterprise는 기업의 프라이빗 클라우드의 도입과 클라우드 공급자가 공용 클라우드 PaaS 서비스를 제공하는 것을 목적으로 상용 버전으로 제공을 예정하고 있다.

Cloud Foundry 맛보기

Cloud Foundry는 STS(Eclipse 플러그인)와 vmc라는 커맨드기반의 도구를 제공하고 있는데 여기서는 vmc기반으로 테스트 한다. 그리고 vmc는 Ruby로 되어 있으며, gem 사용할 수 있는 환경이라면 gem install vmc로 쉽게 설치할 수 있다.

1) 가입하기
여기에서 가입을 하게되면 이메일 주소로 계정 할당되었다는 정보와 Activate 메일이 온다. 그럼 활성화시키면 계정 생성은 마무리된다.

2) 자신의 서버에 Ruby, RubyGems(Centos) 설치
- ruby 지원 버전 : 1.8.7, 1.9.2

> yum grouplist |grep -i Development
> yum groupinstall "Development Tools"
> wget ftp://ftp.ruby-lang.org//pub/ruby/1.9/ruby-1.9.2-p320.tar.gz
> tar xvfz ruby-1.9.2-p320.tar.gz
> cd ruby-1.9.2-p320
> ./configure
> make; make install
> gem -v
1.3.7.1
> gem update --system

3) vmc 설치 및 인증 확인, 패스워드 변경(http://docs.cloudfoundry.com/tools/vmc/installing-vmc.html)
- 가입 이메일로 아이디와 패스워드를 보내주면 그걸로 vmc 설치한 다음 로그인, 패스워드 변경 작업을 커맨드로 진행하면 된다.

> gem install vmc
> vmc target api.cloudfoundry.com
Successfully targeted to [http://api.cloudfoundry.com]
> vmc login
Email: hahojin@gmail.com
Password: ********
Successfully logged into [http://api.cloudfoundry.com]
[root@rent-1137 ~]# vmc passwd
Changing password for 'hahojin@gmail.com'
New Password: *******
Verify Password: *******

Successfully changed password
# 서비스 되는  Java, Node.js, Ruby 정도
> vmc runtimes
+--------+-------------+-----------+
| Name   | Description | Version   |
+--------+-------------+-----------+
| node   | Node.js     | 0.4.12    |
| node06 | Node.js     | 0.6.8     |
| ruby18 | Ruby 1.8    | 1.8.7     |
| ruby19 | Ruby 1.9    | 1.9.2p180 |
| java   | Java 6      | 1.6       |
+--------+-------------+-----------+
> vmc frameworks
+------------+
| Name       |
+------------+
| rails3     |
| standalone |
| sinatra    |
| java_web   |
| grails     |
| rack       |
| node       |
| play       |
| lift       |
| spring     |
+------------+
> vmc services
+------------+---------+---------------------------------------+
| Service    | Version | Description                           |
+------------+---------+---------------------------------------+
| mongodb    | 1.8     | MongoDB NoSQL store                   |
| mysql      | 5.1     | MySQL database service                |
| postgresql | 9.0     | PostgreSQL database service (vFabric) |
| rabbitmq   | 2.4     | RabbitMQ message queue                |
| redis      | 2.2     | Redis key-value store service         |
+------------+---------+---------------------------------------+

4) Rabbitmq기반의 Spring 생플 포팅하기
- 관련 참조 소스 : https://github.com/rabbitmq/rabbitmq-cloudfoundry-samples
- 빌드 및 배포

# Spring  소스 컴파일
> git clone git://github.com/rabbitmq/rabbitmq-cloudfoundry-samples.git
> cd rabbitmq-cloudfoundry-samples/spring/
> mvn package
# 앱 CloudFoundry 등록하기
> cd target
> vmc push
Would you like to deploy from the current directory? [Yn]: y
Application Name: mimul-spring
Detected a Java SpringSource Spring Application, is this correct? [Yn]: y
Application Deployed URL [mimul-spring.cloudfoundry.com]: 
Memory reservation (128M, 256M, 512M, 1G, 2G) [512M]: 
How many instances? [1]: 1
Create services to bind to 'mimul-spring'? [yN]: y
1: mongodb
2: mysql
3: postgresql
4: rabbitmq
5: redis
What kind of service?: 4
Specify the name of the service [rabbitmq-f3dd6]: 
Create another? [yN]: n
Would you like to save this configuration? [yN]: y
Manifest written to manifest.yml.
Creating Application: OK
Creating Service [rabbitmq-f3dd6]: OK
Binding Service [rabbitmq-f3dd6]: OK
Uploading Application:
  Checking for available resources: OK
  Processing resources: OK
  Packing application: OK
  Uploading (3K): OK   
Push Status: OK
Staging Application 'mimul-spring': OK                                          
Starting Application 'mimul-spring': OK        
# 등록된 앱 확인
> vmc apps
+--------------+----+---------+-------------------------------+----------------+
| Application  | #  | Health  | URLS                          | Services       |
+--------------+----+---------+-------------------------------+----------------+
| mimul-spring | 1  | RUNNING | mimul-spring.cloudfoundry.com | rabbitmq-f3dd6 |
+--------------+----+---------+-------------------------------+----------------+

5) URL로 등록된 앱 확인
- 메세지 등록


- 메세지 확인


6) 관리 커맨드들

#동작 확인 및 모니터링
> vmc logs mimul-spring
#인스턴스 증감 커맨드
> vmc instances mimul-spring +1
> vmc instances mimul-spring
+-------+---------+--------------------+
| Index | State   | Start Time         |
+-------+---------+--------------------+
| 0     | RUNNING | 05/22/2012 11:20AM |
| 1     | RUNNING | 05/22/2012 05:08PM |
+-------+---------+--------------------+
# instance 별 로그 모니터링
> vmc logs mimul-spring --instance 0
INFO: Starting Servlet Engine: Apache Tomcat/6.0.35
.....
INFO: Server startup in 1275 ms
> vmc logs mimul-spring --instance 1
INFO: Starting Servlet Engine: Apache Tomcat/6.0.35
.....
INFO: Server startup in 1275 ms

Cloud Foundry 이모 저모

1) Cloud Foundry 아키텍처
시스템 리소스를 낭비하지 않고, 또한 애플 리케이션 추가시 시스템 다운을 방지하기 위해 비동기 I/O를 사용한다. 특히 Ruby의 비동기 I/O Event Machine을 이용하여 이벤트 기반 메시지 버스로 NATS(Cloud Foundry의 개발 멤버에서 VMware CTO의 Derek 씨가 개발)가 활용되고 있다.


- CF kernel(Cloud Foundry Kernel)과 Orchestator 분할하여 설계함으로써 IaaS에 의존하지 않도록 되어 있다.
- CF Kernel(=Cloud Foundry 커널) 부분을 "Cloud Foundry"라고 부른다.
- Orchesrator는 CF Kernel을 IaaS에 구축, 운영 및 모니터링하는 부분으로, 여기는 Cloud Foundry는 포함되지 않는다.

*. CF Kernel을 만드는데 있어서의 방향성

• MTTR (Mean Time To Recovery)을 강화한다. 장애를 빨리 감지하고 더 빨리 복구한다.
• 자율 시스템에서 결함을 자동 복구할 수 있도록 유지 구성 정보를 최소화한다.
• PaaS상의 어플리케이션은 모두 확장할 수 있다.
• Single Point of Failure가 없어야 한다.
• 가능한 단순해야 한다.

*. 기본 디자인 패턴

• 이벤트 기반
• 비동기
• 논블럭 I/O
• 모든 구성 요소는 독립적이며 느슨하게 결합
• 메시징을 통한 상호 인터액션
• Eventually Consistent

*. 커널 구성 요소

• 모든 구성 요소를 동적으로 검색
• 자동 등록을 통해 관리 비용을 절감하고, IaaS와 PaaS 분할을 실현
• 모든 구성 요소를 하나의 OS에서 움직일수도 있고 여러 OS에 분할하여 할 수도 있다. (전자는 Micro Cloud Foundry, 후자는 확장 가능한 Cloud Foundry)

*. 커널 구성 요소 유형

• CloudController : 구성 관리 제어 컨트롤러
• Router : 인터넷 라우터와 별개. URL 부하 분산 기능
• DEA (Droplet Execution Agent) : 사용자 응용 프로그램을 실행 담당
• HealthManager : 감시 도구(DEA의 응용 프로그램 상태 모니터링)
• Messaging System : 구성 요소 간 메시징 처리

*. Cloud Foundry의 플로우


2) Cloud Foundry Portal(https://komportal.cloudfoundry.com)
- 어플리케이션 시작/중지 및 서비스(DB)의 bind 작업, 로그 확인이 가능하게 되어 있다.(어플리케이션 deploy와 update는 현재 지원되지 않음)

 

[참조 사이트]

• rabbitmq-cloudfoundry-samples
• Getting Started with the RabbitMQ Service from a Spring Application
• [클파: 인사이드] 어떻게 만들었나?

출처 - http://www.mimul.com/pebble/default/2012/05/22/1337665188713.html

병렬 컴퓨팅(parallel computing) 또는 병렬 연산은 동시에 많은 계산을 하는 연산의 한 방법이다. 크고 복잡한 문제를 작게 나눠 동시에 병렬적으로 해결하는 데에 주로 사용되며^[1], 병렬 컴퓨팅에는 여러 방법과 종류가 존재한다. 그 예로,비트 수준, 명령어 수준, 데이터, 작업 병렬 처리 방식 등이 있다. 병렬 컴퓨팅은 오래전부터 주로 고성능 연산에 이용되어 왔으며, 프로세서 주파수^[2]의 물리적인 한계에 다가가면서 문제 의식이 높아진 이후에 더욱 주목받게 되었다. 최근 컴퓨터 이용에서 발열과 전력 소모에 대한 관심이 높아지는 것과 더불어 멀티 코어 프로세서를 핵심으로 컴퓨터 구조에서 강력한 패러다임으로 주목받게 되었다^[3].

병렬 컴퓨터들은 대체적으로 하드웨어의 병렬화 방법에 따라 분류된다. 클러스터, MPP, 그리드는 여러 컴퓨터에서 한 가지 작업을 하도록 설계되었다. 멀티 코어나 멀티 프로세서 컴퓨터들은 여러 개의 처리 요소(CPU 등)을 한 기기에 탑재하고 작업한다. 특수화된 병렬 컴퓨터 구조들은 가끔씩 고전적인 프로세서들과 함께 특정한 작업을 가속화 시키는 목적으로도 사용된다.

병렬 컴퓨터 프로그램들은 순차적 프로그램보다 난해하다.^[4] 왜냐하면 동시처리는 여러 종류의 새로운 잠재적 소프트웨어 버그를 가지고 있기 때문이다. (경쟁 상태가 가장 흔하다) 통신과 동기화 를 요구하는 다른 하위 작업들은 병렬 프로그램 성능의 전형적인 방해요소다. 병렬화된 프로그램의 속도 향상은 암달의 법칙에 의해서 그 결과가 결정된다.

[편집]배경

전통적으로 컴퓨터 소프트웨어는 직렬 컴퓨팅 방식을 기본으로 작성되어 왔다. 문제를 해결하는 데 있어서 알고리즘은 직렬형 명령들로 이루어졌고 그 명령들은 하나의 CPU에 의해서 실행되었다. 한 명령이 한 번에 하나씩 실행된다. 하나가 끝나면 그 다음 명령이 실행된다. ^[5]

병렬 컴퓨팅은 여러 개의 처리 요소(프로세서 등)를 이용하여 한 번에 문제를 해결한다. 이것은 그 문제를 독립적인 부분들로 나눠서 각 처리 요소가 그 부분의 알고리즘들을 한 번에 다른 요소들과 처리를 할 수 있게 하는 것을 가능하게 했다. 그 처리요소들은 여러 자원들을 포함한다. 예를 들면 한 컴퓨터에 있는 멀티프로세서, 여러 네트워크 컴퓨터들, 특수 하드웨어, 아니면 그런 것들을 섞어 쓸 수도 있다.^[5]

컴퓨터의 클럭 속도는 1980년도 중반부터 2004년까지 컴퓨터 성능을 향상시키는 데 가장 영향력 있는 요소였다. 프로그램 실행시간은 명령어 수를 명령어 당 평균시간을 곱한 것과 같았는데 클럭수를 늘리면 명령을 실행하는 평균시간은 짧아진다.

그러나 칩의 전력소모량은P = C × V² × F의 공식에 따른다. P는 전력이고 C는 전기용량 V는 전압(voltage)이고 F는 주파수(프로세서 속도)를 의미한다.^[6] 주파수 수(프로세서 속도)를 높이면 전력 사용량이 늘어난다는 뜻이다. 전력 사용량이 계속 높아가자 결국 인텔은 2004년 5월에 테자스와 제이호크(Tejas and Jayhawk)를 취소시키기에 이른다. 그 사건은 주파수 척도에 의한 컴퓨터 구조 패러다임이 끝나는 것을 의미하게 된다.^[7]

무어의 법칙은 매 18에서 24개월 동안 집적도가 두 배씩 늘어난다는 것을 예측하는데,^[8] 전력소모량 사건에 계속됐던 예측은 끝이나고 말지만 무어의 법칙은 여전히 유효하다. 주파수 척도는 끝이 났지만 추가적인 트랜지스터들은 추가적인 병렬 컴퓨팅에 쓰이게 된다.

[편집]암달의 법칙과 구스탑슨의 법칙

 이 부분의 본문은 암달의 법칙입니다.

 이 부분의 본문은 구스탑슨의 법칙입니다.

암달의 법칙을 그림으로 표현했다. 병렬화로 인한 프로그램의 속도 향상은 프로그램이 얼마나 병렬화 되어있느냐에 제한되어있다. 예를 들면 90%의 프로그램이 병렬화될 수 있다면 이론적으로 병렬 컴퓨팅을 사용한 속도 향상은 몇 개의 프로세서를 쓰던지 10배의 속도까지만 향상시킬 수 있다.

병렬화로 인한 속도 향상중 제일 좋은 것은 역시 선형적 결과다. 프로세서 수를 두 배로 늘리면 두 배 역할을 해서 실행시간을 절반으로 줄이고 프로세서 수를 또 두 배로 늘리면 또 실행시간이 절반으로 줄어든다. 그런데 아주 적은수의 병렬 알고리즘만이 최적의 속도 향상을 달성했다. 대부분은 그저 비슷한 선형적 속도 향상을 적은 수의 처리요소(프로세서)로 달성했을 뿐이다. 그것들은 처리 요소들의 숫자가 많아질수록 효과가 적어진다.

병렬 컴퓨팅 기반에서 잠재적인 속도 향상 알고리즘인 암달의 법칙은 1960년대에 진 암달에 의해서 만들어졌다.^[9] 병렬화할 수 없는 작은 부분의 프로그램은 전체적인 병렬화에 영향(제한)을 가져온다는 것이었다. 수학적이나 공학적 문제들은 전통적으로 몇 가지 병렬화된 부분과 병렬화되지 않은 부분으로 구성되게 된다. 이 관계는 아래와 같은 공식으로 나타나게 된다.

여기서 S는 프로그램의 속도 향상을, P는 병렬화 가능한 분수를 의미한다. 만약 프로그램의 10%가 순차적 부분이라면 우리는 몇 개의 프로세서를 추가하든 간에 10배 이상 속도를 높일 수가 없다. 이것이 실용적으로 병렬실행 유닛들을 추가할 수 있는 한계이다. 순차적 부분의 제한으로 작업을 더 이상 나눌 수 없게 될 때 응용 프로그램들은 그 이상 빠른 결과를 만들 수 없게 된다. 인월미신의 예를 인용하자면 “임산부가 아무리 많아도 아이를 낳는 데에는 9개월이 걸린다.”

구스탑슨의 법칙은 컴퓨터 공학의 또 다른 법칙인데, 암달의 법칙과는 밀접한 관계가 있다. 이 공식은 다음과 같다:

작업이A하고 B, 두 개의 독립적인 부분으로 되어있다고 가정하자, B는 전체 계산중에 대충 25%정도 시간을 차지한다. 프로그래머가 노력해서 이 부분을 5배 빠르게 만들었다. 그러나 이것은 전체 계산을 봤을 때에는 그냥 약간의 시간 감소에 불과하다. 반대로 A 부분을 2배로 만들면 B 부분을 빠르게 만드는 것보다 훨씬 더 효과가 있다 B를 5배 빠르게 만들었다고 해도 말이다.

P는 프로세서 수고 S는 속도 향상. α는 비 병렬 부분이다.^[10] 암달의 법칙은 문제가 고정된 크기라는 것과 순차적 부분을 독립적인 프로세서들이라고 가정한다. 구스탑슨의 법칙은 그런 가정을 하지 않는다.

[편집]종속성

병렬 알고리즘은 자료 종속성을 이해하는 것이 기본이 된다. 어떤 프로그램도 가장 길게 연결되어 있는 종속적(비독립) 계산보다 빠르게 실행될 수 없다. (크리티컬 패스라고도 함) 이는 계산들이 이전 계산에 종속되어 있으면 계산은 그 차례를 지켜야 한다는 것을 뜻한다. 그러나 대부분 알고리즘들은 그런 긴 종속의 연결을 포함하지 않는다. 일반적인 병렬에서는 비종속적인(독립적인) 계산을 실행할 가능성이 많다.

P_i 와 P_j 두 프로그램 조각들이 있다고 하자. 번스타인 상태^[11]는 두 개의 독립적이고 병렬적으로 실행될 수 있을 때를 설명한다. I_i 는 P_i의 입력 변수고 Oi는 출력 변수라고 하고 P_j 도 같이 그렇다고 하자. 만약 다음을 만족시키면 P_i와 P_j는 독립적이다.

첫번째 상태의 위반은 종속성 흐름(flow dependency) 을 야기한다. 첫번째 문(文)을 일치시키는 것은 두 번째 문이 작성한 결과를 만든다. 두 번째 상태는 대 종속성(anti-dependency) 상태를 의미한다. 첫번째 문이 두 번째 문에 의해 필요가 된 변수를 덮어쓸 때 세 번째와 마지막 상태는 출력의 독립을 의미하게 된다. 두 개의 문들이 같은 장소에서 작성할 때 마지막 결과는 논리적으로 반드시 마지막으로 실행됐던 명령이 되어야 한다. ^[12]

아래 함수는 몇가지 종속성을 보여준다.

1: function Dep(a, b)
2:    c := a·b
3:    d := 2·c
4: end function

Dep 함수 세 번째 줄은 두 번째 줄이 실행되기 전에는 실행될 수 없다. 왜냐하면 세 번째 줄은 두 번째줄의 결과에 의해서 실행되어야 하기 때문이다. 이것은 첫번째 상태를 위반한거다. 즉, 종속성 흐름을 야기시킨다.

1: function NoDep(a, b)
2:      c := a·b
3:      d := 2·b
4:      e := a+b
5: end function

이 예에서 명령어 간에 종속성은 없다, 따라서 이것들은 병렬로 처리할 수 있다.

번스타인의 상태는 다른 프로세스들 간에 메모리 공유를 허용하지 않는다. 그 때문에 서로 접근할 수 있게 만드는 방법이 필요할지도 모른다. 예를 들면 세마포어나 배리어나 아니면 다른 동기화 방법들 말이다.

[편집]경쟁상태, 상호배제, 동조화, 병렬감속

병렬 프로그램에서 하위 작업들은 스레드라고 불리기도 한다. 몇몇 병렬 컴퓨터 구조는 작고 경량화된 버전의 스레드인 파이버를 이용하기도 한고 큰 버전으로는 프로세스 라고도 한다. 그러나 “스레드”는 일반적으로 하위 작업을 가리키는 단어로 해석된다. 스레드들은 자기들끼리 공유되는 몇몇 변수들을 갱신할 필요가 있다. 두 프로그램들 사이의 명령어들은 아마 끼워넣을 지도 모른다. 예를 들자면 아래 프로그램을 보자.

만약 명령어 1B가 1A과 3A 사이에서 실행되었다거나 1A가 1B나 3B 사이에서 실행되었다면 프로그램은 잘못된 정보를 만들게 된다. 이것을 바로 “경쟁 상태” 라고 한다. 프로그래머는 반드시 락을 사용해서 상호 배제를 해야 한다. 락은 한 개의 스레드가 락이 풀리기 전까지 변수를 제어하고 다른 스레드가 읽거나 쓰는 것을 막는 프로그래밍 언어 구조체다. 스레드는 락을 임계 구역 (몇몇 변수를 접근할 수 있게 허용해 주는 프로그램 구역) 내에서 자유롭게 실행할 수 있게 만든다. 그리고 다 끝나면 잠금을 해제한다. 따라서 올바른 프로그램 실행을 보장시켜준다. 위의 프로그램을 락을 사용해서 다시 작성하면 다음과 같다.

다른 스레드가 락 아웃( V가 다시 풀릴 때까지 진행하지 못하게 함)될 때 한 스레드는 변수V를 성공적으로 잠궜다. 이것은 프로그램이 정상적으로 실행되는 것을 보장한다. 잠금은 프로그램이 정상적으로 실행되는 것을 반드시 보장하지만 프로그램 속도를 느리게 할 수도 있다.

여러 개의 변수들을 비원자성 을 사용해서 잠그면 교착 상태에 빠질 수도 있다. 원자성 락은 한꺼번에 여러 개의 변수를 잠근다. 만약 전부다 잠글수 없다면 아무것도 잠그지 않는다. 만약 두 개의 스레드들이 서로 같은 두 변수들을 비원자성을 사용해서 잠가야 한다면 한 개의 스레드는 하나를 잠글지도 모르고 그러면 두 번째 스레드는 두 번째 변수를 잠가야 한다. 이 경우 두 스레드 다 잠그지 않을것이다. 그리고 교착 상태로 이어진다.

많은 병렬 프로그램들이 하위작업으로 동기화를 필수로 한다. 배리어 는 그 작업에 필요한데, 배리어는 원래 소프트웨어 락에 포함 (implement) 되어 사용된다. 한 클래스의 알고리즘들인 비차단 동기화 (lock-free와 wait-free 알고리즘)는 모두 락과 배리어의 사용을 피한다. 그러나 이 접근은 일반적으로 포함시키기 어렵고 정확한 디자인의 자료구조를 요구하게 된다.

모든 병렬화가 속도 향상을 시키진 않는다. 일반적으로 스레드들을 나누면 나눌수록 그 스레드들은 서로 의사소통 하는 데 시간을 더 증가시킨다. 결국 의사소통에 의한 문제를 해결하기 위해서 간접적인 시간소모를 해야하고 그 이상의 병렬화는(부하를 나누기 위해 스레드들을 나눌 때) 실행시간을 단축시키기는 커녕 늘리게 된다. 이것을 병렬 감속이라고 한다.

[편집]잘게 나눔(fine-grained), 크게 나눔(coarse-grained), 처치 곤란 병렬(embarrassingly parallel)

응용 프로그램들은 가끔 얼마나 자주 하위 작업들이 동기화 되나 혹은 서로 통신해야 하냐에 따라서 분류가 나뉘기도 한다. 만약 병렬 응용프로그램의 하위 작업들이 초당 통신을 많이 해야 하면 잘게 나뉘었다고 하고 초당 통신을 많이 안해도 되면 크게 나뉘었다고 한다. 그리고 만약 아주 가끔 통신하거나 아예 하지 않는다면 처치 곤란 병렬 이라고 한다. 처치 곤란 병렬 응용 프로그램은 가장 쉬운 병렬화로 알려져 있다.

[편집]일관성 모델들

병렬 프로그래밍 언어와 병렬 컴퓨터들은 반드시 일관성 모델 (메모리 모델이라고도 불린다) 을 가지고 있어야 한다. 일관성 모델이란 컴퓨터 메모리 위에서 어떻게 연산들을 할 것인지와 어떻게 결과들을 만들것인지 규칙을 정의하는 것이다.

일관성 모델 중에는 레슬리 램포트의 순차 일관성 모델 (sequential consistency) 이라는 것이 있다. 순차 일관성이란 병렬 프로그램 실행시 순차적 프로그램에서 나오는 결과와 똑같이 만드는 병렬 프로그램의 특성이다. 특히 만약에 “…어떤 실행에서의 결과가 모든 프로세서들의 연산이 어떤 순차적인 차례로 실행되거나 그 연산들의 각 독립적인 프로세서가 그 프로그램에 의해 보여주는 순서가 똑같다면” 프로그램은 순차적으로 모순이 없다.

소프트웨어 트랜잭셔널 메모리 (Software transactional memory (이하 STM)) 는 흔한 방식의 일관성 모델이다. STM은 데이터베이스 이론에서 원자 트랜잭션의 컨셉과 그것을 메모리 접근에 적용한걸 가져온 것이다.

수학적으로 이런 모델들은 여러가지 방법으로 표현될 수 있다. 1962년 칼 아담 페트리의 박사 논문으로 소 개된 페트리 넷은 일찍이 일관성 모델들을 체계적으로 분류하는걸 시도했던 사례다. 자료흐름 이론(dataflow theory) 은 그것을 기반으로 만들어졌고 자료흐름 구조 (Dataflow architectures) 는 자료흐름 이론의 아이디어들을 물리적인 방법에 의해 만들어졌다. 1970년도 후반에 시작된 통신 시스템 미적분 (Calculus of Communicating System) 이나 소통 순차적 프로세스(Communicating Sequential Processes)들 같은 프로세스 미적분 (process calculi)들이 구성요소들의 상호 통합 이라는 대수적 논리에 의해서 개발될 수 있었다. 좀 더 최근에는 파이-미적분 같은 미적분 들이 동적 기하학에 대한 성능 향상을 위해 그 프로세스에 추가되었다. 램포트의 TLA+ 같은 논리들과 대각합 (traces)이나 액터 이벤트 다이어그램 (Actor event diagrams) 같은 수학적 모델들이 동시 행위 시스템의 행동을 설명하기 위해서 개발됐다.

[편집]플린의 분류학

마이클 J. 플린은 가장 쉬운 컴퓨터와 프로그램 병렬(과 순차) 분류 시스템 중에 하나를 만들었다. 이것은 플린의 분류학(영어: Flynn's taxonomy)이라고도 알려져 있다. 플린은 프로그램들과 컴퓨터들을 그것이 단일, 아니면 복수의 명령어 셋을 사용하느냐 아니냐 그리고 그 명령으로 단일 아니면 복수의 데이터 들을 연산하는지 여부에 따라서 분류를 했다.

SISD(단일명령-단일자료)는 완전히 순차적 프로그램과 같다. SIMD(단일명령-복수자료)는 반복되는 큰 자료에 대한 연산을 한다. SIMD는 일반적으로 신호처리 응용 프로그램들에서 실행된다. MISD(복수명령-단일자료)는 거의 쓰이지 않는 분류인데, 컴퓨터 구조들이 이것을 고민하고 있을 때(시스톨릭 배열같은 것들) 몇몇 응용 프로그램들이 이 분류를 구현시켜냈다. MIMD(복수명령-복수자료) 프로그램들은 제일 흔한 종류의 병렬 프로그램들이다.

데이비드 A. 패터슨과 존 L. 헤네시에 따르면 “몇 머신들은 이 카테고리를 여러 개 가질수도 있다, 당연히, 그런데 이 오래된 모델은 살아남는다. 왜냐하면 간단하고 이해하기 쉽기도 하고 처음 배울 때 좋다. 그리고 또 아마 어떤 조직을 넓게 이해하는 데 가장 많이 쓰였기 때문이다.”^[13]

[편집]병렬처리의 종류

[편집]비트수준 병렬처리

초고밀도 집적회로(VLSI)의 등장으로 1970년대부터 1986년까지 컴퓨터 칩 제조 기술은 두 배의 워드 크기를 가진 컴퓨터 구조를 만들어 내서 속도 향상을 달성했다. 프로세서의 정보량은 사이클 단위의 조작이 가능했는데^[14], 워드 크기를 늘리게 되면 워드 길이보다 큰 변수 위에서 실행되어야 했던 명령어 갯수가 줄어들게 됐다. 예를 들자면, 8비트 프로세서는 반드시 16비트 정수형 두 개를 추가시켜야 한다. 프로세서는 반드시 먼저 8 하위 비트를 각 표준 추가 명령어를 정수형으로부터 추가시켜야 하고 그 다음에 하위에서 추가로 ADC 명령과 캐리를 사용하는8 상위 비트를 추가시킨다. 8비트 프로세서는 한 개의 연산을 완료하기 위해서 2개의 명령어들을 필요로 하게 되고, 16비트 프로세서는 1개의 연산을 1개의 명령어로 끝낼수 있게 된다.

역사적으로 4비트 마이크로 프로세서들은 8비트, 16비트 그리고 32비트 마이크로 프로세서들에 의해서 교체됐다. 이 유행은 일반적으로 두 세대를 범용 컴퓨터 표준이 된32비트 프로세서의 등장과 함께 끝나는데, 최근 (2003-2004)엔 64비트 프로세서들을 가진x86-64 구조들이 등장하면서 표준이 된다.

[편집]명령어 수준 병렬 처리

컴퓨터 프로그램은 명령어들의 흐름이 프로세서에 의해서 실행되는걸 바탕으로 한다. 이 명령어들은 재 순차와 결과의 변경 없이 한꺼번에 그룹단위로 병렬실행이 가능했다. 이것을 명령어 수준 병렬화라고도 한다. 이 명령어 수준 병렬화는 80년대 중반부터 90년대 중반까지 컴퓨터 구조를 주름잡았다.^[15]

현대의 프로세서들은 다단계 명령어 파이프라인을 가졌다. 파이프라인에서 각 단계는 다른 행동을 하는 같은 단계의 명령어를 실행하는 프로세서와 일치시킨다. N 스테이지 파이프라인은 N 개 만큼의 다른 명령어들을 다른 완료된 단계에서 가질수 있다. 파이프라인된 프로세서의 정석은 RISC 프로세서다. (다섯 개의 단계 – 명령어 패치, 디코드, 실행, 메모리 접근, 다시 써넣기 (write back) 가 정석이다.) 펜티엄 4 프로세서는 31단계의 파이프라인을 가지고 있다.^[16]

파이프라인을 할 때 명령어 수준 병렬화에서 몇 프로세서들은 한 개 이상의 명령어를 한 번에 만들수 있었다. 이것을 슈퍼스칼라 프로세서라고도 한다. 만약에 자료종속성만 없다면 명령어들은 한꺼번에 합쳐질수 있다. 스코어보딩(Scoreboarding)과 토마줄로 알고리즘 (스코어보딩과 비슷하지만 레지스터 리네이밍 (Register renaming)을 사용한다) 이 두 가지가 가장 흔한 비 순차적 실행과 명령어 수준 병렬화 기술들이다.

[편집]자료 병렬 처리

자료 병렬화는 프로그램 루프에 내재된 병렬화다. 프로그램 루프는 병렬로 처리된 다른 컴퓨팅 노드들의 자료를 분산시키는데 초점을 맞춘다. “루프를 병렬시키는 것은 가끔 비슷한 (완전 같을 필요는 없이) 순차 연산이나 큰 자료구조의 요소에서 실행되는 함수들을 실행시키게 한다.”^[17] 많은 과학적, 공학적인 응용물들이 자료 병렬화를 보여준다.

루프가 가지고 있는 종속성은 이전 반복의 하나 이상의 결과에 종속된다. 루프의 종속성은 병렬화 루프에 의해 막힌다. 예를 들면 아래의 피보나치 수 의사코드를 보자.

1:    PREV1 := 0
2:    PREV2 := 1
4:    do:
5:       CUR := PREV1 + PREV2
6:       PREV1 := PREV2
7:       PREV2 := CUR
8:    while (CUR < 10)

이 루프는 병렬화할 수 없다. 왜냐하면 CUR 이 각 루프를 도는 동안 그 자신(PREV2)과 PREV1에 종속되기 때문이다. 각 반복이 그 이전 결과에 종속되므로 병렬화할 수 없다. 문제의 크기가 크면 클수록 자료의 병렬화의 유효성은 일반적으로 커진다.^[18]

[편집]작업 병렬처리

작업 병렬화는 병렬 프로그램 “전체적으로 다른 계산들은 같거나 다른 자료들에서 실행될 수 있다.”^[17] 라는 성질을 가지고 있다. 이것을 자료 병렬화와 상반시키면 계산이 같거나 다른 자료들에서 실행될 수 있다. 작업 병렬화는 일반적인 규모의 문제와 함께 측정되지 않는다.^[18]

[편집]같이 보기

• List of important publications in concurrent, parallel, and distributed computing
• List of distributed computing conferences

[편집]참조