System Compleat.

'Techs'에 해당되는 글 113건

  1. GPI, PGAS for HPC
  2. System & JavaScript
  3. Cloud, HPC, GPU 11
  4. 오픈소스에 대한 생각
  5. 미디어 노출

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



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

오픈소스에 대한 생각

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


먼저 이 글은, 대규모 화 하지 않아도 되거나 분산이 필요한 만큼 서비스 요구가 크지 않을거라고 생각하는 회사의 관리자 분들, 또 오픈소스라면 나는 학을 띈다 라는 분들께 열람을 권고하지 않는다.  그런 분들은 또, 굳이 시간을 들여 열람하지 않으셔도 된다. 





저비용의 인프라스트럭쳐를 구성하다보면, 종종 신뢰의 한계나 구성상의 한계에 부딪치곤 한다.  하지만 이런 한계라는 것은 잘 살펴보면 동일한 기능을하는 메이저 벤더의 것들에 "비해" 한계로 인식되는 것이고, 그 대부분의 인식은 "유지보수" 라는 벤더로부터의 서비스를 받지 못한다 라는 사실 또는 공포감에 기인하는것이 대부분이다.  핸드폰 하나를 사도 A/S 를 걱정하는 의식이, 일일 접속자 만명 이하의 규모 서비스에도 벤더 서버와, 벤더 스토리지를 구성하게 만든다. 그리고 장비 유지보수료, 기술 유지보수료, 벤더 소프트웨어 라이센스를 꼬박꼬박 지불 하면서 안심한다.

사실, 좋은거 하나사서 잘 쓰고 싶은데 이게 고장나면 큰 문제이긴 하다. 그래서 혹시 고장날까봐 두개 세개 정도 사다보면 어지간한 웹 서비스 하나 하는데도 억소리는 쉽게 나기 마련이고, 문제는 이런 구매비용의 거의 10%의 비용을 매년 지불하게 됨에 따라, 기업 재무관련 담당자가 바뀌거나 구조조정 이야기가 나오면 이런 비용을 주네마네 말들이 많아지는게 바닥의 순리처럼 보인다.

전통적인 큰 기업의 입장에서는, 특히 요 몇년전까지는 이러한 인식이 별 문제가 되지는 않았다. 데이터베이스 관리자나 시스템 관리자는 쉽게 해고하기 힘들정도로 기업 인프라의 중요한 부분이 되어있으며, 이러한 인프라를 꾸준히 유지하는데 드는 비용이 적절하다면 딴지를 걸어야 할 이유도 없다.  네트워크는 네트워크 잘 하는 업체에 맡기면 되고, 스토리지는 스토리지 잘 하는 업체에, 서버는 서버 벤더에, 기반 소프트웨어는 각 벤더에, 심지어 5년전에 소스를 만들고 망해버린 업체가 준 어플리케이션의 유지보수도 능력있는 업체를 찾아 맡긴다.  이런 형태의 업무에서 자연히 한국인의 정서에 맞게 "갑"과 "을"이 생겨나고 그에따른 페단이라면 폐단이고 공생이라면 공생인 관계들이 나타나게된다.  이러한 게층적 구조역시 "서비스가 잘 동작하고 문제가 없다면" 이슈가 될 이유가 없다.  이 이야기는 결국 관리를 하는 "갑"의 사람이 다수의 "을"이 하는 일에 대해서 충분히 검증을 할 의무에 충실했다고 할 수 있으며, 기술적인 깊이는 아주 깊지는 않더라도  없지는 않아서 그들이 서버실에서 무엇을 하고 있는지, 어디를 검증해야 하는지에 대한 정도는 잘 알고 있다는 의미이기 때문이다.

