Embian Blog

시스템 에러 탐지 및 금융사기 탐지, 자동화 시스템의 상태 탐지 등의 분야에서 실시간 데이터 분석은 필수적이나, 데이터량의 폭증에 따라 기존의 데이터 분석 시스템은 그 한계를 드러내고 있다.

이러한 한계를 극복하기 위하여 Big Data를 활용한 준 실시간 분석 시스템이 적용되고 있으나, 이 역시 Batch 형식의 작동방식에 따른 근본적인 문제점을 가지고 있어, 진정한 실시간 분석으로 보기는 어렵다.

따라서 Time Critical한 분야에서의 대용량 데이터에 대한 실시간 스트리밍 분석은 향후 시장에서의 주요한 기술로서 가치가 있다.

엠비안에서는 Distributed Realtime Computation System인 Storm과 대표적인 CEP엔진인 Esper를 사용하여 Big Stream을 실시간 분석하는 기술에 대해서 연구를 하였다. 연구의 주요 목표는 Storm의 비즈니스 환경에서 유연하지 못한 단점과 Esper의 Scale out의 한계를 서로 보완할 수 있는 Architecture를 만드는 것이다.

여기서는 엠비안에서 진행했던 Storm과 Esper의 결합에 대한 연구 과정 및 결과에 대해서 간단히 알아보도록 하자.

사용자 설정 기반의 실시간 Big Data 분석 시스템 Prototype Architecture

ü  분산 처리 환경을 통하여 초당 10,000건의 대용량 Log 를 처리

ü  유입된 Log Data 를 Batch 형태가 아닌 실시간 Streaming 방식으로 처리

ü  실시간 Streaming 처리의 진행 상황을 API로 제공

ü  이용자가 지정한 규칙(Rule)에 따라 유입된 로그에 대한 분석

위 4가지 목표로 모든 데이터(Event , 모니터링, 설정 데이터)가 MessageQueue를 통하여 전달되는 Prototype Architecture를 마련하였으며 테스트 진행하였다.

테스트는 Prototype Architecture 의 Engine 부분에 변화(Esper, Storm&Esper)를 주며 진행하였다.

첫번째 테스트는 Engine 부분을 Esper 만 사용하여 테스트를 진행하였으며 구성은 다음과 같다.

1.     Esper : EPL이 다양한 시나리오를 수용할 수 있는지 확인하기 위한 테스트

 우선 3가지의 테스트 시나리오를 마련하여 EPL statement로 작성하였다. 이 EPL statement로 처리한 결과인 Output Data를 Input Data의 Hit ratio와 대조하는 방법을 통해 EPL의 정합성을 확인하고자 하였다.

 테스트 결과 3가지 시나리오 모두 예상 결과와 일치하였다. 따라서 다양한 시나리오가 EPL statement로 표현이 충분히 가능할 것으로 보인다.

2.     Esper : 시스템 unit 고안하기 위한 테스트 

시스템 resource에 영향을 줄 수 있는 요인

ü  Input Data량

ü  Hit Ratio

ü  EPL 종류

ü  EPL 개수

ü  Window Time

ü  Heap Memory량

에 변화를 주어 resource의 변화(CPU를 사용률, Memory 사용량)를 측정하였다.

테스트 결과는 다음과 같다.

ü  Input Data의 증가량에 비례하여 CPU 사용률과 Memory 사용량이 증가한다.

ü  Hit Ratio는 CPU, Memory 변화량에 크게 영향을 주지 않는 것으로 보인다.

ü  Input Data에 영향을 미치는 조건 (예를 들면 window time, new DataEvent)을 배재한 EPL은 CPU, Memory 변화량에 크게 영향을 주지 않는 것으로 보인다.

ü  동일한 EventData를 사용할 경우 EPL의 갯수와 상관없이 EPL 중   max(window time)과 비례한다.

ü  Window time이 증가할수록 CPU사용율, Memory 사용량이 증가한다.

ü  Heap Memory 량은 Memory 사용량에는 영향을 주지 않는 것으로 보인다.

따라서, 시스템 resource에 영향을 주는 요인은 Input Data량의 변화이며, Input Data의 증가량에 비례하여 resource 사용률이 증가함을 확인하였다.

위 결과를 바탕으로 “10,000건/sec 데이타를 window time 1sec 가지고 있는 1개의 statement”을 1ss로 정의하는 시스템 unit을 고안해 낼 수 있었다.

 1ss의 경험은 현 시스템에서 어느 정도의 데이타 처리가 가능한지 예측 가능하게 한다.

예를 들어, 테스트 시스템(4Core, Mem 16GB, EventData 10,000건/sec)의 1ss의 메모리 사용량을 계산하면 (참고로 0ss일때 Memory 사용량은 약 50M) 약 16M이므로 이 시스템은 약 1000ss 시스템으로 예측 할 수 있다.

