실시간 'BI'를 실행하라, 스톰과 스파크 설명과 그 선택 방법

오픈소스 프로젝트인 스톰(Storm)과 스파크(Spark)에 힘입어 실시간 BI가 주류 기술로 부상하고 있다. 이 두 가지를 선택하는 방법을 소개한다.

실시간 BI(Business Intelligence) 개념이 등장한 지는 꽤 됐다(위키피디아에 따르면, 2006년부터 시작됐다). 사람들이 이 개념을 이야기한지 몇 년이 지났지만, 이 비전을 실제 수용한 기업은 많지 않고, BI의 가치를 실현시킨 기업은 더 적다.

여러 이유 가운데 하나는 BI와 애널리틱스를 실시간으로 구현하게끔 지원하는 툴이 부족했기 때문이다. 기존의 데이터웨어하우징 환경은 지연율이 아주 높고, 많은 비용이 드는 배치 운영에 치우쳐있다.

그러나 강력하고, 이용이 간편한 오픈소스 플랫폼이 다수 등장하면서 변화가 시작됐다. 폭넓은 잠재 사용자군에 실시간 프로세싱 기능을 제공하는 플랫폼으로 가장 주목받는 플랫폼은 바로 아파치 스톰(Apache Storm)과 아파치 스파크(Spark) 이 두가지다.

둘 모두 아파치 소프트웨어 재단(Apache Software Foundation)의 프로젝트로, 기능이 중복되는 부분도 있지만, 독창적인 특징과 역할도 있다.

스톰, 실시간 프로세싱 하둡
이벤트 스트림 프로세싱(처리)을 위한 분산형 컴퓨팅 프레임워크인 스톰(Storm)은 트위터(Twitter)가 2011년 인수한 시장 정보 기업인 백타이프(BackType)가 처음 시작한 프로젝트이다.

트위터는 얼마 지나지 않아 프로젝트를 오픈 소싱하면서 기트허브(GitHub)에 올려 놓았다. 그러나 스톰은 최종적으로 아파치 인큐베이터(Apache Incubator)로 옮겨갔고, 2014년 9월에는 아파치의 최상위 프로젝트로 자리잡았다.

스톰은 때때로 실시간 프로세싱 하둡(Hadoop)으로 지칭된다. 스톰 문서에도 이에 동의하는 내용이 암시되어 있다.

"스톰은 무한대의 데이터 스트림을 하둡의 배치 프로세싱처럼 실시간으로 쉽고 우수하게 처리한다."

스톰은 이를 위해 강력한 확장성, '빠른 실패, 자동 재시작(fail fast, auto restart)'이라는 폴트 톨로런스(fault-tolerance, 고장 방지 능력)를 지원하며, 모든 튜플(tuple)의 처리를 보증한다.

스톰은 '최소 한 차례' 이상 메시지를 보증하도록 디폴트가 되어 있다. 그러나 동시에 '정확히 한 차례'만 처리를 하는 기능을 제공한다.

스톰은 클로저(Clojure)를 주 언어로 사용하지만, 인풋 스트림의 일종인 스파웃(Spouts)과 프로세싱 및 아웃풋 모듈인 볼트(Bolts)를 DAG(Rirected Acyclic Graph)라는 토폴로지로 지원할 수 있도록 설계되어 있다.

스톰 토폴로지는 클러스터에 실행되며, 스톰 스케줄러는 토폴로지 구성에 따라 클러스터 주변의 노드에 작업을 배포한다.

이런 토폴로지를 하둡에서의 맵리듀스(MapReduce) 작업과 유사한 것으로 생각할 수 있지만, 스톰은 실시간, 스트림 기반 프로세싱에 초점이 맞춰져 있고, 토폴로지는 영구적 또는 수동으로 중지할 때까지 실행되는 것이 디폴트라는 차이점이 있다.

토폴로지가 시작되면, 스파웃은 시스템으로 데이터를 가져온 후, 메인 컴퓨팅 작업이 이뤄지는 볼트로 데이터를 밀어낸다(이후 다음 볼트로 데이터를 넘길 수 있다).