하지만 이런 일반적인 갑과 을의 관계에서 크게 문제가 되는 경우가 있는데, 그게 바로 갑이 갑으로서 검증해야 할 일에 대해 "너무" 모르거나, 이로 인해 제대로 된 "을"을 선정할 능력이 없었다면 이건 서비스에 문제가 된다. 실제로 많이 발생하기도 하는 이런 문제는, 굳이 여기서까지 이야기 하지 않더라도 업장에서 근무하는 모든 분들이 아주 잘 알고 계신 것이기도 하다.  아무튼 이러한 검증 능력의 부재는 실질적으로 서비스에 해악을 끼치게 되고, 실제 사건이 터지면 모든 업체를 긁어모아 해결을 위한 압박을 가한다.  기본적으로 문제라는건 좀전까지 되던게 지금 안되는 것을 말하고, 이는 어디엔가 누군가 무언가를 바꿔서 잘못된게 생겨났고, 그로인해 해악이 생긴것이다.  이러한 해악으로 인해 실질적인 금전적 손해가 발생했다면, 이제 모여있는 을들은 자신들이 분명히 잘못한것이 아니면 함구한다.  대답해서 독박을 쓸 이유가 없으며, 다음번 계약에서 손해를 보고 싶지도 않기 때문이다.  따라서 운영과 서비스는 투명해 지지 못하고, 문제가 해결되지 않을 가능성도 있는채 시간은 흐른다.  이는 최악의 상황이고, 실제로 우리는 크건 작건 이러한 상황을 목도해 왔다.

실제 큰 기업의 데이터베이스나 코드를 보면 참 실소가 나오는 경우가 많다.  많은 분들이 보셨겠지만 어디가서나 흔하게 볼수 있는 Encoding 문제.  그렇다.  웃고 계신거 안다.  그래도 이 서비스들이 완전 붕괴하지 않고 그래도 동작하는 이유는, 어떻게든  갑과 을이 동작을 시킬 수 있었기 때문이다.  분산처리 같은거 크게 고민안해도 서버 2~3억 해서 사서 오라클 올리고 AIX 에 WAS 올리고 EMC붙이고 NAS 는 NetApp 사고 하면 되었다.  또 자회사를 두어서 자사의 인프라를 관리하게도 했다.  물론, 이런 경우  갑 - 을 의 2 Tier 가  갑 - 을 - 병 의 3 Tier 로 바뀌는 것 말고는 큰 변화가 없긴 하지만, 그래도 약간이나마 기술적인 필터링을 거치기 때문에 큰 사고들은 잘 안터진다.  아이폰 같은거 없었던 세상이면, 브라우저의 자바스크립트가 웹 소켓으로 통신을 하지 않고, HTML5 , CSS3 이런거 없었던 세상이면 이런 구조는 평생 큰 문제가 없는 구조긴 했다.  기업은 조직과 인력관리만 하면 되고, 기술 관리는 하지 않아도 되었기 때문에.

아이폰따위_없었더라면_우린_이미_천국.jpg


image from : http://farm4.static.flickr.com/3414/3347103456_44feb9d8f3.jpg


클라우드가 참 쓰나미처럼 화두다.  이미 모든 아키텍쳐를 검토한 기업들이 많을것이다.  물론 큰 기업은 아마도 일종의 TF에서 먼저 해외에서 눈으로 확인하고 테스트플랫폼 만들어 보고 하는 것들을 몇년 전에 끝냈을 가능성도 있기는 하다.

네임서버 돌리는데 이제는 아무도 벤더의 Bind 소프트웨어를 구매하지는 않는다.  웹 서버 하면 아파치는 엊그제 입학한 대학 새내기도 안다.  웹 프로그래밍 하면 PHP 정도는 기본이라고 생각하고, 이 외의 다른 언어에 숙련자라면 PHP는 구리다며 사용하기를 꺼려하는 경우도 많다.  눈치 빠른 분들은 아시겠지만,  그렇다 오픈소스 이야기 할려고 이런다. 
Trade off 의 의미는 많이들 아실꺼다.  기업에서 오픈소스를 선택한다면 반드시 버려야 하는 것이 하나가 있는데, 바로 A/S 다.  고쳐달라고 아우성 쳐봐야 아무도 고쳐주지 않는다. 몰랐던 부분에 문제가 발생하면 고칠수 없다는 공포가 의사결정권자의 온몸을 휘감는다.

