System Compleat.

'클라우드'에 해당되는 글 2건

  1. IaaS
  2. Cloud, HPC, GPU 11

IaaS

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


항상 무언가를 만들기 위해서는 많은 시간이 소요된다. 혼자 만들던, 여럿이 만들던, 회사에서 만들던지간에, 새롭게 무언가를 창조하는 것은 힘든일이다. 그래서 우리는 대부분 '모방'의 방법을 사용하고, '모방'의 대상을 찾아 낸다. 사진을 찍을때는 유명한 작가의 작품에 나온 구도, 노출등을 따라해 보고, 스포츠를 배울때는 유명한 운동선수의 폼을 따라 해 보기도 한다.


모방의_올바른_예_JPG



'창의'와 '모방'은 필시 다른 말일게다. 하지만 대부분의 경우에서 그렇듯, 좋은 '모방'은 종종 새로운 '창의'의 모태가 되기도 한다. 너무나도 당연한 말이지만, 모방을 넘어 창의로 닿는 사람들은 그 창의가 '소용'에 다르지 못해 또 고민한다. 이러한 일련의 피라미드와 같은 구조는 역설적이게도 '소용'에 대한 필요에 의해 '모방'을 촉구하기도 한다. 그것이 바로 한국의 IT 산업, 바로 그것일 게다.

매번 기술의 패러다임이 쉬프팅 하게 될 때 문제가 발생한다. 사람들이 PC를 가지기 시작한 시절에 제일 높은 효용의 가치인 '워드'를 배우기 위해 단축키 표를 놓고 '아래아 한글'을 배워대고, 다시 '인터넷'이 발전하는 시절에는 '스타크래프트'를 즐기기위해 혈안이 된다. 이제 인터넷을 기반으로 기존에 하던 '개인사업' 들이 웹으로 움직이기 시작하면서 부터는, '전자상거래' 나 '인터넷 쇼핑몰' 을 만드는데 정력을 쏟는다. 나아가, 애플이 만들어낸 기계들에서 발생한 '사용자 편의성' 과 '인터넷'의 조합은 어디서나 필요한 모든 정보를 할아버지 할머님도 글자만 읽을 수 있으면, 또 손자 손녀의 친절한 도움만 있다면 사용 할 수 있는 또 한번의 거대한 쉬프팅이 발생하도록 했다.

아저씨도_스마트폰_유저_JPG


"데이터 폭발의 원천"

문제는, 이러한 쉬프팅이나 흐름의 주도권을 잡지 못한다는데 있다. 블로그의 많은 포스팅, 트위터의 많은 글들을 보면 왜 우리나라에는 스티브 잡스 어쩌고 하는 글들이 널려있다. 개중에는 공감이 가는 글도 있고, 아닌 것들도 많다.

각 분야의 전문가가 아니라면, 통상 알기 힘든 영역이 반드시 존재한다. 차에 관심이 많은 사람일 지라도 독일 메이저 3사의 자동차 브랜드가 많은 파츠를 동일한 제품을 사용하는 것은 모르는 사람도 많다. 또한, 이러한 파츠들을 국산 브랜드가 어떤 부분에서는 수입해서 그대로 적용하는 것도 흔한 일이다. 그런데, 동일한 파츠를 사용한다고 해서 매번 동일한 '소용'이나 '효용' 또는 나아가 '품질'이 발생하는 것이 아닌가 보다. 만약 그렇다면 독일 메이저 3사나 국내의 차량 브랜드들이 서로 가격차이와 주행 품질에 차이가 있을리가 만무하지 않겠는가.


이런 애들 다 부품은.... 

BOSCH SPARK PLUG / AUDI / FIAT & ETC..

 

이러한 일반인들의 눈에 보이지 않는것, 다른 분야의 저변에는 어떠한 것이 깔려있는지 모르겠지만, 앞서 말했던 IT의 쉬프팅에서는 매번 '인프라스트럭쳐'의 변화가 있어왔다. 인프라라는 것이 일견 제품을 찍어낼 수 있는, 또는 서비스를 구성하는 '저변의 무언가' 로 통하기는 하지만, 나는 여기에 '시대적 환경'을 함께 언급하고 싶다. 이 시대적 환경에서 발생하는 기술의 변화는, '저변의 무언가'를 필연적으로 변화 시키는 힘이 되기 때문이다. 