프로세싱이 진행되어 가면서 하나 이상의 볼트가 데이터베이스나 파일 시스템에 데이터를 쓰거나, 다른 외부 시스템으로 메시지를 전송하거나, 컴퓨팅 결과를 다른 방법으로 사용자에게 제공한다.

스톰 생태계의 강점 가운데 하나는 모든 형태의 소스로부터 데이터를 수신할 수 있는 풍부한 스파웃이 있다는 것이다. 특수한 애플리케이션을 위해 맞춤형 스파웃을 개발해야 할 수도 있지만,트위터 스트리밍 API, 아파치 카프라(Kafka), JMS 브로커 등 놀랍도록 다양한 소스에서 기존에 개발된 스파웃을 발견할 수 있는 확률이 높다.

이를 HDFS 파일 시스템에 쉽게 통합할 수 있는 어댑터도 있다. 필요에 따라 스톰과 하둡을 쉽게 호환시킬 수 있다는 의미다. 여러 언어로 프로그램을 할 수 있도록 지원하는 것도 장점이다.

스톰 자체는 클로저(Clojure)에 기반을 두고 있지만 JVM에서 실행되며, 볼트는 사실상 모든 언어로 개발이 가능하다. 여기에는 표준입출력스트림(stdin/stdout)에 바탕을 둔 제이슨(JSON)을 사용하는 요소간 통신 프로토콜이라는 장점을 이용할 수 있는 JVM 외 언어도 포함된다.

요약하면, 스톰은 확장성이 아주 크고, 빠르며, 내결함성이 강한, 스트림 프로세싱에 초점이 맞춰진 분산형 컴퓨팅을 위한 오픈소스 시스템이다.

스톰은 데이터 스트림의 실시간 롤링 매트릭스 계산, 증진적 계산(incremental computation), 이벤트 처리에서 우수한 성능을 발휘한다. 스톰은 포괄적인 분산형 RPC를 구현하는 기본 요소를 제공하고, 이론적으로는 거의 모든 분산형 컴퓨팅 작업에 이용할 수 있지만, 가장 큰 강점은 이벤트 스트림 프로세싱이다.

스파크, 모든 것을 위한 분산형 프로세싱
스파크는 또 다른 실시간 분산형 컴퓨팅 프로젝트다. UC 버클리 산하 AMPLab에서 시작했으며, 이후 아파치 인큐베이터에 합류해 2014년 2월 최상위 프로젝트가 됐다.

스파크는 스톰과 마찬가지로 스트림 지향형 프로세싱을 지원한다. 그러나 스톰보다는 범용 분산형 컴퓨팅 플랫폼에 가깝다.

스파크는 하둡에서 맵리듀스의 기능성을 대체할 수 있다. 스파크는 기존 하둡 클러스터에서 실행시킬 수 있으며, 자원 스케줄링에는 얀(YARN)을 이용한다. 하둡과 얀(YARN) 외에도, 스파크는 스케줄링을 위해 메소스(Mesos) 위의 계층으로 배치하거나, 빌트인 스케줄러를 이용해 스탠드얼론 클러스터로 실행시킬 수 있다.

그런데 주의할 점이 있다. 하둡과 같이 사용하지 않을 경우, (NFS, AFS 등) 네트워크/분산형 파일 시스템을 이용해야 클러스터에서 실행시킬 수 있다. 그래야만 각 노드가 기반이 되는 데이터에 접속할 수 있기 때문이다.

스파크는 스칼라(Scala)로 작성이 되어있지만, 스톰처럼 다중 언어 프로그래밍을 지원한다. 하지만 스칼라, 자바(Java), 파이톤(Python) API만 지원한다.

스파크에는 스파웃 같은 것이 없다. 그러나 HDFS 파일, 카산드라(Cassandra), HBase, S3 등 여러 이질적인 소스에 저장된 데이터를 처리할 수 있는 어댑터가 들어있다.

스파크의 장점은 다중 프로세싱 패러다임 지원과 지원 라이브러리다. 스파크는 스트리밍 모델을 지원한다. 하지만 SQL 액세스, 그래프 동작, 머신 학습, 스트리밍 프로세싱 모듈 등 여러 모듈 가운데 하나만 이를 지원한다.