전술 했듯이, 이제 뭔가 다양한 기능을 제공하는 웹서버를 설치해야지 하면 아파치를 설치한다.  개발에 입문했거나, 백엔드에 특화된 개발자가 아니라면 통상 아파치 - PHP - MySQL 정도를 표준으로 설치한다.  설치하면서 많은 문제에 직면하고, 웹을 통해 검색하여 해결을 찾는 시간들이 누적되면 이제 httpd.conf 는 쉽게 쓴다.  대강 어디서 어느 문제가 발생하는지는 굳이 관리자가 아니라 개발자도 안다.  관리자들은 이 좋고 무료인데다가 다중 플랫폼도 지원하는 이 웹 서버를 기존의 비싼 인프라, 즉 HP-UX, IBM p Series, SUN 등에 설치하고 돌린다.  근데 신기한건, 아무도 IBM 같은 회사에서 만든 회사의 웹 서버를 사용하지 않고 아파치를 사용해도 되는 서비스가 있으면, 아파치를 설치해도 이의를 제기하지 않는다. 

왜일까?  간단한 Search Engine 용 DB 를 MySQL 로 하고,  간단하게 사용 할 수 있는 웹서버를 Apache 로 하는데, 이것들은 A/S 가 없어서 그토록 우려하던 거의 ( 라이센스의 형태 때문에 '거의'라고 표현한다 ) 오픈소스들인데 말이다.

답은 쉽다. "잘 알기" 때문이다.  이 서비스에 대해 잘 알고 있다고 생각하고, 실제로 알고있으며, 어디에 어떻게 적용하면 되는지에 대해 알고 있기 때문에 "그래도 되는" 서비스에는 그렇게 하고 있는 것이다.  MySQL 이야 모르지만 아파치의 경우에는 실제 서비스의 크리티컬한 파트에서도 많이 사용된다.  물론 벤더 L4-7 같은 장치들이 있어서이기도 하지만.

잘 알고 있는 것들에 대한 두려움은 별로 없다.  또, 문제가 발생하면 대충 어떻게 웹에서라도 정보를 찾아서 고치는 방법을 찾아 내고야 만다.  비교적 흔하게 알려진 POSIX 나 System V 계열에서 발생 할 수 있는 Mutex 관련 이슈와 같이, 조금 어려운 문제도 해외에서 이미 경험한 사람들에 의해 조금의 영어를 읽기만 하더라도 찾아내서 고친사람들이 있어서 이제는 많은 사람이 알게 되었고, 쉽게 쓴다.

문제는, APM 만 안다. 그리고, 뒤늦게 선발주자들을 부러워 한다.  Facebook 이 카산드라를 써서 구현되었데. 우와 정말? 그거 빡세던데 고장나면 어쩌지?

10년전과 다르게, 오픈소스는 이제 당신이 원하는 또는 미래에 생각할 수 있는 거의 모든 것들에 대한 답안을 줄 수 있을 정도로 적어도 인프라 분야에서는 무엇을 선택해야 하는가에 대한 고민을 시간을 많이 들여 고민해야 할 정도로 발전해 있고, 준비되었다. 해외에서는 아무도 서비스를 처음 시작할때 고가의 유닉스를 사지 않는다.  차고에 친구들끼리 모여서 서비스를 만드는데, 그런 서버를 어디서 펀딩을 받지 않는 이상 구매 할 리가 없다.  펀딩을 받더라도 그돈으로 고가의 장비를 구입하면, 투자 회수 당할지도 모른다.   근데 우리나라는 돈이 참 많은지 그런 서버들을 아주 잘 산다.


나 어릴때만 하더라도 이런소리 항상 들었다. "배워서 남주냐"  "아는것이 힘".  환경이 너무 좋아져서 그런가, 네이버에 Git 가 뭐에요 하고 물어보는 사람은 많아도 Git 를 구글링해서 Wiki 를 보는 사람은 많지 않다.  ( 없다는 말이 아니다. 엑스퍼트들 흥분 마시라 )  심지어 Git 를 우리 부장님이 모르신다면 황송하게도 부하직원에 물어보신다.  이런 환경은 갑과 을의 관계에서도 지속된다.  갑은 Git 을 알 필요가 없다고 생각한다. 그래서 15년도 넘은 CVS 쓴다.


