System Compleat.

'HPC'에 해당되는 글 3건

  1. vSMP, Versatile Symmetric Multi-Processing
  2. Cloud, HPC, GPU 11
  3. HPC in the KT Cloud, and CHEF

vSMP, Versatile Symmetric Multi-Processing

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




클러스터링 환경에 익숙하거나, 병렬 컴퓨팅, 또는 일반 PC를 가혹하게 사용하시는 분들은 모두 이런 생각 한번쯤은 해 보셨을 것 같다. 

"아, 이 여러대의 컴퓨터를 각각 별도의 OS를 사용하여 MPI와 같은 방법으로 묶지 말고, 차라리 한대의 서버처럼 묶어 버릴 순 없을까? "

90년대 후반, 인텔이 SMP를 지원하는 프로세서를 시장에 내놓으면서, 워크스테이션 좋아라하는 컴덕후들은 입이 떡 벌어져 Pentium Pro 프로세서를 구매해 대고, 프로세서를 2개 이상 설치 할 수 있는 고가의 메인보드를 구매해 댔다. 그러고나서 당시의 전세계 수퍼 컴퓨팅의 Top 100 중 가장 빠른 컴퓨터는 바로 인텔이 Pentium Pro 프로세서를 병렬로 묶은 컴퓨터라 카더라 하는 이야기를 침튀어가며 이야기 했었다.

당시에도 수퍼컴퓨터 하면 Cray가 항상 다섯손가락 안에 들었으며, 냉각팬이 아닌 화학물질로 시스템 온도를 낮추어야만 하는 이 신기한 컴퓨터의 이미지를 쳐다보며 아~ 한번 만질수 있다면 얼마나 좋을까 하는 생각들을 했었더랬다. 그 시절 1G 이더넷을 구축하는 것도 엄청난 비용이 들었으며, 10G는 아직 나오지도 않은 시점에서 그나마 Cray보다 저렴한 MPI 클러스터를 지금도 고가인 InfiniBand 를 사용해 엮어 사용하기만 해도 대단한 클러스터로 쳐 주었다.

세월은 흐르고 흘러, 그저 꿈으로만 생각했던 소프트웨어가 나왔다. 물론 그 효용성과 성능에 대해서는 일부 검증을 직접 해 볼 수 있으면 좋겠지만, 일단 상용으로 나왔다는거 자체가 이미 어느정도의 지원은 가능하며, 어지간히 동작이 가능한 수준이라고 볼 수 있겠다.

