System Compleat.

'YZCerberos'에 해당되는 글 231건

  1. Fantasy Novel
  2. vSMP, Versatile Symmetric Multi-Processing
  3. Cloud is not a magic carpet.
  4. GPI, PGAS for HPC
  5. System & JavaScript

Fantasy Novel

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




이런 저런 책을 굳이 가려서 읽는 편은 아니지만, 언젠가부터 판타지 소설을 읽으면 무언가 덕후의 느낌이 나는 사람이 되어버리는 것 같다 라는 느낌을 지울 수 없었다. 사실 타인에게 권하기도 좀 그렇고, 내가 느꼈던 감상이 그들에게도 그대로 전달 될 수 있을까 하는 의문도 있었기에 아주 친한 지인이 아니라면 굳이 읽어봐라 한마디 던지지 않았던것도 사실이다.

글이 전달하는 이성과 감성, 그리고 인간이 인간에 대해 품 어야 하는 올바른 감정, 그리고 세상과 자아에 대한 면밀한 탐구를 진행하는 철학등은, 하나의 이야기 로 전달 될 수 있고, 우리는 이러한 이야기를 책과 영화등의 미디어를 통해 전달받고 공감하거나 이해하지 못한다. 대부분의 소설이나 시놉시스가 우리가 살고있는 또는 살았던 시대에 있었을 법한 일을 주제로 하기 때문에, 우리는 별도의 세계관을 가질 필요 없이 그저 우리가 눈으로 보고 귀로 듣고 몸으로 느끼는 것들을 기반으로 한 이야기들은 우리에게 아무런 저항없이 이야기에 몰입하고, 공감하게 된다.

하지만 판타지 소설이라는건, 기본적으로 이야기를 구성하기 위해 하나의 세계관을 만들어 내야하고, 그 허구의 세계관 속에 우리가 보고 느꼇던 것들을 적당히 얼버무려냄으로서, 독자가 이 소설속의 인물들과 교감하려면 이러한 허구의 세계를 상상해 내고, 이해 해야만 한다. 하지만 세계관이란건 무엇인가. 아인슈타인의 일반/특수 상대성 이론이 지배하고, 냉전의 시대를 거쳐 이르른 현대의 우리가 매일 뉴스로 보고 접하는, 우리가 살아왔던 모든 시간동안 보고 느껴왔던 것을 통해 만들어 낸 것이 바로 세계관이라 할 수 있을 것이다. 하지만 판타지에서는 어떤가. 전설의 드래곤과, 대부분이 총보다는 마법검과 마술, 승마, 갑옷 이러한 것들이 통용될 수 있음직한 세계가 있다 라는 상상의 나래를 펼쳐야 하는 것이며, 만약 이러한 내용에 거부감을 가지게 된다면 감정이입은 커녕 "말도 안되는 소리" 라며 책을 덮어 버리게 될 것이다. 그리고 한가지 더 중요한 것은, 이러한 작가에 의해 창조된 세계관이 다소 허술하거나 빈약하게 된다면, 신기하리만큼 그 집중도를 떨어트리게 만드는 것도 사실이다.

따라서, 이 세계관의 창조 작업은 매우 중요하며, 이러한 세계관이 오밀조밀하게 잘 구성된 소설의 경우 엄청난 히트를 하기도 한다. 개인적으로는 이영도님의 "드래곤 라자"를 어린 시절에 참 많이 읽었는데, 이는 전체 이야기의 굵은 선이 매우 일관적이고, 인물의 묘사가 뛰어나며 작가가 그리고자 하는 세계에 대한 덧붙이는 이야기들이 매우 정교하다. 따라서 첫장부터 등장하는 마법이나 몬스터, 드래곤 등에 대해 "후드가 달린 망토를 입은 마술사", "괴물같이 생긴 인형 생물", "날개달리고 똑똑한 유조선만한 도마뱀" 등의 이미지를 충분히 그릴 수 있다면, 소설이 이야기하는 가치관과, 세상에 대한 작가의 시각을 충분히 즐기며, 등장인물에 대한 공감이 수월하다. 그래서 독자들은 열광하거나, 아니면 아예 소설의 제목만으로 읽어서는 안될 책으로 치부하는, 크게 보면 두 종류로 나뉘게 될 것이다.

