System Compleat.

'MPI'에 해당되는 글 2건

  1. GPI, PGAS for HPC
  2. HPC in the KT Cloud, and CHEF

GPI, PGAS for HPC

Techs

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

이런 기사가 일요일 새벽에 떴다.

GPU to GPU Communication Over InfiniBand to be Demonstrated at ISC'11



내용이 무엇인고 하니, 제목에서 알 수 있듯이 HPC에서 GPU와 GPU간의 통신을 Infiniband 를 통해 구현하여 동작하는 모습을 ISC'11 이라는 행사에서 데모로 시연하겠다는 말이다.  기사를 좀 읽어 보니 Fraunhofer Institut ITWM 이라는 회사가 GPI 를 통해 구현 했단다.  음.. GPI 는 원래 내 알기로 Graphic Programming Interface 였는데, 혹시나 해서 보니 역시나 아니다. 그래서 포스팅 한건 더 한다. ㅠㅠ

ISC'11 이라는건 International Supercomputing Conference 2011 이다. 올해는 독일 함부르크에서 하고 있단다. 나도 가보고 싶다 ㅠㅠ  이벤트 홈페이지는 http://www.supercomp.de/isc11/




아무튼 세상은 정말 빠르게 발전하고 있는가보다. HPC에 관심있는 분들이라면 이미 MPI에 대해서는 한번쯤은 들어보았을 것이다. MPI는 Message Passing Interface 로서, 물리적으로 서로 다른 노드간에 동일한 데이터를 처리하기 위해 지정된 노드간의 프로세싱과 관련된 메세지 통신을 지원하는 인터페이스를 말한다. 말이 좀 어려운데, 간단하게 풀자면 만약 듀얼 코어 시스템이 4대가 있다 치자. 어떤 대규모의 계산을 수행해야 할때, 컴퓨터 한대에서 수행 하는 것이 아닌 프로세서를 6개를 사용하고 싶다고 할때, 시스템 3대를 사용하게 된다. 이때 3대의 시스템 사이에서 데이터 처리를 위해 주고 받는 메세지를 처리하는 방법을 정의한 것을 MPI 로 이해하면 쉽다. 실제 MPI 자체는 인터페이스를 규정하는 표준 정도로 생각하면 되고, 이를 실제 클러스터에서 구현하려면, 각 노드를 InfiniBand 나 10G 로 묶어서 물리적 환경을 구성해 준 다음, MPICH 또는 MPICH2 환경을 구성해 주면 된다. 이는 보통 MPI 라이브러리를 사용한 포트란이나 gcc, 와 같은 컴파일러와 함께 설치되며, 이러한 컴파일러를 사용하도록 구성된 어플리케이션을 사용하는 경우 자연스럽게 MPI 를 사용 할 수 있도록 지원한다. 이 말은, 즉 최근의 HPC Cloud 에서도 설정하여 사용이 가능하다는 의미 되겠다. 물론 이 MPI 는 기존의 CPU를 사용하는 방법이며, 이를 확장, 발전 시킨 것이 바로 GPI가 되겠다.


MPI에 관련된 자세한 사항은 다음의 링크에서 정보를 얻도록 한다.
http://www.mcs.anl.gov/research/projects/mpi/
http://www.mcs.anl.gov/research/projects/mpich2/index.php


Fraunhofer


http://www.gpi-site.com/
여기에 사용된 모든 이미지는 위의 사이트로 부터 가져온 것임을 미리 밝힌다.


GPI - Global Address Space Programming Interface

이 GPI는, Fraunhofer Institut ITWM 에 의해 새롭게 구현된 개념이며, 새로운 언어를 사용하는 대신 C, C++, Fortran 의 API를 지원한다. 물론 이미 산업 현장에서 검증 받은 기술이며, 기존의 MPI 가 가지고 있던 구조적인 확장의 한계를 종식시켰다. 이는 다수의 GPI 벤치마크 구성을 통해 어떻게 어플리케이션이 멀티 코어 시스템에서 병렬처리가 가능하도록 구성되는지 확인 할 수 있겠다.

The GPI Architecture




GPI

