[The Power Of Event 요약] 7장 Complex Events and Event Hiearchies

Part 1의 마지막인 7장에서는 이벤트의 조합과 이벤트 추상화 계층을 설명하면서 복합이벤트처리가 실제로 어떻게 이루어지는지에 대한 설명을 여러 예제를 통해서 보여준다. 구체적으로 이 장에서는 다음의 이슈에 대해서 설명한다.

  • 이벤트 조합
  • 복합 이벤트
  • 이벤트 계층 추상화
  • 계층형 시스템의 개인화된, 룰기반의 뷰

7.1 Aggregation

복합이벤트는 다른 이벤트들의 조합으로 이루어진 이벤트이다. 낮은 계층에서 발생하는 상세한 이벤트들이 사용자가 정의한 패턴과 룰에 따라 좀 더 정제된 추상화된 결과물로 복합이벤트가 되는 것이다. 명칭만 생각하면 “복합이벤트”가 정말로 “복잡한” 형태의 이벤트라고 생각할 수 있지만 개념상 여러 이벤트의 조합으로 이루어진 이벤트이기 때문에 “복합(Complex)”라는 명칭이 붙는 것이다. 실제 복합이벤트가 담는 내용적 측면에서 봤을때 “사용자가 이해할 수 있는, 사용자에게 유의미한” 이벤트를 “복합이벤트”라고 정의한다고 생각하면 된다.

복합이벤트가 어떻게 도출되는지에 대한 예를 책에서 5가지로 보여준다. 이 중에서 하나의 어셈블리 연산을 복합이벤트로 하는 간단한 예를 설명해보자.

Add(X, Y)라는 특정 프로세서의 명령어가 있다고 하자. 실제 이 연산은 더 하위 레벨의 프로세서 관련 연산들의 순서로 이어져 있다. 이러한 하위 레벨의 연산은 사용자에게는 직관적이지 않고 상당히 구체적인 연산에 해당한다. 단순히 덧셈 연산하나를 하기 위해서 여러 개의 하위연산을 직접 작성하는 것은 어렵기 때문에 이러한 하위레벨의 연산들의 순서를 하나의 묶음으로 조합하여 상위 레벨의 연산인 Add(X, Y)가 탄생한다.

7.2 Creating Complex Events

복합이벤트가 무엇인지 정의했다면 자연스럽게 어떻게 복합이벤트가 발생하느냐는 질문이 들 것이다. 이에 대한 답은 이벤트 패턴 룰을 정의하라는 것이다. 이벤트 패턴 룰은 사용자가 원하는 복합 이벤트를 도출하기 위해서 여러 이벤트간의 관계(시간, 인과)와 함께 이벤트의 조합을 정의하는 것이다. 예를 들면 4-way handshaking과 유사하게 어떠한 데이터를 하나 보내는데 총 4번의 이벤트가 교환되는 프로토콜이 있다면, 한번의 전송이 완료되었다는 복합이벤트인 CompletedTran 이벤트의 패턴 룰은 다음과 같이 정의할 수 있다.

Create Complex Event

CompletedTran 이벤트는 보는 바와 같이 Send, Receive 등의 이벤트보다 상위 개념의 추상회된 이벤트라는 것을 알 수 있다. 네트워크 매니저가 아닌 이상 우리는 네트워크 계층의 이벤트 정보를 일일이 모니터링하지 않는다. 정확하게 내가 전송하려는 데이터가 보내졌는지에 대한 확인이 중요하기 때문이다. 이러한 요구사항이 바로 이어지는 장 이벤트 추상화 계층에서 다루는 내용이다.

7.3 Event Abstraction Hierarchies

이벤트 추상화 계층은 결국 사용자에게 의미없는 Low Level 정보들 가운데에서 유의미한 정보를 얻기 위한 데이터 계층의 모델링과도 같다. 일반적으로 이벤트 추상화 계층은 다음의 두가지 요소를 명확하게 갖추고 있어야 한다.

  • 시스템의 계층과 각 계층 내의 활동: 시스템을 여러 계층으로 구분하고 각 계층에서 일워지는 활동들을 찾아서 정의한 후 여기서 발생하는 이벤트 타입과 명세를 정의해야 한다.
  • 각 계층에서의 이벤트 조합룰 집합: 이전의 정보를 기반으로 가장 낮은 계층을 제외한 모든 계층에서 이벤트 패턴 룰을 정의하여 어떠한 이벤트를 복합이벤트로 도출할 것인지를 정의해야 한다. 중요한 점은 이벤트 패턴 룰을 통해 도출되는 복합 이벤트를 해당 계층의 어떤 이벤트 타입으로 할 것인지를 잘 설정해야 한다.

위의 두가지 정보들을 잘 정의하여 이벤트 추상화 계층을 구축하는 것은 CEP를 위한 선제적인 조건이다.

7.4 Building Personalized Concept Abstraction Hierarchies

복합이벤트의 정의와 생성, 이벤트 추상화 계층은 결과적으로 특정 사용자군이 관심갖는 정보만을 개인화하여 정확하게 도출해서 제공하기 위한 기술적 수단이라고 할 수 있다.

타겟 시스템 안에는 여러 이해관계자가 있고, 각자가 관심갖고 필요로 하는 정보는 당연히 다를 수 밖에 없다. 따라서 우리는 각 사용자에게 맞는 정보를 제공해야 하고 이를 타겟 시스템의 개인화된 뷰를 통해서 정보를 제공할 수 있는 것이다.

이 책에서는 Monitoring과 Viewing이란 용어를 구분해서 정의하고 있다. 두 행위의 본질은 같으나 가장 낮은 계층을 살펴보는 것을 Monitoring이라 하고 이를 제외한 상위계층에서 발생하는 High-level의 복합이벤트를 살펴보는 것을 Viewing이라 표현한다.

두 개념을 구분하는 이유는 Monitoring하는 대상은 변하지 않지만  Viewing의 대상은 가변적이기 때문이다. 타겟시스템의 계층은 고정된 것이 아니라 우리가 정의하는 영역이다. 따라서 이벤트 패턴룰의 변경을 통해서 우리는 얼마든지 계층과 복합이벤트를 변경할 수 있고 이는 Viewing의 결과에 변화를 가져온다.

개인화된 추상화 계층을 구성하기 위해서는 7.3 장의 이벤트 추상화 계층의 요소에서 설명한 두가지 요소를 순차적으로 잘 정의해야 한다. 다음 장에서 실제적인 예제를 통해서 어떻게 추상화 계층을 정의하는지 확인해 본다.

7.4.1 Viewing Network Activity

이 예제에서는 이전부터 사용한 네트워크의 패킷 전송을 가지고 설명한다. 7.3장에서 설명한 것과 같이 이벤트 계층을 정의하기 위해서는 먼저 각 계층과 계층 내의 활동과 이벤트 명세를 다음과 같이 정의해야 한다.

Step1-Event Abstracion Hierarchy

다음으로 가장 하단의 계층을 제외한 계층 내의 이벤트 패턴 룰을 위의 첫 번째 그림과 정의해야 한다. 이와 같은 과정을 통해 상위 계층에서 도출된 복합 이벤트는 역으로 다시 하위 이벤트의 집합으로 추적이 가능하고 이를 “Drill-Down”이라고 한다. 예를 들면 아래 그림과 같이 CompletedTran 이벤트는 네개의 연속된 이벤트의 조합으로 Drill-Down할 수 있다.

Drill Down

[The Power Of Event 요약] 6장 Event Patterns, Rules, and Constraints

6장에서는 CEP 어플리케이션의 기반이 되는 이벤트 패턴, 반응형 이벤트 패턴 룰, 이벤트 패턴 제약 드의 개념을 설명하고 다음과 같은 내용들을 다룬다.

  • 패턴검색의 종류
  • 이벤트 패턴
  • strawman 이벤트 패턴 언어
  • 이벤트 패턴 룰
  • 이벤트 패턴 제약
  • 이벤트 패턴을 통한 비즈니스 룰 검출

6.1 Common Kinds of Pattern Searching

CEP의목적은 무수한 이벤트로부터 사용자의 관심에 맞는 관련 이벤트의 집합을 적절하게 찾는 것이다. 인터넷에서 필요한 정보를 검색하기 위한 조건으로 검색어를 입력하듯 찾고자하는 정보와 관련된 이벤트 집합을 얻기 위해서 이벤트의 패턴을 기술해야 한다.

이벤트의 패턴을 기술하는 방식은 두가지가 있다. 하나는 컴퓨터가 이해할 수 있는 언어인 이벤트 패턴 언어(Event Pattern Language)를 사용하는 것이다. 이벤트 패턴 언어는 앞으로 계속해서 자세하게 다루게 될 것이다. 두번째 방법은 GUI를 활용한 방법으로 서두에서 설명한 웹서치가 이에 해당한다. 아래 그림과 같이 구글에서도 다양한 검색 조건 필터와 고급검색을 통해서 원하는 정보를 찾아주지만 정확하게 원하는 정보만을 찾는데는 한계가 있다.

구글 고급검색

패턴매칭은 컴퓨터 시스템에서 고전적이고 익숙한 이슈이기도 하다. 유닉스 계열의 OS에서 문자열 검색을 위한 grep 같은 명령어 패턴 매칭을 위한 도구라고 할 수 있다.

그러나 CEP에서 우리가 원하는 이벤트 패턴 매칭은 단순한 웹검색이나 문자열 검색보다 정교하고 복잡한 요구사항이 따른다. 이벤트 패턴 매칭은 이벤트간의 시간, 인과관계, 조합의 정보를 포괄하여 적절한 이벤트 집합을 찾아내는 과정이다. 따라서 단순한 문자열 검색조건보다 복잡한 형태의 이벤트 패턴을 기술할 수 있는 도구가 필요하다.

6.2 Event Pattern

이벤트 패턴이란 우리가 관심갖고 찾기 원하는 특정한 이벤트의 집합을 매칭시키는 하나의 템플릿을 말한다. 이벤트 패턴은 이벤트에 대한 정보 뿐 아니라 이벤트 간의 인과관계 의존성, 시간속성, 데이터 매개변수 및 컨텍스트 정보등을 포함한다. 이는 다른 표현으로 타겟 시스템 안에서 발생하는 이벤트의 Poset 가운데 하나를 기술하는 템플릿이 된다.

이벤트 패턴은 찾고자하는 대상 패턴에 따라 다음의 몇가지로 분류가 가능하다

  1. Content-Sensitive Pattern
  2. Context-Sensitive Pattern
  3. Filter Pattern
  4. Complex Pattern

Content-Sensitive Pattern이란 이벤트 패턴 내의 속성 값을 기준으로 패턴을 매칭시키는 경우를 말한다. 예를 들어 다음과 같은 패턴이 있다고 생각해보자.

“All orders from customer C in the last month”

이 패턴을 매칭하기 위해서는 이벤트의 속성을 일일이 확인하여 소비자가 ‘C’인지, 시간은 한달이 지나지 않았는지를 확인해야 한다. 즉 이벤트의 내용을 기반으로 패턴을 매칭하는 경우를 Content-Sensitive 패턴이라 한다.

Context-Sensitive Pattern은 Content-Sensitive 패턴과 유사하지만 이벤트의 내용을 확인하지 않고 특정한 맥락을 기반으로 패턴을 매칭한다는 점이 다르다. 다음의 예제를 보자

“All orders from frequent customers in the last month”

이 패턴은 이벤트의 속성 값을 기준으로 패턴을 매칭할 수 없다. 이벤트의 속성으로 특정한 소비자를 한정하여 찾는 것이 아니라 어떠한 소비자가 지난 한달간이라는 시간 구간 안에서 반복적으로 구매를 하였는지 그 맥락을 찾아서 패턴을 매칭해야 한다. 이렇게 일정한 상황과 맥락을 기준으로 패턴을 매칭하는 경우를 Context-Sensitive 패턴이라 한다.

세 번째로 Filter Pattern은 예제를 통해서 먼저 살펴보자.

“All orders from customers in response to a discount announcement”

이 패턴은 할인 메시지에 반응해서 구매를 한 소비자를 찾는 것이다. 결국 이 패턴에 따라 검출된 구매 이벤트는 할인 메시지 이벤트의 인과관계로 아래 그림과 같이 종속되어 있음을 알 수 있다.

Filter Pattern

이러한 Filter 패턴은 이벤트 간의 인과관계에서 원인 이벤트를 필터로 하여 매칭대상 이벤트 공간을 한정시켜 주는 역혈을 한다.