이러한 소설들은 보통 세계관을 독자에게 이해 시키기위해, 또는 설명하기위해 주인공의 1인칭 시점으로 주로 모험을 통해 이야기를 진행시키는 경우가 많다. 이러한 구성은 일견 무협지와 비슷하다고 할 수 있는데, 그래서인지 무협지를 스스럼없이 읽는 사람은 판타지도 별 무리없이 잘 읽어 내는 듯 하다. 아무튼, '드래곤 라자' 와 전민희님의 '세월의 돌', 이 두개의 소설이 내게는 재미있었던, 그리고 몇차례 다시 읽다 보면 그 내면에 이야기하고자 하는 바도 숨어있을 법한 것들이었다.

드래곤 라자



드래곤 라자의 경우엔, 마치 호텔 레스토랑의 잘 차려진 정식 코스를 먹는 기분이다. 처음과 끝이 깔끔하며, 이야기 전체의 각 부분에 작은 기승전결과 이야기 전체의 기승전결이 존재함으로서 그 짜임새에서 오는 재미가 크고, 상황과 인물의 묘사, 그리고 사건을 대하는 주인공의 가치 판단에 저어함이 없는, 그야 말로 정찬과 같은 소설이었다. 그 세계관의 묘사와 모든 지명, 인물에 대한 작명법 그리고 이야기 안의 이야기를 풀어내는 뛰어난 구성은, 저 뛰어난 김용의 그때 짜맞추는 듯 하지만 재미있는 소설을 뛰어넘는다.

이와 반해 세월의 돌은, 비극적인 결말의 무협지의 성격을 띈다 라는 느낌이 강하다. 주인공은 모험을 통해 지속적으로 빠른시간에 성장하며, 그것이 타고난 핏줄의 영향인데다가, 주어진 운명에 순응하며, 거의 마지막 순간에 반항한다. 작가님은 결말을 예견해두고 전체 이야기를 구성했음이 분명하지만, 그 최종의 비극은 짙은 여운을 남긴다. 이 짙은 여운은 전체 이야기가 마치 높은 곳에서 낮은곳으로 물체가 떨어지며 속도를 확보하듯이 진행되는 듯 하다가, 결국 땅바닥에 부딫혀 산산히 조각난다. 이는 전체 이야기를 이루는 몇가지 목적, 크게 모든 종족을 구해낸다와 남주인공과 여주인공의 사랑 모두에 반영된다. 하나가 깨졌기 때문에 다른 하나도 깨져야 한다라는, 복선으로 예견되었지만 최종회의 급 이별은 그 진행의 과정이 수긍하기 힘들다. 힘들다 라기 보다는 굳이 수긍하고 싶지 않다. 더군다나 영화나 소설의 여주인공은 굉장한 미인이었을때, 문제가 생기면 슬픔이 배가되는 공식이랄까. 주인공들은 뭔가 불안해 보이는 영원을 약속하고, 결국은 깨어지고. 주인공은 무언가 불안해 보이는 아버지와의 관계를 가지고 있지만, 역시 깨어지고.



따라서 세월의 돌 같은 경우에는, 다 읽고 난 뒤의 느낌은 사실 희망을 갖기는 힘들어 보인다. 노력했지만 가장 신뢰하는 사람으로부터의 배신으로 모든 것을 잃게되는, 그 이후의 과정도 갑작스럽게 3인칭의 시점을 빌려 모호하게 마무리 해 버리는 것 역시 마음에 들지 않는다. 그저, 모든 내용은 최종의 마지막에 눈물을 짜내기 위한 구성이 아니었을까 하는 의구심과 배신이 들정도로, 하지만 진정 그런 감정이 느껴지는것도 어쩌면 슬픈영화 보면서 눈물 빼는것과 다르지 않을지도 모르겠다.