세상이 오픈소스를 원하기 때문에, 아 더럽네 이제 이것도 공부해야 되네 라고 생각한다면,  다른 분야의 개인사업을 차리도록 권고하고 싶다.  세상이 오픈소스를 원하는게 아니라,  앱을 돈내고 사고, 광고를 보아주는 고객들이 핸드폰 들고 당신의 서비스를 찾아온다.  5년전만 해도 컴퓨터는 젊은사람들의 전유물이었는데, 세월이 흐름에 따라 젊은사람들이 늙고, 이 사람들이 경제력을 가져 아이폰과 아이패드를 사고 갤럭시탭을 사고,  그런것들 사서 하는 것들이 모두 소비의 행동이기 때문에 좋은 제품들을 쉽게 내어 놓은 회사들은 떼돈을 번다.  아이폰 앱이 "스트리트파이터" 처럼 몇만원에 달하는 경우는 거의 없고, 대부분 $0.99, 몇백원 수준의 것들인데, 이것들을 4천만원 ~ 몇억 하는 서버들로 구성해서야 단가가 맞겠는가.  설령 단가가 맞는다 하더라도,  시간당 5백원 ~ 몇천원 수준, 심하게는 한달에 몇만원 하는 서비스가 있는데 그런 고비용을 사용한다면,  더 많은 이익을 포기하겠다는 것과 다름이 아니다.

돈들 참 많어~

image from : http://itsnotlevel.com/thepress/wp-content/uploads/2009/01/tons_of_money-21671.jpg


근데 이런게 있어도, 우리나라 대부분의 기업은 못쓴다.  이유는 동일하다.  모른다. 또는, 겁낸다.

현대의 인프라는 대형의 큰 덩어리를 고비용을 주고 구매하는 것이 아니라, 싸고 작은것을 많이 써서 언제든 고장나더라도 대체 할 수 있게 하는 것이 핵심이다.  오픈소스로 된 서비스가 고장은 날 수 있을 지언정 한번에 모든 서버에서 동일한 문제가 뿅 하고 나타날 가능성은 희박하다.  저렴한 서버가 고장날 수는 있지만  모든 서버가 한번에 다 고장날 수는 없는거다.  그렇다, 그래서 오픈소스를 써도 된다.

문제가 생긴다. 우리 인프라는 윈도우인데,  이거 싼걸로 100대 이상 꾸미면 당최 라이센스비가 얼마가 될 지 모르겠다.
아끼자는 비용이 오히려 배꼽이 되어 더 커진다.  이럴때 클라우드를 이용한다.  컴퓨팅 클라우드 사업자는 통상 윈도우 라이센스 문제를 해결한다.  그래서 시간당 사용금액에 몇 센트, 몇 십원 씩을 덧붙인다.  하지만, 윈도우 서버를 써서 이미지를 서비스 하거나 (단순 파일전송) 뭔가 닷넷과 같은 MS특화된 것들을 하지 않는데 윈도우 서버를 쓴다면, 이번기회에 저렴한 리눅스로 이동하는 것도 좋다.

문제가 생긴다. 이제 리눅스가 겁난다.  또는 리눅스 엔지니어링을 하는 사람의 인건비가 겁난다.  이렇게 생각하면 좋다.
간단한 웹용 리눅스 서버가 5대 있는데 이걸 관리하려고 사람을 쓰면 그래, 아까운거 맞다.  근데, 이런 서버가 필요하면 1천대 이상 증가하는 환경에서는 이런 사람 쓰는게 남는거다.  1천대 윈도우 비용 내느니, 리눅스로 또 클라우드로 넘어 갈 수 있는데 도움이 되는 사람이라면, 아예 팀으로 구성하는게 남는거라는 말이다.  그래서 큰 규모의 서비스를 하는 해외에서는 벤더의 L7을  사는 대신 Reverse-Proxy 를 쓴다.  1천대를 로드밸런싱 하는데 L7을 삼십대만 구매한다고 생각해 봐도 구매하지 않는 경우와 비교 했을때의 가격은 후덜덜 하다.  인건비는 계속드는데 어쩔거냐고? 누적비용으로 따지면 더 비쌀거라고?   벤더에 주어야 하는 유지보수비와, ( 안줄 수 없는게 이게 벤더를 구매한 이유거든 )  장비 교체 연한에 따른 교체 비용, 그리고 구매한 장치의 감가상각등을 생각해 본다면, 사람을, 팀을 쓰는게 서비스가 커지면 커질 수록 남는 장사라는걸 깨닫게 될 것이다.  더군다나 그렇게 키워진 사람은, 언젠가는 당신의 다른 사업에 도움이 될 지도 모른다.  (물론 인간 관계가 좋아야 했었다는 과제가 따르긴 하지만.)