GPI는, Infiniband나 10GE 을 사용하여 연결된 클러스터간의 낮은 지연시간을 충족하는 라이브러리와 런타임 시스템을 제공함으로서 병렬 처리하도록 구성된 어플리케이션의 확장 가능한 실시간 분산 컴퓨팅 시스템의 구성이 가능하게 한다. 이는 어플리케이션에 PGAS(Partitioned Global Address Space)를 사용하여 원격의 데이터 위치에 대한 직접적이고도 완전한 접근을 제공한다. 대부분의 통신의 기본은, 런타임 환경 체크, 패스트 배리어(Fast Barrier)나 글로벌 아토믹 카운터(Global atomic counter)의 동기화에 사용됨으로서, 대규모로 확장이 가능한 병령 프로그램의 개발이 가능하도록 한다.

성능의 측면에서는, 주어진 네트워크 회선 속도를 최대한 활용하고, 계산과 통신을 오버랩하여 통신의 부하를 최소화 한다.(완전한 비동기 통신)

GPI는 대량의 데이터에 대한 간단하고도 신뢰할만한 시스템을 제공하며, 빡센 I/O와 계산을 위한 동적이고도 불규칙적인 어플리케이션의 사용을 가능하게 한다.


MCTP

MCTP는 GPI를 노드레벨에서 지원한다. 소프트웨어 개발자들은 이제 더이상 프로세서의 속도를 기반으로 개발할 수 없게 되었다. 따라서 다중 스레드 디자인은 대규모로 확장이 가능한 어플리케이션의 개발을 위한 필수적인 사항이다.

MCTP는 기존의 프로그래머들에게 친숙한 멀티 스레딩 프로그래밍을 지원하는 일종의 스레딩 패키지다. 이는 플랫폼에서 발생하는 네이티브 스레드를 추상화하고, 스레드, 스레드풀, 그리고 높은 주파수의 타이머 또는 동기화와 같은 해결이 어려운 부분에 대해 최첨단의 해법을 제공한다.

일반적인 스레드 라이브러리와 구분되는 MCTP의 중요한 기능중 하나는, 코어 매핑을 위한 캐시와 NUMA 레이아웃을 하드웨어 레벨에서 완전히 지원한다는 점이다.


Benchmarks

MD Benchmark


일반적인 Molecular dynamics 어플리케이션에서의 MPI 와 GPI 의 성능 차이를 보여주고 있다. 그래프를 보면 알겠지만, MPI에 비해 GPI가 보다 큰 데이터를 처리할때 보다 많은 노드를 사용하여 높은 성능을 구가할 수 있음을 보여준다.


Bandwidth


2대의 노드를 사용하여 MPI 와 GPI의 메세지 전달에 사용될 수 있는 최대 대역폭에 대한 그래프를 보여주고 있다. 쉽게 설명하자면, 데이터 처리를 위해 공유되는 메세지의 크기는 각 메세지 별로 크거나 작을 수 있는데, GPI는 일반적으로 MPI 보다 훨씬 작은 메세지 사이즈에서도 최대의 대역폭을 사용할 수 있음을 확인 할 수 있다. 이는 병렬 컴퓨팅에서 매우 중요한 부분중 하나인데, 만약 메세지 전달의 오버헤드가 크면 실제 계산의 속도는 32개의 노드보다 16개의 노드가 빨라지게 되는 웃지못할 사건이 생기게 된다. 물론 이러한 현상은 비단 대역폭 때문만은 아니라 처리해야 할 데이터의 성격에도 관련이 있기는 하지만, 이러한 대역폭은 클러스터링의 구성에 대한 선택에 매우 중요한 포인트가 된다.

2D-FFT


이런 시스템을 사용하시는 분들이라면 잘 알고 계실 병렬 컴퓨팅의 계산 방법 중 하나이다. 그래프를 보면 일반적인 MPI는 128개의 코어가 넘어가게 되면 계산을 위한 시간이 다시 증가하는 것을 볼 수 있는데, 이는 메세지 통신의 오버헤드 또는 데이터의 동기화에 코어가 많아질 수록 처리시간이 증가하기 때문이다. 하지만 GPI는 노드 증가에 따라 꾸준히 그 성능이 좋아지는 것을 확인 할 수 있다.


Collectives



All Reduce 에 대한 그래프이다. 단순히 MPI 에 비해 빠른것 뿐만 아니라, 확장성에서도 매우 뛰어난 것에 주목해야 한다. 512 코어에서는 MPI 가 GPI 에 비해 70% 의 시간이 더 소요되는 것에 주목하자.

Mem barrier