그렇게 힘든 일만 있었던 것은 아니었어. 그렇지?
- 세월의 돌, 유리카

판타지 소설이라는건 결국 이야기의 근간이 되는 밑바탕의 영역까지 상상의 영역으로 만들어 버리지만, 오히려 그렇기 때문에 높은 이야기의 자유도를 선사한다. 그 즐거운 상상의 영역으로 빠져들어 주인공들의 이야기를 눈앞에 그려보는 것이 큰 즐거움일 수 있으며, 사람은 기본적으로 희망적인, 즐거운 방향의 상상을 좋아하기 때문에 그것이 비극으로 끝 나버린다면 거기서 오는 충격은 '악마를 보았다'와 같은 영화에서 오는것에 비해 크게 느껴진다. 유리카와 파비안의 이야기는 슬픈 이야기가 되어버렸고, 눈물짓는 남자 주인공만이 남았을 뿐이다. 후치와 헬턴트영지의 미래는 그들의 여행은 끝났지만 밝았다. 

서른이 넘어 스무살 무렵 군대가기 전에 읽었던 소설들을 다시 읽어보니, 감회가 새롭다. 이야기의 완성도는 제쳐두고, 두 이야기의 시작과 결말이 서로 반대되는, 이를테면 드래곤라자는 주인공의 분노로 시작하지만 평안으로 끝을 맺고, 세월의 돌은 평안으로 시작하지만 슬픔으로 결말이 지어지는, 이 두개의 재미난 이야기들은 삼십대 초반의 나에게도 뭔가 시사하는 바가 있어보인다.

뭐, 사실 우리 사는 세상이 판타지처럼 돌아가는데 굳이 책에서까지 찾아낼 필요야 있겠나 하는 생각이 드는것도 나이가 조금 더 들었기 때문에 그런것만은 아닐게다. 좋아하는 사람이 사라진다는건, 가까이 있지만 오감을 통해 인지 할 수 없다는건 꽤나 슬픈 일이라는 걸, 또 그런일에 아직 휘둘리는 나이라서 그런건 아닐까.

내 손에는 유리카의 엔젠이 꼭 쥐어져 있었다. 녹색의 보석... 그리고 그녀의 녹색 눈동자... 잊지 않을꺼야. 잊혀지지 않을 거야.

모든 것이 끝났고, 나는 처음처럼 또다시 혼자가 되었다.

- 세월의 돌



비오는날 코드보다가 급 센치해져서...
뭐 길게 썼지만 난 슬픈 사랑 이야기는 싫은거다.  그냥 그런거다.

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

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 is not a magic carpet.

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


클라우드, 클라우드, 클라우드.

문득 그런 생각을 해 본다. 전혀 새로울 것 없는 이 클라우드에 왜 다들 목숨들을 이렇게 걸어 대시는지들.
4년전에 아마존 서비스 테스트 하면서 그런 생각을 했더랬다.  이거 뭥미... 이렇게 I/O성능 안나오고 퍼포먼스 떨어지는데다가 공인 IP 갯수 제한도 있고.. ELB도 없던 시절이니 RR DNS나 내부에 별도의 Reverse-Proxy 를 구성해 두고 밸런싱 처리하고.. 

3년전에 Windows Azure 를 테스트 하면서도 비슷한 생각을 했다. 내가 뭐 닷넷 개발자도 아니고. SQL Azure 이거 이 성능 가지고 어디다 쓰지 했던.


뭐, 일찍 해 봤다고 자랑하는건 아니다. 다만, 대부분의 업장에서 이제 클라우드가 어떤건지 어렴 풋이들 이해하고 있는 듯 보이고, 주로 그 구성이 IaaS의 구성에만 촛점이 맞추어져 있는 현실.

