세상은 참으로 빠른 것을 요구합니다. 모든 세상이 빠른 것을 탐하는 것은 아니지만 우리 주변에는 정말일까 싶을 정도로 빠르게 돌아가는 것들이 많습니다. 기즈모도(Gizmodo)에는 인터넷에서 1초 동안 일어나는 일을 재미있게 표현해 둔 그림이 있습니다(아래 그림 참조).

이 그림은 작년 7월에 작성된 것입니다. 우리가 생각하는 그 1초 동안에 더 많은 일들이 벌어질 것입니다. 1초라는 찰나를 위해 소요되는 기술도 많겠죠. 그런 기술들이 뭐가 있을까요? 그리고 오늘날 누구나 이야기하고 있는 빅데이터와는 어떤 관계가 있을까요? 위 그림에서 보는 것처럼 빠르게 생성되는 데이터는 쌓이고 또 쌓이면서 데이터의 크기가 커져서 빅데이터를 이룹니다. 즉 빠르게 생성되는 데이터 이른바 패스트 데이터(Fast Data)와 그로 인한 많은 데이터(Big Data)가 하나가 되면서 빠르면서도 큰 데이터(Fast and Big Data)가 되고 그 속에서 많은 인사이트를 얻고자 하는 것이 우리 시대의 과제인 것입니다.

1초라는 시간에서 발생되는 여러 현상 또는 사상을 우리는 흔히들 이벤트(Event)라고 합니다. 컴퓨터 세계에서 발생하는 이벤트는 참으로 다양합니다. 어떤 소프트웨어가 실행되면서 정상으로 처리되었으면 정상 처리를 알리는 이벤트를 만들고 문제가 있어서 중단되었으면 중단되었다는 이벤트를 만듭니다. 그러한 이벤트들의 일련이 하나의 저장소에 담기게 되면 그것을 우리는 로그라고 부릅니다. 비단 컴퓨터 뿐만은 아니겠죠. 우리의 자동차는 궁극적으로는 기계공학의 산물이지만 최근의 자동차는 점점 전자제품에 가까워져 갑니다. 아예 테슬라와 같은 자동차는 기계 공학의 집합체로서의 기계가 아닌 거대한 OS이면서 컴퓨터이고 하나의 전자제품입니다. 자동차에서의 각종 이벤트들을 모아서 분석해 본다면 어떨까요? 만약 배의 모든 동작 상황을 실시간으로 모니터링 하면서 즉각적인 어떤 조치를 취할 수 있다면 우리는 보다 안전한 세상에 살수 있을 겁니다.

이벤트 프로세싱(Event processing)이라는 이벤트의 흐름을 추적, 분석하여 결론을 도출하는 과정은 상당히 예전부터 거론되고 시도되었던 영역입니다. 이벤트 프로세싱에 복잡함(Complex)을 더한 것이 CEP(Complex Event Processing)입니다. 이벤트가 발생하는 여러 소스들로부터 받아 조합하고 연관관계를 맺음으로써 최대한 빠른 조치(Response or action)를 취하도록 하는 것이 CEP입니다. CEP라는 용어가 생소할 수 있겠지만 사실 주변에서 생각보다 많이 사용되는 것이 CEP입니다. 가장 대표적인 것이 주식 거래에서 사용되는데요, ‘알고리즘 주식 트레이딩’이라는 것이 있습니다. 트레이딩을 할 때 알고리즘에 기반해서 한다는 것인데요, 이 알고리즘이 동작할 수 있도록 하는 기초가 바로 CEP입니다. 환율, 유관 산업의 주가, 정책 당국의 메시지 등을 종합해서 필요 시점이 되면 바로 주식 매수를 하는 것이죠. 금융공학이라는 것의 근저에는 CEP가 깔려 있습니다. 그래서 트레이딩 시스템은 초호화 사양으로 만드는 것이 일반적입니다.

그렇다면 CEP는 어떻게 구성할까요? 요즘과 같은 오픈 소스 시대에서는 소프트웨어 선택의 다양성이 커졌고 이를 운영하기 위한 하드웨어도 점점 저렴해지고 있습니다. 쉬운 것부터 본다면 우선 DRAM 가격이 많이 내렸다는 점과 아울러 x86 서버에 탑재하여 시스템 운용이 보다 현실적인 수준으로 내려왔다는 사실입니다. 이제 DRAM을 4TB까지 꽂고 운영할 수 있는 수준이 되고 있습니다. 하나의 x86 서버에서 4TB의 메모리를 운영할 수 있다는 것은 인메모리 컴퓨팅을 더 이상 사치품이라고 생각하지 않아도 되는 것을 의미합니다. 이러한 현상은 비단 DRAM에 한정되지 않습니다. 플래시에 기반한 스토리지 기술도 역시 그렇습니다. 페이스북의 경우 플래시 기술을 이용해서 캐싱 디바이스로 사용함으로써 수 많은 페이지를 동시에 그렇게 많은 사람들이 볼 수 있도록 하는 것이죠.