스파크는 또 스칼라 또는 파이톤 API를 이용한 실시간 예비 데이터 분석과 간이(Quick-and-Dirty) 프로토타이핑을 지원하는 아주 간편한 인터랙티브 쉘(Shell)을 제공한다.

인터랙티브 쉘을 다뤄보면 스파크와 스톰의 또 다른 중요 차이점을 알 수 있다. 스파크가 좀 더 기능 본위적이다. API 작업은 원시 연산(primitive operation)을 호출하는 계열 기법(successive method)을 채닝(Chaining)한다.

반대로 스톰 모델은 클래스를 창조하고, 인터페이스를 구현하는 경향이 있다. 더 나은 방법은 없다. 당신이 선호하는 방식이 니즈에 더 잘 부합하는 시스템을 결정하는데 영향을 줄 것이다.

스파크는 스톰과 마찬가지로 확장성이 높다. 스파크 팀이 기록한 문서에 따르면, 사용자는 수천 노드로 구성된 생산 클러스터를 실행시킬 수 있다. 스파크는 최근 2014년 데이토나 그레이소트(Daytona GraySort) 콘테스트에서 수상했다. 여기에서 100TB의 데이터로 구성된 워크로드를 처리했다. 스파크 팀에 따르면, 페타바이트의 생산 워크로드를 ETL 연산 처리할 수 있다.

스파크는 하둡 및 메소스와 호환되며, 스트리밍, 그래프 중심의 연산, SQL 액세스, 분산형 머신 학습 등 여러 컴퓨팅 모델을 지원하는 빠르고, 확장성이 높으며, 탄력적인 오픈 소스 분산형 컴퓨팅 플랫폼이다.

스파크는 스톰과 마찬가지로 확장성이 높다는 사실이 입증된, 실시간 분석과 BI 시스템을 위한 우수한 플랫폼이다.

선택
스톰과 스파크, 뭘 선택해야 할까? 스트림 프로세싱, CEP(Complex Event Processing) 스타일의 프로세싱이 중심이 되고, 전용 클러스터를 이용한 독창적인 프로젝트를 추진하는 경우라면 스톰을 권장한다.

특히 통합과 관련된 요건에 부합하는 기존의 스톰 스파웃이 가용한 경우라면 더욱 그렇다. 반드시 그렇다는 의미는 아니다. 그러나 이런 요소들이 있다면 스톰으로 시작을 할 것을 제안한다.

반대로 기존의 하둡 또는 메소스 클러스터를 이용하고 있거나, 프로세싱에서 그래프 처리, SQL 액세스, 배치 프로세싱의 비중이 크다면 스파크를 먼저 살펴볼 것을 권장한다.

고려해야 할 또 다른 요소는 두 시스템의 다중언어 지원성이다. 예를 들어, 스파크가 기본 지원하지 않는 언어나 R로 작성된 코드를 이용할 경우, 지원하는 언어가 더 많은 스톰이 유리하다. API 요청을 이용해 데이터를 분석하는 인터랙티브 쉘을 구현해야 한다면, 스파크가 낫다. 스톰이 지원하지 않는 기능을 제공하기 때문이다.

결론을 내리면, 최종 결정을 내리기 전에 두 플랫폼을 상세히 분석하는 것이 좋다. 소규모의 POC(개념증명)를 통해 두 플랫폼 모두를 이용할 것을 권장한다. 이후 자신이 예상하는 워크로드와 가까운 워크로드를 벤치마킹한 후 최종 결정을 내리자.

물론 반드시 둘 가운데 하나만 선택하라는 법은 없다. 워크로드, 인프라스트럭처, 요건에 따라 스톰과 스파크를 카프카, 하둡과, 플룸(Flume) 등과 병행 사용하는 것이 최상의 솔루션이 될 수도 있다. 이는 오픈 소스의 장점이기도 하다.

어느 쪽을 선택하든, 이들 툴은 실시간 BI 지형이 바뀌었음을 보여주고 있다. 소수 엘리트만 가용했던 강력한 선택지들이 대다수의 사람들로 확대가 됐다. 최소한 중견 기업과 대기업에게는 가용한 선택지들이다. 둘의 장점을 적극 활용하기 바란다. editor@itworld.co.kr