예나 지금이나 중요한건, 메인프레임을 쓰느냐 클라이언트-서버를 사용하느냐 클라우드를 사용하느냐 하는 문제가 아니다. 더 중요한건, 실제 서비스가 어떠한 구성을 가져야 하느냐에 대한 부분일 것이다. 보안이 중요하다 한들 기업 내부 인프라가 아닌 이상, 아니 심지어 기업 인프라라 해도 모바일을 지원하기 위한 관리된 개방성이 필요하다. 일관성이 중요하다 한들, 오늘이 상반기 결산일이 아닌 이상 영업 데이터가 은행 계좌 잔고만큼 중요할리없다. 영상이나 컨텐츠의 저장과 배포를 위해 내부 시스템에서 마이크로초 단위의 디스크 seek time이 반드시 매번 중요하지는 않다. 무엇을 어디에 배치하고, 어떤 구조로 서비스를 만들어 내느냐 하는 문제는 예전부터 있어왔던 고민이고, 예전부터 있어왔던 해법이고, 예전부터 잘 처리해야 했던 부분들이다.  그게 클라우드에 넘어오면서 옵션이 조금 더 많아지고, 어떤 부분에서는 제한적인 요소도 있기 때문에 혼동하기 쉽지만, 똥과 된장을 구분할 줄 안다면 주전자를 쓰다음으며 지니가 나오길 바라지는 않을 것이다. 

최근의 클라우드 광풍을 보면 다들 무슨 마법의 양탄자 쯤으로 생각하고 있는 것 같다. 동시에, 마법의 양탄자가 아니었다는 사실을 깨닫고 빠르게 포기하거나 그 효용성 자체에 의문을 제기하는 사람들도 많은듯 하다.


주걱으로 국을 뜨려하고, 숟가락으로 라면을 먹으려 하는데 그게 쉬울턱이 있나.


예나 지금이나 컴퓨팅의 본질은 다르지 않고, 빠른 서비스를 위한 인프라 구성의 핵심 부분은 그 컨셉의 측면에 있어서 대동소이하다.  4메가 메모리와 5기가의 디스크를 가졌던 서버 시스템들에서 개발하던 빠른플리케이션의 코딩 방법이 42기가 메모리와 2페타 바이트를 가진 시스템을 위한 코딩과 핵심 컨셉이 다를리 없다. 여기에 클러스터링과 분산 컴퓨팅의 개념만 추가하면 무엇을 어떻게 만들어야 할 지에 대해서는 누가 굳이 그려주지 않아도 답은 뻔하지 않겠나. 

우주 왕복선에서 요구되는 연료의 연소와 노즐의 치밀한 각도 계산과 같은 실시간성이 요구되는 웹 서비스는 없다. 가급적 빠르면 좋은 시스템이라는 전제하에, 대부분의 비지니스 요구사항은 굳이 필요없는 RTOS와 같은 기능성을 요구하고 있지는 않은가 생각해 볼 일이다.

또, 그러한 요구사항을 클라우드 서비스에 들이대는 우를 범하지는 않아야 하겠다. 어플리케이션이 아무런 수정없이 클라우드에 적용되고, 기대했던 바와 같이 탄력성 있게 고객을 수용할 가능 성이 가장 높은 구조를 손에 꼽으라면, 아마도 클러스터링의 개념에 가장 충실했던 어플리케이션이 아니겠는가 싶다. 

클라우드에 서비스를 마이그레이션 할 때 가장 먼저 인정해야 하는것은, 비용이 아니라 바로 클라우드의 한계와 장애이다. 컴퓨팅 클라우드를 사용할때, 가장 높은 비용의 인스턴스를 사용할 것이 아니라 4메가 메모리를 가진 언제 고장나도 이상할 것이 없는 시스템 이라는 전제하에 구조를 짜야 할 것이다. 