IaaS 라면 이미 전산 바닥에 계신 분들은 귀에 딱지가 앉을 정도로 많이 들어보셨을 약어이다. Infrastructure as a Service, 전산의 인프라를 서비스로서 제공하는 이 개념은, 엄밀하게 이야기하면 예전부터 있어왔던 개념이다. 여러분은 인터넷 쇼핑몰을 만들고 싶은 경우 그저 호스팅 업체 또는 관련 사업을 제공하는 업체에 가입을 하고, 비용을 지불하여 쇼핑몰의 프레임을 만들고, 거기에 판매가 가능한 컨텐츠를 올릴 수 있으며, 카드 결재 연동을 위한 인프라를 서비스로서 제공받아 왔다. 제공 받아서 장사를 해 보다가, 만약 잘 안되서 접어야 하면 서비스 사용을 중지 신청 하면 되는 것이다. 이러한 용도로 사용되는 서비스의 내부 구조는 이를테면 잘 짜여진 IaaS, 또는 조금 더 발전적으로 생각한다면 PaaS, 즉 Platform as a Service 였다고도 할 수 있을테다. 쇼핑몰이나 웹을 그대로 서비스로 제공 했으니 말이다. 

출처 : IBM Site

이게 요즘 들어와 귀에 딱지가 앉도록 들리는 이유는 이 블로그에서도 수차례 언급한 적이 있는 클라우드 때문이다. 인터넷 기반 서비스의 기본 이라고 하면, 바로 서버와 스토리지, 그리고 인터넷에 연결될 수 있는 네트워킹, 바로 이 세가지를 서비스로서 제공하는 것을 클라우드에서 IaaS 라고 부른다. 이것이 IaaS 로 불리우듯, 새로운 기반 기술은, 모든이가 IT서비스를 통해 삶의 질을 높이는 시대의 요구가 빛어낸 데이터 폭발로 인해 모든 사업자에게 필요할 가능성이 높은 것이 되어버렸다. 이를테면, 할머니 할아버지가 페이스북에 송아지 사진, 두살바기 애엄마의 아이 사진과 걸음마 동영상, 고딩이 미팅때 찍은 퀸카의 얼굴등 기존의 Feature Phone에서는 그저 개인 전화기의 사진 폴더나 아는 사람간의 컨텐츠 전송등을 통해 극히 일부 공유되던 것들이, 이제는 서비스 레벨에서 공유가 되고 있기 때문이다. 

사진_위치_공유_JPG



이러한 공유를 처리하기 위해 이전과는 다른 형태의 인프라가 필요하게 되었고, 해외에서 촉발된 인프라의 변형은 그 사용성이 검증되어 국내에서도 다루지 않으면 안되는 상황이 되어버린 것이다. 

문제는, 전술 했듯이 우리가 시대의 흐름이나 또는 데이터의 소용에 대한 필요충분 조건을 먼저 만들어 내지 못했으므로, 이러한 인프라 기술의 이동에 대해서도 무지한 경우가 많다는 것이다. 오히려, 사업을 검토하고 그 필요를 먼저 깨닫는 것은 회사의 고위 임원이고, 하위의 엔지니어들이 그게 뭐에요 하고 되묻는 현상조차 발생하는 웃지못할 사태가 발생하게 된다는 것이다. 하지만 뭐, 이런 상황은 기술이 고착되면 또다시 순환되기 때문에, 큰 문제라고 생각하지는 않는다. 다만, 지금의 문제는 이러한 변화가 해외에서는 오랜기간 누적된 기술을 바탕으로 이루어지는데, 국내에서는 이 누적된 기술을 보유하고 있는 기술자가 드물어 '내재화'에 매우 어려움을 겪고 있다는 사실이다. 

