실시간 빅 데이터(Real-time Big Data) 프로세싱 맛보기

오늘은 빅데이터의 실시간 빅데이터 프로세싱에 대해서 적어볼까 합니다. 빅데이터를 배치 프로세싱을 하기도 벅찬 마당에 실시간 프로세싱이라니 이게 말이나 될 성 싶을까라고 말하시는 분들도 있을테구요. 어떤 분들은 실시간 임베디드 시스템을 생각하면서 이건 실시간이 아니야라고 하실 수도 있을 것 같습니다. 아무튼 용어에서 오는 혼란을 피하기 위해서 일단 실시간(real-time) 컴퓨팅 또는 프로그램이라는 것에 대해서 그 정의를 다시 한번 정리해보도록 하겠습니다.

실시간 컴퓨팅이라는 것은 엄격히 정해진 시간내에 응답을 보장해주는 것을 말합니다.  즉 주어진 시간안에 필요한 프로세싱을 해서 결과를 내주거나 처리를 하게 되면 이를 실시간이라고 말하는 것이죠. 주어진 시간이 1/10초 이내 일 수도 있고 1초 이내일 수도 있고 심지어는 1분 이내 심지어 그 이상이 될 수도 있습니다. 물론 일반적으로 컴퓨팅에서 실시간이라고 한다면 밀리세컨드, 마이크로세컨드 내에게 응답을 하는 시스템이라고 생각하면 됩니다.  더불어 실시간 컴퓨팅과 고성능 컴퓨팅과 헷갈리지 마시길 바랍니다.

일반적으로 실시간 컴퓨팅은 임베디드 시스템과 같은 곳에서 특정 인터럽트가 발생했을 때 처리하는 응답을 보장하기 위해서 설계하고 적용되는 분야인데 이것을 이제 데이터 프로세싱이라는 관점 , 특히 실시간 데이터 분석이라는 관점에서 보았을 때 생각해 볼 수 있는 다양한 응용들이 있을 수 있겠죠. 그래서 그런지 이런 쪽은 near real-time (거의 실시간?) 이라는 표현을 씁니다. 실시간에 가까운 데이터 처리라는 의미로 보면 될 것 같습니다.

예를 들어 주식거래의 트랜잭션을 분석해서 사람이 아닌 프로그램에 의해서 주가 조작이 일어나는지를 패턴을 분석,학습해서 이를 실시간으로 패턴매칭을 해서 주가조작하는 계정을 찾아내거나 하는 경우에 실시간 분석 기술을 활용합니다.

최근 스마트 그리드라고 하는 지능형 전력 관리 시스템에서 실시간으로 전력현황을 모니터링해서 효율적으로 전력을 공급하거나 하기 위해서 활용하는 케이스들도 소개가 되고 있습니다.

좀더 생활에 밀접한 경우들 들자면 어느 상점에서 물건을 사면 그 물건과 관련된 상품을 구매고객의 핸드폰에 바로 광고한다는가 사람들이 강남역에 내리게 되면 그 사람의 선호에 맞는 근처 식당을 소개하는 광고 문자를 보내준다든가 하는 시나리오들이 그런 예라 할 수 있겠죠. 더 구체적으로 설명하자면 어떤 고객이 어느 지역에 진입했다는 것을 바로 알아채서 그 사람의 평소 선호정보를 바탕으로 그 지역에 방금 어떤 물건을 사거나 식당에 들어갔는지를 알아내서 (예를 들어 매운 음식을 먹었다면) 그 다음에 그 사람이 원할 수 있는 것 (근처 아이스크림 가게를 소개하는 문자) 을 제공하는 사용자 시나리오라 할 수 있습니다.

이러한 것을 위해서 이미 시장에는 CEP (Complex Event Processing) 라고 하는 다양한 실시간 이벤트를 분석할 수 있는 기술이 개발되고 이를 기반으로 다양한 솔루션들이 나와 있습니다.

