Skip to Content
Data Engineering대규모 빅데이터 모니터링을 위한 CEP (Complex Event Processing)와 WSO2 아키텍처
📊 Data Engineering2018년 5월 31일

대규모 빅데이터 모니터링을 위한 CEP (Complex Event Processing)와 WSO2 아키텍처

#cep#wso2#event-processing#flamingo#data-engineering

과거 당사에서 빅데이터 성능 관리 및 모니터링 솔루션인 빅데이터 모니터링 플랫폼를 개발하던 시기, 다양한 오픈소스 에코시스템 기반 위에서 쏟아지는 방대한 데이터를 어떻게 실시간으로 처리할 것인가가 아주 중요한 과제 중 하나였습니다.

Hadoop, HBase, Kafka, Spark 등 수십 대에서 많게는 수천 대에 이르는 노드에서 초당 발생하는 메트릭(Metric)과 로그(Log)를 전부 단순히 DB에 저장하고 쿼리하는 방식으로는 시스템의 병목 현상을 피할 수 없었습니다.

이를 해결하기 위해 도입했던 핵심 기술이 바로 CEP(Complex Event Processing, 복합 이벤트 처리) 엔진이며, 그중에서도 WSO2 CEP를 활용했습니다. 이번 글에서는 CEP의 개념과 WSO2 플랫폼의 동작 아키텍처, 그리고 실제 모니터링 수집 아키텍처에 어떻게 적용했는지를 정리해 봅니다.

1. CEP (Complex Event Processing) 란?

단순히 “서버 A의 CPU 사용률이 90%를 넘었다”는 단일 이벤트는 기존의 Rule-based 시스템으로 충분히 처리가 가능합니다. 하지만 분산 환경에서는 이벤트가 개별적으로 발생하지 않습니다.

  • “최근 5분 동안 HDFS NameNode의 힙(Heap) 메모리 점유율이 95% 이상을 3회 이상 유지하면서, 동시에 DataNode B의 Disk 공간이 99%인 경우”

위와 같이 시간적 흐름(Time Window) 속에서 발생하는 다수의 단순 이벤트들을 조합하여, 논리적이고 복합적인 패턴을 찾아내어 의미 있는 하나의 이벤트(Complex Event)로 가공하는 기술을 의미합니다.

2. WSO2 CEP 엔진과 Siddhi 아키텍처

당시 시장에는 Apache Storm, Esper 등 여러 가지 실시간 스트리밍 처리 및 CEP 기술이 있었지만, 저희는 WSO2 CEP를 채택했습니다. WSO2 제품군은 강력한 SOA 기반 아키텍처(Carbon Platform)를 갖추고 있었으며, 특히 내부 심장으로 빠르고 가벼운 Siddhi(시디) Engine을 사용했기 때문입니다.

WSO2 CEP의 핵심 파이프라인 아키텍처는 아래와 같이 동작합니다.

  1. Input Event Adapters: 외부 수집기(Collector)로부터 발생하는 이벤트 스트림(HTTP, JMS, Kafka, MQTT 등)을 받아들입니다.
  2. Event Builder: JSON, XML 등의 Payload 규격을 빠르고 최적화된 내부 튜플(Tuple) 구조로 파싱합니다.
  3. Event Processor (Siddhi Engine): 사용자가 정의한 Siddhi Query Language(SQL과 매우 유사) 규칙에 따라 이벤트를 필터링하고 패턴을 분석합니다.
  4. Event Formatter: 분석 결과 도출된 이벤트를 다시 외부 포맷에 맞춰 변환합니다.
  5. Output Event Adapters: 알람 발송, Kafka 전송, HBase 로깅 등 외부 액션을 수행합니다.

Siddhi Query Language 예시

Siddhi QL은 SQL과 유사어 직관적인 이벤트 쿼리가 가능합니다. 예를 들어 “최근 1분(1 min window) 동안 CPU 수치가 90을 넘는 이벤트가 들어오면 알람 스트림으로 보낸다”는 쿼리는 다음과 비슷하게 작성할 수 있었습니다.

sql
from ServerMetricStream[cpu > 90]#window.time(1 min)
select host, cpu
insert into AlertStream;

3. 사내 빅데이터 모니터링 플랫폼 적용 사례

당시 플랫폼에서는 수집, 샘플링, 알람 처리의 효율성을 극대화하기 위해 CEP 룰 엔진을 적극 활용했습니다.

이벤트 샘플링과 부하 분산

에이전트로부터 초당 쏟아지는 수만 건의 로우(Raw) 데이터 이벤트를 그대로 DB(HBase 등)에 Insert하게 되면, DB에 무리가 가고 결과적으로 전체 시스템 성능 저하로 이어졌습니다.

  1. 지수적 샘플링(Exponential Sampling) CEP 룰을 통해 특정 메트릭의 평균 수치가 안정적일 때는 1분에 1번씩만 데이터를 기록하고, 임계치를 넘나드는 등 변화가 감지되는(Anomaly) 시점에는 1초 단위로 고해상도 기록을 수행하도록 룰을 구성했습니다.
  2. 복합 장애 패턴 탐지 단순 임계치 알람을 넘어서, ‘Zookeeper 장애 이벤트 발생 1분 이내에 RegionServer 3대 이상이 DOWN되는 현상’과 같은 연계 장애 패턴 조건을 감지하여 통합된 하나의 알림만을 발생하게 만들어 Alert Fatigue(알림 피로도)를 획기적으로 낮출 수 있었습니다.

아키텍처 흐름도

마무리

최근의 모니터링 환경은 Prometheus, Grafana, ELK 기반 환경 등으로 많이 개편되었지만, 대량의 데이터 스트림 한가운데서 룰 기반(Rule-based)으로 실시간 패턴 매칭을 한다는 것은 지금도 매우 유효하고 강력한 방법입니다.

WSO2 CEP 시절 사용했던 그 개념들은 현대의 Apache Flink, Spark Streaming, Kafka Streams 등을 활용하여 빅데이터 실시간 스트리밍 처리 기술로 계속 이어져 발전하고 있습니다. 저에게는 오픈소스 빅데이터 에코시스템이 갖는 다양한 도구들의 아키텍처 메커니즘을 뼛속 깊이 이해할 수 있었던 소중한 경험이었습니다.

Last updated on