마지막 유형은 Complex Pattern으로 의미 그대로 세가지 유형에 속하지 않으면서 복잡한 이벤트 관계를 갖고 있는 경우이다. 다음과 같은 패턴의 예를 보자.

“All orders from customers at the regular price that have led to the customer requesting a reduced price in response to the discount announcement”

이 패턴은 아래 그림과 같이 독립적인 Poset들을 함께 연관지어 매칭하는 복잡한 형태를 띄고 있다. 개별적으로 주문이 완료된 이벤트들이 독립적으로 발행된 할인 이벤트에 반응하여 할인을 요구하는 형태로 서로 다른 Poset들이 연관되어 패턴을 이루고 있음을 알 수 있다.

Complex Pattern

이러한 Complex 패턴은 일반적인 이벤트 패턴 언어로 기술하기 상당히 까다로운 형태의 패턴의 예가 된다. 이벤트 패턴 언어는 이러한 형태의 복잡합 패턴 매칭까지 다룰 수 있어야 한다.

6.3 A Strawman Pattern Language

이제까지 이야기한 이벤트 패턴 언어의 예를 들기 위해서 이 장에서는 아주 단순한 형태의 이벤트 패턴 언어를 다룬다. 여기서 설명하는 간단한 형태의 이벤트 패턴 언어를 STRAW-EPL이라고 한다. 복잡한 패턴 언어를 다루기 전에 이벤트 패턴언어에 대한 전반적인 이해와 입문으로서 STRAW-EPL을 생각하면 된다.

STRAW-EPL은 and, or, ->(인과관계)의 세가지 관계연산자를 지원한다. 각 연산자들은 예를 들면 다음과 같이 사용할 수 있다.

  • A and B and C : 이 패턴의 의미는 A,B,C 모든 패턴을 동시에 매칭한다는 뜻이다.
  • A or B or C: 이 패턴의 의미는 A,B,C 중 어느 하나라도 매칭한다는 뜻이다.
  • A -> B: 이 패턴의 의미는 A가 B의 원인일 경우의 두 이벤트 짝을 매칭한다는 뜻이다.

STRAW-EPL에서 패턴을 정의하기 위해서는 다음의 네가지 요소를 선언해야 한다.

  1. 변수: 변수의 타입과 명칭을 선언 [예: Message M]
  2. 이벤트 타입: 이벤트의 명칭과 속성을 열거하여 선언 [예: Send(Message M, Bit B, Time T)]
  3. 패턴: 패턴은 관계 연산자를 활용하여 선언 [예: Send(M, B, T1) and ReSend(M, B, T2)]
  4. 상황조건: 패턴이 매칭되었을 때의 반드시 만족시켜야하는 조건 선언 [예: 0 < T2 – T1 < 10]

6.3.1 Pattern Matching

패턴의 각 매칭결과는 패턴의 변수들을 이벤트의 값으로 치환한 결과로서 하나의 인스턴스로 Poset을 이룬다. 결국 매칭은 패턴안에 변수들을 동일한 값의 속성으로 치환하는 과정이다.

6.3.2 Writing Patterns in STRAW-EPL

STRAW-EPL에서 패턴은 표양식위에 작성한다. 표 안에는 6.2장에서 설명한 것과 동일하게 패턴의 요소들인 변수, 이벤트 타입, 패턴, 패턴에 사용한 관계연산자, 상황조건을 선언하면 된다. 다음은 STRAW-EPL 패턴의 예제이다.

STRAW-EPL Pattern 예제

이 패턴은 보는바와 같이 네트워크 상의 패킷 전송이 정상적으로 이루어 졌음을 나타내는 패턴매칭이다. 상세하게 설명하면 Send, Receive, Ack, RecAck 네 이벤트가 동일한 Data, Bit 값을 기준으로 순차적으로 인과관계로 묶여 있고 Send와RecAck의 시간 구간이 10초 이하인 상황조건일 경우 성공적으로 데이터가 전송되었다는 것을 매칭하는 패턴이다.

6.4 Event Pattern Rules

이벤트 패턴 룰은 이벤트 패턴이 매칭될 때 실행하는 반응 규칙을 말한다. 사용자가 정의한 이벤트 패턴이 매칭되면 이에 따른 반응으로 새로운 이벤트가 생성되므로 자연스럽게 양자간에 인과관계가 암묵적으로 생긴다.

반응 규칙은 논리적으로 두 부분으로 나눌 수 있다. 하나는 트리거로서 이벤트 패턴이고 다른 하나는 패턴이 매칭될 때 실행되는 액션이다.

패턴이 매칭될 때 생성되는 이벤트는 자신의 인과관계로서 이벤트 패턴의 전체 이벤트와 연관된다. 이 때 인과관계를 갖는 패턴 매칭의 모든 이벤트는 생성된 이벤트의 인과관계상 조상 이벤트들이 된다.

반응규칙은 구현에 따라 순차적이거나 병렬적으로 생성된다. 다음의 그림을 먼저 살펴보면 순차적인 반응규칙과 병렬적인 반응 규칙을 구별할 수 있다.

Reactive Rules

순차적인 규칙은 트리거에 따라 새로운 이벤트가 생성될 때 생성된 이벤트 사이의 순차적인 인과관계가 존재하고, 병렬적인 규칙은 오직 트리거 이벤트(인과관계의 조상 이벤트)와의 인과관계만을 갖고 있다는 것을 알 수 있다.(둘 사이의 차이가 어떤 의미를 지니는지 이해하지 못했다.)

다음의 이벤트 패턴 룰의 예이다. 이벤트 패턴 룰 역시 이전에 이벤트 패턴과 같이 STRAW-EPL의 표양식을 동일하게 사용할 수 있다. 다만 여기에 Action 행을 하나 추가하여 이벤트 패턴이 매칭될 때의 액션을 선언하면 된다.

Event Pattern Rule

이 이벤트 패턴 룰은 이전 장의 네트워크 패킷 전송의 이벤트 패턴의 확장으로, 데이터의 전송까지의 시간이 1시간을 넘을 경우 Warning 이벤트를 생성하라는 의미이다. 이 패턴에서의 이벤트 관계는 다음의 그림으로 표현할 수 있다.

Causal Ancestors

주황색 배경에 이벤트 집합이 패턴 매칭된 Poset 이며 이는 암묵적으로 Warning 이벤트와 인과관계를 가지고 있다는 것을 알 수 있다.

6.5 Constraints

제약조건은 시스템에서 이벤트들이 반드시 만족시켜야 하는 조건을 선언하는데 사용된다. 시스템이 어떻게 작동해야하는지 뿐만 아니라 시스템을 사용하는 사람이 어떻게 활용해야 하는지를 제약한다.

제약조건은 STRAW-EPL에서는 간단하게 “never”라는 연산자를 통해서 선언한다. 이 연산자는 두개의 구성요소를 갖는다. 하나는 never라는 연산자 자신과 다른 하나는 만족시켜야 할 STRAW-EPL 이벤트 패턴이다. 다음의 패턴을 예로 보자.

Constraints Example Pattern

보는 바와 같이 이 패턴은 소비자가 한번 주문한 제품을 바로 뒤에 취소하는 것을 허용하지 않겠다는 제약 조건의 패턴을 표현한 것이다. 이 패턴 선언 중간에 never 연산자가 포함된 것을 확인할 수 있다.

이벤트 패턴 룰의 목적은 패턴을 매칭하여 새로운 이벤트를 생성시키는 것이었다면 제약조건의 목적은 단순하게 시스템에서 발생하면 안 되는 상황을 모니터링 하는 것이다. 따라서 제약조건을 이벤트 패턴 룰로 전환하여 문제상황에 대해서 이벤트를 생성시켜 모니터링하는 것도 좋은 방법이다. 결론적으로 제약조건은 시스템이 보장하지 않는 행동에 대하여 표현하는 수단으로 활용할 수 있다.

[The Power Of Event 요약] 5장 Events, Timing, and Causality

5장부터 Part 1의 마지막 7장까지 총 3장에서 본격적으로 Event, Pattern 분석 등 CEP의 기본 개념을 개괄적으로 설명한다.특별히 5장에서는 다음의 내용을 다룬다.

  • 이벤트란?
  • 이벤트의 생성
  • 이벤트의 형태, 의미, 관계성
  • 이벤트의 타이밍, 인과관계, 조합
  • 이벤트의 기본 속성
  • 이벤트의 부분순서
  • 이벤트의 패턴의 타이밍 요구사항
  • 상호프로세스의 활동의 인과관계 분석 예제

5.1 What Events Are

이벤트의 정의를 책에서는 다음과 같이 표현한다.

An event is an object that is a record of an activity in a system.
(Power of Event 88p)

위와 같이 시스템 내부에 어떤 활동의 상태정보를 기록한 객체(Object)를 이벤트라 한다. 즉 이벤트는 시스템에서 수행하는 활동 정보의 상태를 나타내주는 중요한 정보원이 된다. 이러한 이벤트는 독립적이지만 상호간에 생성시기에 따른 순서나 인과관계등의 관련성을 가질 수 있다.

이벤트는 형태(Form), 의미(Significance), 관계(Relativity)라는 세가지 속성을 갖게된다.

  • 형태: 이벤트의 형태는 객체(Object)이다. 객체는 객체지향 프로그래밍에서 말하는 객체를 의미하기 보다는 좀 더 포괄적인 형태를 지칭하는 것으로 볼 수 있다. 상황에 따라서 객체의 구현은 XML이나 단순한 문자열이 될 수도 있고, 내부의 필드를 값으로 자바 클래스의 객체와 같은 것이 될 수도 있다.
  • 의미: 이벤트의 본질은 시스템 내부의 활동을 나타내주는 것이다. 이벤트가 속성으로 내포한 정보를 통해서 우리는 시스템 활동의 상황을 알게 된다.
  • 관계: 시스템의 활동은 상호 연관관계를 필연적으로 갖게 된다. 따라서 활동의 상태를 드러내는 이벤트 역시 다른 이벤트와의 관계성을 갖게 된다.

Esper와 같은 오픈소스 CEP 툴에서는 Event의 표현 방식으로 POJO나, Map 등의 자바 구현체를 사용하기도 하고 XML이나, CSV파일의 정보를 Event로 입력 받을수도 있다.

CEP의 관점에서 우리가 논하는 “이벤트”는 일상적으로 우리가 사용하는 이벤트와 약간의 차이가 있다. 우선 상황의 정보를 드러내는 이벤트는 CEP의 최종 목적이 아니다. 이벤트는 활동을 나타내는 역할을 하지만 CEP에서 프로세싱하는 대상은 활동이 아니라 “이벤트”자체이다.

또한 “이벤트”라는 개념은 분산시스템에서 다루는 “메시지”의 개념과도 차이가 있다. 물론 이벤트를 메시지로 부를 수 있지만 이벤트는 메시지와는 다르게 반드시 “관계”성을 내포한다.

5.2 How Events Are Created

이벤트의 생성은 먼저 시스템의 분석을 통해서 이벤트를 정의하는 것에서부터 시작된다. CEP를 적용할 시스템의 활동을 모든 계층에서 분석하여 어떠한 정보들이 오고가는지를 파악하고 이를 이벤트로 정의하는 것이다. 시스템 관찰과 분석을 통해 정의한 이벤트들을 생성하여 CEP에서 연산할 수 있도록 연결해 주는 것을 “어댑터”라고 표현한다.

요약하면 CEP를 타겟 시스템에 적용하기 위해서는 다음과 같이 두 가지 절차가 수반된다.

  1. 관찰 단계: 시스템의 모든 계층에서 유통되는 정보들을 분석, 정의
  2. 적용 단계: 시스템 내의 정보들을 어댑터를 통해 CEP에서 처리할 수 있는 이벤트로의 전환

엔터프라이즈 시스템에서 일반적으로 관찰 단계의 대상이 되는 곳 즉, 이벤트의 주요한 소스가 되는 곳은 보통 다음의 세 가지로 귀결된다.

  1. IT Layer: 엔터프라이즈 시스템의 분산환경에서 필연적으로 갖추게되는 미들에웨, MOM, ORB, ESB등 네트워크 계층에서 교환되는 정보들이 관찰의 대상이 되고 이벤트로의 치환 대상이 된다.
  2. Instrumentation: 엔터프라이즈 시스템에서 활용하는 도구와 서비스들에서 생산되는 정보 또한 관찰의 대상임과 동시에 이벤트가 된다.
  3. CEP: 마지막으로 복합 이벤트 처리를 통해 생성된 결과들 역시 하나의 이벤트로 간주되어 재활용될 수 있다.