CEP 솔루션들은 매우 다양한 데이터 소스와 연결되는 어뎁터를 제공하거나 커스텀 어뎁터를 만들 수 있는 개발도구를 제공하고 있습니다. 특히 EPL(Event Processing Language) 또는 EQL(Event Query Langauge) 이라는 스크립트 언어를 통해서 SQL에 익숙한 개발자나 데이터 관리자가 직관적으로 데이터(이벤트) 모델링과 프로세스를 설계해서 적용할 수 있다는 장점을 가지고 있습니다. 또한 상용 솔루션들은 이러한 프로세싱을 모델링할 수 있는 GUI 도구와 프로세싱 상태를 모니터링할 수 있는 관리도구를 함께 제공하고 있기 때문에 매우 편리합니다. 충분한 개발비와 투자할 수 있는 여력이 있는 곳에서는 당연히 이에 대한 도입과 적용을 하는 것이 현명하겠습니다. 지금까지 CEP 는 기업 시스템의 BI 나 비지니스 프로세스 관리 시스템과 같은 곳에 활용되어져 왔습니다.

보다 직관적으로 설명하자면 RDBMS 는 데이터가 저장된 데이터소스에 원하는 데이터 명령을 (쿼리문) 내려서 원하는 데이터를 끄집어내는 것이라고 본다면  CEP 또는 이벤트 프로세싱은 미리 정의된 쿼리문이나 특정 조건을 이벤트 프로세싱 엔진에 저장하고 이곳에 데이터 스트림을 흘리면서 해당되는 이벤트 패턴 추출하거나 감지하는 것이라고 생각하시면 됩니다.

CEP와 관련한 자료들은 검색을 해보시면 다양하고 많은 자료를 쉽게 찾으실 수 있습니다만 아래 자료가 나름 용어들과 구체적인 예를 들어 설명을 해놓은 자료이니 참고하셨으면 합니다. (무려 70페이지!!)

http://www.slideshare.net/aparnachaudhary/esper-cep-engine

사실 지금까지의  CEP 솔루션 기술은 빅데이터에 적합한 수평적인 확장성(scale-out) 을 갖추고 있지 않습니다. 다시 말하면 이벤트 스트림별로 여러대의 서버로 부하 분산을 하거나  여러개의 네트워크 카드가 있고 수백기가 메인메모리를 갖춘 고성능 서버를 이용해서 대량의 이벤트 처리를 할 수 있는 아키텍쳐(scale-up) 를 가지고 있습니다. 즉 동일한 아키텍쳐를 유지하면서 복수의 서버를 이용해서 클러스터를 구성,  성능 확장을 할 수 있는 구조는 아닌 것이죠.

위 자료중에 보면 다음과 같은 내용이 나옵니다. 이벤트 스트리밍 프로세싱과 복합 이벤트 프로세싱의 차이점에 대해서 얘기하는 부분입니다.

  • Event Stream Processing is focused more on high-speed querying of data in streams of events and applying mathematical algorithms to the event data.
  • Complex Event Processing includes event data analysis, but places emphasis on patterns of events, and abstracting and simplifying information in the patterns.

실시간 빅데이터 분석이라는 관점에서 본다면 CEP 보다는 ESP 의 접근이 더 맞다고 생각됩니다. 물론 각자 적용하는 범위에서 어떠한 기술을 사용해야하는지는 도메인의 특성에 맞게 선택을 하거나 아쉽지만 특성에 맞게 기술을 적용해야 할 것입니다.

아래는 ESPER을 제외하고는 상용 CEP 솔루션들입니다. 참고하시길 바랍니다.

이밖에 오픈소스로 최근 공개된 실시간 빅데이터 분석 프레임워크들은 다음과 같은 것들이 있습니다. CEP 보다는 분산 ESP 프레임워크들이라고 보면 될 것 같네요.

  • Apache S4 : Distributed Stream Computing Platform. 야후! 에서 공개한 오픈소스 기반의 실시간 프로세싱 프레임워크입니다.
  • Twitter Storm : Distributed Real-time Computing System. Backtype 이라는 회사를 인수하면서 공개한 분산 실시간 컴퓨팅 시스템, Esper 엔진을 결합할 수 있는 특징을 가지고 있습니다
  • HStreaming : Scalable Real-time Analytics Platform. hadoop pig 을 확장해서 실시간 처리를 할 수 있는 기능을 추가한 것입니다.

원래 이 포스팅을 쓸때 생각은 위의 프레임워크들에 대한 아키텍쳐와 특징들에 대해서 나름 비교를 해 볼 생각이었는데 아래와 같이 간단히 소개하는 정도로 정리를 했습니다.

아파치 S4 는 야후! 에서 실시간 개인화 검색광고를 구현하기 위해서 개발된 것입니다. 아직은 아파치 인큐베이터 프로젝트로 등록되어 있습니다. 얼핏보면 문서화도 잘되어 있고 한데 왠일인지 작년 8월 이후 활동이 좀 뜸한 듯 보입니다.

