Complex Event Processing Wiki 요약 부분 번역

2013년 12월 26일 기준 위키피디아에 있는 Complex Event Processing에 대한 내용 번역입니다.

원문 PDF 다운받기

Event Processing
이벤트 처리(Event Processing)란 발생하는 일련의 이벤트에 관한 정보(혹은 데이터)의 흐름을 추적하고 분석(및 처리)하고, 이로부터 결과를 도출하는 방법이다. 복합 이벤트 처리(Complex Event Processing, 줄여서 CEP)는 좀 더 복잡한 상황을 제안하는 이벤트나 패턴을 추론하기 위하여 복수의 정보원으로부터 데이터를 결합하는 이벤트 처리 방법이다. CEP의 목표는 의미있는 이벤트(기회나 위협)를 도출하고 이러한 결과에 대해 가능한 빠르게 대응하는 것이다.

이러한 이벤트들은 세일즈리드(Sales leads), 주문서 및 소비자 서비스 전화 같은 조직의 여러 계층들 상에서 발생할 수 있다. 아니면 새로운 품목, 문자 메시지, 소셜미디어상의 포스트, 주식시장의 피드, 교통정보, 기상 정보 등 여러 종류의  데이터도 이벤트가 될 수 있다. 또한 측정값이 사전의 정의된 시간, 온도 등의 기타 값의 임계치를 넘었을 때 “상태의 변화”를 이벤트로 정의할 수 있다. 분석가들은 CEP가 실시간으로 패턴을 분석하고 비즈니스 관련 부서에서 IT 및 서비스 부서와 더욱 원활하게 의사소통할 수 있는 새로운 길을 조직에 제공할 수 있다고 주장한다. 이벤트에 관련하여 이용가능한 막대한 양의 정보들을 때로 이벤트 구름(event cloud)으로 표현된다.

개념적 설명
유입되는 수천의 이벤트 가운데, 예를 들면 모니터링 시스템은 다음의 3가지 정보를 동일한 정보원으로부터 받을 수 있다.

  1. 교회의 종이 울린다.
  2. 턱시도를 차려입은 남성과 넘실거리는 하얀 가운을 걸친 여성의 외모
  3. 공기 중으로 음식냄새가 흐른다.

이러한 이벤트들로부터 모니터링 시스템은 아마도 복합이벤트로 “결혼식”을 도출할 것이다. CEP는 기술로서 다른 이벤트들(1번부터 3번)을 분석하고 연관시키면서 복합이벤트를 발견하는 것을 돕는다.