하이브리드 클라우드 만드는데 기존 인프라와 빡세게 통신이 발생될 가능성이 있는 부분을 선택한다면 실패할 가능성이 높다고 말해주고 싶다.  캐시에 대한 고민없이 클라우드에 있는 디스크가 우리꺼보다 더 좋을꺼라는 환상을 가지고 있다면 얼른 깨어나시길.  아마존의 EBS가 Private Cloud 구성에 가장 중요한 덕목이 되었다면 어플리케이션 구조부터 다시 보시길 진심으로 권고하고 싶다.  그렇게 만드는거 아니라고. 

Share nothing 이라는 컨셉, Live Migration의 필요성등이 사설 클라우드를 만들고자 한다면 그 필요성에 비추어 반드시 재고되어야 할 것들이다. 아마존 클라우드의 각 서비스에 대한 분석을 제대로 했다면, 클라우드에서 구현해야 하고, 구현 할 수 있는 것이 무언인가에 대해 다들 이렇게 고민할 이유가 없다. 

진정 오라클을 잘 사용하고 있는 사업장에서는, Lock과 Latch가 가져오는 시스템 지연속도 등을 고려하고, 논리적인 관계는 쿼리와 어플리케이션에 녹아있지만 실제 FK를 걸어서 사용하지는 않는다.  내부 쿼리 처리가 어찌나 빠른지 페이지를 열면 데이터베이스에서 뽑아져 나오는 정보는 이미 페이지에 표시되어 있고, 이미지가 천천히 올라와 주신다. 이정도로 데이터베이스를 사용할 줄 아는 조직, 그렇게 많이 못봤다.  다들 오라클 주머니만 채우고 있지 않나.  

클라우드에 서비스를 구성 할 지 말지를 고민하기 전에, 서비스가 어떤 서비스인지 부터 고민하고 어떻게 인프라가 구성되어야 하는지에 대한 밑그림이 먼저 그려져야 하지 않겠는가. 

좋든 싫든, 또 지난시절 언제나 그래왔듯이 컨셉을 이해하고 그 구현을 고민하는 사람들에게는 지난날의 시스템도 이미 충분히 잘 동작하고 있을 것이다. 또 이런 시스템을 굴리고 있는 조직에서는 주변에서 하도 떠들고 있는 클라우드에 마이그레이션이 어떻게 되어야 하는지, 어떤 부분을 적용할 수 있는지의 여부도 면밀히 살펴보고 있을 것이다.  이런 분들에게는 이 새로운 환경은 그저 필요에 의해서 사용되고, 효율적으로 사용 될 것임을 믿어 의심치 않는다. 

대기업의 기존 인프라는 클라우드가 필요 없을 것이다 라는 식으로 이야기 하는 분들이 있는데, 당장 옮기기는 힘들긴 하지만, 그런건 단정 지을 수 있는게 아니다. 지금의 시스템들을 언제까지나 사용할 리도 없고, IBM pSeries를 다음번에 매번 구매해야 할 필요성이 있는건 아니다. 세상의 모든 데이터베이스가 RDBMS만 되어야 하지 않는다면, 자연히 클라우드는 아니라도 클러스터의 필요성은 생겨날 것이다. 

물론 컨셉을 이해하고 적용하시는 분들도 계시겠지만, 또 마케팅과 인문과학 출신으로 도배된 IT조직에서 귀까지 닫고 있는건 그들 사정이겠지만, 자꾸 말도 안되는 소리를 하는 분들이 있어 답답함에 간단히 적어본다.

원래 꼭 해야 했던건, 그게 클라우드라고 해서 안해도 되는건 아니다. 다만, 원래 꼭 해야 되는걸 하지 않았을때 클라우드는 예전보다 더 심한 좌절과 프로젝트의 처절한 실패만을 불러올 뿐이다. 서비스의 클라우드 마이그레이션은 일견 쉬워 보일지 모르겠으나, 그 기술적 진입장벽은 전보다 높아졌음을 이해할 필요가 있을 것이다. 한가지 더 중요한 사실은, 클라우드는 또 하나의 새로운 인프라 형태일 뿐이지 기존의 모든 것을 완전히 대체 할 수 있는 무언가는 아니다. 필요한곳에 적절히 사용 할 때, 비용과 성능, 그리고 가용성의 여러마리 토끼를 잡을 수 있을 것이다. 

