본문 바로가기

Home > 열린마당 > 공개SW 소식

공개SW 소식

클라우드 기반 스트리밍 데이터 처리 주목...왜?

OSS 게시글 작성 시각 2015-07-20 18:16:03 게시글 조회수 3391

2015년 07월 14일 (화)

ⓒ 지디넷코리아, 김우용 기자 yong2@zdnet.co.kr



‘키네시스, 애저 이벤트허브, 데이터플로’


최근 2년 사이 아마존웹서비스(AWS), 마이크로소프트(MS), 구글 등 퍼블릭 클라우드 빅3가 경쟁적으로 선보인 서비스들이다. 모두 스트리밍 데이터 처리와 관련된 서비스로 ‘강물처럼 흐르는 데이터의 파이프라인’이다.


세 회사는 하둡 플랫폼 서비스를 시작으로 빅데이터를 위한 전용 데이터베이스, 분석도구 등을 내놨고, 이제 배치 분석을 넘어 스트리밍 데이터 영역으로 발빠르게 서비스를 확대하고 있다.


3사가 주거니 받거니 하며 스트리밍 데이터 처리 서비스를 내놓은 건 우연일까. 그 서비스들이 ‘서비스형 플랫폼(PaaS)’의 형태로 제공되고 있다는 점도 주목할 만하다. 이같은 현상 뒤엔 프로그래밍 단계부터 데이터를 고려하는 개발 방법론의 흐름이 있다.



빅데이터, 사물인터넷(IoT), 머신러닝 등 최근 IT업계의 핫이슈는 공통적으로 방대한 데이터를 어떻게 다룰 것인가를 핵심에 둔다. 초기 빅데이터의 흐름이 수많은 데이터를 어떤 방식으로든 저장해둔 뒤 인사이트를 찾는 쪽이었다면, 이제 흘러가는 데이터에 실시간으로 쿼리를 날려 즉각적으로 활용하는 것도 중요해졌다.


하지만, 스트리밍 데이터를 분석하는 일은 만만치 않다. 데이터의 양도 많고, 형태도 소스에 따라 제각각이어서 쿼리를 날리기 좋게 정리돼 있지도 않다. 무엇보다 데이터가 끊임없이 흘러 들어와야 한다. 형태야 어떻든 일단 받아놓고 봐야 한다


김재우 한국MS 부장은 “일정기간 데이터를 모아 간헐적으로 분석하는 전통적인 ETL 방식을 활용할 수도 있다”며 “그러나 사용자를 붙잡고, 시스템과 서비스의 지능을 높이려면 실시간 분석이어야 한다”고 설명했다.


이렇게 되면 IT 아키텍처는 3가지 구성요소를 필요로 한다. 일단 이벤트 소스가 필요하다. 데이터가 이벤트다. 그리고 이벤트 소스를 흐르게 하는 파이프가 있다. 마지막으로 흘러들어온 데이터를 모아둘 이벤트 싱크가 있어야 한다. 세 요소는 비동기식으로 작동한다.


여기서 파이프, 즉 스트림은 오랜 시간동안 기술적으로 발전해왔다. AWS의 키네시스, MS 애저 이벤트허브, 구글클라우드플랫폼 데이터플로 등은 이벤트 소스를 끊임없이 흘러들어오게 만드는 파이프를 제공한다. 개발자가 힘들게 파이프를 만들 필요가 없어진 것이다.


그리고 이벤트 싱크도 빠르게 발전하고 있다. 수많은 NoSQL 데이터베이스와 더불어 AWS의 다이나모DB, MS의 애저 데이터스토어(저장소), 구글의 클라우드데이터스토어 등 유연하고 안정적으로 확장되는 클라우드 기반의 이벤트 싱크가 존재한다.


문제는 애플리케이션이나 서비스를 개발하는 차원에서 어떻게 이벤트와 데이터 스트림을 처리하느냐다. 전통적인 객체지향프로그래밍(OOP) 패러다임을 벗어나 다른 발상이 필요해진다.


이벤트 드리븐 프로그래밍, 함수형 리액티브 프로그래밍(FRP), 데이터플로 프로그래밍 등 데이터를 맨 바탕에 둔 개발 모델은 이같은 요구에 따라 각광받는다. 자바스크립트를 활용한 웹 GUI 개발이나, 클라이언트 소프트웨어의 GUI에서 이벤트를 다뤄온 방식이 서버 사이드 개발까지 확장되고 있는 것이다.