5.3. Time, Causality, and Aggregation

5.1장에서 잠깐 언급한 메시지와 이벤트의 시각의 차이를 이번 장에서 자세하게 알 수 있다. 이벤트는 반드시 시간과, 인과관계 그리고 조합의 관계를 통해 상호 연관을 갖게 되어 있다.

시간 관계는 우리에게 이미 익숙한 방식으로 시스템의 타임스탬프를 통해 이벤트간의 전후 순서의 관계를 갖는 것을 말한다.

모든 IT 시스템은 크게는 프로세스 간에서 작게는 객체간의 호출과 데이터교환을 가지기 때문에 상호간의 인과관계 역시 반드시 존재한다. 즉 어떤 이벤트가 다른 이벤트 발생의 원인이 되었을 경우에 두 이벤트 사이의 인과관계가 성립함을 알 수 있다.

조합은 하위 계층의 여러 이벤트들의 조합이 상위 계층의 이벤트로 표현되는 것을 말한다. 만약 하위 계층의 이벤트 집합인 B1, B2, B3, …, Bn의 이벤트들이 모여 상위 계층의 이벤트 A를 구성한다면 이벤트 A와 이벤트 집합 Bx 사이의 관계를 조합의 관계로 정의한다. 또한 이벤트 A는 복합 이벤트라고 명명한다.

지금까지 살펴본 이벤트의 세가지 관계의 속성은 관계이론의 속성 중 전이적(transitive)이고 반대칭적(antisymmetric)속성을 만족한다.

전이성은 수학적으로 다음과 같이 표현된다 1.

\forall a,b,c\in X:(aRb\wedge bRc)\Rightarrow aRc시간의 관계로 예를 들면 A 이벤트가 B 이벤트보다 시간상 앞서 생성되었고, B 이벤트가 C 이벤트보다 시간 상 앞서서 생성 되었다면, A 이벤트가 C 이벤트가 앞서 생성되었음을 유추할 수 있다.

반대칭성도 마찬가지로 다음과 같이 수학적으로 표현된다. 두 표현 모두 동등한 정의다 2.

\forall a,b\in X,\ R(a,b)\land R(b,a)\;\Rightarrow \;a=b

\forall a,b\in X,\ R(a,b)\land a\neq b\Rightarrow \lnot R(b,a).

인과관계의 예를 통해 반대칭성을 설명한다면, A 이벤트가 B 이벤트의 원인이 되는 이벤트라면 역의 관계로 B 이벤트가 A 이벤트의 원인이 될 수 없다는 것을 안다.

수학적으로 위와 같이 이항관계에서 (반사성을 포함하여) 전이성과 반대칭성을 갖는 것을 부분순서(Partial Ordering) 3라고 정의한다. 시스템 내부에서 발생되는 이벤트가 수학적으로 부분순서의 속성을 갖는다는 것의 의미는 발생하는 모든 이벤트들이 반드시 상호간에 관계를 갖는 것은 아님을 증명해준다.

5.3.1. The Cause-Time Axiom

이전 장에서 설명한 내용을 이해하면 우리는 인과관계와 시간의 관계가 상호간에 깊은 관계가 있다는 것을 알 수 있다. 즉 A 이벤트가 B 이벤트의 원인이 되는 이벤트라면 자연스럽게 A 이벤트가 B 이벤트보다 시간상 앞서 생성된 시간관계를 갖는다는 것을 증명없이 알게 되며 거창하지만 이를 인과관계-시간의 공리라고 부를 수 있다.

5.4. Genetic Parameters in Events

이벤트에 기본적으로 따라붙는 속성을 여기서 Genetic Parameter라고 정의한다. 이 속성 안에는 시간정보가 들어가는 타임스탬프와 인과관계 정보가 포함되는 Causal Vector가 있다.

5.4.1. Timestamps

타임스탬프를 복수로 표현하는 이유는 이벤트에 여러 타임스탬프를 속성으로 가질 수 있기 때문이다. 예를 들면 이벤트의 생성시점이 아닌 어떤 활동의 구간시간을 타임스탬프로 저장한다면 수행시작과 끝시간을 가져야 한다. 또는 측정기준이 다른 시각을 타임스탬프로 복수로 가질 수도 있다.

5.4.2. Causal Vectors

Causal Vector 속성은 자신의 이벤트의 원인이 되는 이벤트의 벡터값을 갖는 것을 말한다. 이벤트 안에 Causal Vector를 둔다는 것은 쉽게 이벤트의 인과관계를 추적하는 정보가 된다.

Causal Vector

5.5 Time

이벤트에서의 시간관계는 시스템의 작동상황을 모니터링할 수 있는 좋은 정보가 된다. 예를 들면 시스템이 제대로 작동하는지 모니터링 한다면 “어디서부터 이벤트를 찾아볼 것인가?” 하는 물음이 들을 수 있다. 사용자가 확인하고자 하는 활동의 이벤트 정보의 시간관계를 통해서 어느 구간의 이벤트를 확인할 것인지 필터링할 수 있는 것이다.

Pattern Matching Rule

또한 이벤트의 시간의 속성은 다음 장에서 다룰 이벤트 패턴 매칭에도 효율적으로 활용된다. 책에서 설명하는 미들웨어의 통신 시스템에 보편적으로 활용되는 Publish/Subscriber 을 예로 든다면, 하나의 이벤트가 발행된 후에 구독하는데 까지 걸리는 시간의 제약조건을 위와 같이 패턴으로 정의하여 이 시간을 초과할 경우에 대해서 다음과 같이 알람 메시지를 생성할 수 있다.

Pattern Matching Result

5.6 Causality and Posets

5.3장에서 설명한 것처럼 분산환경 시스템내에서 발생하는 이벤트들 사이에는 일련의 인과관계가 존재하며 특별히 인과관계라는 이항관계가 부분순서를 따른다고 설명했다. 이렇게 부분순서의 속성을 지니는 서로간에 원인과 결과의 관계로 연관있는 이벤트들의 집합을 부분순서집합이라고 표현하며 영어로는 Partially Ordered Set이라 하고 줄여서 Poset이라 한다.

5.3장에서 이미 설명했만 Poset의 함의는 모든 이벤트들이 반드시 상호간의 인과관계로 엮여 있을 필요는 없다는 사실이다. 이는 그래프를 통해서 시각적으로도 증명이 되는데, Poset이 그래프로는 Directed Acyclic Graph(DAG) 4의 형태를 띄기 때문이다.

DAG는 이벤트의 인과관계가 모든 이벤트로 연결되지 않고 특정한 인관관계를 구성하는 집합이 제한되어 있음을 알려준다. 따라서 인과관계를 통해서 찾고자하는 정보와 관련 없는 모든 이벤트를 다 모니터링 하지 않고 인과관계가 있는 이벤트에 한정해서 모니터링할 수 있다. 정리하면 인과관계의 분석은 모니터링할 이벤트의 검색공간(search space)를 한정시켜 준다.

Causal Event History

위의 그림에서 각 타원은 하나의 이벤트를 의미하고 화살표는 인과관계를 보여준다. Withdraw(15, A1) 이벤트의 인과관계는 Deposit(10, A1)이라는 것을 그림을 통해서 알 수 있다. 그림에서 회색배경의 타원이 Overdraft(A1)의 인과관계를 나타내는 Poset에 해당한다. 위 그래프를 통해서 Overdraft(A1)의 가장 직접적인 인과관계는 Transfer(5, A1, A2)라는 것을 추적하여 알 수 있다. 또한 반대로 Deposit(10, A2)와 같이 Overdraft(A1)과 직접적인 연관이 없는 이벤트도 Poset 안에 포함될 가능성도 있다는 것을 알 수 있다.

5.7 Causal Event Executions-Real-time Posets

Causal Event Execution 은 시스템 에서 생성된 이벤트들의 Poset을 다르게 표현하는 말이다. 이 표현은 실시간으로 이벤트 간의 인과관계를 분석하는 부분을 강조하기 위한 표현이다. 실시간으로 이벤트의 인과관계 분석의 적용이 쉬운 전형적인 예는 네트워크 모니터링이다. 다음의 그림은 M,M1,M2 세개의 패킷을 전송하는 것과 관련된 네트워크 상의 이벤트 로그를 보여준다.

An event log of network protocol

 

 

이 예제에서 패킷의 전송 시 발생하는 이벤트는 Send -> Receive -> Ack -> RecAck 순으로 이어지는 것이 정상적인 순서이다. 이 예제는 단순히 몇개의 패킷의 예만 보여줄 뿐 실제 운영상에서 무수히 많은 패킷로그들이 있다고 하면 현재와 같이 순차적으로 이벤트 로그를 보면 인과관계를 제대로 분석하기 어렵다. 아래 그림은 이를 보완하여 각 이벤트 사이의 인과관계를 화살표로 표시하여 나타내었다.

An event log of network protocol added causal relationship

 

5.8 Orderly Observation

이벤트는 타겟시스템에서 생성되어 실시간 모니터링을 위해 CEP 어댑터를 통해 도착한다. 이 때 반드시 이벤트의 도착순서가 타겟 시스템에서의 인과 순서와 동일하다고 보장할 수 없다. 그렇지만 확실하기 이벤트의 인과순서대로 이벤트가 CEP에 적용될 때 “Orderly Observation”이라고 명명할 수 있다. Orderly Observation의 보장은 이벤트 분석을 용이하게 해준다는 장점 그 이상도 그 이하도 아니다.

5.9 Observation and Uncertainty

타겟 시스템에 적용된 CEP는 시스템이 발생시키는 이벤트도 분석하지만, 분석을 통해 추론된 이벤트들도 다시 분석하는데 활용하기도 한다. 이렇게 시스템 내에서 발생된 이벤트로부터 생성된 이벤트를 Event Inferences라고 명명한다. 추론된 이벤트는 시스템에서 발생하는 이벤트가 나타내지 못하는 시스템의 활동들을 표현하는데 활용된다.

그러나 시스템의 모든 활동을 이벤트로 치환할 수는 없다 마지막 장에서 저자가 몸을 사리는 내용을 더한다.  “불확실성의 원리”라는 두루뭉술한 개념을 정의하여 이벤트 분석을 통해서 확인할 수 없는 시스템의 활동 상황의 존재의 여지를 남겨둔다.

Notes:

  1. http://en.wikipedia.org/wiki/Transitive_relation
  2. http://en.wikipedia.org/wiki/Antisymmetric_relation
  3. http://ko.wikipedia.org/wiki/%EB%B6%80%EB%B6%84%EC%88%9C%EC%84%9C
  4. http://en.wikipedia.org/wiki/Directed_acyclic_graph

[The Power Of Event 요약] 3장 Viewing the Electronic Enterprise

3장의 핵심은 “어떻게 하면 무수한 이벤트로부터 각 사용자가 해결하고자 하는 문제에 적절한 정보들을 도출할 것인가”이다. 네트워크 상에서 흐르는 수 많은 이벤트 클라우드(Event Cloud)은 우리에게 필요한 형태의 이벤트 형태가 아니다. Open Enterprise 환경에서는 자사의 문제해결 방식에 맞도록 이벤트 정보를 이벤트 구름에서 도출해야 한다. 따라서 본 장에서는 엔터프라이즈 관점에서 유의미한 정보를 어떻게 이벤트로부터 적절하게 분석하여 도출할 수 있는지에 대한 개론적인 설몀을 한다. 구체적으로는 다음의 내용들에 대해서 다루다.

  • 이벤트 모니터링 – 표준 기술들
  • 엔터프라이즈 관점 – 모니터링을 넘어 어떻게 데이터를 분석할 것인가
  • 글로벌 이벤트 클라우드에서 유의미한 이벤트 묶음을 도출,분석하는 방법- 엔터프라이즈 환경과 맥락에 맞는 정보 제공 방법
  • 정보 격차
  • 엔터프라이즈의 구조와 이벤트 정보의 추상화 계층
  • 계층형 시스템 뷰를 통한 엔터프라이즈 시스템의 정보를 컨트롤하기

3.1 Today’s Event Monitoring Is Too Primitive