국자는 국 뜨는데 쓰자. 

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

 

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

System & JavaScript

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

오래전에 그만두었던 프로그래밍을, 최근 들어서 다시 하게 되었다. 그 첫번째 이유는 인프라의 자동화와 관련되어 있는 Ruby 코드를 작성하기 위한 것이었고, 그 두번째가 바로 오늘 포스팅할 주제, 자바 스크립트 때문이다.

Aptana Studio 3.02



솔직히 말해서, 리눅스 커널/드라이버 관련 개발을 그만두고 나서는 별로 개발 할 생각이 없었다. 90년도 후반에 리눅스 배포판을 성공적으로 설치하면 따라오던 HOW-TO 문서를 따라하는 재미도 쏠쏠했고, 이미 이때부터 소개된 클러스터링이나 당시 떠오르던 웹 플랫폼에 관련한 인프라 기술들이 나에게는 더 매력적으로 느껴졌고, 또 더 재미 있었기 때문이다.  무언가를 미시적인 관점에서 살펴보는 것보다, 거시적으로 만들어 내는 재미가 보다 컸던 이유로, 또 하나는 이미 중학생 때부터 어셈블러, C, C++, Windows 95 API, MFC 클래스를 달달 외워낸 친구가 있었기 때문에, 그렇게 개발은 일찌감치 손을 떼었다. 고2때 이미 DirectX 3.0 을 가지고 3D 큐브 게임을 만들어 내던 놈이었으니, 당시가 이미 97~98년도다.

다시는 돌아보지 않을 것 같던 이런 탭으로 들여쓰기 해 놓은 코드들이 다시 언젠가부터 꼭 보아야만 할 것들로 다가오기 시작했다. 그 시작은 예전부터 자주 죽어나가던 데몬들의 사망 원인을 밝히기 위함이었고, 더 나아가서는 회사에서 사용하는 PHP의 프로파일링이 필요 했었고, 보안을 위한 exploit 의 코드를 twick 하여 운영서버에서 모의 테스트를 하는 등의 이유였달까. 더군다나 최근에 들어서는 인프라의 다량화가 진행되면서, 더이상 쉘코드나 펄과 같은 도구만으로는 자동화가 힘들었기에, Chef나 Puppet의 사용을 위해서 인프라를 코딩하는 정도의 수준에서 다시금 개발에 손을 대게 되었다.

Do you want to know more?

Image from: http://cfs12.tistory.com/image/18/tistory/2009/02/20/17/32/499e6a989c083


일을 꾸준히 하면서, 소스코드를 쓰는 능력이 필요한 개발자와 소스코드를 읽어낼 줄 아는 운영자의 능력 중, 후자의 능력을 배양하는 것은 제법 힘들지만, 반드시 필요하다는 점을 강하게 깨닫게 되었다. 시스템의 문제는 통상 인프라를 구성하는 일반적인 오픈 소스데몬의 문제라기 보다는, 그 위에서 동작하는 어플리케이션에 문제가 발생하는 경우가 대부분이고, 특히 국내와 같은 환경에서는 잘잘못을 가리기 위한 부분보다는 문제를 빠르게 해결 하기 위해, 그 필요성은 점점 더 강해졌다. 서비스 운영 중 대부분의 시간에 개발자가 관여하는 일은 드물고, 업데이트로 인해 발생했던 장애에 대해 그 원인의 분석은 코드에 까막눈이고서는 절대 불가능하다. 더군다나, 일부 개발자가 책임을 회피하기 위해서 묵비권이라도 행사하는 날에는 골치가 이만저만 아픈게 아니다. 이러한 점은 리눅스나 유닉스 기반에서보다, 윈도우 기반에서 더 강하게 느껴졌던건 아마도 윈도우 커널과 Support Tools에 대한 일천한 지식과 다소 폐쇠적인 윈도우 자체가 큰 몫을 했으리라.

