[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