의사결정에 필요한 정보 획득이 어려운 근본적인 이유 중 하나는 모니터링 솔루션들의 대부분이 네트워크 계층에만 집중되어 있기 때문이다. 최근의 엔터프라이즈 시스템들의 요구사항들은 단순히 장애처리를 위한 과거 하위계층에서의 문제 모니터링 뿐 아니라 의사결정에 필요한 유의미한 정보 도출을 위한 상위계층의 모니터링들이 많다.

3.1.1 System Monitoring Focuses on the Network Layer

엔터프라이즈 시스템이 직면하는 가장 주요한 문제들을 네트워크 장애다. 특별히 네트워크 문제는 분산환경으로 인해 더욱더 문제의 원인을 추적하기가 상당히 어렵다. 네트워크 계층 상의 TCP 패킷, 경고, 퍼포먼스 정보들이 끊임없이 로깅되고 모니터링 된다. 대부분의 모니터링 툴들이 이러한 낮은 계층의 raw 이벤트 정보들의 추적과 분석에 집중되어 있다.

3.1.2 Network-Level Monitoring Doesn’t Event Solve Network Problems

네트워크 게층의 모니터링 툴이 다양하게 존재하지만 문제는 여전히 이러한 툴들이 효과적이지 못하다는 점이다. 네트워크 계층에서 발생하는 이슈와 요구들은 다음과 같이 다양하다.

  • 네트워크 계층에서 발생하는 이벤트 로그의 양이 막대하게 증가하고 이를 실시간으로 다루기가 어렵다.
  • 네트워크 계층은 분산환경에서 상호 연관되어 있기 때문에 일부 시스템의 장애로 인하여 관련된 이벤트 로그들이 다양한 곳에서 발생할 수 있다. 이렇게 원인이 동일한 관련 이벤트 로그들의 묶음을 적절하게 분석할 수 있어야 한다.
  • 네트워크 계층에서 발생하는 여러 이벤트 로그의 핵심 원인을 파악하기 위한 인과관계의 추적이 필요하다.
  • 발생하는 이벤트 로그의 패턴 분석을 통한 예측적 모니터링은 쉽지 않다. 최선의 방법은 이전의 장애로부터 패턴을 도출하여 재발의 우려를 모니터링하고 막는 것이다.

결론적으로 현재의 IT 레이어(네트워크 계층)의 모니터링 툴은 네트워크 관리에 효과적이지 못하고 개선의 여지가 있다[2002년에 쓰여진 책이기 때문에 현재의 상황을 담고 있지는 않지만 위의 이슈들은 변하지 않은 것 같다].

3.2 An Example of Causal Tracking

이벤트의 인과 관계 추적을 위한 예로 뱅킹시스템의 트랜잭션을 설명한다. 특히 일반적인 트랜잭션 시스템에서 데이터의 Integrity 보장을 위한 2PC(Two Phase Commit) 방법에 대해서 간단히 설명한다.

2PC는 하나의 트랜잭션을 Polling Phase와 Commit Phase로 나누어 트랜잭션에 연관된 각 참여자가 하위트랜잭션들을 성공적으로 수행할 준비가 되어있는지를 Polling하는 단계와 이를 모두 수행할 수 있다는 확인 뒤에 Commit을 통해서 하나의 완결된 트랜잭션을 마치는 단계로 이루어진다.

이러한 트랜잭션이 이루어지는 과정 사이에서 주고 받는 이벤트 정보들의 인과 관계 분석을 통해서 어떤 시스템에서 어떤 단계에 이벤트를 주고 받는지를 시간과 논리적 순서에 따라 인과관계를 분석하여 이벤트 자체를 모니터링할 때 보다 더 유의미한 정보를 도출할 수 있다.

3.3 Information Gaps

필요한 정보를 도출하지 못하는 문제는 IT Layer(네트워크 단) 모니터링 때문이 아니다. 엔터프라이즈 내의 모든 계층에 대한 적절한 모니터링과 관리의 문제이다.

Information Gaps

각 계층마다 관련된 사용자와 그들이 요구하는 정보는 다르게 마련이다. IT Layer에서 발생하는 정보는 시스템 관리자에게는 의미있는 정보일 수 있지만 조직 관리자나 의사결정권자에게는 불필요한 정보이다. 각 계층에서 자신의 과업을 효율적으로 달성하기 위해서 요구하는 정보의 형태가 다르기 때문에 정보의 격차가 발생하게 된다.

정보의 격차는 수직적인 측면과 수평적인 측면에서 격차가 발생한다. 수직적 측면이라함은 시스템 구조의 계층(Layer)의 차이로 인해 발생하는 정보의 형태와 양에서 오는 정보 격차를 말한다. 수평적 측면은 관심갖고 분석하는 정보의 대상의 차이에서 오는 동일 계층 내의 정보 격차이다.

3.3.1 Examples of Information Gaps

정보 격차의 예로 책에서는 제조관련 엔터프라이즈 시스템을 든다. 네트워크 매니저의 관심사는 당연히 네트워크 내부의 문제 상태를 모니터링하는 것이 중요하다. 반면에 제품 생산라인의 매니저는 네트워크 관련 이벤트는 관심사가 전혀 아니다.  매니저에게는 제품 생산라인의 작동 현황 및 상태나 퍼포먼스 등의 정보가 필요하다. 이러한 정보는 네트워크 계층에서 얻을 수 없고, 좀 더 상위 계층의 이벤트로부터 정보를 도출할 수 있다. 마찬가지로 의사결정권자들에게는 개별적인 생산라인의 구체적인 정보들은 관심사항이 아니다. 이들에게는 운영을 위한 더 포괄적인 정보(제품 주문 및 재고, 생산단가와 출하일정 등)가 필요하며 이러한 정보들은 상위 계층의 이벤트로부터 추론해야 한다.

결론적으로 각 사용자의 요구사항에 따라 수평, 수직적인 측면에 따라 정보의 격차가 발생한다.

3.4 Problem-Relavant Information

정보격차를 해소하는 해결책은 문제와 관련도가 높은 정보(Problem-Relavant Information)를 획득하는 것이다. 문제와 관련도가 높다는 것은 불필요한 이벤트 정보를 일일이 모니터링하는 것이 아니라 사용자들이 즉각적으로 원하는 문제와 관련된 이벤트를 모니터링하고 분석하는 것이다.

문제와 관련도가 높은 정보를 얻기 위해서는 알고 싶은 즉각적인 문제에 대해서 명료하게 정의하는 것, 그리고 언제든지 변동 가능한 이러한 사용자의 관심 문제상황 등을 실시간으로 적용해서 모니터링 대상이 되는 이벤트들을 분석하는 것이다. 이를 잘 하기 위해서는 다음의 4가지 조건을 만족시켜야 한다.

  • 즉각적 관심을 일으키는 문제에 대한 적절성: 이벤트가 문제와 어느 정도의 연관성이 있는지를 파악하는 것은 주관적인 부분이다. 그렇다고 비즈니스 관리자에게 TCP 패킷 관련 정보를 제공할 수는 없지 않은가! 이 조건의 핵심은 어떻게 이벤트 정보들 사이에서 문제와 관련성이 높은 이벤트를 최대한 사용자에게 제공할 것인가 하는 점이다.
  • 상황에 대한 쉬운 이해를 제공: 의사결정의 흐름을 자동화하면 되는데 굳이 사용자가 상황을 이해할 필요가 있을까 싶겠지만, 오류나 버그상황에 대한 인지와 수정에 대한 결정도 사람이 하게 된다. 따라서 적절하게 시스템의 진행상황에 대한 정보를 이해하기 쉽게 제공할 수 있어야 한다.
  • 분석의 용이함: 이벤트 분석은 이벤트가 내포한 데이터와 상관이 있다. 각 이벤트가 담고 있는 상태 정보, 타임스탬프, 인과 관계 정보 등을 기반으로 이벤트 분석을 할 수 있으며 이를 통해 사용자가 요구하는 문제상황에 맞는 정보들을 도출한다.
  • 다양한 모니터링 결과에 대한 조합의 용이: 사용자가 상정한 문제상황들 사이에도 연관성이 존재 가능하고 이는 각각의 결과정보의 조합을 통해서 더 추상적이고 포괄적인 정보를 제공하는 단초가 된다. 따라서 여러 이벤트 분석 결과들을 통합적으로 모니터링하고 분석할 수 있어야 한다.

3.5 Viewing Enterprise Systems

시스템의 특수한 문제와 관련성이 높은 정보결과를 제공하는 것은 실시간 의사결정을 위한 작업 프로세스의 자동화와 시스템 운영을 위한 선제조건이다. “시스템의 뷰”는 결국 사용자가 관심갖고 있는 특정한 문제와 연관도가 높은 정보의 선택적 제공이다. 이러한 뷰에는 애플리케이션 단에서의 네트워크 트래픽 사용 현황률, 네트워크 장애상황에 대한 뷰 등의 다양한 예가 있다.

“시스템의 뷰”는 공통적으로 다음의 요소들을 갖고 있다.

  1. 모든 뷰에는 특정한 관심사항의 문제와 연관된 정보를 제공한다.
  2. 모든 뷰는 이벤트 기반이다.(불필요한 이벤트를 필터링, 이벤트를 카테고리화하고, 관련 이벤트 간의 조합)
  3. 모든 뷰는 그래픽을 활용하여 이해하기 쉬운 결과정보를 사용자에게 제공한다.
  4. 모든 뷰는 자동화된 의사결정 과정 지원을 위한 관련 정보를 제공한다.
  5. 가장 중요한 점은 실시간으로 시스템의 중지 없이 문제상황에 대한 모니터링 조건을 수정한다.

3.6 Creating and Coordinating Multiple Views

이 장의 기본적인 전제는 모든 사용자는 저마다 시스템에 대해서 다른 관심사항을 갖고 원하는 정보가 다른다는 것이다. 따라서 각 사용자에게 해당하는 개인화된 뷰를 제공해야 하고, 따라서 시스템의 모니터링 결과는 복수의 뷰를 제공해야만 한다. 한걸음 더 나아가 각 사용자의 요구사항에 맞게 뷰를 커스터마이제이션도 할 수 있어야 한다. 동일한 시스템 내에서 동시에 서로 다른 사용자 개인 또는 그룹에 따라 복수의 뷰를 생성하고 개인화하여 제공하는 것이 필요하다.

3.7 Hierarchical Viewing

복잡한 엔터프라이즈 시스템에 대한 이해를 쉽게 해주는 것은 시스템을 계층으로 분리하는 것이다. 레이어(또는 레벨)로 분리된 계층의 관점으로 사용자는 다른 계층에 대해서 신경 쓰지 않고 해당하는 계층에 대해서만 관심 갖고 분석할 수 있다. 이렇게 시스템을 계층의 관점으로 분리해내는 것을 계층형 뷰(Hierarchical Viewing)이라고 한다.

게층형 뷰의 관점으로 시스템을 분석하기 위해서는 추상화된 계층(abstraction hierarchy)을 정의해야 한다. 추상회돤 계층을 정의하는 일은 몇가지 번거로운 작업이 수반된다. 우선 실제 조직의 운영 및 활동을 명확히 정의해야 하는데 이는 기술적 이슈라기 보다는 조직 내에서 합의 되어야 할 운영문제이다. 또한 시스템 자체를 계층형으로 구조화해야 한다. 시스템을 계층화 아키텍쳐로 구성하는 일은  각 계층을 순서를 가지고 탑다운 방식으로 분리하는 일이다. 분리된 최하위 계층의 이벤트들이 모여 상위 계층의 이벤트를 구성할 수 있는 방식이 되어야 한다.

3.7.1 An Example of Hierarchical Viewing

계층형 뷰에 대한 예제는 이전 3.2장의 인과분석의 예에서 사용한 2PC 방법의 트랜잭션의 예로 다시 설명 가능하다. 이 트랜잭션은 상위 계층(금융 트레이드 레벨)에서는 Polling Phase와 Commit Phase로 뷰를 제공할 수 있고 2 단계의 정보는 하위 계층(트랜잭션 프로토콜 레벨)에서는 좀 더 세분화된 단계와 이벤트들의 조합으로 구성된다.

Hierarchical Viewing

계층을 구성하기 위해서는  3.7에서 설명한대로

  1. 엔터프라이즈 시스템의 활동에 대한 기술을 정확하게 정립하고
  2. 상위 레벨의 이벤트와
  3. 상위 이벤트와 하위 이벤트 사이의 관계

를 정의해야 한다.