그대_앞에만서면_나는_왜_작아지는가.jpg

Image from: http://www.flutterby.com/images/other0000/MSInfoMinister_WindowsNET.jpg

뭐 어쨌든 그런 시절은 지나갔고, 나에게 생소했던 닷넷이라는 프레임웍은 이제 당분간 보지 않아도 되게 되었지만, 현희형과 준호형, 그리고 AJ, 그렇게 함께 만들어 냈던 일본의 모 서비스가 쌩쌩 돌아가는 것을 보면서, 무슨 도구던지 제대로 만질 줄 아는 사람들이 뭉치면 어마어마한 서비스 퀄리티가 튀어나온다는 것도 깨닫게 되었다. 진정한 협업이란 그런 것이었을 게다.

Real Collaboration

Image from: http://agile101.files.wordpress.com/2009/07/collaboration.jpg

이제 그분들과 모두 적을 달리하게 된 지금에 와서 컨설팅으로 여기저기 쑤시고 다니다 보면, 참 어이없는 상황들을 많이 맞이하게 된다. 게다가 그분들과 같이 일하게 되면서 괜시리 눈만 높아진건 아닌가 하는 생각이들 정도로, 웹 어플리케이션의 완성도에 대한 욕구는 커져만 갔지만, 인프라 아키텍쳐와 어플리케이션의 설계에 대한 방향성은 제시 할 수 있어도 내가 직접 샘플을 보여 줄 수는 없다는 현실에 점점 기술적인 못난이가 되어가는 느낌을 지울수 없었다.

너 못났어! ㅠㅠ

Image from: https://t1.daumcdn.net/cfile/blog/137AEB0A49ABD9149B

요새 맨날 클라우드 이야기만 풀었는데, 굳이 클라우드가 아니더라도 요새의 서비스들은 자바 스크립트와 Ajax, 그리고 HTML5 를 통한 서비스 구성의 유연성이 날로 확대 재생산 되고 있다. 더군다나 최근 서비스의 주요한 개념인 Eventual Consistency 의 주요한 사용은, 더 이상 자바스크립트와 Ajax를 모르고서는 세상살기 힘들겠다는 생각이 들게 하기에 충분했다. 더군다나 최근 인프라에 사용되는 여러가지 도구들과 서비스들은 실제 웹 페이지 기반 보다는 REST로 구성된 API 호출의 형태가 많아졌으며, 이를 통해 주고 받는 JSON 또는 XML의 데이터들은 이런 기본 언어들을 모르고서는 페이지 한장에 간단히 표시조차 하기 힘들어 졌다. 게다가 카산드라나 Reddit, SimpleDB 와 같은 NoSQL 지원 서비스들의 등장은 이제 제아무리 시스템 분석가라 하여도 코드를 읽거나 간단한 시스템 동작을 시뮬레이트 할 수 있을 정도의 코딩 능력이 없다면 개발자들과 대화하는 것도 쉽지 않겠다 라는 생각에 이르게 되었다.

NoSQL

Image from: http://stormseed.com/files/2010/03/image2.png


시스템 하는 사람이 오지랖도 넓네 라고 말할지도 모르겠지만, 경험상 이러한 도구들이 어떻게 어플리케이션에 사용되는지를 알고, 어떤게 제대로 사용하는 것인지를 아는 것은 매우 중요하다. 물론 내가 직접 개발을 해서 좋은 코드를 쓰겠다는 것은 분명 아니다. 하지만, 만들어진 코드의 동작이 인프라의 설계 구조나 목적과 부합하는가의 여부에 대한 판단은 정말로 중요한 것이어서, 이는 누가 어떤 일을 하는가에 대한 롤의 분류보다 서비스 그 자체를 문제 없도록 하는데 더 큰 이유가 있는 것이다.