우리나라에서 최근 벤처로서 성공하여 화두가 된 기업은 '카카오톡' 말고는 들어 본 바가 없다. 하지만 미국은 어떤가. '페이스북', '플리커', '티켓몬스터', 심지어 '애플' 등 그들의 벤처 순환고리는 도대체 실리콘 밸리 내에서 끊임이 없다. 물론 그들 중 대부분이 없어지고, 또 생겨나고, 다시 투자 받고 하지만, 우리나라는 정말로 그런 예가 별로 없다. 대부분 대기업과 공생관계, 또는 해외 본사의 파트너 뿐이다. 물론, 내가 지적하고 싶은건 이러한 기업 인프라가 아니라, '기존의 것'에 유착하여 '기존의 기술'을 판매해 왔기 때문에, 스스로 새로이 무언가를 만들다 실패할 때 발생하는 '저렴한 원가를 통한 서비스의 개발'이 별로 이루어 지지 않고 있다는 점이다. 



국내의 많은 대기업은 IaaS 를 만들고 싶어 한다. 이미 각 텔코에서는 구현에 성공한 기업도, 또 한번 구현 했다가 말아먹은 기업도, 이제 슬슬 시작하려고 하는 기업도 있다. 문제는, '저렴한 원가를 통한 서비스의 개발' 의 다른말인 '오픈소스를 통핸 서비스의 개발' 을 충분히 숙련자라 할 만큼 다루어 본 기술자가 부족하기 때문에, 이 새로운 해외 기술의 내재화에 시간이 걸리고 있다는 것이다. 더 나아가, 이 새로운 기술에 국내 벤더는 이름조차 올릴 곳이 없다. 나름 핵심적인 '가상화' 부분은 더 절망적이다. 뭐 그 문제는 해외에서는 사장되려는 PC용 OS 만들다 말아먹은 모 회사에 망쪼가 들던 시점에 이미 SaaS의 개념이 발생했던 것을 뼈아픈 예로 치고 고만하자. 

아무튼, 현재의 관계자들은 대부분 이런말을 한다. '그거 오픈소스 배우는데 얼마나 걸린다고. 이미 다 공개 되어 있으니 시간을 조금만 들이면 누구나 할 수 있는거 아닙니까.' 맞다. 맞는 말이다. 그런데 나는 이렇게 이야기 하고 싶다. 그 조금만 들이면 누구나 할 수 있는 시간을, 누구는 십수년 전 부터 베타 테스터로 참여하고, 버그를 레포트하고, 코드를 푸쉬하는 형태로 살아온 '성당과 시장' 의 시장의 사람들은 없지 않냐 라고. 전체 바닥을 통틀어 오픈소스 커뮤니티에 하나라도 가입하여 테스트나 버그 레포트를 해 본 경험이 있는 사람들, 생각보다 없다. 금방 배우고 설치해서 사용은 할 수 있겠지만, 문제가 발생하면 구글도 아니고 네이버에서 찾는 사람들이 '배워서' IaaS 를 구현할 꺼에요라고 말한다면 나는 '시간이 오래 걸릴거에요' 라고 말해줄 테다. 

예를 들어, '부트스트래핑' 에는 여러가지 방법이 있다. 베어메탈 박스가 주어졌을때, 또 매번 동일한 박스를 세팅한다고 했을때, 가장 간단한 방법은 이미지의 사용이다. 두번째가 복합적인 코드 레포지트리를 사용한 패키지 인스톨 정도가 될 수 있겠고, 세번째로는 이렇게 설치된 박스의 업데이트 지원에 대한 방법까지 고려한 내용이 있을 수 있다. 이러한 조촐한 세단계 조차 구현의 경험이 없거나 심지어 사용해 본 경험도 없다면 당장 머리에 그 구조가 떠오를리 만무하지 않을텐가. 

이아저씨가_떠오른다면_안습_JPG