이 예제에서는 성공적으로 커밋이 이루어진 경우와 실패한 경우의 시스템 활동에 대해서 정의할 수 있고 이와 관련된 이벤트 상위 레벨 이벤트를 Successful-2pc, Failed-2pc와 같이 정의하고 이 이벤트들을 하위 이벤트의 조합과 패턴과 매칭 시켜 정의 할 수 있다.

결론적으로 하위 레벨(트랜잭션 프로토콜 레벨)의 이벤트들의 조합 또는 패턴은 결국 상위 레벨(금융 트레이드 레벨) 이벤트로 추상화 되었다고 볼 수 있다.

좀 더 자세히 나누어 보면 상위레벨에서는 하위레벨과 달리 다음과 같은 정보들을 제공할 수 있다.

  • 트랜잭션의 성공/실패율 정보
  • 완료된 트랜잭션의 타이밍, 성공/실패시의 타이밍 정보
  • 실시간으로 동시에 운영되는 트랜잭션의 수

마찬가지로 하위레벨에서도 상위 레벨과 달리 상위레벨에서 이벤트가 추상화되면서 감추어진 하위 레벨만의 구체화된 정보를 보여줄 수 있다.

4장 Designing the Electronic Enterprise는 내용이 엔터프라이즈 시스템 설계를 다루므로 생략

[The Power Of Event 요약] 2장 Managing the Electronic Enterprise in the Global Event Cloud

2장에서는 엔터프라이즈 시스템에서 어떻게 정보를 관리, 감독하고 있는지의 현황과 앞으로의 기술적 이슈들에 대해서 다루며 구체적으로 다음의 내용들을 설명한다.

  • Global Event Cloud
  • Global Event Cloud 속에서 엔터프라이즈의 운영
  • 작업플로우를 넘어 관리 프로세스
  • 자동화된 병렬, 비동기 프로세스
  • 엔터프라이즈 시스템
  • 엔터프라이즈 시스템을 사용자 측면에서 다루는 법
  • 엔터프라이즈 시스템을 관리하기 위한 기술적 요구사항

2.1 How the Global Event Cloud Forms

인터넷 기반의 정보처리 시스템은 계속해서 증대되며 거스를 수 없는 추세임을 설명한다.

2.1.1 The Open Enterprise

단일 엔터프라이즈 내부에서만 이벤트가 생성되어 소비되는 구조는 존재하지 않는다. 이전 장에서 설명한 계층을 통해 바라보면 Collaboration 계층에서의 기업 간의 경계가 모호해 지고 있다. 이러한 기업의 IT 시스템 구조의 상황을 개방형 엔터프라이즈라고 표현할 수 있다. 상호간의 협력적 관계를 통해 기업내부 뿐 아니라 외부와의 이벤트 흐름도 생성되는 것이다. 따라서 이러한 외부와의 이벤트 교류를 모니터링할 수 있는 정교한 보안 및 인증, 관리, 감독 기술이 필요하다.

2.1.2 The Global Event Cloud

개방형 엔터프라이즈와 함께 이제는 전 세계적으로 복잡하고 막대한 이벤트의 더미 속에서 엔터프라이즈 시스템이 운영된다. 네트워크에 연결된 수많은 엔터프라이즈 시스템이 생성하는 이벤트들의 총체를 Global Event Cloud라고 한다. Cloud라는 표현을 쓰는 이유는 네트워크 상의 이벤트들이 제대로 로 정돈되어 있거나 구조화 되어 있는 것이 아니기 때문이다. 또한 이벤트의 생성 시점이나 전송 순서에 따라 이벤트가 반드시 순차적으로 도착하는 것도 아니다. 조직화 되지 않은 이벤트 클라우드로부터 개방형 엔터프라이즈는 개별적으로 이벤트의 입력을 다룰 수 있어야 한다.

2.1.3 The Electronic Enterprise

영어 표현을 직역하면 전자 엔터프라이즈이지만 의미는 오늘날의 엔터프라이즈 시스템을 의미한다. 좀 더 구체적으로는 이벤트 기반의, 자동화된 정보 처리 시스템을 말한다. 책이 쓰여진 2002년과 달리 현재는 전세계적으로 네트워크로 통합되어가는 엔터프라이즈 시스템은 선택사항이 아닌 필수이다.

2.2 Operating in the Global Event Cloud

Example Workflow

이 그림은 어떻게 기업 내의 업무가 실제 엔터프라이즈 시스템으로 표현되는지를 보여주는 예이다. Process Order라는 하나의 선형 작업흐름은 4개의 단계를 가지고 있다. 이 작업흐름을 완료하기 위해서는 엔터프라이스 시스템의 경계를 넘어 많은 이벤트 들이 오고가야 한다.

 Event-Driven Business Process Figure

이 그림은 Process Order의 작업흐름을 엔터프라이즈 시스템 내에서 운영하기 위한 구현의 한 예시이다. 가운데 영역의 Event Cloud에는 네트워크 상의 존재하는 무수한 이벤트들이 포함되어 있다. 이 이벤트들 가운데 Process Order 작업과 연관이 있는 이벤트는 빨간색 배경을 가진 이벤트들이다. 엔터프라이즈에서 정의한 업무의 규약들은 Process Rule로 구현되어 있다.

각각의 이벤트가 발생하였을 때 좌측의 프로세싱 룰에서 수신된 이벤트의 정보에 따라 새로운 이벤트를 생성하여 다음 스텝으로 작업이 넘어갈 수 있도록 대처한다. 위의 과정은 기업 내의 활동의 흐름을 보여주는 전형적인 예이다. 엔터프라이즈 시스템의 내외를 이벤트들이 통과하면서 하나의 작업흐름이 수행된다. 물론 프로세스의 작업  단계나 이벤트 클라우드 혹은 프로세스 룰에서 예외상황이 나타날 수 있다. 이 떄 적절하게 어느 부분의 어떤 과정에서 문제가 발생하였는지 파악해야 한다.

이 모델에서 발견할 수 있는 핵심은 프로세스는 이벤트 기반이라는 점이다. 이벤트의 발생과 도착 유무에 따라 사전에 정의된 적절한 프로세스 룰이 실행되어 새로운 이벤트를 생성시켜 다음 절차로 넘긴다.

2.3 Going Beyond Workflow

이전 장의 예제에서 확인할 수 있는 사실은 이벤트의 도착 여부에 따라 다음 이벤트가 발생하는 동기화된 흐름을 갖고 있다는 점이다. 또한 작업 흐름 내부의 사람의 개입이 많이 필요하다는 점이다. 선형의 단순한 작업흐름의 구조는 현재의 엔터프라이즈 시스템의 요구사항을 만족시키기에는 부족하다.

모든 작업을 사람이 개입이 전혀 필요없게끔 하는 것은 사실상 불가능 하지만 가능한 사람의 개입을 줄이고 자동화 하는 것이 엔터프라이즈 시스템에서는 중요하다. 비용과 효율성의 측면에서도 작업의 흐름을 비동기적으로 전환하고 여러 업무를 병렬적으로 실행하는 것이 필요하다. 또한 프로세스에 대한 주도권을 관리자가 갖고 있어 언제든지 상황에 따라 프로세스를 수정하며 의사결정을 위해 사용자에 맞는 정보를 제공할 수 있어야 한다.

2.4 Parallel and Asynchronous Processes

이전 예제의 2단계인 SelectVendor를 좀 더 세분화된 하위작업들의 집합으로 확장할 수 있다. 이 하위 작업들은 비동기적이면서 병렬적으로 동시에 실행가능하다.

Asynchronous-Parallel Process Figure

그림에서 보는 바와 같이 Select Vendor라는 이전 그림의 2번째 절차가 다음과 같이 병렬적으로 비동기적으로 프로세스를 구성하면서 완전히 자동화를 이루었다. 유효한 주문의 발생과 동시에  프로세스 룰에 기초해서 비동기적으로 여러 RFQ 이벤트를 전송하고, 벤더사들로부터 입찰을 받을 때도 비동기적이면서 병렬로 입찰정보를 받는다.

이와 같은 작업은 이전의 선형작업흐름보다 좀 더 복잡한 이벤트 패턴 매칭이 요구된다. 하나의 하위작업에서 여러개의 이벤트를 동시에 확인하고, 또한 여러 이벤트를 동시에 병렬적으로 출력해야 한다. 더불어 현재 작업의 상황에 따라 동적으로 이벤트를 출력할 수 있어야 한다. 이러한 기능을 우리는 보통 Context Checking이라고 한다.

결론적으로 엔터프라이즈 시스템 내부에서는 하위작업들인 Process Rule로 인터페이스화 되고 모든 실행은 외부의 Event Cloud를 통해서 자동으로 비동기, 병렬 실행된다. 또한 이와 같은 작업을 위해서는 여러 이벤트를 복합적으로 모니터링하고 패턴매칭할 수 있는 기술적인 요구가 포함된다.

2.5 On-the-Fly Process Evolution

비즈니스 환경은 정적이지 않고 항상 변화한다. 따라서 우리가 설계하고 정의한 작업흐름대로 비즈니스가 진행된다고 생각해서는 안된다. 따라서 엔터프라이즈 시스템은 언제든지 상황에 따라 변화할 수 있는 구조를 갖추고 있어야 한다. 특별히 시스템의 중지 없이 프로세스를 변화할 수 있어야 한다. 이러한 과정을 On-the-Fly 프로세스라고 할 수 있다. 아래 그림과 같이 RFQ 발행과 관련된 기존의 프로세스 룰을 실시간으로 변경하여 시스템에 적용할 수 있어야 한다

On-the-Fly Process Figure

. 실시간으로 변경된 룰에 이벤트들이 기준을 충족시키지 못할 경우가 있다면 시스템은 어떻게 될까? 이런 경우를 대비해서 사용자는 늘 전체 프로세스의 진행상황과 이벤트의 유출입, 로그정보 등을 확인해야 하고 이를 위해서 시스템은 사용자의 관심사항에 맞게 개인화된 모니터링 정보를 제공할 수 있어야 한다.

결론적으로 실시간으로 프로세스 룰(요구사항)을 변경시키기 위해서는 다음과 같은 기술적인 요구들을 검토할 필요가 있다.

  • 시스템 내 모든 레벨의 활동 정보를 실시간으로 개인화된 정보제공창을 통해 보여주는 것
  • 시스템의 중지 없이(On-the-fly) 프로세스의 수정
  • 변경이력을 실제 시스템에 적용하기 전에 시뮬레이션

2.6 Exceptions Must Be First-Class Citizens in Process Design

제목에서 말하는 바와 같이 시스템 설계에 있어서 핵심은 예외사항을 반드시 먼저 고려해야 한다는 점이다. 따라서 프로세스의 설계 과정에 있어서 정상적인 프로세스 룰과 예외 룰을 동시에 설계해야 한다. 다음의 그림은 이를 보여준다.

Exception Rule Process Figure

그런데 예외룰을 설계에 고려한다는 것은 사실 어려움이 따른다.

  1. 실시간으로 우리가 상정하지 않은 상황에 대해서 항상 인식해야 하며
  2. 문제를 일으키는지 원인이 무엇인지 반드시 알아야 한다.

 

[The Power Of Event 요약] 1장 The Global Information Society and the Need for New Technology

먼저 1장을 다루기 전에 Part 1에 대해서 간략하게 소개한다. Part 1은 1장부터 7장까지를 다루며 A Simple Introduction to Complex Event Processing란 제목을 달고 있다. Part 1에서는 다루는 이슈는 다음과 같다.

  • 오늘날의 전자정보 시스템을 사람이 어떻게 관리, 감독할 것인가와 관련된 이슈들
  • CEP의 기본 컨셉, 개념
  • CEP를 통해서 어떻게 위와 같은 이슈들을 다룰 것인가

따라서 1-4장에서는 오늘날의 비즈니스 세상에서 어떻게 IT 시스템이 운영되는지에 대한 배경과 특성을 다룬다. 여기에서 여러가지 관련 이슈들을 도출하고 왜 CEP가 오늘날의 비즈니스 엔터프라이즈 세상에서 필요한 지를 찾아본다. 5-7장에서는 CEP의 기본적인 개념과 동작원리들을 설명함으로 어떻게 엔터프라이즈 시스템의 최근 이슈들에 대응할 것인가에 대해서 개괄한다. 그럼 이제 1장의 본론으로 넘어가자