바로 그렇다. 여러대의 x86 시스템위에 하나의 OS를 올릴 수 있는 시스템 소프트웨어가 출현 한 것이다. 개발 업체의 이름은 ScaleMP (http://www.scalemp.com), 제품은 vSMP Foundation 으로 소개되고 있는듯. 제품의 구매는 삼부 시스템이라는 업체에 문의 해 보면 될 듯 하다. (http://www.samboo.co.kr) 회사의 홈페이지를 보면 원래 Cray를 전문으로 취급하던 기업 같은데, 아마 이 분야의 사람들에게는 익숙한 업체이지 않을까 짐작해 본다.


일단, x86 기반의 머신들만 가지고 한대의 OS를 사용한 기존과는 획기적으로 다른, 상상해 왔던 바로 그 클러스터 시스템이 제공하는 기능은 다음과 같다.

vSMP Foundation for SMP


기능
  • 최대 128대의 노드를 사용하여 단 하나의 OS를 가진 시스템을 생성 
  • Highest CPU Capacity :  vSMP를 사용한 OS는 최대 16,384 개의 CPU를 단일 PC와 같이 하나의 공유메모리 기반에서 사용 가능 ( 8192개의 코어를 사용한다는 말도 있는데 이 두개의 숫자가 어떻게 다른지 써보기 전에는 모르겠다.)
  • Largest Memory footprint : 최대 64TB 의 메인 메모리 
  • High Speed I/O : 빡센 데이터의 처리에 병렬 스토리지를 활용 
  • 장애 대응을 위한 InfiniBand  연결 지원 
  • 장애로 부터 자동 복구
  • 나머지 생략

장점
  • 기존의 단일 머신의 SMP 성능을 뛰어넘는 기절할만한 성능
  • 투자 보호 : 서로 다른 속도의 CPU, 서로 다른 크기의 메모리, 다른 I/O 장치를 사용한 환경에서도 구성이 가능
  • 기타 생략

OMG

Image from : http://i7.photobucket.com/albums/y286/SNOOP97DAWG/NHL/homer-simpson-5.jpg



그렇다. 입이 떡 벌어진다.  기존의 병렬 시스템들이 추구하는바가 Scale-Out 으로, 단일 시스템이 Scale-Up 의 형태로 성능을 확장하기 힘들었기 때문에 생긴 방법들이다. 하지만 이 물건은, Scale-Up 과 Scale-Out 을 모두 지원함으로서, 아니, Scale-out 의 형태를 사용하여 Scale-Up 을 구현 함으로서, 비지니스의 성장요구에 따라 점진적으로 하드웨어의 추가가 가능하며, 더군다나 대부분의 Block 레벨로 I/O를 공유하는 클러스터가 요구하는 하드웨어의 동일성마저 없다. 따라서 세월이 지나면서 HCL 만 충족하는 하드웨어를 지속적으로 구매한다면, 다양한 하드웨어를 사용한 노드의 집합으로 하나의 OS를 사용하는 거대한 시스템을 구성 할 수가 있는 것이다!

난 쩔어 버렸어~ (태지 보이스, 필승)

혹시 국내에 사용중인 환경이 있는가 궁금해서 네이버등에 검색을 쌔워보니, 뉴스 이외의 정보는 없는것으로 봐서는 그다지 많이 알려져 있지는 않은 것 같다.


실리콘밸리의 벤처 회사들을 다니다 보면, 그런 생각을 갖게된다. 얘들이 설명하는거 절반만 제대로 동작해도 이건 먹어주는 물건이다, 라는.  OS라는건 나름 복잡한 물건이다. 관련 전공을 이수하신 분들이라면 한번쯤 읽어 보았을 Operating System Concepts 에서 설명하는 대부분의 내용들은 시스템이 동작하는 기본이며, PC와 서버가 발전하면서 단일 PCB상에서 연결된 장치들의 오묘한 타이밍 통제와 락, 스케줄링이 복합적으로 그리고 유기적으로 조합된 하나의 소프트웨어인 것이다. 이 새로운 패러다임의 단일 OS지원 클러스터는, 이 OS에서 제공하는 별도의 라이브러리를 사용한 별도의 소프트웨어만 동작한다면 기존의 클러스터보다 나을것이 그다지 없을 것이다. 하지만 상상해 보라. 만약, 이 OS에서 오라클이 아무 문제없이 동작하고, 리눅스 기본 패키지들이 별 문제 없이 동작한다면, 이건 정말 두손 두발 다 들어주어야 할 기존과는 다른, 그야말로 신세기 컴퓨팅 플랫폼이 되는 것이다. 물론 오라클이 동작하지 않을 거라는 심증이 좀더 크지만.

아무튼 ScaleMP 사이트의 제품 소개를 제외한 대부분의 정보는 Subscription 으로 보호되어 있다. 심지어 Whitepaper 조차 등록 후에 열람이 가능하다. 따라서 이 블로그에서 소개하는 것 이상의 정보가 필요하신 분들께서는 ScaleMP의 홈페이지 또는 삼부시스템의 홈페이지를 참조하시기 바란다.

궁금한 부분은, 각 시스템의 연결을 10G를 지원하는지의 여부 (어떻게 각 클러스터들을 연결하는지의 여부) 와 각 시스템의 Disk를 어떻게 사용하는가와 같은 부분들이다. 또는 별도의 Shared Storage를 연결해야 하는지 등도 매우 궁금하다. 나중에 알게되면 설명하겠다.

분명한 것은, ScaleMP는 컴퓨팅의 새로운 패러다임을 만들었다. 이들 역시 이 부분을 강조하는데, 기존의 클라우드와 같은 단일 서버를 여러대의 가상서버로 분리하는 것을 Partitioning 으로 정의 하며, 데이터 센터에 데스크탑을 설치해 두고 원격지의 Thin-Client로부터 접근하여 사용하는 방법을 Remotting 으로 정의 한다. 이 새로운 패러다임은 여러대의 물리서버를 사용하여 하나의 논리적인 OS로 구성하는 방법으로서, 이를 Aggregation 으로 정의하고 있다. 이는 가상화의 또 다른 모습이며, 여러분이 기존에 이해하고 있었던 가상화에 대한 신선한 충격이 될 것을 믿어 의심치 않는다.

상용 소프트웨어인데다가, 그 사용 방법 역시 널리 알려졌다고 보기엔 무리가 있다. 따라서 별도의 교육이 있지는 않은지 살펴 보니 역시 있다.  교육 과정은 다음과 같다.

VSMP101: Introducing vSMP Foundation

VSMP201: System Administration (Basic)
VSMP202: System Administration (Advanced)
VSMP301: Developers (Theory)
VSMP302: Developers (Hands-on)


301과 302는 각각 8시간, 나머지는 각 4시간으로 일주일 정도의 코스가 되지 않을까 싶다. 이 일주일 정도의 교육이 의미하는 바는, 아마도 개발자가 아니라면 기존의 시스템과 크게 다르지 않기 때문에 쉽게 적응이 가능하지 않을까 하는 기대를 품게한다.


자, 이제 ScaleMP 측의 제품에 대한 설명을 좀 살펴보자.


The Versatile SMP (vSMP) Architecture

현재 특허 출원중인 Versatile SMP 아키텍처는 하이엔드 SMP 시스템의 구성을 위해 사용된다.  vSMP는 기본적으로 InfiniBand 로 상호 연결된 시스템들을 사용해 기존의 시스템들을 대체한다. vSMP Foundation 은 ScaleMP가 만들어낸 아키텍처를 실제로 구현해 낸 제품이다. 이는 업계 표준의 일반적인 하드웨어를 사용하여 하나의 대형 X86 시스템을 만들어내는 기술이다. 이 기술은 특별히 하나의 하드웨어 벤더 또는 한 종류의 하드웨어를 사용할 필요가 없으므로, 기존 클러스터가 요구했던 맞춤형 하드웨어의 제작 또는 이러한 하드웨어를 제작하는 벤더만을 사용해야 하는 벤더-락-인 의 단점을 종식시킨다.

전통적인 멀티 프로세서 시스템은 프로세서간의 통신 및 공유 메모리, 사용자 정의 칩셋등이 하나의 메인보드에 집약되어있는 구성을 가진다. 이러한 구성은, 시스템이 4개 이상의 프로세서를 지원하기 위해서는 훨씬 복잡한 내부 구조로 인해 설계가 쉽지 않다. 따라서 이 이상의 프로세서를 지원하는 시스템은 거의 없다고 봐도 무방하다. 또한 프로세서의 빠른 신제품 발매주기로 인해 이러한 프로세서들을 메인보드는 지속적으로 지원해 주어야 하므로, 이렇게 수많은 프로세서의 탑재가 가능한 보드를 어렵게 설계 하는것은 큰 의미가 없다. 따라서, 기존의 Scale-UP 형태의 시스템 확장에 한계가 발생하는 동시에, 하이-엔드 컴퓨팅은 새로운 형태의 시스템을 요구 하게된다.

vSMP는, 별도의 커스텀 하드웨어를 사용할 필요가 없다. vSMP 아키텍처의 핵심은 바로 기존의 멀티 프로세서 시스템들과는 다른 형태의 칩세 서비스를(칩셋은 보통 하나의 PCB에 위치하므로 단일 시스템의 의미로 생각해도 좋다) 소프트웨어를 사용하여 구성한다는데 있다. vSMP 아키텍처는 I/O 및 시스템 인터페이스 (BIOS, ACPI)의 공유와 캐시등의 기존 OS에 필요한 모든것들을 제공한다. 이는 완전히 투명한 방식으로 구현되며, 별도의 추가적인 드라이버를 필요로 하지 않으며, 기존의 어플리케이션에 아무런 변경을 하지 않아도 동작하도록 한다.


Requirements

vSMP Foundation Requires :

  • Multiple high volume, 업계 표준 x86 시스템 또는 프로세서와 메모리를 탑재한 시스템 보드
  • HCA 리스트에 정의된 하드웨어를 사용한 InfiniBand 인프라. 케이블, 스위치.
  • vSMP Foundation 을 부팅하기위한 시스템 보드별 하나의 스토리지 장치. vSMP Foundation for Cloud 제품은 네트웍 부팅을 사용하므로 필요하지 않음.

One System

vSMP Foundation 은 최대 128대의 x86 시스템을 지원한다. 이 하나의 가상화된 OS는 각 노드의 메모리의 로딩이 끝나고 나면, vSMP Foundation 은 이 각 노드에 있는 컴퓨팅과 메모리, I/O 자원을 병합하여 단일화된 하나의 가상 OS와 이 OS 에서 사용할 어플리케이션의 구동이 가능하게 된다. vSMP Foundation 은 균등한 실행 환경을 제공하기위해 Virtual Machine Monitor(VMM) 의 형태를 사용한 소프트웨어 엔진을 사용한다. 또한, vSMP는 단일화된 시스템의 사용성을 위해 BIOS나 ACPI와 같은 환경을 만들어내는 부분도 포함한다.


Coherent Memory

vSMP 는 여러가지 신기술을 사용하여 각 시스템 보드간의 캐시 동일성을 유지한다. 이 복잡한 알고리즘은 실시간 메모리 활동 및 접근 패턴에 대해 블럭레벨로 동작한다. vSMP는 시스템간의 통신에 대한 지연시간을 최소화하기 위해 보드의 로컬 메모리와 최상의 캐시 알고리즘을 사용한다.


Shared I/O

vSMP Foundation 각 시스템 보드의 모든 PCI 자원을 하나로 병합하고 이를 공통의 I/O pool 리소스로서 OS와 어플리케이션에 제공한다. OS는 시스템 스토리지와 네트워크 장치를 적절히 활용 하여 최상의 성능을 제공한다. 


Flexible Versatile Architecture

vSMP Foundation 소프트웨어는 vSMP 아키텍처를 구현한 것으로서, 128대의 산업 표준의 일반적인 x86 시스템을 하나로 통합하여 가상의 단일화된 OS를 생성할 수 있다. vSMP Foundation 은 최대 1024 개의 프로세서 ( 8,192 코어) 와 64TB의 공유 메모리를 사용한 가상 시스템을 생성해 낼 수 있다.

vSMP Foundation 은 이러한 각 노드의 CPU와 메모리의 크기가 서로 다르더라도 지원이 가능하며, 심지어 I/O 장치가 다르더라도 동작한다. 이는 x86 공유 메모리 시스템의 고유한 기능이다.

높은 프로세서 부하를 요구하는 컴퓨팅 어플리케이션의 경우, 최대 1.5TFLOPS 를 사용하는 단일화된 시스템의 사용이 가능해진다. 만약 어플리케이션이 메모리를 많이 사용하지만 요구되는 컴퓨팅 파워는 그다지 높지 않은 경우, 높은 속도의 프로세서와 낮은 속도의 프로세서를 복합적으로 사용하는 아키텍처가 구성이 되는 경우가 있다. 이러한 불균형 구성에서, vSMP Foundation 소프트웨어는 OS 에서는 낮은 속도의 프로세서들을 노출하지 않는 동안에는 항상 가장 빠른 프로세서들을 병합하여 사용한다.
이러한 구성은 비용과 전력의 손실은 절감하면서, 최대 사이즈의 메모리와 최고의 성능을 발휘할 수 있게 한다. 마찬가지로, 사용자는 어플리케이션의 요구에 따라 I/O를 구성할 수 있으며, 따라서 업계 최고의 유연한 고성능 x86 시스템을 구비할 수가 있게된다. 이러한 비용/성능의 두마리 토끼를 모두 잡아냄으로서, vSMP Foundation 을 사용한 시스템은 고객에게 최고의 비용 효율성을 제공할 것이다.

Performances (http://www.scalemp.com/performance)


일반 - 메모리 대역폭 테스트

Memory Bandwidth



Life Science

Computational Chemistry




Computational Chemistry



Bio Informatics






Manufacturing

Fluid Dynamics




Weather Forecast

MOM4 - CM2P1:1 MODEL DAY



Numerical Simulations

Mathworks MATLAB





정리.

그런 생각을 해 본다.  GPGPU를 사용한 전통방식의 클러스터가 빠를까, 여러대의 머신을 하나로 클러스터링한 ScaleMP 의 클러스터가 빠를까. 그리고 또 ScaleMP가 향후 GPGPU 를 그들의 가상 OS 레벨에서 지원하게되면 또 어떻게 될까.  또, 이렇게 묶여진 가상 OS를 다시 병렬로 묶을 수 있을까?  (128 node vSMP) -- MPII -- (128 node vSMP) 이렇게 말이다.

기존에 했던 포스팅들과는 달리, 무언가 새로운 패러다임이 나타난것 같아서 흥분했다. 위의 퍼포먼스 사이트에 가시면 SPEC CPU2006 과 같은 일반적인 벤치마크 도구의 결과도 볼 수 있다.


사실, 오픈소스 진영에서 만들기는 쉽지 않은 도구다. 물론 뭐 어떤건 쉬웠겠냐마는.  물론 이 상용 소프트웨어 역시 그 기반기술의 대부분이 오픈소스에 의존하고 있을 것이라는 추측을 해 본다. 이 도구가 얼마나 많이 알려지고, 또 도입 사례가 발생할지는 모르겠지만, 이 소프트웨어의 HCL을 충족하는 하드웨어를 기존에 사용중이었다면, 충분히 테스트 해 봄직 하다 라는 생각을 해 본다. 더군다나 클라우드와 클러스터를 위한 패키지들을 함께 제공하므로, 관심있으신 분들은 직접 홈페이지에서 정보를 얻어보시는것도 좋을 것 같다.



ScaleMP Home page
http://www.scalemp.com

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










Cloud, HPC, GPU

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

들어가기에 앞서, 각 1, 2 와 같은 내용의 구분은 별 의미 없으며, 내용이 길어 고개 하나 넘고 쉬어가라는 의미에서 넘버링 하였음을 알린다. 으음.. 그리고 일부러 중간중간 그림을 많이 넣었는데 읽는데 방해가 될 수 있음을 인지 하시라.
물론, 당연히 관심있는 분들만 읽어주시길.


누구냐..넌!


Image from : http://t3.gstatic.com/images?q=tbn:ANd9GcQp63GW_-iGDkvhIJKN5vpXJpA8VBJ0ulVKi9rZyQ7uoSat2OXj&t=1

1

기존의 전통적인 인프라들은 정말로 많은 요구사항들을 충족해 왔다. 거대했던 메인프레임들은 크레이가 만들어 내는 수퍼컴퓨터의 발전을 가져왔으며, 피씨와 인터넷, 인트라넷의 눈부신 발전은 리눅스의 등장과, 이 리눅스로 만들어내는 기존의 수퍼컴퓨팅의 아성을 뛰어넘는 수퍼컴퓨팅의 또 다른 형태, 클러스터링을 발전시켜왔다.

돈없어서_이러는거_아님.jpg


Image from : http://www.clustercompute.com/images/image4.jpg


10년전, 이제 막 Jazz 나 당대 최고의 그래픽 카드인 Matrox 제품군들을 뒤로하고 3D 그래픽 카드들이 보급되기 시작했다. 이들은 게임의 발전과 함께 피씨 시장에서 늘 주요한 구성품목으로 자리잡아 왔으며, 기존의 해상도와 색 표현력을 위시한 2D의 세상을 넘어 화려하고 아름다운 3D 세상을 열게된다. 퀘이크, 언리얼 등의 인기있는 3D 기반 게임의 엔진들이 게임시장의 중요한 위치를 선점하게 되었고, 이러한 게임 및 게임에 사용되는 3D 영상의 제작을 위해 사용되는 쿼드로같은 그래픽카드들은 디자이너가 사용하는 워크스테이션에 붙어 엄청난 프리미엄의 가격과 함께 날개돋친듯 팔려나갔다. 이제는 그저 보급형 PC의 메인보드에 붙어있는 그래픽 칩셋조차 3D 가속을 처리하는 별도의 GPU를 가지고 있으며, 보다 나은 영상의 게임을 즐기고자 하는 게이머들에 의해 GPU를 중심으로한 그래픽 카드 산업은 어마어마하게 발전하여 현재에 이르렀다.

아아... 그시절의 클라우드 ㅠㅠ

Image From : http://premium.uploadit.org/dem2001/ff7epsxe01.JPG
(당시 3D 그래픽 카드가 없으면 분당 5프레임의 지옥을 경험해야 했다. 사진은 10여년 전의 Final Fantasy VII)

5년전 즈음 분자화학식의 계산을 위한 컴퓨팅에 GPU를 사용하는 라이브러리를 만들어 보자는, 당시로서는 세계적으로도 그다지 발전하지 못한 부분에 관심을 두었던 자그마한 회사의 제의가 있었다. 결국 지금 그 회사는 없지만, 그 당시의 아이디어는 이제 현실이되어 우리들이 쉽게 접하지는 못하는 분야에 널리 깔려있다. GPU가 CPU보다 부동소수점 연산이 뛰어나다는 사실은 굳이 여기서 언급하지 않더라도 많이들 알고 계시리라 믿는다.

한때 프로세서의 FPU (Floating Pint Unit, 부동소수점 처리장치)의 성능이 중요했던 시기가 있다. 아마도 펜티엄 프로, MMX 등의 인텔 기반 CPU 가 등장하던 시기였던 듯 한데, 이 제품들은 부동소수점 연산의 처리능력을 MIPs 수치와 함께 병렬 프로세싱이 가능한 형태의 SIMD 와 패키징하여 프로세서를 홍보하던 시절이 있다. 지금의 멀티 코어 시대에서는 사실 별 것 아닌것 같아 보이지만, 9년 전만 하더라도 이러한 프로세서를 2개 이상 박을 수 있는 메인보드와 걸출한 성능의 GPU를 가진 그래픽 카드, 4기가 정도의 램을 가진 워크스테이션은 모든 그래픽 하는 사람들, 또는 서버에 관심있었던 사람들에게 꿈의 머신이었다.(당시에는 64비트가 범용적이지 않았다) 조금 더 하자면 SCSI 를 사용하여 I/O 프로세싱을 CPU를 사용하지 않도록 하는 부분까지 추가하게 된다면, 당시의 물가에도 돈 500은 수월하게 깨졌으니까.

지난 시절을 회상하고자 이렇게 길게 서두를 뽑은건 아니다. 이제는 컴퓨팅 클라우드 이야기를 해 보자.



2

컴퓨팅 클라우드, 즉, 일반 서버의 기능을 클라우드에서 누려보자 하는 서버 인프라 그 자체를 클라우드로 제공하는 개념의 컴퓨팅 클라우드는, 사실 그 사용의 범위가 일반적인 웹 서비스를 사용하기 위한 용도 이상으로서 활용하기에는 쉽지 않다. 물론 현대의 거의 모든 고객 요구사항은 웹을 통해 이루어지고, 기존 웹의 3계층 구조(3계층 아니라고 따지지 말자. 잘 알지만 주제가 아니다.)를 어떻게 클라우드에 잘 반영하고 마이그레이션 해 내느냐에 따라 클라우드의 비용에 대한 효율성, 신축성이 이야기 될 수 있을 것이다. 이에 맞는 웹 어플리케이션의 설계도 중요한 과제지만, 이러한 내용은 이 포스팅의 주제는 아니다.

이러한 일반적인 컴퓨팅 클라우드를 HPC의 사용에 도입하려는 시도가 일부 있다. High Performance Computing 이라 불리는 이 수퍼컴퓨팅의 한 분야는, 사실 R&D를 하고자 하는 기반 기술을 가진 어떠한 기업이라도 관심이 있을법한 중요한 하나의 카테고리이다. 이 부분은 모든 산업의 기반이 되는 산업들에서 더욱 중요하게 취급된다. 예를 들면, 지금 손에 들고있을 일회용 재생 플라스틱 커피용기라던가, 지금 보고있는 모니터의 각 플라스틱 부품의 성분들, 또는 여러분의 몸이 지니고 있는 DNA등과 관계된 모든 산업의 기반 기술인 화학, 생물학, 유체역학, 이론물리학, 공기역학 더하여 양자역학등 모든 기초과학의 분야에 아주 필요한 기술이 IT에 들어오면 이러한 HPC 라는 분야가 되는것이다. 대다수는 이런 기술과 상관없다고 생각하겠지만, 타이어를 만드는 회사는 타이어의 원료인 고무를 어디서 구매한 어떤 재료와 어떻게 연소시켜 얼마만큼의 효율로 타이어를 생산해 낼 수 있는지는 매우 중요한 문제이다.  또는, 정유회사에서 어느 지역의 원유를 가져다가 어떻게 정제하여 어떤 비율로 고급유, 무연휘발유, 경유, 백등유 등을 얻어낼 수 있는지 역시 생산가와 소비자가를 가늠짓는 매우 중요한 요소가 된다. 물론, 이러한 가격들은 여러분이 실제로 비용을 지불하는데 아주많이 직접적인 영향을 끼치게 된다. 

요딴거의 계산에 쓰인다는 말

Image from : http://www.photon.t.u-tokyo.ac.jp/~maruyama/kikan2002/clustering.gif


문제는 이러한 부분에 필요한 계산들, 분자화학식을 계산해 내는 시스템을 준비하는것은 어마어마한 규모의 자금을 가지고 있는 회사, 또는 연구 단체가 아니면 불가능하다. 아니, 클라우드 컴퓨팅 이전에는 불가능 했다. 실제로 현재 국내의 각 대학들 중에서는 이러한 시스템들을 "베오울프" 프로젝트 이상으로 구비하고 있는 장소는 많지 않을 것이며, 일부 보유하고 있더라도 세월의 흐름에따라 그 성능이 현대의 기술이 요구하는 데이터량에 미치지 못할 가능성도 높다. R&D 분야가 언제나 그렇듯이, 항상 많은 돈이 들고 시간에 촉박하며 누가 먼저 깃발을 꼽고 특허를 따 내느냐가 중요한 부분이며, 따라서 이러한 부분의 지원을 위한 HPC 환경의 필요성은 기초과학이 필요한 모든 분야에 매우 중요하게 되는 것이다.

이런 부분에 종사하는 분들의 클라우드에 대한 관심이 높을것 같지만, 사실 나는 반대라고 본다. 이미 이 분야는 병렬 컴퓨팅의 끝이다. 현재 국내의 IT 분야에 종사하는 그 어느 누구보다, 물리엔진을 설계하는 분들을 제외하고는 이미 밥먹고 수학과 물리와 화학만 하시는 분들이 이런 HPC를 사용한 분산 컴퓨팅 환경에 익숙하다. 다량의 노드에 일종의 메타 데이터 형태인 계산식을 넣고 큐에 뿌리면, 배치 시스템은 이를 계산노드, 즉 컴퓨팅 노드에 뿌려서 분산시켜 계산하고 그 결과를 얻어내고, 다시 모아서 데이터베이스 또는 필요한 데이터 형태로 바꾸어 스토리지에 넣는다. 최근의 클라우드 컴퓨팅에 익숙하신 분이라면 잘 알고 있을 Map/Reduce 의 구성은 이미 이 분야에서 오래전 부터 사용해 왔던 기술들인 것이다. 그렇기에, 일반 CPU만을 게스트에 쪼개어 사용하는 형태의 구성은 만약 그 계산이 빡세게 돌아가는 분야라면, 그다지 매력적으로 들리지는 않을 것이다. 하지만, 클라우드가 구현하고 있는 클러스터링의 방식은, HPC의 요구사항과 딱 맞아 떨어지는 것이 사실이며, 여기에 GPGPU와 같은 기능을 부여한 VM이 클라우드에서 제공된다면 이제 이야기는 달라진다.  두둥.



3

상황이 이럴진데, HPC의 요구사항을 반영한 클라우드의 서비스가 생기지 않을리 없다. 이들은 일반 컴퓨팅 클라우드 서비스보다는 그 수요가 낮지만 높은 비용을 과금 할 수 있기 때문에, 전략적으로 시장의 수요를 잘 예측하고 공급한다면 클라우드 서비스 공급자 입장에서는 제품의 다양화를 꾀할 수 있기에 분명 매력적이다. 그리고 연구 개발 기관에서는, 수많은 서버를 직접 구매하는 대신 필요할때 공급자로 부터 컴퓨팅 노드를 "빌려서"사용할 수 있기에 원래 할 수 없었던 것이 "가능" 해 지며, "저렴" 하다고 느끼게 된다. 물론 한국은 그 기초과학의 수요가 낮은 만큼 그 시장이 미국이나 일본만큼 크지는 않을 것이다.  하지만, 그 어느 기업이 이런 R&D 분야에 뒤떨어 지고 싶을까?

많은 기업이 보안상의 이유로 인하여 클라우드를 그들의 환경안에 자체적으로 구축하고 싶어할 수 있다. 일반적인 웹 서비스는 R&D 분야보다 그 보안성이 뛰어나다고 말하긴 힘들다. 분명하진 않겠지만 Shell 과 같은 국제적 원료기업은 이러한 전산화된 부분의 지원에 Aspen 등의 기업이 만들어낸 특수한 소프트웨어와 인재를 사용한다. 수십만 배럴의 원유를 구매하여 제품 생산 비율을 1% 이상이라도 높이려는 기업의 노력은 그 비용면에서 합당하다. 따라서 그들은 그 비용의 규모에 맞는 시스템들을 구비하여 제품의 개발에 사용하며, 그것이 클라우드 기반이던, 아니면 물리적 수퍼컴퓨팅의 클러스터링 환경이건 그에 걸맞는 규모로 경쟁사들과 치열하게 경쟁하고 있음이 분명하다.

Image From: http://www.sodahead.com/living/whats-your-fantasy-gift-this-year/question-1377465/

삼천포로 빠졌다.  따라서, 많은 기업이나 연구기관, 대학등은 아마도 그들의 전산실의 기존 자산 또는 일반적으로 쉽게 구할 수 있는 저렴한 하드웨어 (Commodity Hardware)를 사용하여 이러한 HPC 환경을 만들고 싶을 것이다. 본질적으로 이러한 부분에 굳이 가상화를 사용할 필요는 없지만, 또는 가상화를 써서 굳이 계산 속도를 떨어뜨릴 필요는 없겠지만, 중요한 것은 바로 "서로 다른 분야" 의 합목적성 때문에 가상화를 기반으로 한 일반적 컴퓨팅 클라우드의 모델을 도입하는것이 보다 이익이 될 수 있다는 점이다.

대학을 기준으로 이야기 해 보자. 대학에는 생물학과, 물리학과, 뭐 심지어는 자동차 학과에서의 충돌 계산을 위해서라도 이러한 HPC 환경이 필요하게 된다. 하지만 이 모든 학과를 위해 전산실에 HPC를 각각 구성해 주는 것은 아무래도 비용면에서 아리송 하게 된다. 아마도 행정담당은 "야 그거 그냥 걔네꺼 같이 쓰면 안돼?" 의 카운터 펀치를 날릴 것이 거의 확실하다고 본다. 이러한 환경에, 가상화를 사용한 클라우드의 구조를 가져다가 구성하되, 이 각각의 VM들이 GPU를 통한 연산을 수행할 수 있는 컴퓨팅 노드의 구조를 가진다면 어떨까? 물리학과는 그들이 필요한 기본 배치 시스템과 이런 배치 시스템과의 연동이 구성된 그들만의 소프트웨어/라이브러리를 설치한 이미지를 만들어 두고, 필요할 때 필요한 수량만큼 인스턴스를 생성하여 작업하고 또 계산이 끝난 다음 인스턴스를 삭제해 버린다면, 기존의 고정된 물리적 환경보다는 그 유연성이 높지 않을까?

이 연장선 상에서, 나는 각각의 HPC 의 형태가 요구하는 시스템의 구성이 서로 많이 다르지 않음을 알게 되었다. 드림웍스가 쿵푸팬더를 만들기 위해 사용했던 렌더 팜이나, MPICH2 라이브러리를 사용하여 계산식을 처리하는 시스템이나, Q-Chem이나 PC_GMESS, Gaussian 을 사용하는 화학식 계산에 필요한 인프라들의 구성은 비용 합리성 측면에서 그 컴퓨팅 노드로 사용될 일반적인 하드웨어의 형태가 크게 다르지 않다. 또한 이들에 필요한 네트워크 인프라의 요구사항도 거의 대동소이 하다. 이러한 시스템에서는 웹의 REST 구조와 같은 특수한 구성은 그다지 의미가 없으며, 전통적인 수퍼컴퓨팅에서 사용되던 잡/큐/배치/매니지먼트 시스템, 그리고 각 연구형태에 맞는 소프트웨어가 설치된 컴퓨팅 노드일 뿐이기 때문이다.

이러한 인프라의 아키텍처가 비슷하다는 점은, 다수의 사용자에게 동일한 물리적 인프라를 통해 가상화로 서비스하게 될 경우 많은 잇점을 가져다 줄 수 있다는 의미가 된다.

여러분이 만약 CUDA를 사용한 무언가를 만들고 있다면, 이러한 효과는 배가 될 것이다.  그런데, 이런 생각을 과연 나만 하는 것일까?  당연히, 아니다.  이런 분야를 노리고, 이러한 환경으로 구성된 클라우드가 이미 실재한다. 다음의 업체들이 바로 그들이다.

  • Amazon
  • NIMBIX
  • peer1 hosting
  • Penguin Computing
궁금하신 분들은 직접 검색해 보면 많은 정보를 얻을 수 있을 것이다. 또는, 다음의 링크를 참조하셔도 좋다.
http://www.nvidia.com/object/gpu-cloud-computing-service.html

링크에서 볼 수 있듯이, 이들은 모두 NVIDA의 Tesla 기술을 사용한다. 이 Tesla 기술이 적용된 하드웨어들은 다음의 링크에서 확인이 가능하다.
http://www.nvidia.com/object/preconfigured-clusters.html



4

단일 노드에서 리눅스를 기반으로 한 Tesla 기술이 반영된 장치를 붙인 물리적 머신을 구성하는 것은 어렵지는 않다. 다만, 이를 "가상화" 하고, 가상화된 VM 안에서 이를 CUDA를 사용하여 장치에 엑세스 하게 하는것은 쉽지 않다. 이는 GPU에 대한 Passthrough를 하이퍼바이저에서 지원해야 하고, GPU에서 SLI Multi-OS 가 가용해야 한다는 조건이 충족되어야 한다. Para Virtualization 형태로의 지원은 아직까지는 힘들어 보이며, Full Virtualization을 사용해여 일부 구현이 가능하다. Citrix Xen 5.6 에서 이를 지원하기는 하지만 실제 내손으로 테스트 해 본적은 아직 없다.

꽤_비싼_워크스테이션.jpg

Image From: http://www.microway.com/images/Octoputer_Tesla1000px.png


Citrix 에서 XenServer 5.6 부터 지원하는 방법은, Multi-GPU 를 가진 일부 GPGPU 장치의 각 GPU를 개별 가상 머신에 1:1 로 할당하는 방식으로서, 가상머신에서 GPU로의 직접적인 접근을 허용한다. 이는 Multi-GPU Passthrough 로서, 일반적인 VT 기술과는 달리 Full Virtualization 을 사용하여 하드웨어 리소스를 가상머신에 직접 할당함을 의미한다. Citrix는 윈도우 게스트에서 HDX 3D Pro 에서 제공하는 코덱을 사용하여야 제대로 사용 할 수 있다고 말하고 있으며, 리눅스 게스트에도 이러한 직접 엑세스는 제공하지만 아직까지 코덱을 별도로 제공하고 있지는 않는다고 설명한다. 현재 가용한 하이퍼바이저가 Citrix Xen이 유일하기 때문에, 아마존이 HPC 클라우드의 구성에 Xen을 사용했다는 말이 심심치 않게 들린다. PCI Passthrough 에 대해 궁금하신 분들은 맨 아래의 링크를 참조하시라. 역시 이런 문서는 IBM이 잘만든다.

아무튼, 이런 환경의 구성을 위해서는 관련 정보의 양과 하드웨어의 선정, 하이퍼바이저의 선정이 매우 중요하다. 물론 이들은 일반적인 클라우드를 구성할때도 중요한 내용이긴 하지만, GPGPU를 사용한 클라우드에서는 이런 요구사항이 충족되지 않으면 자칫 서비스 자체를 구성하지 못하게 될 가능성도 있기 때문에, 또한 아직까지는 범용 기술이 아니기 때문에 매우 주의를 요한다. 대단위의 서버를 구매하기 전에 가용성을 테스트 하기위한 방법에서는, 적어도 2대이상의 머신을 기반으로 시작해야 할 것이다.


가상화가 굳이 필요할지에 대해서는 각 기관이나 단체별로 의문을 제기 할 수 있겠지만, 일반적인 컴퓨팅 클라우드의 사용성을 위해서라도(굳이 HPC로 사용되지 않더라도) 가급적이면 가상화를 구현하는 것이 좋을 수 있다. 다만 Shared Storage를 사용하는 형태를 고집할 필요는 전혀 없으며, 오히려 스크래치를 위한 로컬 디스크가 중요하게 고려 되어야 한다. 이러한 HPC가 요구하는 그야말로 고성능의 조건에 부합하기 위해서는, 가상화를 하더라도 그 가상화의 비율이 일반 컴퓨팅 클라우드 보다는 현저히 낮을 것이라는 점이다. 이는 I/O에 대한 요구사항과 게스트OS가 많아지면 많아질 수록 계산 자체가 느려질 확율이 있기때문에, 게스트 OS가 많아지면 많아질 수록 Full Virtualization 을 사용해야 하는 강제성으로 인해 그 성능의 저하가 심각해 질 것이기 때문이다. 잊지말아야 할 점은, 컴퓨팅 클라우드는 원래 대부분의 시간동안 Idle 상태인 시스템 자원을 가급적이면 높게 사용하도록 분할하자는 취지였지만, HPC의 경우 계산을 하는 대부분의 시간동안 Idle 상태 따위는 없을 것이기 때문이다.  이러한 HPC만의 고사양에 대한 요구가 클라우드에서 어떻게 반영되었는지는 다음의 아마존 HPC 인스턴스 오퍼링에서 확인 할 수 있다.

The Cluster Compute instance family currently contains a single instance type, the Cluster Compute Quadruple Extra Large with the following specifications:

23 GB of memory
33.5 EC2 Compute Units (2 x Intel Xeon X5570, quad-core “Nehalem” architecture)
1690 GB of instance storage
64-bit platform
I/O Performance: Very High (10 Gigabit Ethernet)
API name: cc1.4xlarge

The Cluster GPU instance family currently contains a single instance type, the Cluster GPU Quadruple Extra Large with the following specifications:

22 GB of memory
33.5 EC2 Compute Units (2 x Intel Xeon X5570, quad-core “Nehalem” architecture)
2 x NVIDIA Tesla “Fermi” M2050 GPUs
1690 GB of instance storage
64-bit platform
I/O Performance: Very High (10 Gigabit Ethernet)
API name: cg1.4xlarge

일반적인 하드웨어에서, 48GB 이상의 메모리를 넣는것은 쉽지 않다. 따라서 위와 같은 아마존의 오퍼링을 두고 살짜쿵 추리를 해 보자면, Multi-OS 지원이 가능한 SLI 형태의 GPGPU가 최소한 2개 이상이며, 48기가의 메모리와 10G 이더넷 인터페이스를 가진 하나의 물리적 머신으로 2대 정도의 게스트를 수용한다고 볼 수 있겟다. 그냥 경험에 비추어 볼때 쿼드코어 2개 정도의 프로세서에서 이러한 고성능의 I/O를 지원하기 위해서는, 3개 이상의 게스트를 수용하는 것은 하드웨어 비용과 조합의 측면에서 맞지 않아 보인다. 아무리 GPU가 계산의 많은 부분을 담당하더라도 CPU와 Ram이 노는 건 아니기 때문이다. 아니면, 4개의 GPGPU를 가지고 대당 4개의 게스트 OS를 지원할 가능성도 있기는 하다. 이럴때의 물리 서버 대당 비용은 이미 Commodity HW라고 말하기 어려운 정도의 비용이 된다. 2U 서버를 Full 랙에 한 8칸 비우고 꽉 채운다고 가정하면 대략 17대, 10G 스위치가 24포트 하나에, 랙당 가용한 전력이 보통 미국이니까 100V 15A 정도라면....  아.. 직업병 나왔다. 암튼 뭐, 실제 정확한 구성은 아마존 엔지니어만이 알겠지만, 적절한 가격 선상에서 대략 2U서버하나에 전술한 바와 같은 서버를 적절한 양으로 구성한 것으로 보인다.


아무튼 이러한 점은 Private 클라우드를 구현하려는 기업이나 HPC 클라우드를 공급하는 기업 모두가 신중하게 고민해야 할 부분이기도 하다. HPC는 배치시스템을 통해 서로 다른 계산을 꾸준히 큐에 넣어 지속적으로 돌려줄 때 의미가 있다. 필름회사가 렌더팜을 직접 구성하게 된다면, 이는 자신들의 필름을 위한 렌더링이 끝나게 되면 이 비싼 시스템이 100% 놀아야 하게되는 단점이 있는 것이다. 따라서 지속적인 요구 사항이 있는 경우가 아니면, 이런 방법을 사용하여 직접 시스템을 구축하는것은 대단한 자산의 감소를 불러올 수 있음을 인지해야 한다.


HPC의 특성상, 클라우드의 가상화 개념 대신 자동화를 사용하여 구성 하는것도 가능할 것이다. 마치 필요한 OS를 수분만에 갈아치울 수 있는 노턴의 고스트와 같이, 필요한 때에 대상 머신을 순식간에 필요한 형태로 갈아 치우는 것은 이러한 가상화를 도입 하던지 하지 않던지 중요하다. 가상화를 사용하면 템플릿이나 이미지를 통해 비슷한 기능을 수행 할 수 있을 것이지만 아마도 자동화 도구 없이는 좀 뻑뻑할 것이다. 하지만 이런 자동화 만으로 HPC를 구성해서 고객에게 할당 하는 것은, 아무래도 그 사용성이나 서비스의 관리면에서 기존의 호스팅 환경과 다를바가 없게 된다. 즉, 가상화 없이 이러한 컴퓨팅 환경은 유연성이 떨어진다는 말이 된다.

국내에서 CUDA를 활용한 HPC가 현재 얼마나 필요한지는 모르겠다. 하지만 중요한 것은, 이 HPC가 가지는 기능성이 굳이 GPGPU를 통해서만 고비용을 들여 확인 해 볼 것이 아니라, 여러분이 수행중인 일반적인 계산을 위한 컴퓨팅 환경을 필요한 경우 기존의 컴퓨팅 클라우드에 적용해 시험해 보는것이 반드시 필요할 것이다. 만약 이에 대한 결과가 충분히 합리적인 것이라면, 굳이 이런 시스템을 자사에 구현 하거나, 또는 Private 클라우드에 굳이 Tesla 기술을 도입하여 고비용으로 구축할 필요는 없을 것이다. 아니면, 위의 아마존의 예에서 처럼 HPC만을 위해서라면 게스트 OS의 오케스트레이션에서 물리적 서버당 가상화 서버의 비율을 낮추는 방향으로 요구를 충족시키는 방법도 있을 수 있다. 아무튼 중요한것은, 필요한 소프트웨어의 성능을 KT 클라우드나 아마존 클라우드 인스턴스 또는 구성하고자 하는 Private Cloud에 사용될 컴퓨팅 노드의 가상화를 사용하여 환경을 구성하여 테스트 하는 것이다.


쿵푸팬터2를 예로 들면, 약 56만개의 프로세서가 있어야 1시간 안에 렌더링을 마칠 수 있다고 한다. 사실 이런 규모의 프로세서를 직접 구매한다는건 거의 미친짓에 가깝기 때문에, 렌더링에 필요한 클러스터 환경을 클라우드에 구성하고, 인스턴스를 약 100여개 정도 생성한 후에 샘플 테스트로 나오는 결과값을 추려보면 얼마의 비용이 필요한지, 얼마의 시간이 필요한지에 대한 챠트를 구성해 볼 수 있을 것이다.  이를 실제 물리 머신 또는 Tesla 머신에 적용해 보고 나오는 시간과 비교했을때의 결과가 합리적이라면, 여러분은 동일한 작업을 수행하기 위해 필요한것이 무엇인지 알게 될 것이다.

Time vs Money

Image from: http://www.dollarthug.com/wp-content/uploads/2010/05/time-vs-money.jpg


5

어쨌든, CPU 보다 GPU를 중점적으로 사용하는 컴퓨팅 환경은 엄청난 매력이 아닐 수 없다. 또한 이를 가상화 하여, 클라우드로서의 사용성을 부여하게 된다면 이는 그야말로 대다수의 기업에게는 눈이 번쩍 뜨이는 달콤한 기술이 될 것임에 분명하다. 하지만, 그 사용 목적성을 생각해 보면 아마존과 같은 퍼블릭 클라우드의 형태 보다는, 각 기업에서 스스로 이를 구축하여 사용하고자 하는 요구가 더 높을 것이다. 이러한 요구사항들에 비추어, 반드시 GPGPU를 사용한 클라우드 환경의 구성이 필요하다면, 다음의 내용을 중요하게 고려해야 할 것이다.

  • 사용중인 어플리케이션의 CUDA 지원 여부
  • 하이퍼바이저의 Multi-GPU Passthrough 지원 여부
  • 구매하려는 그래픽 카드의 Multi-OS Enable 여부
  • 사용중인 어플리케이션의 CPU 요구 사항 (일반적으로 1개의 VM에 적어도 1개의 vCPU를 할당해야 할 수 있다)
  • 사용중인 어플리케이션의 Disk I/O 요구사항
  • Infini Band 또는 10G 네트워크
  • 작업 결과물을 저장 할 수 있는 스토리지 요구사항 (사이징, 안전성 기타. )

현재까지로서는, GPU에 대한 Passthrough 를 지원하는 하이퍼바이저는 Xen 밖에 없어보인다.(맥에서 사용하는 패러랠즈도 지원 하는거 같기는 하다.) 하지만 이런 인프라의 구성은 사용중인 어플리케이션에대한 전문가 및 인프라 전문가, 그리고 CUDA 환경에 대해 높은 이해를 가지고 있는 여러 분야 사람들의 협업이 필요할 것이다. "HPC 클라우드 구성용 CD한장 원큐 패키지" 와 같은 오픈소스의 일반 모델로 자리잡아 일반인이 리눅스 깔아보듯이 접근하려면 많은 시간이 필요할 것이다. 이런 부분이 오픈소스의 특징이기도 하지만, 구성하는데 필요한 모든 재료는 이미 주어졌다.

HPC 클라우드는, IaaS 클라우드 서비스의 많은 형태 중 단 한가지 일 뿐이다. 국내에서 이 단계로까지의 서비스를 제공하려는 사업자가 있을지는 모르겠지만, 이는 분명 어디엔가는 필요한 인프라일 것이며, 고객에게 Private HPC 클라우드로서 Farm을 제공하는 형태의 서비스가 가능하다면, 아마도 기존의 많은 연구기관들을 유치 할 수 있지 않을까 하는 생각을 해 본다.


부연적으로 한가지 더 말하자면, 이는 이 글을 쓴 이유이기도 한데, 이러한 접근이 쉬운 환경이 대학생이나 연구원들에게 공개적으로 열리게 되면 아무래도 기존보다는 훨씬 더 좋은 연구 인프라의 확보가 가능하지 않을까 생각해 본다. 사업 하고 싶어도 서버 살 돈이 없었던 사람들에게 컴퓨팅 클라우드가 유용했던 것처럼, 이러한 HPC 클라우드는 많은 기초과학 분야, 그리고 이런 과학을 공부했던 학도들이 나중에 연구소에 뛰어들게 되었을 때, 보다 경쟁력 있는 제품을 만들어 낼 수 있는, 장기적인 기반이 되지 않을까 생각해 본다. 기술이 보다 많은 사람에게 저렴한 가격으로 열려있을 때, 이러한 환경을 바탕으로 발생된 새로운 기술로 인해 모든 사람이 더 잘 살수 있는, 또 누군가에게는 성공의 열쇠가 되는 기회가 제공 될 수 있지 않을까.

Nella Fantasia

Image from: http://postfiles7.naver.net/20100727_102/sweetgirl28_1280227194717lvcaW_gif/%EB%AA%85%EA%B3%A1_%EB%84%AC%EB%9D%BC%ED%8C%90%ED%83%80%EC%A7%80%EC%95%84_nella_fantasia__sweetgirl28.gif?type=w2


PCI Passthrough 에 대한 내용
http://www.ibm.com/developerworks/linux/library/l-pci-passthrough/

Citrix 5.6 Multi-GPU Passthrough feature
http://support.citrix.com/article/CTX125574

NCSA Tesla Linux Cluster
http://www.ncsa.illinois.edu/UserInfo/Resources/Hardware/Intel64TeslaCluster/

TESLA
http://www.nvidia.com/object/preconfigured-clusters.html

클러스터를 사용한 수퍼컴퓨팅 디자인 - 뉴 멕시코 컴퓨팅 센터
http://nmcac.net/encanto.html

쿵푸팬더와 HPC, PDF 문서
http://science.energy.gov/~/media/ascr/pdf/benefits/Hpc_dreamworks_072809_a.pdf

렌더팜을 만드는 방법, Tom's Hardware
http://www.tomshardware.com/reviews/render-farm-node,2340.html

Amazon HPC Cloud & Case Study
http://aws.amazon.com/ec2/hpc-applications/
NASA JPL(Jet Propulsion Lab)
http://aws.amazon.com/solutions/case-studies/nasa-jpl/
Harvard Medical School
http://aws.amazon.com/solutions/case-studies/harvard/





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