이는 서로다른 라이브러리의 스레드 성능을 나타낸다. MCTP_NUMA 1.52 가 가장 좋은 성능을 나타내고 있으며, 이러한 성능이 코어가 증가될 때에도 지속적으로 유지되는 점에 주목하여야 한다.


Tile Rendering



일반적인 3D 렌더링이나 2D 작업에 사용되는 타일 렌더링에 대한 벤치마킹 그래프이다. 역시, MCTP가 가장 우월한 성능을 보임을 나타낸다. 세로축의 숫자는 초당 처리되는 프레임(사진 한장)의 갯수라고 보면 된다.




Installation

현재 해당 업체의 홈페이지의 다운로드 페이지에 갔더니 가입하라고 한다. 지금 당장 테스트 해볼 플랫폼도 없어서 그냥 설명으로 대신 한다. 하긴 생각해 보면 이런 툴 사용하시는 분들은 굳이 여기에 적어놓지 않아도 벌써 사용하고 계시지 싶다. ㅋ 뻘짓인가..  물론 직접 설치해 본 것이 아니기 때문에 발생 할 수 있는 예외사항에 대한 고려는 읍다.

플랫폼 요구사항.

  • 반드시 Linux , Supported Linux distribution. ( GPI가 OFED 스택 기반이므로 )
  • 64bit 지원한다.
  • GPI 데몬은 root 권한으로 동작해야 한다.
  • Infiniband/Ethernet 드라이버 및 완벽한 설정
  • Infiniband/Ethernet 의 멀티캐스트 네트워크 설정
  • 파일 캐시 제어
  • 사용자 인증 (PAM)
  • GPI 프로세스에 대한 완벽한 제어. 일반적으로 발생하는 문제는 거의 배치 시스템 연동 부분
  • GPI 바이너리에 대한 의존성 확인 ( ldd 등으로 필요한 라이브러리 확인 )

위의 내용 말고도 몇가지 더 있지만 워낙 당연한 것들이라 제외했다.


GPI 데몬 설치

설치를 위해서는 단 하나의 스크립트만이 존재한다. install.sh  이 스크립트는 GPI 데몬을 설치한다. 이 스크립트를 동작할 때는 반드시 -i 옵션과 함께 사용하여야 한다. -i 옵션은 라이센스 서버의 IP 이며, -p 옵션은 GPI 가 설치될 경로를 지정한다. GPI 데몬은 RPM 으로 제공되며, 설치가 완료된 이후에는 다음의 설정 파일들이 생긴다.

  • /usr/sbin/gpid.exe
  • /usr/sbin/gpid_NetCheck.exe 
  • /etc/ 하위에 설정 파일
  • /etc/init.d/ 에 gpid 스크립트. 런레벨 3과 5가 기본으로 활성화 되어있음
  • /etc/pam.d/ 에 gpid_users

/etc/init.d/gpid 가 올바른 설정값을 가지고 있다면, 설치 된 이후에 데몬은 바로 시작될 것이다.
설정 파일은 /etc/gpid.conf 에 위치한다. 구동하기 전에 잘 살펴보자. 이는 machinefile 이 위치한 디렉토리를 설정해야 하는데, 이 machinefile 이라는건 병렬 처리할 클러스터의 각 노드 리스트를 넣어준 것이라고 보면 된다.

보통 PBS와 함께 연동하는 경우가 많을텐데, 이런 경우 /etc/gpid.conf 에 보면 다음과 같은 설정이 있을 것이다.

NODE\_FILE\_DIR=/var/spool/torque/aux   # 아... 망할 윈도우 \ 표시 증말 싫다 ㅠㅠ

만약 machinefile에 중복된 호스트네임 엔트리가 있으면,  해당 노드는 사용되지 않는다. 옵션에 대한 설명은 따로 하지 않는다.


GPI SDK

역시 설치를 위해서는 1개의 스크립트가 지원된다. install.sh 이는 -p 옵션으로 반드시 설치될 위치를 지정해 주어야 한다. 설치가 완료되면 다음의 내용들이 시스템에 존재할 것이다.

  • /include/  어플리케이션 개발자를 위한 헤더
  • /lib64/  라이브러리
  • /bin/ 사용자의 바이너리가 위치할 디렉토리. 서브디렉토리의 사용도 허용된다.
  • /bin/gpi_logger  워커 노드 GPI 어플리케이션의 stdout 을 확인하는데 사용 될 수 있다.