1장에서 다루는 내용은 다음과 같다.

  • 오늘의 대부분의 지식정보 시스템에는 Event가 존재한다는 점
  • 인터넷과 전세계적으로 통신 네트워크의 복잡성이 증대된 점
  • 엔터프라이즈 시스템 아키텍쳐에서의 다단계 레이어 구조
  • 전세계적인 온라인 거래의 작동 원리
  • 애자일 시스템이 과연 가능한 지
  • 개방된 전자정보 사회가 스스로를 보호할 수 있는가
  • 웹상의 정보를 모으는 것이 전세계적인 협력이 될지 혼돈이 될지

이 책이 2002년에 출판된 점을 감안해서 진부한 배경설명을 만나게 된다. 21세기 우리들의 삶의 근간을 컴퓨터 시스템이 구축했다는 것, 웹과 인터넷을 통해서 막대한 정보가 생산, 증대된다는 점 등의 이야기들이 이에 해당한다.

문제는 전세계적으로 정보들이 소통하는 시스템 구조에서 이러한 정보들을 적절하게 모니터링하고 관리하는 기반기술이 없다는 점이다. 따라서 이 장에서는 이벤트를 중심으로 데이터를 교환하는 정보시스템과 이와 관련된 이슈들을 다룬다.

1.1 Distributed Information System Everywhere

분산시스템은 사실 우리가 이미 익숙하게 사용하는 인터넷 뱅킹이나 홈쇼핑 같은 상업용 서비스에서부터 대부분의 엔터프라이즈 시스템에 녹아있다. 중요한 사실은 이러한 분산시스템의 성장은 인터넷 기술의 발전이 가져왔다는 사실이다. 단일한 기업의 경계와 국가를 넘어 전세계적으로 수많은 정보들이 오고가는 것이다.

엔터프라이즈에서 대표적인 분산시스템의 예를 들자면 온라인 주식거래를 들 수 있다. 전세계에 걸쳐 기업, 개인투자자, 투자은행, 중개인 등을 네트워크를 통해서 하나의 시스템으로 묶어준다. 동시에 이들은 내부적으로도 자체적인 처리 시스템을 독립적으로 가지고 있다.

이러한 엔터프라이즈 시스템 간에 메시지(혹은 이벤트)가 네트워크를 통해 교환된다. 수신된 이벤트 정보에 따라 적절한 대응을 처리하는 이러한 시스템을 우리는 “이벤트 기반 시스템” 으로 정의할 수 있다. 이와 같은 시스템에서는 초당 수천,수백 이상의 이벤트가 전달되며 시스템의 규모에 따라 그 숫자는 훨씬 더 커지게 된다.

주식거래와 같은 금융경제 시스템 뿐만 아니라 전자정부나 군사용 시스템도 동일한 분산시스템이다. 응용분야는 달라도 근본 아키텍쳐는 모두 동일하다. 우리는 이러한 분산 정보 시스템을 통칭하여 “엔터프라이즈 시스템”이라 부른다.

이들 시스템에는 공통적인 문제가 하나 있다. 그것은 시스템 내부의 이벤트와 활동을 인간인 우리가 이해할 수 있는 방식으로 볼  수 있는 기술이 없다는 점이다. 우리는 하위영역의 네트워크 활동 정보 뿐 아니라 비즈니스나 전략적 의사결정 레벨의 고차원적인 정보를 사용하기 위한 상위영역의 활동 정보도 확인할 수 있어야 한다. 이러한 정보들은 단편적인 이벤트의 조합으로부터 복잡한 이벤트(Complex Event)로 추출되며 오늘날 최신의 엔터프라이즈 모니터링 기술을 통해서 우리는 이와 같은 활동들을 할 수 있다.

1.2  The Global Communication Spaghetti Pot

웹을 통한 정보의 교환이 전세계적인 의사소통의 복잡성 속에서 이루어지고 있다는 것을 이 장은 말한다. 예를 들면 우리가 어떤 특정한 사이트에 접속할 때 이 사이트에서 보여지는 정보들은 하나의 서버에서만 들어오는 정보가 아니다. 각종 광고 배너, 여러 실시간 정보, 보안, 사이트 코어 컨텐츠 등이 서로 다른 서버나 시스템으로부터 들어오게 된다. 이러한 통신의 유연성는 인터넷의 발전의 아주 큰 원동력이었다. 따라서 우리는 이러한 유연성을 우리는 제한해서는 안 된다.

그렇지만 단점도 있다. 통신의 유연성과 복잡도 때문의 이벤트의 인과관계를 찾아내기가 어렴다는 점이다. 결론적으로 우리가 사는 세상은 전세계적으로 복잡하게 얽혀 있는 상태에 있다. 우리는 하나의 정보가 어디서 시작해서 어디서 끝나는지 확인할 길이 없고, 밝혀낼 수도 없으며, 대부분은 어떻게 작동하는지도 모른다.

여기서 우리가 직면하게되는 이슈는 통신의 유연성을 보장하면서도 이벤트 정보와 활동들을 이해할 수 있는 새로운 기술을 개발하는 것이다.

1.2.1 Event Causality

이벤트를 이해하는 핵심은 무엇이 이벤트를 발생시켰는지, 이벤트 발생 시에 인과관계를 바로 아는 것이다. 이벤트는 인터넷 기반의 시스템을 통해 세계의 이편에서 인과관계에 있는 세계 저편으로 흐른다.

이벤트 간의 인과관계는 두가지로 분류할 수 있다.

  • 수평 인과관계(Horizontal Causality): 이벤트 간의 인과 관계가 개념적으로 전체 시스템 내에서 동일 레벨에서 일어날 때를 말한다.
  • 수직 인과관계(Vertical Causality): 복합이벤트는 여러 이벤트를 구성요소로 가질 수 있는데 하위레벨에서 발생한 이벤트들의 집합을 통해서 상위레벨의 이벤트가 발생하는 경우를 말한다.

1.3 Electronic Archeology: Layers upon Layers

엔터프라이즈 시스템은 분산 시스템이면서 이벤트 기반 시스템이기도 하지만 보통은 계층형 시스템(Layered Sysem) 이기도 한다. 계층을 구분하는 것은 복잡도를 줄이고 시스템의 영향의 영역을 제한하는 전통적인 설계기법이다. 우리는 계층화된 IT 시스템 내부에서 이벤트가 발생하는 것들을 모니터링하는 방법들에 대해서도 고민해야 한다.

1.3.1 A Layered Enterprise System

계층형 시스템은 본 책에서 다음과같은 4개의 층으로 구성한다.

Layerer Architecture애플리케이션 계층은 최상단에 위치하여 비즈니스 레벨 또는 전략적 계획 레벨로 볼 수 있다. 왜냐하면 실질적인 비즈니스 계획과 교환이 이 층위에서 이루어지기 때문이다. 이 계층에서는 사용자가 실제 작업하는 서비스들이 위치하게 되며 이는 구체적인 서비스들의 목표들과 연결된다. 이 계층에서의 이벤트는 사용자가 이해할 수 있다는 특징이 있다.

의사결정을 위한 고수준의 이벤트들은 주로 사용자가 애플리케이션 내에서 명시적으로 생성한 단일 이벤트가 아니라 여러애플리케이션들 내에서 발생한 이벤트들의 순차적 결과로서 생성된 것들이다. 이와 같은 고수준의 이벤트는 이벤트 자체로는 존재하지 않지만 여러 이벤트들로부터 조합되어 추론된 것이고 가상 이벤트라고 칭하기도 한다. 결론적으로 최상단에서 사용자가 결정을 내리기 위한 이벤트들은 애플리케이션 계층에서 발생된 이벤트들의 조합을 통해 이루어진다.

협력 계층은 사용자가 애플리케이션을 좀 더 효율적으로 활용할 수 있도록 돕기 위한 계층이며 이 계층과 애플리케이션 계층을 구분하는 기준이 엄격한 것은 아니다.

미들웨어 계층은 통신을 위한 가장 기본적인 네트워크 위에 위치한다. 보통 EAI라 불리는 엔터프라이즈 애플리케이션 통합 제품군들이 이 계층에 위치하여 데이터의 전송 등의 역할을 감당한다. 최근에는 다양한 오픈소스 및 사용 EAI 제품군들이 미들웨어 계층에서 사용되고 있다.

네트워크 계층은 데이터 전송의 핵심이 되는 계층이다. 일반적인 사람들은 이 게층에서 전송되는 정보들을 식별하거나 이해할 수 없다. 따라서 이 계층을 이해할 수 있는 전문가들과 이들을 위한 전용 툴들이 많이 있다. 시스템의 결함 뿐 아니라 점차 증대되는 보안침투 이슈를 포함해서 이 계층에서 이루어지는 정보들을 제대로 이해하고 분석할 필요들이 늘고 있다.

1.3.2 Vertical Causality: Tracking Events up and down the Layers

모든 계층에서의 활동은 상하위 계층으로 변환되어 이벤트로 전달된다. 계층 사이의 인과관계를 정확하게 실시간으로 분석하는 일을 수직 인과관계라 부른다. 구체적으로 수직 인과관계를 분석하는 능력은 두가지 일을 필요로한다. 첫째는 비즈니스 계층의 이벤트가 어떻게 하위 계층의 이벤트들로 나뉘어지는지를 이해하는 것이고 둘째는 하위 계층의 이벤트들을 묶어서 상위 계층의 이벤트를 표현하는 것이다. 하지만 수직 인과관계를 찾는 일은 쉬운 일이 아니다. 왜냐하면 모든 계층의 시스템은 항상 변화하기 때문이다. 결론적으로 우리의 시스템의 현재 무슨 작업을 하고 있는지 이해하는 일은 그리 쉬운 작업이 아니다.

1.3.3  Event Aggregation: Making High-Level Sense out of Low-Level Events

이전 장에서 수직 인과관계를 찾는 능력에 대해서 다루었는데 이를 진행하려면 고수준의 이벤트 정보가 필요하다. 하지만 고수준의 이벤트는 비즈니스 측면에서는 분명한 실체이지만 실제 시스템에서는 존재하지 않는 가상이벤트 형태이다. 따라서 고수준의 이벤트를 찾기 위한 대안은 저수준의 이벤트로부터 고수준의 이벤트를 도출하는 것이다.

이처럼 모든 엔터프라이즈 시스템 내의 저수준의 이벤트 집합으로부터 새로운 단일한 이벤트를 도출시키는 과정을 이벤트 조합(Event Aggregation) 이라고 한다.  따라서 이벤트 조합을 제대로 수행한다면 고수준의 이벤트를 도출하여 수직 인과관계를 분석할 수 있다.

1.4 The Gathering Storm of New Activities on the Web

파편화된 정보들을 웹과 인터넷을 통해서 통합하려는 시도와 요구들이 늘어나고 있다. 많은 분야에서 IT시스템과 웹의 신기술을 활용하여 자신들의 목적을 달성하려는 움직임이 많다. 이어지는 세개의 주제에서 어떠한 흐름과 요구들이 있는지 확인해본다.

1.5 Global Electronic Trade

지금 이 시점에서는 당연한 이야기를 하는 것으로서 인터넷의 도래와 함께 전세계적인 온라인 마켓이 활성화 된다는 이야기를 한다. 시스템 간의 표준화된 데이터 공식 포맷으로 XML이 트렌드라는 점과 함께 여러 산업군의 시장을 묵는 트레이딩 허브를 이야기한다. 바로 최근에 아마존에서 고객의 행태분석을 통해서 상품의 구매시점까지 예측해서 보내주는 현실에서 비교할 때 진부한 이야기가 되어버린 챕터이다.

1.6 Agile System

이 장에서 말하는 애자일 시스템은 소프트웨어 개발 방법론을 말하는 것이 아니다. 실시간으로 이벤트를 모니터링하여 요구사항에 민첩하게 대응하는 모든 시스템을 의미한다. 책에서는 군사용 시스템을 예로 들지만 현재 비즈니스 시장에서도 소비자들의 트렌드와 상황을 실시간으로 분석하여 적절하고 민첩한 대응을 필요로 한다는 점에서 중요한 응용분야이다.

1.7 Cyber Warfare and the Open Electronic Society

마지막은 해킹과 보안 공격에 대비하는데 있어서 네트워크 단위의 이벤트 모니터링의 중요성을 이야기한다. 컴퓨터에 대한 악의적인 침입이나 DDOS 공격, 바이러스, 스팸 메일등과 같은 다양한 공격에 대해서 실시간으로 네트워크 상의 패킷(이벤트)들을 모니터링하여 사전 차단하는 방안들은 효과적일 것이다.