CEP는 다음의 다양한 기술들을 기반으로 한다.

  • 이벤트 패턴 감지(Event-pattern detection)
  • 이벤트 추상화(Event abstraction)
  • 이벤트 필터링(Event filtering)
  • 이벤트 조합 및 변형(Event aggregation and transformation)
  • 이벤트 계층 모델링(Modeling event hierarchies)
  • 이벤트 관계 감지(Detecting relationships such as causality, membership or timing between events
  • 이벤트 기반 처리 추상화(Abstracting event-driven  process)

상용 CEP 어플리케이션이 다양한 산업군에서 존재하며 알고리즘을 활용한 주식거래, 신용카드 사기, 비즈니스 활동 모니터링 및 보안 모니터링 등을 포함한다.

역사
CEP 영역은 이산 이벤트 시뮬레이션, 활성 데이터베이스 영역과 일부 프로그래밍 언어에 그 뿌리를 드고 있다. 산업군에서의 활동은 1990년대의 연구프로젝트의 흐름을 따라 시작되었다. 범용적인 CEP 언어에 대한 길을 포장한 첫 프로젝트와 David Luckham이 주도한 스탠포드 대학의 Rapide 프로젝트에 따라서 3개의 다른 연구프로젝트가 병행되어왔다. K. Mani Chandy가 지도하는 Caltech의 Infospheres, John Bates가 이끄는 캠브리지대학의 Apama와 Opher Etzion의 IBM Haifa 연구소의 Amit이 있다. 상업용 제품들은 상기의 프로젝트 및 후속 연구 프로젝트에서 개발된 개념에 종속된다. 커뮤니티에서도 Event Processing 기술 그룹 및 후에는 ACM DEBS 컨퍼런스를 통해서 조직한 이벤트 처리 심포지움들을 통해 시작되었다. 커뮤니티의 기여 중 하나는 이벤트 처리 기준의 생산이었다.

관련 개념
CEP는 운영 인텔리전스(Operational Intelligence, OI) 솔루션에서 라이브 피드와 이벤트 데이터에 대해서 쿼리 분석을 실행함으로 비즈니스 운영에 대한 통찰력을 제공하기 위하여 사용된다. OI 솔루션은 실시간 데이터를 사용하여 현재 상황에 대한 분석과 통찰력을 제공하기 위해서 과거 데이터를 수집하여 연관시킨다. 데이터의 다양한 소스는 다양한 조직의 데이터 사일로로부터 결합된어 현재 정보를 활용하는 공통된 운영그림을 제공한다. 실시간의 통찰력이 큰 가치를 가지고 있든 없든, OI 솔루션은 정보와 필요를 제공하는데 응용될 수 있다.

네트워크, 시스템, 어플리케이션, 서비스 관리에서 사람들은 대신 주로 이벤트 연관을 참조한다. CEP 엔진으로서 이벤트 연관 엔진은(event correlator) 다량의 이벤트를 분석, 가장 중요한 이벤트를 정확히 집어서 조치를 취힌다. 그러나 대부분의 시스템은 새롭게 추론된 이벤트를 생성하지는 않는다. 대신에 그들은 고수준의 이벤트를 저수준의 이벤트와 연관시킨다.

추론 엔진(예를 들면 룰 기반의 추론 엔진)은 전형적으로 인공지능 분야에서 추론된 정보를 생산한다. 그러나 추론엔진은 복잡한 (추론된) 이벤트의 형태로 새로운 정보를 생산하지는 않는다.


생략…

타입
대부분 CEP 솔루션과 개념은 두 개의 메인 카테고리로 분류할 수 있다

  1. 집합 지향 CEP(Aggregation-oriented CEP)
  2. 감지 지향 CEP(Detection-oriented CEP)

집합 지향 CEP 솔루션은 시스템에 유입되는 이벤트 데이터에 대해서 그 반응으로 온라인 알고리즘을 실행하는데 집중된다. 간단한 예로 인바운드 이벤트에 대해서 지속적으로 평규기반의 데이터를 계산하는 것이 있다.

감지 지향 CEP 는 이벤트 패턴 혹은 상황이라고 불리는 이벤트의 조합을 감지하는 것에 집중되어 있다. 감지 상황의 간단한 예로 구체적인 이벤트의 순서를 찾는 것이다.

현재 많은 어플리케이션이 두 방식을 혼용해서 사용한다.

금용 서비스 관련
생략…

시계열 데이터베이스와의 통합
시계열 데이터베이스는 시간을 기준으로 구성된 데이터를 다루는데 최적화된 소프트웨어 시스템이다. 시계열은 유한하거나 무한한 데이터 아이템의 나열이며 각각의 아이템은 타임스탬프와 연관되어 그 순서가 내림차순이 아닌 방식으로 나열된다. 시계열 데이터는 조종 틱(tick)으로 불리기도 한다. 타임스탬프는 반드시 오름차순이지도 않은데 그 이유는 실제로 금용 데이터를 다루는 일부 시스템의 시간 측정 정밀도가 매우 낮아(밀리, 마이크로 혹은 심지어 나노 세컨드 급), 연속된 이벤트들이 동일한 타임스탬프를 가지게 될 수도 있기 때문이다.

시계열 데이터는 전형적으로 복합 이벤트 처리와 관련된 분석에 과거 문맥을 제공한다. 이는 금융권과 같은 모든 수직적 산업에 적용 가능하고 협력적으로 BPM과 같은 다른 기술들과 함께 적용될 수 있다.

미래 가격의 움직임의 통계적 임계치를 결정하기 위해서 과거 가격 변동성을 이해할 필요가 있는 금융권의 시나리오를 고려해보자. 이는 거래 모델과 매매 비용 분석 모두에 매우 유용하다.

CEP 분석의 이상적인 사례는 과거 시계열과 실시간 스트리밍 데이터를 단일한 시간연속체로 보는 것이다. 어제, 지난주 혹은 지난 달에 발생한 것은 단순이 오늘 그리고 미래에 일어날 것의 확장이다. 예로들면, 현재 시장의 크기와 과거의 크기를 비교할 수 있고, 매매실행 로직을 위한 가격와 변동성도 포함시킬 수 있다. (마지막 문장 생략)

[에스퍼] 간단한 실시간 이벤트 처리 기술

espertech_logo_transparent
Coupon For air jordan
에스퍼는 실시간 이벤트에 활용되는 대표적인 오픈소스이다. 일명 CEP, Complex Event Processing을 위한 솔루션 중에 하나인데 오픈소스이면서 문서화가 잘 되어 있으면서 안정적이라 실시간 이벤트 처리에 많이 사용된다. CEP에 대해서 궁금한 점이 있다면 현재 학습하면서 조금씩 업데이트는 하는 위키를 참조하면 된다.
nike air jordan 23
이 포스팅은 에스퍼 엔진을 실제로 스탠드얼론 자바 프로그램에 올려 코딩해 보는 간단한 실습내용이다. 에스퍼 문서는 에스퍼 레퍼런서와 IO관련 레퍼런스가 있는데 4.9.0 버전 기준으로 페이지수가 각각 712, 52가 된다. 천천히 읽고 있지만 이 레퍼런스에서는 실제 설치 및 활용에 대한 예제가 없다. 다만 블로그 상에 몇몇 글 1이 있긴 하지만 조금 달라진 부분도 있어서 이 포스트를 남겨둔다.

우선 에스퍼 프로젝트 다운로드 링크로 들어간다. 페이지에 들어가면 Esper EE, Esper HA, Esper가 있는데 여기서 “Esper” 최신버전 2를 다운받는다. Esper EE와 Epser HA는 Esper 엔진 기반의 추가적인 기능이 부가된 것으로 실제 다운로드 하려면 가입이 승인의 절차가 필요한다. Esper만 다운 받아도 충분히 사용하는데 문제가 없다.
air jordan iv
다운 받아서 압축을 풀면 다음과 같이 여러 개의 폴더와 jar 라이브러리리가 나온다.
air jordan Korea
esper folder contents

자세히 보면 폴더와 jar 라이브러리의 이름이 하나씩 매칭되어 있다는 것을 알 수 있다. 즉 각 폴더는 해당 라이브러리와 관련된 문서와 의존관계에 있는 라이브러리 등이 있다. 또한 example 폴더 안에 들어가면 다양한 예제 소스도 있다.
oakley overthetop sunglasses
이 포스팅에서 실습할 예제에 대해 간단한 요구사항을 적어보면 임의의 후보들에게 점수를 부여하는 이벤트들을 임의로 생성해서 에스퍼로 보내서 특정 후보의 점수 평균과 카운트를 뽑아내는 프로그램이다.
nike air max 97
우선 이클립스에서 자바프로젝트를 하나 생성한다. 생성하고 난 후 에스퍼 라이브러리와 에스퍼 라이브러리가 참조하는 추가 라이브러리를 프로젝트에 포함시킨다. 에스퍼 라이브러리는 압축을 풀고 난 폴더 바로 밑에 “esper-4.9.0” 이름으로 있고 다른 라이브러리는 “{압축 푼 장소}/esper-4.9.0/esper/lib” 폴더에 들어가면  있다. 자 이제 모든 준비는 끝이 났고 코딩만 하면 된다. 에스퍼를 활용하기 위해서 포함시켜야 할 것은 크게 세가지다.

  1. 이벤트 타입 정의
  2. 에스퍼 기본 설정과 EPL 입력
  3. UpdateListener 구현

에스퍼에서는 이벤트 타입으로 다양한 형태를 입력받을 수 있다. 간단한 POJO부터 Map, Hash도 가능하고 XML이나 RDB도 가능하다. 여기서는 다. 서두에 정의한 요구사항대로 특정 후보에 대해서 점수를 매기는 이벤트를 만들려면 이 이벤트는 최소한 사람의 이름과 점수를 속성으로 가져야 하고 다음과 같이 POJO로 간단하게 이벤트를 정의할 수 있다.

이벤트 타입을 정의했다면 실제 메인에서 돌아갈 수 있도록 에스퍼 설정을 해야한다. 일단 코드를 보자.

소스를 보면 첫 번째 라인에서 에스퍼의 configuration 객체를 하나 생성하고 2번째 라인에서는 위에서 생성한 이벤트 타입을 등록시킨 것을 볼 수 있다. 그리고 3번째 라인에서는 configuration 객체를 전달해서 새롭게 epService라는 객체를 생성시켰다. 이 객체를 통해서 나중에 우리는 이벤트를 생성해서 에스퍼에 전달하게 된다는 것을 기억해 둔다.

다음으로는 이벤트들을 탐지할 EPL을 생성해야 한다. EPL은 Event Processing Language의 약자로 SQL과 유사한 형태의 이벤트 처리 언어라고 생각하면 된다. 나중에 에스퍼 레퍼런스를 참조하면 대부분의 내용이 이 EPL을 설명하고 있다는 것을 확인하게 될 것이다. 즉 EPL을 얼마나 잘 사용하느냐가 중요한 관건이다. 그러나 DB에서 SQL에 익숙하다면 그리 어렵지 않게 이해할 수 있다. 다음의 소스를 보자.

epl이라는 문자열에 우리가 원하는 이벤트 탐지를 위해 EPL을 작성해 넣었다. 이 EPL의 의미는 지난 30초 동안 들어온 VotingEvent에서 candidate가 NFM인 이벤트들의 평균 rating과  이벤트의 개수를 구하는 것이다. 자세히 들어다보면 SQL과 같이 select, from, where로 되어 있다는 것을 알 수 있다.

여기서 EPL에 대해서 다 설명할 수는 없지만 간단하게 DB와 비교하면 이렇다. DB에서 table의 개념은 에스퍼에서 스트림이라는 개념으로 볼 수 있다. 스트림은 간단하게 설명하면 이벤트가 생성되어서 들어오는 통로라고 생각하면 된다. 그리고 DB에서의 하나의 레코드가 에스퍼에서는 이벤트에 해당되며 DB에서의 열에 해당하는 필드가 에스퍼에서는 이벤트에 속성애 해당한다. 소스의 2번째 라인과 같이 이렇게 EPL 문자열을 위에서 생성한 epService에 등록하면 두번째 준비도 끝이난다.

마지막으로 Update Listener를 구현해야 한다. 에스퍼에서는 epl에 해당하는 이벤트가 탐지될 경우 어떤 액션을 할 것인가를 구현할  수 있도록 UpdateListener 인터페이스를 제공한다. 따라서 자신의 입맛에 맞게 UpdateListener를 상속받아 적절한 프로세싱을 하면 된다.

위 소스에서는 UpdateListener 인터페이스를 상속받아 “update”라는 메소드를 구현한 것을 볼 수 있다. update 메소드는 반드시 구현해야 하는 것으로 새롭게 들어온 이벤트들을 어떻게 처리할 것인지를 이 메소드 안에서 구현하면 된다. 우리는 아주 간단하게 들어온 이벤트의 평균 점수와 숫자를 출력하도록 정의했다.

참고로 update메소드의 매개변수를 자세히 보면 newEvents와 oldEvents 배열이 있는 것을 확인할 수 있다. 에스퍼는 모든 이벤트들을 다 감지할 수 없기 때문에 탐지하는 이벤트들의 스코프를 정해놓고 이를 윈도우라고 한다. 이 예제에서는 30초라는 시간 윈도우를 두었고 30초간의 윈도우를 벗어난 이벤트들은 oldEvent 형태로 이 update 메소드를 지나간다.

위에서 말한 대로 세 가지를 모두 다 했으니까 끝이 났다…가 아니다 ;; 딱 두가지가 더 남아 있다. 하나는 방금 구현한 Update Listener를 에스퍼 엔진에 연결시켜줘야 하고 마지막으로 애드혹하게나마 실습을 위해서 임의로 이벤트들을 생성시켜주는 generator같은 것이 필요하다.

리스너 등록은 간단하다. 이 소스를 아까 epl 문장을 등록한 곳 바로 밑에다 추가하면 Update Listener 등록이 끝난다.

마지막으로 실습을 위해 임의로 이벤트를 생성하고 생성한 이벤트를 epService객체에 던져주는 코드만 짜면 된다. 이 부분은 순전히 애드혹하게 실습을 위해 만든 것이다. 소스를 한번 보자.

소스는 “EventCreateNum” 만큼 임의로 이벤트의 속성 값을 만들어서 VotingEvent 객체를 만들고 이를 epService에 sendEvent 메소드를 통해서 던져주는 간단한 예제이다.

자 돌려보자!

에스퍼 스타트 프로그램 실행화면

스크린샷에서 보는 바와 같이 이벤트가 주기적으로 발생하는가운데 EPL에 해당하는 이벤트가 탐지되었을 때에 평균 점수와 이벤트 숫자를 출력해 주는 것을 확인할 수 있다. 처음 log4j 경고문구는 이 예제에서 log4j 설정을 따로 하지 않아서 그런 것이므로 무시해도 된다. 필요할 경우 처음에 log4j 설정만 넣어주면 된다.

지금까지 한 예제는 github에 올라가 있으며 메이븐을 통해서 빌드하면 관련 라이브러리도 다 받아서 실행할 수 있다. https://github.com/jwj0831/EsperStudyProject