다들 잘 아시겠지만, 이는 그저 MPI 와 같이 그 자체만으로는 아무것도 하지 않는다. SDK 를 사용하여 클러스터를 사용하도록 지원되는 라이브러리를 사용하여 어플리케이션을 개발하고, 빌드하여야 비로소 동작한다. 물론 PBS와 같은 시스템과의 연동을 위해서는 추가적인 작업이 좀 필요하긴 하지만, 전반적으로 MPICH 와 비슷한 구성이므로 분야에 익숙하신 분들께는 그 내용이 그다지 어렵지는 않을 것이다.


보다 자세한 내용은 해당 홈페이지에서 다운로드가 가능한 문서들을 참조하도록 한다.  어차피 라이브러리를 블로그 한페이지에 다 설명하는 것 자체가 정상이 아니라고 본다 나는.  흑.. 이미 충분히 길다.  아.. 나도 자바스크립트 열심히 배워서 간지나는 코드 박스 넣어줘야지. ㅠㅠ


개발 된지 얼마 되지 않은 라이브러리인 듯 하다. 이런 추세를 살펴보면, 일반적인 웹과 수퍼컴퓨팅이 결합될 날도 머지 않은 듯 하다. HPC나 수퍼컴퓨팅은 예로부터 PBS 와 같은 시스템에서 배치로 클러스터에 잡을 떨구는 형태였는데, 이를 조금만 웹 스타일로 세련되게 바꾸면 디게 멋져질 것 같다. 어떤 서비스에 적합할런지는 아직 모르겠지만, 만약 나중에 트위터 정도의 데이터를 실시간으로 분석해야 한다면 이런 결합이 필요하지 않을까? 말이 트위터지만, 전 세계의 주식 거래에서 오고가는 주가 변동의 정보와 이에대한 실시간 분석등이 웹으로 지원 될 수 있다면. 뭐, 그저 꿈일 수도 있지만 어쨌든 그만한 데이터의 처리를 위해서는 단순한 클라우드 뿐 아니라 HPC 도 주요한 역할을 할 수 있다고 생각한다.
단지 기상 데이터나 천체의 시뮬레이션과 같은 연구 목적에서 벗어나서 말이다.


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

HPC in the KT Cloud, and CHEF

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


개인적인 사정과 몇몇가지 머리 복잡한 일들이 최근에 겹치게 되면서 블로그에 많이 소흘했었다. 지난회에 연재하기로 한 Chef 코드도 작성하다가 말아버리고 끈을 놓아 버리게 되어서 다시시작하려면 한동안 시간을 투여 해야 본 궤도에 올릴 수 있을 것 같다.  뭐, 그다지 어려운 코드들은 아니지만...

뭐 쉬어가는 페이지 처럼, 금일은 조금 뚱딴지 같지만 조금 있으면 런칭될 KT 의 클라우드 서비스가 잘 사용될 수 있을만한 분야 중 하나를 소개하고자 한다.  구체적인 런칭 일자가 언제일지는 모르겠지만, 아마존의 EC2 와 비슷한 스타일의 컴퓨팅 클라우드를 제공 할 예정이다.  물론, 여기서 소개하는 내용은 아마존 EC2 에서 사용 될 수 있거나, 이미 사용 되고 있는 내용이다.


우리가 주변에서 쉽게 접하지만 실제 일반 고객에게는 잘 알려지지 않은 분야들 중에는 굉장히 높은 컴퓨팅 리소스를 요구하는 분야들이 있다.  이를 테면 "쿵푸팬더", "슈렉" 등과 같은 3D 실사 애니매이션이라던가, 수집돤 온도, 습도, 대기압 등의 자료를 기반으로 수학 모델로서 시뮬레이션 하는 일이라던가, 정유/화학 또는 신소재 개발 부분등에서 사용되는 분자/화학 시뮬레이션 및 기타 전통적으로 컴퓨터가 사용 되어야만 하는 모든 분야들이 소위 말하는 HPC , 즉 High Performance Computing 의 범주로 넣을 수 있는 분야들이겠다.  