전통적인 OOP 패러다임은 변화무쌍한 변수를 처리하는데 한계를 갖고 있다. OOP는 상태(state)를 메모리의 주소를 정해서 값을 바꿔 덮어쓰기(overwrite)는 식으로 관리하기 때문에 실시간으로 바뀌는 상태의 변화를 활용하기 까다롭다. 과거가 없으므로 변화의 흐름에서 미래를 추론하기도 어렵다(물론 자바와 C#이 스트림 피처를 추가하면서 한계를 극복하고 있다).


‘프리젠테이션-애플리케이션-데이터’로 이뤄지는 3계층 아키텍처도 스트림 데이터를 활용하기에 적합하지 않다. 이 아키텍처는 데이터를 저장한 뒤 활용하는 배치성 분석에 적합하다.


스트림 데이터를 실시간으로 활용하려면 프로그래밍을 위한 그림을 완전히 달리 그리는 게 필요하다. ‘이벤트 소스-스트림 파이프-이벤트 싱크’로 전체 뼈대를 만들고, 정형화된 분류법에 따라 특정 이벤트를 걸러내는 ‘필터’, 혹은 ‘이벤트 리스너(listener)’를 스트림에 붙여 이벤트 발생에 반응하게 하는 식이다.


이때 동시성(concurrency) 확보와 상태 문제 해결을 위해 함수형 패러다임을 활용하는게 유용하다. 자바스크립트처럼 람다 표현식을 사용하거나, 시간의 흐름에 따라 상태의 변화값을 리스트(list)로 만드는 것이다. 후자의 경우가 좀더 유연한데, 특정 순간의 상태값을 알기 위해 시점만 알면 된다. 이벤트 발생 시점에 따른 모든 값을 누적될 가치가 있는 것으로 본다는 게 중요하다.


AWS의 경우 아예 이벤트 드리븐 애플리케이션을 쉽게 구성할 수 있는 서비스도 내놨다. AWS 람다 서비스다. AWS 람다는 이벤트 발생에 응답해 코드를 실행하고, 백엔드의 컴퓨팅 리소스를 자동으로 관리해준다.


라이브러리 형태의 이벤트 스트림 파이프도 있다. MS에서 만들어 오픈소스로 공개한 ‘리액티브익스텐션(Reactive Extentions, RX)’이 대표적이다. RX는 코널 엘리엇(Conal Elliott)의 함수형 리액티브 애니메이션(FRAN)에서 나왔다. FRAN은 가상현실마크업언어(VRML) 표준을 두고 실리콘그래픽스와 경쟁하던 MS가 다이렉트X 이전에 만든 하스켈 그래픽 라이브러리다.(☞함수형 리액티브 프로그래밍에 대한 코널 엘릿엇의 스택오버플로 답변)


RX는 비동기식 데이터 스트림을 구성하게 해준다. MS에서 만든 만큼 초기에 닷넷 프레임워크만 지원했었다. 오픈소스로 풀리면서 자바스크립트, C/C++, 파이선3, 루비 등도 지원하게 됐다.


RX를 사용해 데이터 스트림 구조를 효과적으로 구성한 대표사례는 넷플릭스다. 넷플릭스는 자바용 RX를 만들어 넷플릭스API 아키텍처를 새롭게 구성했다. 클라이언트와 서버 간 빈번한 통신을 줄여 성능을 높였고, API 개발을 여러팀으로 분산시켰으며, 분산처리시스템의 동시성을 확보했다.(☞넷플릭스 블로그 바로가기)


넷플릭스 API 다이어그램

넷플릭스 API 다이어그램


넷플릭스는 RX를 자바가상머신(JVM)에서 사용할 수 있는 라이브러리 ‘RxJava’를 만들었고, 이를 오픈소스로 내놨다. RxJava는 자바6 이후 버전에서 활용할 수 있다.


김재우 부장은 “이벤트 데이터 스트림이 계속 들어오는 가운데, 전통적인 OOP 모델에선 계속 I/O가 발생하므로 값비싼 프로세싱이 된다”며 “함수형 패러다임을 응용한 이벤트소싱 기술을 쓰면 리스트를 통째로 저장하기때문에 I/O가 계속 발생하지 않고, 순간의 단면을 쿼리로 파악하기도 좋다”고 설명했다.


그는 “이벤트 드리픈 프로그래밍은 특정 서버에 기능을 구현하기 위한 기술의 일부로 보기엔 큰 주제다”라며 “전체 서비스 구조를 밑바탕부터 바꿔야 하는 것이므로, 명령형 프로그래밍으로 일단 만든 뒤 나중에 구조를 개선하면 공수가 너무 많이 들어간다”고 말했다.




※ 본 내용은 (주)메가뉴스(http://www.zdnet.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒ 지디넷코리아. 무단전재 및 재배포 금지


[원문출처 : http://www.zdnet.co.kr/news/news_view.asp?artice_id=20150714140612]

맨 위로
맨 위로