그러한 이유로 해서, 좀 시간을 두고 살펴보아야 할 것들을 간추려 보니 HTML5, Java Script, Ajax 정도가 될 것 같다. 그야말로 필수 요소만 보겠다는 노력이 가상하지 않은가! 


서버 인프라 분야에서 일을 한다고 해도 꽁짜 VM을 쓰는것은 만만치 않다. 뭐 물론 방법이 있기는 하지만, 굳이 그런 방법을 쓰지 않더라도 로컬에서 코드 동작하는거 테스트 해 보는 정도로 앱태나는 정말 걸출한 듯 하다. 게다가 Github나 Cloud9IDE, 구글 사이트의 도움 정도면 사이트를 개발하는데 필요한 것들은 무난하게 배워 볼 수 있지 않나 싶다.



신기한 것은, 묘하게 욕구가 샘솟는 점이다. 이는 아마도, 인프라스트럭처/네트워크/스토리지/큐/메세지/백엔드/프론트엔드 에 대한 원큐 샘플을 필요한 모델별로 만들어 낼 수 있을 것 같다는 기대감에서 오는 것 같다. 구글API나 트위터 API를 사용한 인증 체계의 구현 모델이라던가, 이에 얹혀지는 컨텐츠들의 저장과 메세지 통신에 대한 것들을 좋은 모델로, 또 각 부분의 코드로 제시할 수 있다면 이 얼마나 기쁜 일이겠는가.  게다가 이 블로그를 조금 더 이쁘게 내손으로 코딩 할 수 있는 재주까지 생기게 되는것은 덤으로 얻어지는 행복일 것이다. 


이런 그림과 코드의 제공을 동시에!!

Image from: http://m1.mycloudbuddy.com/images/cb_dataflow.gif



비동기로 가능해지는 기존에 생각 할 수 없었던 많은 부분의 분산처리 모델은 분명 또 다른 컴퓨팅의 모델일 것이다.



그리고 혹시 여러분은 Darkstar 에 대해 들어보신적이 있는가?  어마어마하게 흐르는 SNS 메세지 형태의 데이터 형태들을 실시간 분석에 사용할 수 있다면 얼마나 좋을까?  아마 이런 기술의 사용도 앞으로 볼 생각을 하니 묘한 기대를 넘어 흥분까지 되는 것 같다. 훗. NoSQL을 넘어 Continuous SQL로, Cloud Event Processing 으로!  이건 나중에 기회가 되면 소개하도록 하겠다. 못 기다리시는 분들은 아래 링크의 pdf 에 소개된 내용을 바탕으로 구글링을 쎄워 보시도록.



돌아다니다 보니 깔끔하게 정리된 튜토리얼 페이지들이 몇개 있어 소개한다.


HTML5 - 영문 페이지

http://www.w3schools.com/html5/default.asp


JavaScript - 영문 페이지

http://www.w3schools.com/js/js_howto.asp


Ajax - 한글 페이지

http://www.ibm.com/developerworks/kr/library/wa-ajaxintro1.html


이론과 개념에 대해서는 옆의 링크에 소개된 A.J의 블로그도 많은 호응을 얻는 것 같다.
심화된 자바스크립트의 사용 역시 옆의 링크의 파이어준 횽아의 블로그도 인기 절정.

About Darkstar, SAX, Continunous SQL
http://www.google.co.kr/url?sa=t&source=web&cd=1&ved=0CCoQFjAA&url=http%3A%2F%2Fwww.eventprocessing-communityofpractice.org%2Fep-10%2Fcc-pdf.htm&ei=JO78TcPXEJSCvgOkipWvDw&usg=AFQjCNGHZwk0PYp_HnXiER6XdjYywJoHYA&sig2=W7_YW1CHoK8O2mP9QC4JMw

Darkstar 개발자인 Colin Clark의 블로그
http://colinclark.sys-con.com/node/1394840/blog

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

Serious Cat, "Yay"

Image from: http://img.photobucket.com/albums/v418/bawanaal/SeriousCatYAY.jpg