기존의 일반적인 서비스 시스템을 사용하는 기업 입장에서도, 또 위와 같은 일반적이지 않은 시스템을 구비하고 있는 기업 입장에서도 클라우드는 매력적일 수 밖에 없다.  전자에게는 기업이 직접 운용 하는 것 이상의 시스템 가용성과 확장성을, 후자에게는 단시간 내에 저렴한 비용으로 최대한의 컴퓨팅 파워를 얻을 수 있는 점이 바로 그렇다.  이전에는 기상청에서 슈퍼컴퓨터를 어마어마한 규모의 비용으로 구매를 해야 했지만, (라이브러리 및 기존 어플의 포팅이 가능하다는 전제하에) 이제는 시간당 몇백원 또는 몇십원 하는 클라우드의 인스턴스를 계산에 필요한 시간만큼 필요한 수량으로 생성하여 계산에 사용하고, 종료 되면 인스턴스를 끄거나 지워 버리면 된다.  Compute Node 는 그 자체로 이미 Temporary 한 성향을 가지고 있기 때문에, Master Node 및 계산 결과 등이 저장되는 노드를 적절히 배치 하였다면 이런식의 저렴한 컴퓨팅 파워의 사용이 이롭지 않을리가 없다.

실제 이러한 HPC 컴퓨팅의 특성은 다음과 같다고 할 수 있다.

1. 시스템 구조적 모델이 비교적 단순하다.
2. 결과값을 만들어 내는 어플리케이션의 최적화에 효율성과 비용이 연계되어 있다.
3. 시스템적 구조 보다는 컨텐츠 ( 계산식 또는 렌더링 하게 될 Scene ) 가 매우 중요하다.
4. 어플리케이션에 따라 컴퓨팅 노드에 요구되는 구조가 다를 수 있다.


또한, 이러한 HPC 클러스터들은 단순하게 보면 다음의 구조적인 공통점을 가지고 있다.

1. Job Queuing 또는 Job Orchestration 이 중요하다. 보통 이런 역할을 담당하는 노드를 마스터 또는 메인노드라 한다.
2. 마스터 노드와 연계되어 실제 죽어라 계산만 담당하는 컴퓨팅 노드들. 컴퓨팅 노드의 적절한 수량 산정 및 필요에 따라 MPI 와 같은 형태로 컴퓨팅 노드간에 적절한 수량으로 클러스터를 구축 해 줄 필요가 있을 수 있다.
3. 결과 값을 저장하기 위한 공용 스토리지.
4. 어플리케이션에 따라 결과값을 파싱하여 Db 화 할 필요가 있을 수 있다.

위에서 이야기한 기능을 구현하기 위해서는, 고전적인 베오울프 프로젝트를 따라해 보자면 다음과 같은 것들을 준비해야 했다.

0. 계산에 필요한 물리적 서버. ( 필요에 따라 수십 ~ 수백 또는 그 이상 )
1. PXE Boot / DHCP
2. system image ( Optimized for application / Hardware )
3. Bootstrap
4. NFS / DB / PBS like Queuing System.

다른 것들은 고사하고 물리적 서버의 준비에 어마어마한 비용이 들어간다는 것은 잘 알것이다.  여기에 각종 라이센스.

분자/화학 분야에서 사용되는 어플리케이션의 경우 예를 들기가 다소 곤란하므로 일반적으로 생각 할 수 있는 렌더링 팜이나 MPICH 클러스터, 또는 HDR ( High Dynamic Range ) 이미지를 수만장을 생성/ 자료화 해야 하는 경우등을 생각 해 볼 수 있겠다.  시스템의 구조가 단순하며, 동일 목적의 노드가 많은 동시에, 해당 노드들의 라이프 사이클이 짧고 재사용성이 요구되는경우, 우리는 이러한 시스템의 구현에 무엇을 생각 할 수 있는가?  바로 그렇다. 자동화 툴, Chef.
물론 CFEngine 이나 다른 툴을 사용하여도 무방하다.  다만 나는 Chef 가 편하기 때문에. 
이러한 경우에는 심한경우 Cookbook 1개로도 처리가 가능하다.


예를 들자면, 일반적으로 많이 사용되는 3Ds MAX 의 경우, Windows 만을 지원한다. ( WINE 은 접어두도록 )  물론 내가 지금 3DS MAX 의 라이센스를 가지고 있는 것은 아니어서 스크린샷을 찍게 되지는 못하겠지만, 보통 다음의 순서로 환경의 구성이 가능해진다. ( MAYA 및 기타 다른 툴도 대부분 동일한 구성 )