두번째 테스트는 Engine 부분을 Storm&Esper 사용하여 테스트를 진행하였으며 구성은 다음과 같다.

1.     Storm&Esper : Scale out 가능한 Topology 구성 테스트

Storm&Esper 를 사용했을 때 아래 6가지 테스트를 통해 Scale out 가능한 Topology 구성을 알아내고자 하였다.

ü  Pre Test : Storm Single Test

“Noop”(초당 3개 tuple을 보내는 Bolt)의 CPU와 Memory 사용률을 측정하여 Storm&Esper를 사용함으로써 증가되는 CPU와 Memory 사용률 확인하였다.

ü  Set0 : 1up Test (1 Unit Processing)

1대의 서버에서 1개의 Esper Bolt에 3가지 테스트 시나리오의 EPL statement를 구동하여 “Esper Bolt”의 CPU, Memory 사용률을 측정했다.

이를 통해 Esper 단독 테스트의 동일한 조건(모든 EPL 구동)의 결과와 비교하여 1up의

resource 수치를 확보하였다.

ü  Set1 : Rule Per Bolt Test (Rule 분산 Test)

     여러개의 EPL Statement를 여러개의 Esper Bolt에 분산하여 처리하는 것이 가능하며

     resource 사용에는 효율적인지 알아보기 위한 테스트를 진행하였다.

그 결과 분산 처리는 가능하나 resource 사용에는 효율적으로 보이지 않았다.

ü  Set2 : Rule Partition Test

     1개의 rule이 “context EPL statement”를 통해 병렬 처리 가능한지 알아보려고 하였으나

     다음의 2가지의 문제로 진행하지 못하였다.

     - Context의 granularity option이 “Esper Document”에서 명시한 대로 동작하지 않았다.

     - Context의 filter option은 적용에 제약 사항이 있을 수 있다.

Storm과 Esper의 결합에 대한 연구에 대한 결론

Storm과 Esper의 결합에 대한 연구는 글 초반에 언급한 4가지 목표를 가지고 진행되었다.

이에 위의 3가지 테스트를 통해 다음과 같은 결론이 도출되었으며 그에 따른 Prototype Architecture이 마련되었다.

1.     여러 시나리오에 대해 EPL로 표현은 충분히 가능한가?
충분이 가능하며 Context, Enumeration method(lamda expression), Pattern expression, match and recognize 등 다양한 표현 방법과 match 방법 제공을 통해 확장적이 표현 또한 가능하다.
그러나 사용자 별로 EPL의 이해도가 달랐을 때 Performance의 영향을 줄 수 있어 주의가 필요하다.

2.     초당 3,000건의 데이타 처리가 가능한가?
Stream Processing에서는 대량의 데이타가 시스템에 유입 할 때 크게 느는 것은 메모리에 대한 요구사항이다.
이에 1 Second  Statement’(1 SS) 라는 시스템 Unit을 고안하여 시스템 사양에 따른 데이타 처리량을 예측하도록 하였다.
따라서, 앞서 진행한 테스트 시스템(4Core, Mem16GB, Heap Mem 12G)을 기준으로 약4~5분의 window time에서 초당 10,000건의 데이타 처리도 가능하다는 것을 예측할 수 있다.

3.     scale-out 가능한 Topology 구성은 무엇인가?
resource 측면에서는 효율적이지는 못했지만 Rule 갯수 만큼 Scale out이 가능함을 확인하였다.
또한 Rule은 resource에 영향을 주는 "window time"을 기준으로 분산하는 것이 적당하다고 판단된다.

4.     Rule의 동적 설정이 가능한가?
Esper Engine은 EPL Statement의 동적 설정(추가, 삭제, 상태변경 등)에 필요한 API를 제공한다.
따라서, 아래 그림과 같은 Rule 분산을 통한 Esper Bolt의 Scale out이 가능하고 storm stream 을 이용하여 EPL statement 동적 설정이 가능한 prototype을 제작하였다.

이번 연구성과물의 적용범위

상기 프로젝트의 결과물을 Big Data의 Log형 데이타의 실시간 분석에 사용될 수 있으며, 예로는 

ü  Enterprise 환경에서 Application Server들의 통합적인 기능오류 분석

ü  Intrusion Detection

ü  상기 기능들을 포함하고 Rule의 Life Cycle을 고려한 Commerical Package로 재구성

등에 쓰일 수 있다.

연구 결과물은 Commerical Package가 아닌 Prototype인 관계로 실제 사이트 적용시에는  반제품의 형식으로 System Integration이 필요하나, 우리의 결과물이 그러하듯이 기본적인 Scaling은 Storm단에서 이루어지기 때문에 Storm의 Spout과 Bolt를 Chaining하여 서비스에서 필요한 Scale Out을 쉽게 구현할 수 있을 것이다.