기억하라, 꽁자로 돌릴수 있는 오픈소스는 다른 플랫폼에서도 많이 동작하지만, 리눅스에서 돌리는게 제일 잘돌고 쉽다.

 
인프라가 리눅스인데 고민하고 있으면... 더 말 않겠다.


이제 인프라를 싸게 만드는 방법은,  기존에 있던 기술들을 사용한 오픈소스의 각 제품중 꼭 들어맞는 것을 잘 찾아서 조립 ( Assemble ) 하는데에 있다.


Thieves!!!!!

image from : http://www.antipatterns.com/orig/images/lock-in.gif


결론은 글 전체에 계속 나와있다. 모르는거 챙피한거 아니다. 언제? 남들 다 모를때. 하지만, 육군 병장이 조정간 안전 - 단발 - 점사 를 모르면 그건 맞아야 되는거다.   회사에서 때리진 않지만, 적절한 시간과 기회가 부여 되었음에도 불구하고 모르면 감봉당해도 할말 없고, 우리는 그런 돈 주고 받는 세상에서 산다.

물론, 우리나라에 많은 오픈소스 전문가들이 계심은 잘 알고 있다. 그리고 내가 쓰고있는 이 주제가 껄끄러우셨다면 죄송
하다. 하지만 이런 이야기는 한번 꼭 해야겠다.   많은 경우, 이런걸 알고자 하는 노력을 게을리한다.  사실 노력이 없고, 이런 부분에는 시간을 쓸 필요가 없다고 생각할 수도 있겠다.  하지만 위에 말했던 상황을 겪고 있다면, 준비하는게 좋지 않을까?  키우고 계신 자녀의 등록금을 위하여서라도.


자, 오픈소스를 잘 알기위한 팁을 보자.
  1. 네이버의 지식인에 관련 지식을 물어보는걸 그만한다.  뉴스는 뭐.. 취향이니까 관여 않는다.
  2. Google 검색을 한다.
  3. Google 검색을 한다.
  4. Google 검색을 한다.
  5. Google 검색을 한다.
  위의 5가지의 훌륭한 방법을 모두 수행했음에도 불구하고 잘 안나오는 소프트웨어가 있다면, 다음의 방법을 따른다.
  1. 서비스에 도입하지 않는다.
  2. "Human knowledge belongs to the world" 정신을 몸소 실천하여 내가 마루타가 되어 본다.
  3. 상용화된 서비스에 도입하여 어디가 문제인지 알아본다. ㅡ_ㅡ

정보는 널리고 널렸다.  옆사람 아랫사람한테 야 우리 소스 형상관리 뭘로 하냐? 했을때 "SVN" 이요 라는 대답을 들었으면,  야 그래도 우리가 어떤회산데 간지가 있지 Git 한번 갈수 있나 봐라  하는 꽃상사 님이 되는 방법은 어렵지 않은것이다. 

Stuff You Should Know: How donkeys were invented.

image from : http://biomesblog.typepad.com/photos/uncategorized/calvin9_2.gif

한가지더 주의 해야 할 점은, 처음부터 모든 것을 알려고 하지 마라. 필요한 것 부터 하나씩, 우리 서비스에 있는거 하나씩 검색을 시작해 보기만 하면 되는 것일게다.

IT업계에 농담이 있다.  MS가 윈도우와 관련 제품들을 팔고, HP,IBM이 서버를 팔고, 다른 모든 소프트웨어 업체의 솔루션을 구매하더라도, 모든 돈은 Oracle 로 흐른다 는 것이다.   항상 말하지만, Oracle 참 좋은 DB다.  다만, 오라클을 오라클 답게 썼을때일 뿐이라는게 좀 아쉬울 뿐. 

나중에 천대씩 넣어야 하는 상황에서 라이센스때문에 벤더 바짓가랭이 잡고 울지 말고, 미리미리 준비 하자.
괜찮다. 아직 늦지는 않았다.  우리나라의 서비스 할만한 돈을 가지고 있는 회사들의 대부분이 아직 모른다.