0. 렌더러 및 배치 또는 큐잉 또는 오케스트레이션 설치 및 설정을 위한 Chef 코드 및 서버를 준비한다.
1. 돈내고 Instance 를 필요한 수량만큼 만든다.
2. 작업용으로 사용하는 워크스테이션에 VPN 환경을 구성한다. 물론 서버는 클라우드 안에 있다.
3. 생성된 인터페이스에 Chef 구동을 위한 환경을 준비한다.
4. Computing 노드에서 적절히 Chef 를 구동한다.
5. 사용한다.

위의 0 ~ 5 와 같은 작업은 만약 3D 툴로 Blender 를 사용한다면 쉽게 오픈소스만으로 구성이 가능하다.
렌더링 팜이 아니라, 계산식을 위한 노드의 사용으로서도 위의 0~5 의 시스템 구성 순서에는 큰 차이가 없다.

예전에는 1대의 워크스테이션을 구매하여, 포트폴리오 또는 양질의 영상을 만들기를 원하는 개인 또는 영세 사업자가 1분 이상의 동영상을 만드는건 굉장한 일이었다.  렌더링 시간을 위해 프레임을 아껴야 했고, 플러그인 등 각종 화려한 기법들을 눈물을 머금고 삭제해야 했으며 그렇게 힘들게 만들어낸 영상은 당연히 맘에 들지 않을 수 밖에 없었다.  어마어마한 비용과 쓰러지는 감가상각비를 가진 서버로 구성된 렌더링 팜을 소유하는 대신, 이제 쉽게 "클라우드" 라는 자원을 활용함으로서 약간의 지식만 있으면 수억원을 들이지 않고도 양질의 결과를 얻게 될 것이다.

실제 서비스를 런칭 해 보면 알 일이지만, Amazon 의 EC2 와 같은 컴퓨팅 서비스가 국내에 대규모로 런칭 되는것은 매우 환영할 만한 일이다.  물론 기존의 호스팅 업계에서는 문제가 될 수 있긴 하겠지만,  개인 및 각 기업의 다양화 되어있는 서비스 요구사항을 충족하기에는 기존의 호스팅이 다소 버겁거나 제한적인 요소가 있어왔던 것도 사실이기 때문에, 충분한 성능및 사용성에 대한 부분들만 검증 된다면  많은 기업에 비용을 획기적으로 줄일 수 있는 서비스가 될 것이기 때문이다.

다만, "오~ 클라우드 죽이는데" 하는 태도로 자신들의 솔루션에 대한 검토없이, 즉 마이그레이션에 대한 사전 준비 및 고려 없이 무작정 달려든다면, 분명 2중으로 지출되는 비용에 클라우드는 마법의 양탄자가 아님을 깨닫고 물러서게 될 수 밖에 없다.  마찬가지로, HPC 에는 수많은 어플리케이션이 있고, 경우에 따라서는 그 구조 자체가 다소 복잡 해 지거나 추가적인 어플리케이션의 개발이 필요 할 수 있다.  이런점을 모두 인지 하고 가능성을 충분히 검토한다면,  클라우드는 저비용, 고성능, 고가용성으로 사장님 및 팀장님을 미소짓게 만들 수 있을 것이다.


위에서 대략 설명한 내용들에 대한 구성을 실제 문의 받고 싶다면, 본 블로그에 적혀진 메일 주소로 이메일 주시면 가용한 범위 내에서 충분히 설명 드리겠다.


다음의 Amazon EC2 페이지 참조 및 관련 Case Study 를 찾아보면 많은 자료를 얻을 수 있다.
http://aws.amazon.com/ec2/hpc-applications/

NASA JPL  Image Processing in the Cloud
http://aws.amazon.com/solutions/case-studies/nasa-jpl/

Ushering Biotech Firms into the Cloud ( from hpcinthecloud.com )
http://www.hpcinthecloud.com/blogs/Ushering-Biotech-into-the-Cloud-115020599.html?utm_source=twitterfeed&utm_medium=twitter

설명 하려던 바와 비슷한 형태의 HPC 솔루션
http://www.cyclecomputing.com/products/cyclecloud/overview

Molecule Related Work case in Cloud
http://aws.amazon.com/solutions/case-studies/pathwork-diagnostics/

그나저나 코드 쓰던거 마저 써야 하는데... 이게 시간이 영...;;;

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