[Esper Manual 4.10.0 번역] 섹션 14.3 관리 인터페이스

14.3.1 문장 생성

이벤트 패턴 식과 EPL 문장을 관리 인터페이스인 EPAdministrator를 통해서 생성한다.

아래 코드조각은 Esper 엔진을 얻어와서 이벤트 패턴과 EPL 문장을 생성한다.

이벤트 패턴 식은 EPL 문장 안에 포함 될 수 있다는 점을 주목해야 한다. 이 내용은 섹션 5.4.2 “패턴 기반 이벤트 스트림”에서 자세하게 다룬다.

EPAdministrator의 create 메서드는 오버로드되며 선택적으로 문장 이름이 엔진에 전달되는 것을 허용한다. 문장 이름은 나중에 엔진으로부터 이름을 가지고 문장을 얻을 수 있는데 유용하게 활용될 수 있다. 엔진은 문장 이름이 문장 생성시 제공되는 것이 아니면 문장 이름을 할당한다.

createPattern과 createEPL 메서드는 EPStatement 인스턴스를 반환하다. 문장은 자동적으로 생성시에 시작되어 활성화된다. 문장은 또한 다음 코드조각과 같이 stop, start 메서드를 통해서 정지 및 재시작 될 수 있다.

EPAdministrator의 create 메서드는 또한 유저 객체를 수용한다. 유저 객체는 문장의 생성시점에 문장과 연관이 되는 하나의 이름 없는 필드로 모든 문장에 저장된다. 당신의 애플리케이션은 이 필드 안에 임의의 객체를 넣어둔다. EPStatement의 getUserObject를 사용하여 문장의 유저 객체를 얻을 수 있고 StatementAwareUpdateListener를 리스너로 사용한다.

당신의 애플리케이션은 새로운 문장을 생성하거나 스레드를 통하거나 또는 리스너나 구독자 코드 안에서 기존 문장을  중지시키고 제거할수도 있다. POJO 이벤트를 사용한다면, 당신의 애플리케이션은 동일한 이벤트가 현재 문장에 의해서 처리 중일 때는 이벤트 객체 그 자체 안에서는 문장을 생성하거나 관리할 수 없다.

14.3.2 문장 결과를 받기

Esper는 문장의 결과를 받는데 3가지 선택사항을 제공한다. 당신의 애플리케이션은 3가지 메커니즘을 각기 사용하거나 각 문장에 대해서 어느 조합으로도 사용할 수 있다. 선택사항은 아래와 같다.

  1. 리스너 콜백 / addListener와 removeListener / 당신의 애플리케이션은 UpdateListener 또는 StatementAwareUpdateListener 인터페이스의 구현을 문장에 제공한다. 리스너는 문장의 결과를 담고 있는 EventBean 객체를 받게 된다. 엔진은 연속적으로 결과가 발생하자마자 모든 리스너와 지정했다면 ouput율을 제한하는 절에 결과를 알려준다.
  2. 구독자 객체(Subscriber Object) / setSubscriber / 당신자의 애플리케이션은  문장 결과를 받기 위해서 메서드를 공개하는 POJO를 제공한다.엔진은 연속적으로 결과가 발생하자마자 모든 리스너와 지정했다면 ouput율을 제한하는 절에 결과를 알려준다. 이것은 엔진이 확실하게 타입이 정해진 결과를 직접 애플리케이션에 전달하기 때문에 문장의 결과를 받는 가장 빠른 방법이다. 문장 당 최대 1개의 구독자 객체가 등록 가능하다. 만약 1개 이상의 리스너를 사용하려면 대신 리스너 콜백을 사용하는 것이 좋다. 구독자 객체는 타입 변환 없이 새로운 이벤트의 직접적인 전달을 보장하기 때문에 확실한 타입 지원이 필요하다. 이러한 최적화는 문장당 구독자 객체가 오직 0개 이거나 1개 이기 때문에 가능하다.
  3. Pull API / safeIterator와 iterator / 당신의 애플리케이션은 문장에게 결과를 요청하고 java.util.Iterator<EventBean>을 통해서 이벤트의 집합을 받는다. 이 방법은 실시간으로 새로운 결과를 연속적으로 알릴 필요가 없을 경우에 유용하다.

당신의 애플리케이션은 1개 이상의 리스너를 부착하거나, 0 또는 1개의 구독자를 부착할수도 있고 거기다 동일한 문장에 Pull API를 사용할 수도 있다. iterator, 구독자의 사용이나 리스너의 단독 사용, 또는 조합된 형태 모두 문장의 결과를 받는데 사용 가능하다.

최고의 전달 성능은 일반적으로 리스너를 붙이는 것보다 구독자를 붙이는 것을 통해서 달성할 수 있다. 엔진은 문장에 부착된 리스너와 구독자를 인식한다. 엔진은 문장의 오버헤드를 줄이기 위해 내부적으로 이러한 정보를 사용한다. 예를 들면 당신의 문장이 리스너나 구독자가 부착하지 않았다면, 엔진은 연속적으로 결과를 생성하여 전달할 필요가 없기 때문이다.

만약 당신의 애플리케이션이 구독자와 하나 이상의 리스너를 모두 사용한다면 구독자는 어느 리스너보다도 먼저 결과를 받을 것이다.

만약 당신의 애플리케이션이 하나 이상의 리스너를 부착했다면 UpdateListener 리스너들은 문장에 추가된 순서로 먼저 결과를 받고 StatementAwareUpdateListener 리스너들은 다음으로 문장에 추가된 순서대로 결과를 받는다. 당신의 애플리케이션에서 리스너 사이의 전달 순서를 변경하기 위해서 실행 중에 리스너를 추가 및 제거할 수도 있다. 만약 당신이 outbound 쓰레딩을 설정했다면, 연산이나 이벤트 전달 쓰레드 대신에 outbound 쓰레드 풀에서 하나의 쓰레드가 결과를 구독자나 리스너에 결과를 전달한다.

만약 outbound 쓰레드가 켜져 있다면, 우리는 리스너에 전달된 이벤트의 순서를 보존하는 엔진 설정을 끌것을 제안하며 이는 섹션 15.4.10.1 “리스너에 전달된 이벤트의 순서 보존”에서 설명한다. 만약 outbound 쓰레드가 켜져 있으면 문장의 실행은  구독자나 리스너가 너무 많은 시간을 차지하는 것에 대비해 설정된 시간에 따라 차단되지 않는다.

14.3.3 구독자 객체를 설정하기

구독자 객체(Subscriber object)는 자바 객체 쿼리의 결과를 직접 묶는 것을 말한다.   POJO 타입의 객체는 메서드 호출을 통해서 문장의 결과를 받는다. 구독자 클래스는 인터페이스를 구현하거나 슈퍼클래스를 상속받을 필요가 없다. 오직 하나의 구독자 객체는 하나의 문장을 위해 설정될 수 있다.

구독자 객체는 리스너보다 몇가지 이점을 보유한다. 첫 번째로, 잠재적인 성능 장점을 제공한다. 쿼리의 결과가 자바 가상 머신의 메서드 호출을 통해 직접 당신의 메서드로 전달되며 Event Bean과 같은 중간 전환 과정을 거치지 않는다. 둘째로 구독자는 강하게 결합된 매개변수를 받기 때문에 구독자 코드는 간단하게 구현 가능하다.

이 챕터에서는 당신의 구독자 클래스를 통해 제공되는 메서드의 요구사항에 대해서 설명한다.

엔진은 두 가지 방법을 통해서 결과를 제공한다.

  1. insert 스트림 안에 있는 각 이벤트는 메서드를 호출하고 remove 스트림 안에 있는 이벤트도 다른 메서드를 호출한다. 이 방법을 row-by-row 전달이라고 한다.
  2. insert와 remove 스트림의 모든 행을 전달하는 단일한 메서드 호출이 있으며 이를 multi-row 전달이라고 한다.

14.3.3.1 Row-By-Row 전달

당신의 구독자 클래스는 insert 스트림의 이벤트를 받가 위해서 반드시 update라는 이름의 메서드를 제공하여 한다. 매개변수의 개수와 타입은 update 메서드에서 선언되어 select 절에 기술된 동일한 순서대로 열의 개수와 타입과 반드시 일치해야한다.

예를 들면, 만약 당신의 문장이 다음과 같다고 가정해보자:

그렇다면 당신의 구독자 클래스의 update 메서드는 다음과 같을 것이다

update 메서드에서 선언한 각 메서드의 매개변수는 반드시select 절의 나열된 순서 대로 각각의 열의 타입으로부터 반드시 할당이 가능해야 한다. 할당의 규칙은 다음과 같다

  • 타입의 확장은 자바 기준을 따른다. 예를 들면 당신의 select 절이 정수 값을 선택한다고 하면 동일한 열에 해당하는 메서드의 매개변수는 int, long, float 이나 double (혹은 이와 동등하게 객체로 박싱되는 타입)의 타입이 될 수 있다.
  • 자동 박싱과 언박싱[역자주: 래퍼 클래스의 따른 형변환]은 자바 기준을 따른다. 예를 들면 만약 당신의 select절이 java.lang.Integer 값을 선택한다면, 동일한 열에 속한 메서드의 매개변수는 int 타입이 될 수 있다. 만약 당신의 select 절의 열이 null 값을 발생시키면, 실행 중에 null 값을 언박싱하는 과정에서 예와가 발생할 수 있다.
  • 인터페이스와 슈퍼클래스는 할당을 위한 테스트로서 의미가 있다.따라서 java.lang.Object는 select 절의 어떤 열의 타입도 받아서 사용할 수 있다.

당신의 구독자 클래스가 복수의 update 메서드 footprint를 갖는 경우를 보자. 이 때 엔진은 결과 타입과 메서드의 매개변수의 타입을 비교하여 가장 일치하는 footprint를 선택한다. 엔진은 정확하게 타입이 일치하는 경우를 최우선으로 선호하며, 다음으로 박싱이나 언박싱을 요구하는 메서드, 타입의 확장을 요구하는 메서드, 그리고 마지막으로 허용 가능한 타입의 메서드 순으로 선호한다.

14.3.3.1.1. 와일드카드

만약 당신의 select 절이 하나 이상의 와일드카드(*)를 보유하고 있다면, 동등한 매개변수의 타입은 선택된 스트림의 기본이 되는 이벤트 타입이 된다.

예를 들면, 당신의 문장이 다음과 같을 수 있다.

그러면 당신의 구독자 클래스의 update 메서드는 다음과 같다.

조인 연산의 경우 와일드카드는 from 절에서 나타난 스트림의 순서에 따라 각 스트림의 기본 이벤트 타입을 확장 된다. 다음 문장은 조인의 예이다.

그러면 당신의 구독자의 update 메서드는 다음과 같이 된다.

스트림의 와일드카드 문법과 스트림의 이름 자체는 다음과 같이 사용가능하다.

일치하는 udpate 메서드는 다음과 같다.

14.3.3.1.2. Map과 객체 배열로 행 전달

다른 방법으로, 당신의 update 메서드는 각 행의 표현 방식으로 java.util.Map을 간편하게 선택하여 수용할수도 있다. select 절의 각 열은 결과 Map의 요소로 생성된다. Map의 키는 공급되는 열의 이름이 되거나 이름 없는 열에서는 문자열 표현 자체가 된다.

Map 전달을 위한 update 메서드는 다음과 같다.

엔진은 또한 select절의 전송을 객체 배열로도 지원한다. 객체 배열의 각 요소는 select 절의 각 열을 표현한다. update 메서드는 다음과 같이 표현된다.

14.3.3.1.3. Remove 스트림 이벤트의 전달

당신의 구독자는 만약 updateRStream이란는 메서드를 제공한다면 remove 스트림 이벤트를 받을 수 있다. 이 메서드는 update메서드와 동일하게 똑같은 매개변수의 개수와 타입을 받는다.

문장의 예는 다음과 같다.

그러면 update 메서드와 updateRStream 메서드는 다음과 같이 될 수 있다.

14.3.3.1.4. 시작과 끝의 알림 전달

만약 당신의 구독자가 이벤트의 시작과 끝의 노티피케이션을 요구한다면 updateStart와 updateEnd 메서드를 통해서 노출시킬 수 있다.