패스트 데이터(Fast Data)를 위한 컴퓨팅 기술에서 핵심은 사실 하드웨어 보다는 소프트웨어입니다. 새롭게 설계되고 탄생되는 소프트웨어, 특히 오픈 소스 기반의 소프트웨어는 산업의 판도를 바꾸고 있습니다. 혹자는 심지어 “(기존의 전통적인 관계형) 데이터베이스는 이제 죽었다”고도 합니다. 전통적인 데이터베이스는 트랜잭션 중심으로 정형화된 형태로 세상에 대한 기록을 해왔으나 정형화할 수 없는 것들 또는 정형화하기 어려웠던 것들을 이제 컴퓨터 속으로 넣어 분석을 시도하고 있습니다.

전통적인 관계형 데이터베이스도 마냥 손 놓고 있지는 않습니다. 데이터베이스로 전세계를 평정하고 있는 오라클의 경우 얼마 전 인메모리 형태로 사용할 수 있는 옵션을 Oracle 12c를 통해 내놓았습니다. 컬럼(Column) 형과 로우(Row) 형을 모두 지원하는 이번 옵션 기능으로 기존 관계형 DB에 추가하여 보다 빠른 처리를 위한 방법으로 IMDB(In Memory Database)를 지원하는 것이죠. 오라클은 SAP HANA에 비해 비교적 늦었지만 HANA와 견주면서 HANA 따라잡기를 숨기지 않고 있습니다. 실제로 홈페이지를 통해 HANA와 인메모리 옵션과의 비교를 통해 적극적으로 알리고 있습니다.

전통적인 DB업체의 이러한 변화와 아울러 오픈 소스 계열의 움직임으로 아주 빠르고 혁신적입니다. RDB를 NewSQL이나 NoSQL이 대체할 수 있는 것은 아니겠지만 점차 그것도 알 수 없어 보입니다. 이를테면 Oracle을 구입하기 보다는 PostgreSQL을 사용하고 패스트 데이터 영역이라고 할 수 있는 IMDB와 In-Memory Data Grid(IMDG) 부문은 오픈 소스를 사용하는 것이죠.