싸고 쓸만한데 안쓸 이유가 없잖아? 

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


미디어 노출

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

어제 inews24.com 에서 주최하는 Nexcom 2011 에서 "Cloud Automation" 이라는 주제로 강연을 맡았다.  KT 프로젝트를 하면서 만난 김우현님의 소개로 하게된 이런 세미나에서의 강연은 처음이라 초반에는 좀 떨었지만, 말을 하면 할 수록 안정을 찾게되어 그래도 무난히 끝마칠 수 있었다.  

언론사에서 주관하는 행사라 그런지 역시, 크게는 아니지만 기사가 나기도.  기사에서는 "줄일 수 있다" 라는 부분에 대해서 강하게 언급을 했는데, 이것과 함께 "DevOPs" 라는 주제에 대한 설명도 나름 비중있게 다루었었는데 잘 전달이 되지못했나 보다.  어제 이야기의 핵심은,

  • 클라우드의 모토는 신축성이며, 필요할때 늘리고 필요 없을때 줄일 수 있어야 하며, 이런 신축성을 고려한 서비스 구조와 이를 뒷받침 하기 위한 자동화가 필요하다.
  • 서비스 인프라를 코드로 만들기 위해서는 시스템 관리자가 코드를 사용 할 수 있어야 한다. 특히, 오픈소스 인프라에 전문적인 지식을 가진 관리자의 코드 작성 능력은 반드시 필요하다.
  • 관리자는 전문 개발자가 아니기 때문에, 자동화를 위한 도구는 배우고 사용하기 쉬워야 하며, 이러한 툴로는 Ruby 기반의 Chef 와 Puppet 이 있다.
  • 비지니스 변화의 요구에 대응하기 위해, 서비스는 개발자에 의하여 계속 변경 될 수 밖에 없다. 이러한 변화는 장애를 발생 시킬 수 있는 주요 요인이 될 수 있으며, 이런 문제를 극복하기 위한 "DevOPs" 의 문화가 필요하다.
  • DevOPs 란, 자동화된 인프라스트럭쳐 위에 개발자와 관리자가 협업하는 방법에 대한 문화와 도구를 말한다.  개발도 하면서 관리도 하는 사람을 일컫는 말이 아님에 주의한다.
  • 분산을 위한 구조를 서비스 도입단계부터 고려하는 것은 클라우드 서비스에서 중요한 부분중 하나다.  현재 서비스의 데이터를 먼저 분석하고, 흐름을 볼 줄 알아야 하며, 이를 통해 서비스의 각 리소스를 3중화 하는 것에 대한 고려로서 시작한다.  1개를 2개로 서비스 하는것은 1개로 할때보다 어려우며, 2개를 3개로 서비스 하는것은 1개에서 2개로 갈때보다 훨씬 어렵다.  하지만, 3이 고려된 서비스는 클라우드 내에서 N개로 증식이 가능하다.


이런 말들을 조리있게 하고 싶었지만, 잘 되지 않은 듯.  주제를 너무 많이 잡았나 보다. 중간에 시계도 잘못보고 ㅠㅠ
어쨌든, 미디어에 얼굴박힌 사진과 함께 노출된다는건 참 신기한 기분.

http://news.inews24.com/special_page/nexcom2011.php?
http://photo.media.daum.net/digital/view.html?cateid=1008&newsid=20110518172707373&p=inews24

좋은 경험의 기회를 소개해 주신 김우현님과 inews24 측에 감사드린다.




마지막으로, 딴지에서 읽은 "읽은척 매뉴얼"의 사마천 사기에 다음 구절이 요새의 클라우드 분위기와 딱 들어 맞는 것 같아서 소개한다.

'[역(易)]의 '대전(大傳)' 에 이르기를 "천하 사람들의 의향은 서로 같으면서도
사고방법은 가지각색이며, 목적지는 다 같으면서도 가는 길은 서로 다르다"라고
하였다.'
딴지일보 읽은척 매뉴얼 - 사마천 사기 링크 : http://www.ddanzi.com/news/62834.html


팀장님이랑 그런 이야기를 했다. '목적지는 알고 가자.'  전에 일본 서치나에 올랐을때도 느낀거지만, 재미있는 세상이다.


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