스톰은 원래 Backtype 이라는 회사가 개발한 것인데 트위터가 인수를 했죠. 그리고 얼마 있다가 이 기술을 공개했습니다. 수평적 확장성을 가진  아키텍쳐 입니다.  흥미로운 것은 ESPER 엔진을 플러그인으로 설치해서 EPL 을 사용할 수도 있을 것 같더군요. 물론 어느 정도 수준에서 결합이 되었는지는 아직 확인을 하지 못했습니다만 그만큼 확장성도 갖추고 있지 않다 싶습니다. 또는 커뮤니티의 활동이 활발하다는 증거일 수도 있겠죠.

HStreaming 의 접근 방법은 매우 재미있는데 Pig 의 Load / Store 에 지정하는 데이터 소스와 싱크를 HDFS이 외에 실시간  데이터 스트리밍을 받아들일 수 있도록 I/O 를 확장하고 CEP와 같은 time window 등을 지정할 수 있도록 함으로써  하둡의 프레임워크 상에서 실시간 데이터 프로세싱을 할 수 있도록 했다는 점입니다.


  • IBM InfoSphere Streams 는 오픈소스는 아니지만 빅데이터 프로세싱에 적합하게 개발된 아키텍쳐와 확장성을 갖추고 있고.  9.11테로 이후 미정부가 실시간 데이터 분석을 위해서 IBM에 의뢰해서 개발한 솔루션을 상용화한 것이라고 들었습니다. 사이트에 들어가시면 다운로드 받아서 테스트 해볼 수 있다고는 하지만 IBM 에 요청해서 교육지원을 받으시는게 더 좋을 것입니다.

개인적으로는 스톰이 상당히 관심이 갑니다. 일단 그 아키텍쳐와 프로그래밍 모델이 하둡과 매우 유사하고 커뮤니티의 개발 활동이 활발하니까요.  contrib 프로젝트들도 여럿 있고 여러가지 언어를 지원하는 것을 보면 보다 활용하는데 적합하지 않을까 생각이 드는 거죠. 이쪽을 좀 뒤지다보니 Scala 을 쓰는 개발자들이 제법 되는군요. 스톰 소스코드를 슬쩍 뒤져보니 (내용을 구체적으로 본건 아닙니다)  Java, Clojure, Python, Ruby, Scala 언어들이 보이는 군요.

결론적으로 저의 생각은 이렇습니다. 왠만하면 메인메모리 많이 꽂아서 적당한 CEP 솔루션으로 실시간 처리를 해도 충분합니다. NoSQL보다는 RDBMS 로 하면 속편한거랑 마찬가지인 거죠. 그래도 상용 솔루션이 너무 비싸다면 ESPER 의 도입을 고려할만 하지만 편리한 UI 툴이나 관리도구는 결국 돈주고 엔터프라이즈 버전을 사야합니다. 아니면 직접 개발을 해야 합니다.

매우 큰 규모의 이벤트 스트림을 처리하고자 하고 향후 확장성을 고려한다면 역시 IBM 의 솔루션이 좋은 대안이 될 것이겠지만  역시 돈이 많이 들겠죠? 이럴때 트위터의 스톰을 적용을 검토해보는 것도 좋을 것 같습니다.

오픈 소스를 선택해야 한다면 제가 앞서 포스팅한 오픈 소스를 선택해야 할 때 고려할 점들을 꼭 명심하면 좋을 것 같습니다.

이벤트 스트림 프로세싱 플랫폼들에 대한 얘기를 더했으면 하는데 너무 CEP 라는 측면에서의 얘기를 초반에 너무  많이해서 좀 아쉬움이 남네요. 글도 좀 두서가 없구요. 솔직히 말씀드리면 ESP 에 대한 공부가 아직 부족해서 그렇습니다. 앞으로 좀더 연구할 시간이 나면 다시 한번 다루어 보는 것도 좋을 것 같다는 생각이 듭니다만.

아무튼 오늘 글까지 해서 기술적으로 깊이 있는 내용을 다루진 않았지만 그간 제 경험과 머리속에 있는 빅데이터 관련한 것들을 대충 풀어놓은 것 같네요.

Advertisements
이 글은 IT 카테고리에 분류되었고 , 태그가 있습니다. 고유주소 북마크.