한가지 더 재미있는 사실은, 바로 국내에서는 그다지 데이터 폭발이 많이 발생하지 않기 때문에 IaaS를 만들어 두었지만 잘 팔리지 않는다는 사실이다. 아니, 엄밀하게 말하면 '네트워크 인프라에 대한' 폭발은 발생 했으나, 모바일 기반 클라우드 서비스는 국내에 별로 없기 때문에 IaaS 가 인기가 없다는 사실이다. 이는, 아마존을 근간으로 많은 서비스를 내어 놓고있는 수많은 미국의 벤처들과는 달리, 국내에는 벤처 자체가 이미 별로 없기 때문에 IaaS 가 인기가 별로 없다. 그저 대학과 일부 업계의 관심있는 사람들이 이용할 뿐이다. 때문에 텔코들은 기존의 기업들을 자신의 IaaS로 끌어들이려 한다. 하지만 기존 기업의 관리자들은 이러한 새로운 환경이 전술했던 이유로 인해 어색하기만 할 뿐이고, 위에서는 비용 문제로 검토해 보라 하지만 도무지 기존의 상식으로는 긍정적인 대답이 나오지가 않는다. 그래서 IaaS를 구현한 업체들은, 대부분의 장비를 놀린다. 글쎄, 이러한 부분이 실제로 악순환이 될 지, 아니면 언젠가는 새로운 환경에 익숙해 져서 사용에 거리낌이 없어질 지는 잘 모르겠지만, 어쨌든 분명한건 있어도 잘 못쓴다는 것이다. 만들지도 못하고, 만들어 줘도 잘 쓰지 못한다. 그런데 준비도 안된 사람들이 만들겠다 하는 경우는 많다. 

어머나_터져버렸네_JPG



우리나라에서 Flickr 같은 서비스를 만들면 투자 받고 성공 할 수 있을까? 또는, Vimeo 같은 서비스를 만들면 어딘가에서 인수 해 줄까? 또는, 앞으로 등장할 새로운 무언가를 클라우드 기반의 서비스로 만들면, 투자를 받아서 사업을 키우거나 또는 동일한 사업을 하는 보다 큰 기업에 인수 합병 될 수 있을까? 모든 대답이 부정적이다. 작은 기업에서 만들면 큰 기업에서는 내부에 얼른 똑같은거 만들어라 지시하고, 자본력으로 '소녀시대'와 같은 모델을 앞세워 홍보해서 자사의 서비스를 만들 뿐이다. '페이스북' 의 영화에서 주커버그 처럼 남의 아이디어를 가지고 서비스를 만들었다면, 성공한 이후에 법정 싸움에서 정당한 비용을 뱉어낼 수 있어야 한다. 글쎄, '올레 톡'이나 '마이피플'이 '카카오톡' 에 비용을 과연 지불 할까? 하긴, '카카오톡' 조차 핵심 아이디어를 어딘가에서 가져오지 않았다는 부분에서는 자유로울 수 없으니 그저 서로들 쉬쉬 하면 되는 것일까. 



아무튼, 이 모든 이유로 인해 IaaS는 만들기도 쉽지 않거니와, 또 만들었을때 사용할 고객도 별로 없다. 다만, 대기업의 기존 인프라의 대규모 마이그레이션이 뒤따를 뿐이지 않겠는가. 그럼에도 불구하고 이렇게들 부나비처럼 만들고자 하는 것은, 바로 시대의 흐름이기 때문이며, 기술의 쉬프팅이 여기서 이루어지고 있기 때문일 것이다. 이러니 저러니 해도, 분명 먼저 구현해 낸 기업은 그들만의 내재화를 먼저 시작했다고 볼 수 있을 것이며, 이렇게 진행되고 발전된 내재화 뒤에는 '역량'이 쌓이게 되므로, 많은 인프라가 IaaS 위에서 동작 할 수 있을 것이라고 기대해 본다. 또한, 이런 내재화를 이룬 사람들, 즉 클라우드를 경험하고, 만들어 보고, 사용해 본 사람들이 나중에 신규 서비스 제작에 투입될 경우에 발생하는 인력에 대한 재교육 등의 미래 사건을 통해, 점차 사용자는 점진적으로 늘어나지 않을까 싶다. 

IaaS 세미나를 진행하는 모 담당자에게 자료를 전달했다. IaaS 를 구현할때 각 포인트에서 기술적으로 중요한 부분과, 이를 해결하기 위해서는 컨설팅을 받는것이 좋다, 라는 내용의 어찌 보면 회사 입장을 대변하는 뭐 그런 내용의 자료였단다. 모 담당자의 연락은, '내용이 부실하니 보충했으면 좋겠다, 혹시 샘플 없는가' 라는 입장이었다. 컨설팅이란게 계약 전에 구체적인 내용을 제시하는 것이 맞는지는 잘 모르겠지만, IaaS의 경우 구현하려는 목적과 사이징에 대한 정보도 없이 내부 개발자에게 'Quick Install' 에 가까운 해답을 원하는 것이라면, 글쎄, IaaS란 여태 서술한 대로 '카톡 잡아 먹듯이' 해서 만들 수 있는게 아닙니다 일테다. 그나마 그마저도 어도비 Air를 사용해서 데스크탑용을 구현 했으니, phonegap 이나 appcelarator 를 알고 있는 자들에게는 얼마나 웃을일일텐가. 