updateStart 메서드는 insert 스트림의 이벤트 개수와 전달되는 remove 스트림을 알려주는 두 개의 정수 매개변수를 가져야 한다. 엔진은 updateStart 메서드를 즉시 호출하여 이벤트를 update와  updateRStream메서드에 전달하는 것보다 앞선다.

updateEnd 메서드는 어떠한 매개변수도 필요하지 않다. 엔진은 update와 updateRStream메서드로 이벤트를 전달한 후에 바로 호출된다.

전달 메서드의 예는 다음과 같다.

14.3.3.2 Multi-Row 전달

row-by-row 전달을 대신해서 당신의 구독자는 insert와 remove 스트림에 있는 모든 이벤트를 단일한 메서드 호출을 통해서 전달 받을 수 있다. 이 방법은 주어진 입력 이벤트나 시간 변동에 따른 EPL이 복수의 결과 행을 전달할 때 적용한다. 예를 들면 동일하게 들어오는 이벤트에서 복수의 패턴 매칭이 일어날 때, 조인이 복수의 결과 행에 발생할 때나 출력률을 제한하지 않을 때 등이다.

이벤트의 전달은  앞선 14.3.3.1.2 섹션의 Map과 객체 배열로 행 전달의 구조를 따른다.  구독자 클래스는 반드시 다음의 메서드 가운데 하나를 제공해야 한다.

  • update(Object[][] insertStream, Object[][] removeStream): 각 객체 배열의 첫 번째 차원은 이벤트의 행을 의미하고 두번째 차원은 문장의 select절의 열 순서에 일치한다.
  • update(Map[] insertStream, Map[], removeStream): 각 Map은 하나의 이벤트를 표현하고 Map의 요소는 문장의 select 절의 열을 나타낸다.

14.3.3.2.1. 와일드카드

만약 당신의 select 절이 하나 이상의 와일드카드를 포함한다면, 구독자 객체는 아마 직접 기본 이벤트의 배열을 받을 것이다. 이 경우에는 구독자 클래스는 update(Underlying[] insertStream, Underlying[] removeStream) 같은 메서드를 제공해야 하며 “Underlying”은 기본 이벤트의 클래스를 나타낸다.

예를 들면, 당신의 문장이 다음과 같다면

당신의 구독자 클래스는 다음과 같은 메서드를 포함해야 한다.

14.3.3.3.  매개변수가 없는 Update 메서드

당신의 구독자 객체가 문장으로부터 아무런 데이터를 받기를 원하지 않는 경우에는 다음의 지시사항을 따르면 된다.

당신의 EPL 문장은 반드시 하나의 null 값을 선택해야 한다.

예를 들면, 당신의 문장은 다음과 같을 수 있다.

당신의 구독자 클래스는 다음의 메서드를 포함한다.

 

 

 

 

 

 

 

[Esper Manual 4.10.0 번역] 섹션 14.2 서비스 제공 인터페이스

EPServiceProvider 인터페이스는 엔진 인스턴스를 나타낸다. Esper 엔진의 각각의 인스턴스는 완벽하게 다른 엔진 인스턴스와 독립적이며 자기 자신의 고유한 관리 및 실행 인터페이스를 가지고 있다.

Esper 엔진의 인스턴스는 EPServiceProviderManager 클래스의 정적 메서드를 통해서 얻을 수 있다. getDefaultProvider 메서드와 getProvider(String providerURI) 메서드는 Esper 엔진의 인스턴스를 반환한다. getProvider(String providerURI) 메서드는 서로 다른 Provider URI 값을 통해서 복수의 인스턴스를 얻을때 사용된다. EPServiceProviderManager는 Provider URI가 이전의 Provider URI 값과 비교하여 동일하면 같은 Provider URI의 인스턴스를 반환하고 Provider URI가 이전에 없던 것일 경우 새 엔진 인스턴스를 만든다.

아래의 코드조각 기본 Esper 엔진을 전달한다. 기본엔진을 얻기 위한 그 다음의 메서드 요청은 동일한 인스턴스를 반환한다

이 코드조각은 “RFIDProcessor1″이라는 Provider URI의 Esper 엔진을 반환한다.동일한 Provider URI의 엔진을 얻기 위한 그 다음의 요청은 동일한 인스턴스를 반환한다.

getProvider 메서드는 각 URI에 해당하는 기존에 저장된 엔진 인스턴스를 반환하기 때문에 애플리케이션 내에서 정적으로 엔진 인스턴스를 임시 저장할 필요가 없다.

기존의 Esper 엔진 인스턴스는 EPServiceProvider 인스턴스의 initialize 메서드를 통해서 리셋이 가능하다. 이 명령은 모든 문장을 중지하여 제거한 후에 해당하는 URI의 엔진 인스턴스 된 경우 엔진을 기존에 제공된 설정으로 리셋한다. 만약 기존의 설정이 없으면, 기본 설정이 적용된다.

initialize을 실행한 후에 애플리케이션은 반드시 새롭게 관리, 실행 서비스를 획득해야 한다. 초기화 전에 갖고 있던 어떠한 관리, 실행 서비스도 유효하지 않고 정의되지 않은 행동을 갖고 있게 된다.

다음의 코드 조각이 전형적인 사용 순서이다.

기존의 Esper 엔진 인스턴스는 EPServiceProvider 인스턴스의 destroy 메서드를 통해서 제거된다. 이 명령은 인스턴스에 의해서 점유된 모든 리소스를 해제하면서 모든 문장들을 중지하고 제거한다. destroy한 후에 엔진은 더이상 사용되지 않는다.

애플리케이션 안에서 엔진 인스턴스의 제거 및 초기화 할 때 콜백을 받기 위해서EPServiceStateListener 인터페이스를 구현할 수도 있다. 구현한 리스너는 addServiceStateListener 메서드를 통해서 등록한다. EPStatementStateListener는 문장이 생성되거나 시작, 중지, 제거될 때의 콜백을 받기 위해서 사용된다. 리스너는 addStatementStateListener 메서드를 통해서 등록한다.

인스턴스를 제거할 때 애플리케이션은 반드시 엔진으로 이벤트를 보내는 스레드가 그 작업을 반드시 마무리 된 것인지 확인해 두어야 한다. 좀 더 일반적으로, 엔진은 제거 명령중이나 후에 사용되어서는 안된다.

엔진 인스턴스는 완벽하게 독립적이기 때문에 애플리케이션에서 한 엔진 인스턴스에서 발생한 이벤트 빈 인스턴스를 다른 엔진 인스턴스에 보낼 수 없다. 왜냐하면 이벤트 타입의 공간을 두 엔진 인스턴스가 공유하지 않기 때문이다.

[Esper Manual 4.10.0 번역] 섹션 14.1 개관

Esper는 다음의 주요한 인터페이스들을 지닌다:

  • 이벤트와 이벤트 타입 인터페이스는 섹션 14.6 “이벤트와 이벤트 타입”에서 설명한다.
  • EPL과 패턴문장을 생성,관리하고 런타임 설정을 위한 관리 인터페이스는 섹션 14.3 “관리 인터페이스”에서 설명한다.
  • 이벤트를 엔진에 전송하고 변수의 값을 얻고, 온디맨드 쿼리 실행을 위한 실행 인터페이스는 섹션 14.4 “실행 인터페이스”에서 설명한다.

EPL의 입문정보는 섹션 5.1 “EPL 소개”, 패턴은 섹션 6.1 “이벤트 패턴 개관”에서 다룬다.

JavaDoc 문서 역시 API 정보를 위한 훌륭한 출처이다.

센서네트워크에 CEP를 적용할 수 있을까?

이 글은 센서네트워크 시스템에서 실시간으로 이벤트를 처리하는 CEP 기술이 어떤 의미를 가지는가에 대해서 간략하게 서술할 목적으로 썼다. CEP에 대한 자세한 설명이 필요하다면 위키피디아의 설명을 번역한 다음 글 “Complex Event Processing Wiki 요약 부분 번역” 을 참조하기 바란다

sensor network

 출처: ISN 컨퍼런스

CEP(Complex Event Processing) 기술은 초당 수십~수백만건의 이벤트(데이터)가 발생하는 시스템에서 실시간으로 사용자에게 유의미한 정보를 검출, 이에 대하여 적절한 대응을 하기 위해 사용된다. 따라서 아주 짧은 시간의 resolution과 대용량의 데이터가 발생하는 금융권이 CEP의 대표적인 적용분야이다. CEP의 오픈소스로는 대표적으로 EsperDrools Fusion이 있다.

Esper building blocks

 출처: Esper 사이트

사용자가 원하는 이벤트 검출을 정의하는데는 EPL(Event Processing Language)이 사용된다. EPL SQL의 문법 구조와 유사한 형태 1를 갖고 있으며 기본적인 이벤트 처리와 복합이벤트처리를 EPL을 통해서 구현한다. 구현된 EPL문장을 패턴 혹은 룰이라 표현하기도 하며, 이벤트가 시스템에 입력될 때에 실시간으로 시스템의 운영 중에도(on-the-fly) 다양한 EPL을 적용할 수 있다.

그렇다면 고용량, 고속의 데이터로부터 실시간으로 이벤트를 검출하는 CEP 기술이 과연 센서네트워크에 적합한가?

표면적으로는 적합하지 않을 수 있다. 기본적으로 센서네트워크에서 발생시키는 이벤트의 양이 그다지 많지 않기 때문이다. 2 또한 비즈니스 영역만큼 시간에 민감하게 실시간 분석과 대응이 필요한 것도 아니기 때문이다. 즉, 센서네트워크에 CEP를 적용하는 것은 닭 잡는데 소 잡는 칼을 쓰는 격처럼 보인다.

그러나 다음의 세 가지 이유 때문에 센서네트워크에서 CEP기술은 의미를 가질 수 있다.

1. EDA(Event Driven Architecture)
CEP는 근본적으로 이벤트 기반 아키텍쳐에 뿌리를 두고 있다. 이전에는 분산환경에서 웹상의 자원들을 서비스 관점으로 인식하며 요청/응답 방식의 통신을 하는 SOA가 있었다. EDA는 전통적인 요청/응답 방식이 아닌 데이터의 발생을 이벤트로 정의,이벤트 기반의 비동기적인 통신 아키텍쳐이다.

EDA

 출처: Event Processing In Action 6p

센서네트워크에서는 각 센서들이 주기적으로 데이터를 발생시켜 전송하기 때문에 요청/응답 방식보다 전형적으로 EDA에 적합하다. 중앙에서 일일이 센서데이터 수신여부를 관리, 감독할 필요 없이 비동기적으로 센서에서 보내는 데이터를 이벤트 형태로 받아들이기만 하면 된다.

2. Event Stream
센서네트워크에서는 데이터의 발생량은 많지 않지만 이벤트를 발생시키는 센서별 스트림의 숫자는 결코 적지 않아 관리에 어려움이 따른다. 그러나 CEP에서는 어댑터를 통해서 다양한 형식의 데이터를 스트림으로 입력 받을 수 있다. 동일 센서네트워크 내에서 관측 특성을 달리하는 복수의 스트림이나 여러 도메인의 센서네트워크 스트림의 이벤트를 실시간으로 동시에 모니터링 하면서 유의미한 정보를 검출할 수 있다.

3. EPL(Event Processing Language)
마지막으로 CEP에서는 EPL을 통해서 이벤트 연산 및 복합 이벤트 검출을 구현할 수 있다. EPL의 사용이 센서네트워크에서 의미를 가지는 이유는 센서네트워크의 관리자 및 사용자가 각자의 필요에 맞게 EPL로 필요한 이벤트 패턴이나 복합이벤트를 정의하고 유연하게 시스템의 중지 없이 실시간으로 적용하여 결과를 얻을 수 있다.

CEP와 센서네트워크와의 연계는 향후에는 더욱 발전할 가능성이 있다. 앞으로 IoT(Internet of Things)를 넘어 IoE(Internet of Everything) 3 세상이 오면 무수한 센서 스트림으로부터 이벤트 발생하게 될 것이다. 이러한 환경에 대응할 수 있는 기술로 EDA(Event Driven Architecture)와 CEP는 분명 센서기반의 빅데이터에서 의미가 날로 증대될 것이다.

 

Notes:

  1. Select-From-Where절의 문법 구조를 차용하여 SQL과 비슷하게 구현되어 있음
  2. 물론 아주 조밀하게 센서를 배포하여 국가적인 단위로 센서네트워크를 정의하면 다를 수도 있지만 이는 차원이 다른 문제이다.
  3. 비슷한 개념으로 CPS(Cyber Physical System)