실시간 빅 데이터(Real-time Big Data) 프로세싱 맛보기에 1개의 응답

  1. Taehui Hong댓글:

    좋은 정보 감사합니다.

  2. calmglow댓글:

    IBM Business Events는 내부적으로 object grid라는 그리드기반의 memory cache를 쓰고 있어서 매우 자유로운 scale out기능을 제공합니다. oracle의 CEP도 coherence를 사용해서 확장성을 유연하게 가져갈수 있을겁니다. IBM은 국내 사례가 좀 있는데, oracle도 있는지는 잘 모르겠네요. 그리고 LG CNS의 Event Pro라는 CEP솔루션도 빼먹으시면 섭하죠. 자그마치 5년 넘게 국내시장에서 준비해온 솔루션인데요…. CEP라는게 아무래도 현업에 매우 가깝게 쓰여져서 실시간적인 분석과 반응을 보여야해서 개인적으로 EPL이나 EQL같은 엔지니어적인 언어를 활용한 사용자 인터페이스를 기존 CEP 엔진들이 계속 유지하면.. 시장에서의 반응이 별로 좋지 않을까 하는 생각이구요.. 국내 CEP솔루션들은 이러한 사용자 친화적인 측면에서 많은 강점을 보이려고 노력하는 듯 합니다.
    아, IBM의 Infosphere Streams는 정말 연구소에서 만든 티가 팍팍 나는… 그런 솔루션인데요.. 음.. 기능도 좋고 성능도 좋은데, 나름 제공하는 스크립트 언어가 좀 배우기가 좀 껄끄럽습니다. 바이너리 데이터가 무지막지하게 들어오고 그것들을 패턴처리화하는 능력이 좀 괜찮은 듯 합니다. 그래서 CCTV 이미지라던지 음성 처리등을 대량으로 하는 용도등으로는 탁월할것 같은데.. 요즘의 유행인 실시간으로 유연하게 ESP처리하는 범용적인 용도로… 잘 감이 안오네요.
    아무튼 드디어 주위에 CEP에 관심가지시는 분들이 늘어나서 기쁩니다. 비록 저는 그 바닥을 떴지만. ^^

    • kimws댓글:

      역시 고수들이 계시는군요. 전 5-6년전 쯤 전 직장에서 디바이스의 상태를 실시간으로 체크하기 위해서 TIBCO의 솔루션을 기반으로 프로젝트를 진행한 경험이 있었습니다. 지금도 마찬가지지만 CEP가 그리 범용적인 시스템은 아닌지라 솔루션 엔지니어도 별로 없고 비용도 무지 비싸더군요. IBM Infostream은 기술적으로나 학문적으로나 완성도가 높지만 넘 비싸죠. 아직은 구체적인 사례는 많지 않아보이더군요. 다만 미국의 국방프로젝트에 쓰여져서 증명이 된 것이니 신뢰할만하다고 생각합니다. 좋은 말씀 감사합니다

  3. 이상부댓글:

    CEP 검색하다가 들어오게 되었습니다.^^;
    저희도 이번에 EsperCEP 기반으로 CEP 솔루션(CEP엔진,실시간 대쉬보드,알람,리포팅 등 스위트)
    을 개발했습니다.
    자주 들어오도록 하겠습니다. 수고하세요^^!

    • kimws댓글:

      아 그러시군요. EsperCEP 로 전직장에서 비슷한 모습으로 프로젝트를 했었습니다. CEP로는 활용할만한 것이 Esper 밖에 없어서. 다른 솔루션은 대부분 상용이라서 말이죠. 한가지 말씀드리고 싶은 것은 Esper의 라이센스가 GPL이다보니 직접 솔루션 비지니스 하는데는 한계가 있을지도 모르겠어요.

      • 이상부댓글:

        네. 그래서 EsperTech OEM 계약을 했습니다.
        비슷한걸 하셨다니, 혹시 궁금한거 있으면 물어보겠습니다.
        lsb@kopens.com 로 메일주소 좀 알려주시면 안될까요?^^

  4. minsbrz댓글:

    Esper 와 Storm 을 간략하게 비교할만한 자료 없을까요.

    • kimws댓글:

      두 시스템은 사실 비교하기가 애매할 것 같습니다. 하나는 core module에 가깝고 하나는 스트림 프로세싱을 위한 프래임워크이니까요. Esper는 container가 따로 없기 때문에 적절한 컨테니어를 선택해야합니다. 심지어 esper는 storm상에도 올라갈 수 있죠.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중