옛다_샘플_JPG




길고 구질구질하게 썼지만, 인프라에 발생하는 기술이동은 완전 새로운 것들로 이루어지는 것이 아니다. 따라서, 이러한 잘알려진 패키지들의 조합을 통한 새로운 인프라의 구성에 내재화가 필요하다는 말은, 돌려 말하면 '오픈소스'의 사상과 이에대한 기술이 뛰어난 인재들을 기업 내부에 키워야 하며, 이들을 통해 오픈소스에 기여할 때 우리가 원했던 시대적 흐름이 발생할 가능성이 높아질 것일테다. 


클라우드 IaaS 를 만들기 위해 필요한 가장 첫 단추는, 발전된 시각에서의 Amazon / Rackspace 서비스의 분석이다. Compute 와 Storage 는 시작이 될 수는 있겠지만, 실제 고객이 구성하려는 서비스에는 부가적인 많은 것들, 이를테면 DB, Queue, Load Balancing 등이 필요하게 된다. IaaS 는 '가상화' 라는 단순한 내용으로 접근하는 것이 아니라, 장기적으로 어떠한 인프라들을 서비스로 제공할 지에 대해 명확하게 깨닫지 않고, '샘플 없나요?' 따위로 접근하게 된다면 심각한 문제가 된다. 저런 멘트를 던지는 담당자는 필시 프로젝트에 손을 대지 못하게 하는 것이 정답. 

처음에 말했지만, 클라우드 구현은 '모방' 이 필요한 부분이다. 헌데, 가만히 보면 각 구성요소는 무엇인지 알겠는데 이것들을 어떻게 '조합' 했는지는 참 모를일이다. 바로, 이게 기술인 것이다. 우리의 현대 자동차나 독일의 메이저 3사가 가지고 있는, 그들만의 조합의 방법이 바로 기술이 되는 것이다. 부품의 베이스는 Bosch 와 같은 업체 또는 각 국가의 내부 인프라에 속한 기업들이 생산해 내는것으로 동일하겠지만, '완성차' 라는 것은 각 브랜드 별로 그 색깔과 기능이 확인히 다르게 된다. 바로 이부분이 모방하기 힘들기 때문에 노련한 사람들, 그리고 경험있는 사람들의 분석을 바탕으로 한 '창의'스러운 '모방' 이 필요한 것이다. 물론, 우리가 보다 좋은 인프라, 즉 오픈소스의 수많은 컨트리뷰터를 가지고 있다면 이런 고민 하지 않아도 된다. 굳이 우리 현대차를 중국산 차량과 비교하지 않는 것과 마찬가지의 맥락에서 말이다. 하지만, 우리는 분명 먼저 서비스를 만들지 못한 후발주자 이며, 인력을 확보하지 못한 모방자라는 사실, 그리고 이해 없이 단순히 우리도 만들어야 하지 않을까 와 같은 접근은 매우 실망스러운 결과를 가져 올 수 밖에 없을 것이다.  

 





매번 느끼는 거지만, 오픈소스는 정말 이제는 거부할 수 없는 흐름이다. 원래 이쪽을 보기는 했지만, 이제는 무엇을 검색하더라도 오픈소스가 걸리지 않는 경우는 드물다. 심지어 겜보이 조차 오픈소스로 만들어대는 세상이니 말이다. 따라서, 누가 많은 오픈소스를 알고 있느냐의 싸움이 아니다. 누가 이 환경에 익숙하며, 필요한 것을 빨리 경험해서 자신의 것으로 만드는가의 싸움 일 것이다. 


DIY Open Source Game-boy



우주선도 만들겠다. @_@ 

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