( younjin.jeong@gmail.com , 정윤진)
들어가기에 앞서, 각 1, 2 와 같은 내용의 구분은 별 의미 없으며, 내용이 길어 고개 하나 넘고 쉬어가라는 의미에서 넘버링 하였음을 알린다. 으음.. 그리고 일부러 중간중간 그림을 많이 넣었는데 읽는데 방해가 될 수 있음을 인지 하시라.
물론, 당연히 관심있는 분들만 읽어주시길.
10년전, 이제 막 Jazz 나 당대 최고의 그래픽 카드인 Matrox 제품군들을 뒤로하고 3D 그래픽 카드들이 보급되기 시작했다. 이들은 게임의 발전과 함께 피씨 시장에서 늘 주요한 구성품목으로 자리잡아 왔으며, 기존의 해상도와 색 표현력을 위시한 2D의 세상을 넘어 화려하고 아름다운 3D 세상을 열게된다. 퀘이크, 언리얼 등의 인기있는 3D 기반 게임의 엔진들이 게임시장의 중요한 위치를 선점하게 되었고, 이러한 게임 및 게임에 사용되는 3D 영상의 제작을 위해 사용되는 쿼드로같은 그래픽카드들은 디자이너가 사용하는 워크스테이션에 붙어 엄청난 프리미엄의 가격과 함께 날개돋친듯 팔려나갔다. 이제는 그저 보급형 PC의 메인보드에 붙어있는 그래픽 칩셋조차 3D 가속을 처리하는 별도의 GPU를 가지고 있으며, 보다 나은 영상의 게임을 즐기고자 하는 게이머들에 의해 GPU를 중심으로한 그래픽 카드 산업은 어마어마하게 발전하여 현재에 이르렀다.
5년전 즈음 분자화학식의 계산을 위한 컴퓨팅에 GPU를 사용하는 라이브러리를 만들어 보자는, 당시로서는 세계적으로도 그다지 발전하지 못한 부분에 관심을 두었던 자그마한 회사의 제의가 있었다. 결국 지금 그 회사는 없지만, 그 당시의 아이디어는 이제 현실이되어 우리들이 쉽게 접하지는 못하는 분야에 널리 깔려있다. GPU가 CPU보다 부동소수점 연산이 뛰어나다는 사실은 굳이 여기서 언급하지 않더라도 많이들 알고 계시리라 믿는다.
한때 프로세서의 FPU (Floating Pint Unit, 부동소수점 처리장치)의 성능이 중요했던 시기가 있다. 아마도 펜티엄 프로, MMX 등의 인텔 기반 CPU 가 등장하던 시기였던 듯 한데, 이 제품들은 부동소수점 연산의 처리능력을 MIPs 수치와 함께 병렬 프로세싱이 가능한 형태의 SIMD 와 패키징하여 프로세서를 홍보하던 시절이 있다. 지금의 멀티 코어 시대에서는 사실 별 것 아닌것 같아 보이지만, 9년 전만 하더라도 이러한 프로세서를 2개 이상 박을 수 있는 메인보드와 걸출한 성능의 GPU를 가진 그래픽 카드, 4기가 정도의 램을 가진 워크스테이션은 모든 그래픽 하는 사람들, 또는 서버에 관심있었던 사람들에게 꿈의 머신이었다.(당시에는 64비트가 범용적이지 않았다) 조금 더 하자면 SCSI 를 사용하여 I/O 프로세싱을 CPU를 사용하지 않도록 하는 부분까지 추가하게 된다면, 당시의 물가에도 돈 500은 수월하게 깨졌으니까.
지난 시절을 회상하고자 이렇게 길게 서두를 뽑은건 아니다. 이제는 컴퓨팅 클라우드 이야기를 해 보자.
컴퓨팅 클라우드, 즉, 일반 서버의 기능을 클라우드에서 누려보자 하는 서버 인프라 그 자체를 클라우드로 제공하는 개념의 컴퓨팅 클라우드는, 사실 그 사용의 범위가 일반적인 웹 서비스를 사용하기 위한 용도 이상으로서 활용하기에는 쉽지 않다. 물론 현대의 거의 모든 고객 요구사항은 웹을 통해 이루어지고, 기존 웹의 3계층 구조(3계층 아니라고 따지지 말자. 잘 알지만 주제가 아니다.)를 어떻게 클라우드에 잘 반영하고 마이그레이션 해 내느냐에 따라 클라우드의 비용에 대한 효율성, 신축성이 이야기 될 수 있을 것이다. 이에 맞는 웹 어플리케이션의 설계도 중요한 과제지만, 이러한 내용은 이 포스팅의 주제는 아니다.
이러한 일반적인 컴퓨팅 클라우드를 HPC의 사용에 도입하려는 시도가 일부 있다. High Performance Computing 이라 불리는 이 수퍼컴퓨팅의 한 분야는, 사실 R&D를 하고자 하는 기반 기술을 가진 어떠한 기업이라도 관심이 있을법한 중요한 하나의 카테고리이다. 이 부분은 모든 산업의 기반이 되는 산업들에서 더욱 중요하게 취급된다. 예를 들면, 지금 손에 들고있을 일회용 재생 플라스틱 커피용기라던가, 지금 보고있는 모니터의 각 플라스틱 부품의 성분들, 또는 여러분의 몸이 지니고 있는 DNA등과 관계된 모든 산업의 기반 기술인 화학, 생물학, 유체역학, 이론물리학, 공기역학 더하여 양자역학등 모든 기초과학의 분야에 아주 필요한 기술이 IT에 들어오면 이러한 HPC 라는 분야가 되는것이다. 대다수는 이런 기술과 상관없다고 생각하겠지만, 타이어를 만드는 회사는 타이어의 원료인 고무를 어디서 구매한 어떤 재료와 어떻게 연소시켜 얼마만큼의 효율로 타이어를 생산해 낼 수 있는지는 매우 중요한 문제이다. 또는, 정유회사에서 어느 지역의 원유를 가져다가 어떻게 정제하여 어떤 비율로 고급유, 무연휘발유, 경유, 백등유 등을 얻어낼 수 있는지 역시 생산가와 소비자가를 가늠짓는 매우 중요한 요소가 된다. 물론, 이러한 가격들은 여러분이 실제로 비용을 지불하는데 아주많이 직접적인 영향을 끼치게 된다.
문제는 이러한 부분에 필요한 계산들, 분자화학식을 계산해 내는 시스템을 준비하는것은 어마어마한 규모의 자금을 가지고 있는 회사, 또는 연구 단체가 아니면 불가능하다. 아니, 클라우드 컴퓨팅 이전에는 불가능 했다. 실제로 현재 국내의 각 대학들 중에서는 이러한 시스템들을 "베오울프" 프로젝트 이상으로 구비하고 있는 장소는 많지 않을 것이며, 일부 보유하고 있더라도 세월의 흐름에따라 그 성능이 현대의 기술이 요구하는 데이터량에 미치지 못할 가능성도 높다. R&D 분야가 언제나 그렇듯이, 항상 많은 돈이 들고 시간에 촉박하며 누가 먼저 깃발을 꼽고 특허를 따 내느냐가 중요한 부분이며, 따라서 이러한 부분의 지원을 위한 HPC 환경의 필요성은 기초과학이 필요한 모든 분야에 매우 중요하게 되는 것이다.
이런 부분에 종사하는 분들의 클라우드에 대한 관심이 높을것 같지만, 사실 나는 반대라고 본다. 이미 이 분야는 병렬 컴퓨팅의 끝이다. 현재 국내의 IT 분야에 종사하는 그 어느 누구보다, 물리엔진을 설계하는 분들을 제외하고는 이미 밥먹고 수학과 물리와 화학만 하시는 분들이 이런 HPC를 사용한 분산 컴퓨팅 환경에 익숙하다. 다량의 노드에 일종의 메타 데이터 형태인 계산식을 넣고 큐에 뿌리면, 배치 시스템은 이를 계산노드, 즉 컴퓨팅 노드에 뿌려서 분산시켜 계산하고 그 결과를 얻어내고, 다시 모아서 데이터베이스 또는 필요한 데이터 형태로 바꾸어 스토리지에 넣는다. 최근의 클라우드 컴퓨팅에 익숙하신 분이라면 잘 알고 있을 Map/Reduce 의 구성은 이미 이 분야에서 오래전 부터 사용해 왔던 기술들인 것이다. 그렇기에, 일반 CPU만을 게스트에 쪼개어 사용하는 형태의 구성은 만약 그 계산이 빡세게 돌아가는 분야라면, 그다지 매력적으로 들리지는 않을 것이다. 하지만, 클라우드가 구현하고 있는 클러스터링의 방식은, HPC의 요구사항과 딱 맞아 떨어지는 것이 사실이며, 여기에 GPGPU와 같은 기능을 부여한 VM이 클라우드에서 제공된다면 이제 이야기는 달라진다. 두둥.
상황이 이럴진데, HPC의 요구사항을 반영한 클라우드의 서비스가 생기지 않을리 없다. 이들은 일반 컴퓨팅 클라우드 서비스보다는 그 수요가 낮지만 높은 비용을 과금 할 수 있기 때문에, 전략적으로 시장의 수요를 잘 예측하고 공급한다면 클라우드 서비스 공급자 입장에서는 제품의 다양화를 꾀할 수 있기에 분명 매력적이다. 그리고 연구 개발 기관에서는, 수많은 서버를 직접 구매하는 대신 필요할때 공급자로 부터 컴퓨팅 노드를 "빌려서"사용할 수 있기에 원래 할 수 없었던 것이 "가능" 해 지며, "저렴" 하다고 느끼게 된다. 물론 한국은 그 기초과학의 수요가 낮은 만큼 그 시장이 미국이나 일본만큼 크지는 않을 것이다. 하지만, 그 어느 기업이 이런 R&D 분야에 뒤떨어 지고 싶을까?
많은 기업이 보안상의 이유로 인하여 클라우드를 그들의 환경안에 자체적으로 구축하고 싶어할 수 있다. 일반적인 웹 서비스는 R&D 분야보다 그 보안성이 뛰어나다고 말하긴 힘들다. 분명하진 않겠지만 Shell 과 같은 국제적 원료기업은 이러한 전산화된 부분의 지원에 Aspen 등의 기업이 만들어낸 특수한 소프트웨어와 인재를 사용한다. 수십만 배럴의 원유를 구매하여 제품 생산 비율을 1% 이상이라도 높이려는 기업의 노력은 그 비용면에서 합당하다. 따라서 그들은 그 비용의 규모에 맞는 시스템들을 구비하여 제품의 개발에 사용하며, 그것이 클라우드 기반이던, 아니면 물리적 수퍼컴퓨팅의 클러스터링 환경이건 그에 걸맞는 규모로 경쟁사들과 치열하게 경쟁하고 있음이 분명하다.
삼천포로 빠졌다. 따라서, 많은 기업이나 연구기관, 대학등은 아마도 그들의 전산실의 기존 자산 또는 일반적으로 쉽게 구할 수 있는 저렴한 하드웨어 (Commodity Hardware)를 사용하여 이러한 HPC 환경을 만들고 싶을 것이다. 본질적으로 이러한 부분에 굳이 가상화를 사용할 필요는 없지만, 또는 가상화를 써서 굳이 계산 속도를 떨어뜨릴 필요는 없겠지만, 중요한 것은 바로 "서로 다른 분야" 의 합목적성 때문에 가상화를 기반으로 한 일반적 컴퓨팅 클라우드의 모델을 도입하는것이 보다 이익이 될 수 있다는 점이다.
대학을 기준으로 이야기 해 보자. 대학에는 생물학과, 물리학과, 뭐 심지어는 자동차 학과에서의 충돌 계산을 위해서라도 이러한 HPC 환경이 필요하게 된다. 하지만 이 모든 학과를 위해 전산실에 HPC를 각각 구성해 주는 것은 아무래도 비용면에서 아리송 하게 된다. 아마도 행정담당은 "야 그거 그냥 걔네꺼 같이 쓰면 안돼?" 의 카운터 펀치를 날릴 것이 거의 확실하다고 본다. 이러한 환경에, 가상화를 사용한 클라우드의 구조를 가져다가 구성하되, 이 각각의 VM들이 GPU를 통한 연산을 수행할 수 있는 컴퓨팅 노드의 구조를 가진다면 어떨까? 물리학과는 그들이 필요한 기본 배치 시스템과 이런 배치 시스템과의 연동이 구성된 그들만의 소프트웨어/라이브러리를 설치한 이미지를 만들어 두고, 필요할 때 필요한 수량만큼 인스턴스를 생성하여 작업하고 또 계산이 끝난 다음 인스턴스를 삭제해 버린다면, 기존의 고정된 물리적 환경보다는 그 유연성이 높지 않을까?
이 연장선 상에서, 나는 각각의 HPC 의 형태가 요구하는 시스템의 구성이 서로 많이 다르지 않음을 알게 되었다. 드림웍스가 쿵푸팬더를 만들기 위해 사용했던 렌더 팜이나, MPICH2 라이브러리를 사용하여 계산식을 처리하는 시스템이나, Q-Chem이나 PC_GMESS, Gaussian 을 사용하는 화학식 계산에 필요한 인프라들의 구성은 비용 합리성 측면에서 그 컴퓨팅 노드로 사용될 일반적인 하드웨어의 형태가 크게 다르지 않다. 또한 이들에 필요한 네트워크 인프라의 요구사항도 거의 대동소이 하다. 이러한 시스템에서는 웹의 REST 구조와 같은 특수한 구성은 그다지 의미가 없으며, 전통적인 수퍼컴퓨팅에서 사용되던 잡/큐/배치/매니지먼트 시스템, 그리고 각 연구형태에 맞는 소프트웨어가 설치된 컴퓨팅 노드일 뿐이기 때문이다.
이러한 인프라의 아키텍처가 비슷하다는 점은, 다수의 사용자에게 동일한 물리적 인프라를 통해 가상화로 서비스하게 될 경우 많은 잇점을 가져다 줄 수 있다는 의미가 된다.
여러분이 만약 CUDA를 사용한 무언가를 만들고 있다면, 이러한 효과는 배가 될 것이다. 그런데, 이런 생각을 과연 나만 하는 것일까? 당연히, 아니다. 이런 분야를 노리고, 이러한 환경으로 구성된 클라우드가 이미 실재한다. 다음의 업체들이 바로 그들이다.
http://www.nvidia.com/object/gpu-cloud-computing-service.html
링크에서 볼 수 있듯이, 이들은 모두 NVIDA의 Tesla 기술을 사용한다. 이 Tesla 기술이 적용된 하드웨어들은 다음의 링크에서 확인이 가능하다.
http://www.nvidia.com/object/preconfigured-clusters.html
단일 노드에서 리눅스를 기반으로 한 Tesla 기술이 반영된 장치를 붙인 물리적 머신을 구성하는 것은 어렵지는 않다. 다만, 이를 "가상화" 하고, 가상화된 VM 안에서 이를 CUDA를 사용하여 장치에 엑세스 하게 하는것은 쉽지 않다. 이는 GPU에 대한 Passthrough를 하이퍼바이저에서 지원해야 하고, GPU에서 SLI Multi-OS 가 가용해야 한다는 조건이 충족되어야 한다. Para Virtualization 형태로의 지원은 아직까지는 힘들어 보이며, Full Virtualization을 사용해여 일부 구현이 가능하다. Citrix Xen 5.6 에서 이를 지원하기는 하지만 실제 내손으로 테스트 해 본적은 아직 없다.
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 머신에 적용해 보고 나오는 시간과 비교했을때의 결과가 합리적이라면, 여러분은 동일한 작업을 수행하기 위해 필요한것이 무엇인지 알게 될 것이다.
어쨌든, CPU 보다 GPU를 중점적으로 사용하는 컴퓨팅 환경은 엄청난 매력이 아닐 수 없다. 또한 이를 가상화 하여, 클라우드로서의 사용성을 부여하게 된다면 이는 그야말로 대다수의 기업에게는 눈이 번쩍 뜨이는 달콤한 기술이 될 것임에 분명하다. 하지만, 그 사용 목적성을 생각해 보면 아마존과 같은 퍼블릭 클라우드의 형태 보다는, 각 기업에서 스스로 이를 구축하여 사용하고자 하는 요구가 더 높을 것이다. 이러한 요구사항들에 비추어, 반드시 GPGPU를 사용한 클라우드 환경의 구성이 필요하다면, 다음의 내용을 중요하게 고려해야 할 것이다.
현재까지로서는, GPU에 대한 Passthrough 를 지원하는 하이퍼바이저는 Xen 밖에 없어보인다.(맥에서 사용하는 패러랠즈도 지원 하는거 같기는 하다.) 하지만 이런 인프라의 구성은 사용중인 어플리케이션에대한 전문가 및 인프라 전문가, 그리고 CUDA 환경에 대해 높은 이해를 가지고 있는 여러 분야 사람들의 협업이 필요할 것이다. "HPC 클라우드 구성용 CD한장 원큐 패키지" 와 같은 오픈소스의 일반 모델로 자리잡아 일반인이 리눅스 깔아보듯이 접근하려면 많은 시간이 필요할 것이다. 이런 부분이 오픈소스의 특징이기도 하지만, 구성하는데 필요한 모든 재료는 이미 주어졌다.
HPC 클라우드는, IaaS 클라우드 서비스의 많은 형태 중 단 한가지 일 뿐이다. 국내에서 이 단계로까지의 서비스를 제공하려는 사업자가 있을지는 모르겠지만, 이는 분명 어디엔가는 필요한 인프라일 것이며, 고객에게 Private HPC 클라우드로서 Farm을 제공하는 형태의 서비스가 가능하다면, 아마도 기존의 많은 연구기관들을 유치 할 수 있지 않을까 하는 생각을 해 본다.
부연적으로 한가지 더 말하자면, 이는 이 글을 쓴 이유이기도 한데, 이러한 접근이 쉬운 환경이 대학생이나 연구원들에게 공개적으로 열리게 되면 아무래도 기존보다는 훨씬 더 좋은 연구 인프라의 확보가 가능하지 않을까 생각해 본다. 사업 하고 싶어도 서버 살 돈이 없었던 사람들에게 컴퓨팅 클라우드가 유용했던 것처럼, 이러한 HPC 클라우드는 많은 기초과학 분야, 그리고 이런 과학을 공부했던 학도들이 나중에 연구소에 뛰어들게 되었을 때, 보다 경쟁력 있는 제품을 만들어 낼 수 있는, 장기적인 기반이 되지 않을까 생각해 본다. 기술이 보다 많은 사람에게 저렴한 가격으로 열려있을 때, 이러한 환경을 바탕으로 발생된 새로운 기술로 인해 모든 사람이 더 잘 살수 있는, 또 누군가에게는 성공의 열쇠가 되는 기회가 제공 될 수 있지 않을까.
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, 정윤진)
들어가기에 앞서, 각 1, 2 와 같은 내용의 구분은 별 의미 없으며, 내용이 길어 고개 하나 넘고 쉬어가라는 의미에서 넘버링 하였음을 알린다. 으음.. 그리고 일부러 중간중간 그림을 많이 넣었는데 읽는데 방해가 될 수 있음을 인지 하시라.
물론, 당연히 관심있는 분들만 읽어주시길.
누구냐..넌!
1
기존의 전통적인 인프라들은 정말로 많은 요구사항들을 충족해 왔다. 거대했던 메인프레임들은 크레이가 만들어 내는 수퍼컴퓨터의 발전을 가져왔으며, 피씨와 인터넷, 인트라넷의 눈부신 발전은 리눅스의 등장과, 이 리눅스로 만들어내는 기존의 수퍼컴퓨팅의 아성을 뛰어넘는 수퍼컴퓨팅의 또 다른 형태, 클러스터링을 발전시켜왔다. 돈없어서_이러는거_아님.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 라는 분야가 되는것이다. 대다수는 이런 기술과 상관없다고 생각하겠지만, 타이어를 만드는 회사는 타이어의 원료인 고무를 어디서 구매한 어떤 재료와 어떻게 연소시켜 얼마만큼의 효율로 타이어를 생산해 낼 수 있는지는 매우 중요한 문제이다. 또는, 정유회사에서 어느 지역의 원유를 가져다가 어떻게 정제하여 어떤 비율로 고급유, 무연휘발유, 경유, 백등유 등을 얻어낼 수 있는지 역시 생산가와 소비자가를 가늠짓는 매우 중요한 요소가 된다. 물론, 이러한 가격들은 여러분이 실제로 비용을 지불하는데 아주많이 직접적인 영향을 끼치게 된다.
요딴거의 계산에 쓰인다는 말
문제는 이러한 부분에 필요한 계산들, 분자화학식을 계산해 내는 시스템을 준비하는것은 어마어마한 규모의 자금을 가지고 있는 회사, 또는 연구 단체가 아니면 불가능하다. 아니, 클라우드 컴퓨팅 이전에는 불가능 했다. 실제로 현재 국내의 각 대학들 중에서는 이러한 시스템들을 "베오울프" 프로젝트 이상으로 구비하고 있는 장소는 많지 않을 것이며, 일부 보유하고 있더라도 세월의 흐름에따라 그 성능이 현대의 기술이 요구하는 데이터량에 미치지 못할 가능성도 높다. 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
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
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, 정윤진)