인메모리 데이터베이스와 데이터 그리드는 패스트 데이터 기술의 핵심 중 하나입니다. IMDB와 IMDG는 유사하지만 사실 다릅니다. IMDG는 Oracle Coherence와 IBM WebSphere eXtreme Scale, 테라코타(Terracotta), 팁코 액티브스페이스(Tibco Activespace), JBoss Data Grid, Pivotal GemFire 등이 있습니다. 오픈소스 계열로는 헤젤캐스트(http://hazelcast.org)가 있고 헤젤캐스트는 오픈소스로 다운받아 자유롭게 사용할 수도 있지만 엔터프라이즈 제품(http://hazelcast.com)도 있습니다. 정확하게 IMDG는 아니지만 레디스(redis)나 카우치베이스(Couchase) 등도 대안이 될 수 있다고 하는군요.

IMDB와 관련해서 SAP HANA의 인지도가 높은 편이지만 사실 이 세계도 그렇게 절대 강자는 없어 보입니다. 국내에서는 알티베이스가 워낙 앞서가고 있고 선재소프트도 그 실력이 상당히 알려져 있으며 국내 상당한 비즈니스 성과를 보이고 있습니다. 오라클 역시 IMDB 제품이 있는데, 많이 팔리지는 않고 있습니다. TimesTen이라는 이 제품은 2005년 HP Lab에서 나온 제품을 인수한 것으로 Oracle 12c 출시 이후 어떻게 될 지는 지켜봐야겠죠. IBM의 SolidDB나 볼트DB(VoltDB), Pivotal GemFireXD 등도 있습니다. 최근에는 워낙 오픈소스 계열이 이쪽에 많이 나와 있습니다. 카산드라(Cassandra)를 비롯해 HBase, MongoDB, Neo4j, 카우치DB(CouchDB), 리악(Riak) 등등 대충 아는 것이 이 정도인데, 실제로는 더 많이 있을 것입니다. 위키피디어 한글판에서는 인메모리 데이터베이스에 관한 설명이 다소 엉성한데요, 영문 설명에서도 크게 낫지는 않지만 그래도 참조해 볼 만하군요.

CEP를 위해서 IMDB나 IMDG가 있다고 해결되는 것은 아닙니다. 다만 중요한 방법론으로서 인메모리 컴퓨팅 기술이 있지만 실제로 소스가 되는 기기에서 뿜어내는 그 많은 이벤트를 처리하면서 액션을 취하기 위해서는 아파치 스톰(Apache Spark)나 트위터 스톰(Twitter Storm) 등의 소프트웨어가 있습니다. CEP의 속성은 무엇보다도 ‘저장 후 처리’하는 방식에서 ‘처리부터’ 한다는 것입니다. 이를 위해서는 메모리에 기반해야 해야 하고 분산 처리를 해야 합니다. 하지만 분산 처리를 위해서는 어려움이 많은 모양입니다. 노드 간에 메모리를 공유하는 것이 녹록하지 않고 최근의 기술 중 하나인 RDMA(Remote Direct Memory Access) 기술에 대해 인식이 높아지면서 조만간 이러한 문제도 해결되지 않을까 생각해 봅니다.

지난 달 끝난 Spark Summit 2014에 올라온 영상과 자료를 보면 스파크 현재와 미래에 대해 자세히 알 수 있습니다. 이들 세션 중에서 특히 흥미로웠던 것은 Berkeley Data Analytics Stack(아래 그림 참조)이었는데요, 이 Stack의 완성도를 논할 수는 없겠지만 이것만 보면 앞으로의 패스트 & 빅데이터 분석에서 상당한 역할을 하지 않을까 하는 생각을 해 봅니다. 또한 빅데이터와 관련해 의미 있는 성과를 발표했습니다.

위 그림에서 가장 상단에 있는 SNAP이라는 기술을 통해 유전자 서열을 분석해서 병의 근본 원인이 무엇인지를 알고 그에 적합한 처방을 한다는 합니다. 여기서 빅 데이터 기술이 사용되었는데요, 의학용어의 압박으로 어려웠지만 몇 단어를 익히고 나니 그냥 그냥 읽을 법했습니다.

먼저 SNAP이 뭔지 알아 보았습니다. Scalable Nucleotide Alignment Program의 약자로서 일종의 의학용 분석 소프트웨어인데, 기존의 다른 툴(BWA-mem, Bowtie2, Novoalign 등)에 비해 3-20배 빠르고 정확하며, 일반적인 x86 서버에서 동작하는 오픈 소스 소프트웨어입니다. 또한 SANP은 아마존 클라우드에도 올라가 있어 클라우드 기반의 서비스로도 가능합니다. 생명정보학에서의 빅데이터 사례는 흔히들 나오고 있는데요, SNAP은 유전자 서열 정렬(sequence alignment)에 관한 정보를 제공합니다. 서열 정렬을 이해하기 위해서는 먼저 서열을 이해해야 하는데요, 유전자 서열에 관한 연구는 생명체에 나타난 현상을 이해하기 위한 것이고 서열 데이터만으로는 모든 현상을 분석하고 이해하기 어렵고 그래서 서열 정렬이라는 방법으로 서열 분석을 합니다. 단백질 서열과 핵산 서열 사이의 상관관계를 나타내는 방법으로 서열 정렬을 통해 발현되는 현상에 대한 분석을 한다고 하는군요.

빅데이터에 근거한 SNAP 성공사례는 이미 버클리 대학의 홈페이지에 공개되어 있는데요, 이번 Spark Summit에서 이를 정리하여 발표했습니다. 홈페이지에 따르면 미국 내 2만여 명, 이들 중 대개는 어린 아이들인데, 뇌염(brain-swelling encephalitis)으로 매년 입원을 하게 되고 이들 중 60%는 의사들이 정확한 원인을 모른 채 심각한 상황으로 이어진다고 합니다. 실례로 현재 나이 15세의 코마 상태에 있었던 조슈아 오스본은 정확한 원인을 모르고 있던 와중에 마지막 테스트를 해 보자는 의사의 제의에 부모가 동의했고 조슈아의 척수를 채취하여 SNAP 테스트를 하였습니다. 테스트를 시작한 이틀이 안되 결과가 나왔는데, 아주 희귀한 박테리아에 감염되었고, 항 박테리아 치료를 열흘 동안 실시한 끝에 코마에서 깨어났고 그 후 4주가 지나서 퇴원을 했습니다.

증상의 원인을 정확히 모르면 경험이나 지속적이고 다양한 시도를 하게 되는데, 원인 분석을 정확하고 빠르게 할 수 있는 SNAP 덕분에 적절한 치료를 하게 되었고 그 결과 코마 상태에 있던 한 생명이 부모의 곁으로 되돌아 갈 수 있었다는 사실은 분석이 가지는 대단한 힘입니다. 여타의 다른 방법에 비해 빠르고 정확하기 위해서 IT 기술이 뒷받침 되어야 했고 오픈 소스 소프트웨어 Apache Spark가 가지는 강점을 증명하는 한 사례일 것입니다.

Spark에 대해 좀 더 살펴 보고 끝내겠습니다. Spark는 2009년 프로젝트로 시작하여 2010년 오픈소스로 공개되었고 2012년에 알파 버전이 나왔습니다. 버클리, 프린스턴, 클라우트(Klout), 포스퀘어(Foursquare), 야후 등에서 사용되고 있으며 맵리듀스(MapRedue)가 가지는 배치 성격으로는 보다 더 복잡해지고(more complex), 보다 더 인터랙티브(more interactive)해 지는 요구에 대응하기 위해 기존의 디스크 기반의 처리에서 벗어나 메모리 상에서 구현하는 것입니다.

최근에는 SparkSQL, MLib(machine learning), GraphX(graph processing), 모니터링 및 HA 등도 수용하고 있습니다. 또한 호튼웍스(Hortonworks), MapR, 클라우데라(Clouera), 피보탈(Pivotal) 등의 하둡 배포판에도 통합되었고 AWS와의 통합성을 제공하고 있습니다.

Spark Summit 2014에 올라온 자료에는 성공사례와 적용을 하면서 얻게 된 교훈들이 있습니다. 해당 세미나의 동영상 데이터 역시 유투브를 통해 확인할 수 있는데요, 개발자들에게 상당히 유용할 것 같습니다.

빅데이터, 그리고 패스트 데이터 그것을 위한 플랫폼 기술에는 인 메모리 데이터 그리드, 인 메모리 데이터베이스, CEP(Complex Event Processing) 등 많은 것들이 있습니다. 이 밖에 더 많습니다. 하나의 기술이 특화되지도 않고 서로 엉켜서 동작합니다. 오픈 소스 소프트웨어는 그 소프트웨어들이 서로 엮여져 하나의 소프트웨어나 솔루션이 되기도 합니다. 그리고 앞서의 예에서 보는 것처럼 빅데이터 기술이 사람의 생명을 살리는 마음 따뜻한 사례도 볼 수 있었습니다. 속도만을 앞세워 정작 중요한 것을 보지 못하고 사고를 내지 말고 속도와 정확성으로 원인을 바라보고 올바른 치료법을 제시하는 것이 필요한 시대입니다.

- fin -

저작자 표시 비영리 동일 조건 변경 허락
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

클라우드 파운드리와 오픈스택은 모두 오픈소스 기반의 강력한 커뮤니티와 상당히 많은 스폰서 기업들이 후원을 하고 있고 이미 공개된 코드와 지금 이시간에도 계속해서 공헌(contribution) 이 이뤄지고 있습니다. 또한 클라우드 파운드리(Cloud Foundry; 이하 CF)와 오픈스택(OpenStack) 모두 클라우드 기술에 있어 상당히 많은 기여를 하고 있고 사실상의 표준(defacto standard)를 위해 나가고 있다는 생각이 듭니다.

오픈스택과 CF, 이 두개의 기술 결합은 이미 IT 거대 기업들이 테스트를 하고 있습니다. 어떻게 통합(integration)할까요? IaaS 부문인 오픈스택과 PaaS 영역인 CF를 통합하기 위해서는 BOSH가 필수입니다. BOSH는 클라우드 파운드리에서 제공하고 있는 것으로서 CPI(Cloud Provide Interface) 중 하나입니다. 클라우드 파운드리는 여러 가지 CPI를 제공하고 있는데요, 그중 하나가 오픈스택과의 연계를 위해서 제공되는 것이 BOSH이고 그밖에 AWS나 VM웨어와의 연계를 위한 CPI도 있습니다. 이는 다시 말해서 IaaS가 AWS나 VM웨어로 구성되어 있거나 아니면 여기와 같이 오픈스택과의 연계는 얼마든지 가능하고 또 다른 의미는 하이브리드 클라우드를 만들기 위한 조건으로서 클라우드 파운드리는 상당히 고려해야 할 요소라고 할 수 있습니다.

위 그림은 오픈스택과 클라우드 파운드리가 통합 연계되는 것을 간단히 표현해 본 것인데요, 그렇다면 BOSH에서 어떻게 적용(deploy)하는지 보겠습니다. BOSH는 그 자체로 존재하기 보다는 기존에 있는 오픈소스 세프(Chef), 포그(Fog), 루비(Ruby) 등을 이용합니다.

오픈스택 설치 자동화를 위한 세프(Chef): Chef를 사용하면 자동화를 할 수 있는데, 이것 역시 오픈 소스 기술입니다. 오픈스택 컨트롤러와 컴퓨트 노드, 네트워크 정보, 오브젝트 및 블록 스토리지 등의 설치와 셋업을 할 수 있는데, 45분만에 빈깡통 상태에서 시작하여 설치까지 완료할 수 있다고 하는데, 상황에 따라 다르겠죠.

포그(Fog)를 이용한 탐색 자동화(discovery automation)와 설정 자동화(Setup automation): 포그 역시 오픈소스로서 세프와 마찬가지로 오픈스택에서 사용할 수 있는 도구 중 하나입니다. 포그는 루비 클라우드 서비스 라이브러리(Ruby cloud service library)로 오픈스택의 각종 정보를 찾을 수 있도록 하는 것입니다. 예를 들어 클라우드 파운드리 적용을 할 때 크레덴셜(Security credentials)을 비롯하여 VM 구성, 네트워크 서브넷, 네트워크 보안 규칙(Network Security Rules), DHCP, DNS, Gateway 등의 정보를 찾을 수 있도록 합니다. 이러한 정보 확인 및 탐색 자동화 뿐만 아니라 설정 자동화(setup automation)도 할 수 있습니다. 크레덴셜(security credentials)을 생성하거나 VM에 들어가는 네트워크 설정, 보안 규칙(security rules), 가입자 용량(tenant quota) 설정 등을 할 수 있습니다.

BOSH와 Ruby를 이용한 클라우드 파운드리 적용 자동화(deployment automation): OS 이미지 또는 줄기세포(Stemcell)의 수정/변경 등을 자동화 할 수 있다는 것입니다. 또한 Ruby ERB 템플릿을 이용하여 클라우드 파운드리에서 사용할 매니페스트(Manifest) 파일을 자동으로 만들 수 있습니다. 번거로운 작업들의 자동화는 생산성으로 연결되는데, 특히 오픈스택과 클라우드 파운드리 간의 조합은 최고의 조합이라는 이야기를 합니다.

그런데 앞서 이야기 하고 있는 세가지 유용성들은 BOSH를 알아야 하는데, BOSH에 대해 좀 살펴 보겠습니다. 현재 클라우드 파운드리는 버전 2입니다. 버전 1은 VM웨어 시절에 내놓은 것이고 그것을 오픈 소스 커뮤니티에 공개함으로써 오픈소스로서 클라우드 파운드리가 탄생하게 됩니다. 클라우드 파운드리를 이용하여 cloudfoundry.com을 운영하면서 CF의 각종 컴포넌트가 독립적이고 확장적이기 때문에 설치를 비롯해 운영, 관리 등을 위한 중심 도구가 필요했고 그래서 탄생하게 된 것이 BOSH입니다. 따라서 BOSH는 IaaS에서 제공하는 다양성과 IaaS와의 커뮤니케이션을 위해 상대적으로 무겁다는 평가를 받고 있습니다.

BOSH는 패키지(Package), 작업(Jobs), 줄기세포(Stemcells), 릴리즈(Release), 매니페스트(Manifest) 등으로 구성됩니다. 줄기세포(Stemcells)는 Base OS와 BOSH 에이전트로 구성되고, 작업(Jobs)은 소프트웨어 패키지, 구성 템프릿(Config template), 스크립트 등으로 구성됩니다. 적용 매니페스트(Deployment Manifest)는 릴리즈 이름과 버전(release name/version)과 VM 수, 작업 파라미터, 사용할 줄기세포 등을 정의합니다.

샘플 매니페스트 파일을 보면 쉽게 이해가 됩니다. 아래 그림은 클라우드 파운드리에서 제공하는 예제 매니페스트 파일에서 MySQL 부문만 본 것입니다.

 


http://docs.cloudfoundry.org/deploying/vsphere/cloud-foundry-example-manifest.html

학습해야 할 양이 많습니다. 지난 몇 주 동안 클라우드 파운드리에 관한 깊은 관심을 가지고 있습니다. 앞으로도 상당히 기간 동안은 여전히 CF에 관심과 학습을 할 것입니다. 계속 다듬어 보겠습니다.

- fin -

신고
크리에이티브 커먼즈 라이선스
Creative Commons License


 

티스토리 툴바