Embian Blog

Apache Storm과 Spark는 그 동안 많이 사용되고 있는 실시간 데이터 처리 엔진이다. 그런데 eBay가 Pulsar를 발표하면서 실시간 데이터 처리 엔진에 후보가 하나 더 늘게되었다.

Storm-ESPER는 Apache Storm과 EsperTech의 ESPER를 결합한 것으로 엠비안에서 해당 과제에 대해서 연구한 적이 있다. (Storm & Esper Prototype 및 Test) 

비교를 하기 위해서 다음의 상황을 가정한다.

* Cost :  도입을 위해 어느정도의 커스터마이징이 필요한가?

곤충을 머리, 가슴, 배로 나누는 것 처럼 시스템도 입력, 처리, 출력으로 나눌 수 있다. 이 3가지 부분이 커스터마이징이 필요한 부분이다. 먼저 입력 부분에서 해결해야 할 문제는 nginx의 access log를 수집해야 한다는 것이다. 이 문제는 Storm-ESPER, Pulsar 둘 다 가지고 있다. nginx의 access log는 fluentd를 사용해서 수집하여 Json형태로 변형한 후 Message Queue로 던지게 하면 간단히 해결할 수 있다.

nginx에서 Message Queue까지 던지게 하는 부분은 Storm-ESPER나 eBay Pulsar 모두 필요한 단계이다. (물론 다른 방법으로 데이터를 수집할 수 있도록 할 수 있다. 여기서는 fluentd를 통해서 Message Queue로 던지는 방식으로 구현했다고 가정한다.)

• Storm-ESPER
  Storm-ESPER의 구성은 다음과 같이 될 수 있다.
  
  

[ 그림 1. Storm-ESPER의 구성 ]

Storm-ESPER의 기본 구성에서 추가해줘야 하는 작업은 다음과 같다.

1. EPL Bolt에서 GeoIP를 써서 IP의 국가를 추출할 수 있는 클래스 작성
2. 메일발송, 통계 집계 등을 위한 Sinker 작성

이렇게 2가지만 추가로 구현하면 위의 시나리오를 만족할 수 있다. 물론 EPL Bolt에 다음과 같은 EPL을 처리하도록 추가해줘야 하지만 이것은 Storm-ESPER의 기본 구성에 속하는 운영 툴을 통해서 동적으로 추가하는 것이 가능하다.

• Jetstream (eBay Pulsar)
  Jetstream의 구성은 다음과 같이 될 수 있다.
  

[그림 2. Jetstream (eBay Pulsar)의 구성]

각 Stage의 이름은 Pulsar의 예제에서 따왔지만 실제 Pulsar의 코드를 바로 사용하는 것은 아니다. 각 Stage별로 추가해야 하는 작업은 다음과 같다.

1. Collector
 - Message Queue로부터 데이터를 읽어와서 GeoIP를 써서 IP의 국가를 추출하는 클래스를 작성
 - Pipeline Wiring을 수정하여 outbound Channel을 Distributor쪽으로 맞춰준다.
2. Distributor
 - 각 EPL을 가지고 있는 Bean을 작성
 - 각 EPL들의 결과를 구분하여 Metric Calculator쪽으로 outbound Channel을 맞춰준다.
3. Metric Calculator
 - 메일발송, 통계 집계 등을 위한 코드 작성

추가해야 하는 작업은 Storm-ESPER에서 했던 작업들에 추가로 Wiring을 위한 설정을 해줘야 한다. Storm-ESPER가 EPL을 동적으로 추가/삭제할 수 있는 운영 툴을 제공해주는 반면에 Jetstream은 Config에서 해당 기능을 할 수 있도록 해준다.

• Storm-ESPER
  엠비안에서 진행한 Storm-ESPER는 EPL을 동적으로 추가/삭제할 수 있는 툴을 제공한다. 이 툴을 사용해서 Event Type을 지정해주고 EPL Bolt에 EPL을 추가시키면 된다.
  
  그리고 결과의 형태에 따라서 기존의 메일 발송 Sinker를 그대로 사용할 수도 있고 추가로 작성해줘야 할 수도 있다.
  
  
• Jetstream (eBay Pulsar)
  eBay Pulsar는 Config를 통해서 동적으로 EPL을 추가하는 것이 가능하다. Config의 웹 인터페이스로 로그인해서 Bean을 등록해주면 된다.
  
  그런데 만약 시스템 구축 초기에 Config를 사용하지 않고 각 Stage의 XML에서만 Bean을 관리할 경우 XML파일을 수정해서 EPL을 등록해야 한다.
  
  Storm-ESPER와 마찬가지로 메일 발송을 그대로 사용할 수도 있고 추가로 작성해줘야 할 수도 있다.

서비스 운영에서 Failover는 필수요소가 되어가고 있다. Storm-ESPER와 eBay Pulsar도 Failover에 대해서 점검해볼 필요가 있다.

• Storm-ESPER
  Storm-ESPER의 경우 기본적으로 Storm 위에 Esper를 올려놓은 것이다. 그렇기 때문에 Failover에 대해선는 Storm과 같다고 할 수 있다.
  
  Storm을 구성하는 각각의 요소들에 문제가 생긴 경우 어떻게 동작하는지 알아보면 다음과 같다.
  1. Bolt : Bolt가 죽는 경우 Supervisor가 해당 Bolt를 restart하게 된다.
  2. Supervisor : Supervisor가 죽는 경우 Nimbus에 의해서 Reassign 및 Restart하게 된다.
  3. Nimbus : Nimbus가 죽는 경우 Topology의 동작에는 문제가 없다. 단, Nimbus가 죽는 경우 Supervisor에 대한 관리를 못하게 된다. Storm의 구성에서는 Nimbus를 Restart하거나 Reassign할 수 있는 시스템이 없다. 
  
  Nimbus가 SPOF라고 하는 말들이 있긴 하다. 하지만 SPOF라면 말 그대로 Nimbus가 죽었을 경우 전체 Topology가 동작을 못하고 죽어버리든지 그와 비슷한 상황에 빠져야 하는데 실제로는 그렇지 않다.
  그리고 Nimbus가 죽은 경우 다시 실행만 시켜놓음 되기 때문에 번거롭고 신경쓰이는 상황이기는 하지만 SPOF까지는 아니다.
  
  
• Jetstream (eBay Pulsar)
  Pulsar는 Clustering구성을 통해서 Failover를 할 수 있도록 되어있다. 그런데 Pulsar는 Storm과는 다르게 노드가 Down된 경우 restart해주는 기능 등이 없다. 하지만 Nimbus와 같이 단일 노드로 구성되는 요소는 없다.
  
  그리고 Storm과는 달리 Pulsar는 3개의 이벤트 전달 모델을 가지고 있다.
  1. Push 모델
      Storm과 같이 다음 노드로 Push하는 모델이다. 
  2. Pull 모델
      Message Queue를 통해서 이벤트를 받는쪽에서 Queue의 내용을 가져가는 모델이다.
      
  3. Hybrid 모델
      Push 모델과 Pull모델을 합친 것으로 기본적인 경우 Push를 통해서 데이터 전달을 하다가 문제가 생겨서 데이터 처리를 못하게 되는 경우 Message Queue에 넣고 replay 시키는 모델이다.
  
  
  이와 같은 3개의 모델을 활용하여 Storm보다 더 유연한 Topology구성이 가능하다.

Storm-ESPER는 Nimbus, Supervisor 등에 의해서 문제가 생긴경우 자동으로 복구를 시도하게 된다. 하지만 Storm에서는 Nimbus의 문제에 대해서는 대안이 없는 상황이다.
eBay Pulsar는 3가지 데이터 전달 모델을 활용해서 Cluster구성을 하는 것이 가능하다.

* Extensibility : Scale out이 가능한가?

시스템의 규모를 초기에 정확히 예측하는 것은 불가능하다. 그렇기 때문에 시스템 규모를 확장해야 하는 경우에는 단순히 시스템을 추가하는 것으로 서비스 규모를 확장할 수 있도록 하는 것이 중요하다. Storm-ESPER, eBay Pulsar의 Scalability에 대해서 알아보면 다음과 같다.

• Storm-ESPER
  Storm-ESPER는 앞에서 언급한대로 Storm의 시스템 구성을 가지고 있다. Storm에서는 Scale out이 가능하다. 하지만 Node를 추가한 후에는 Topology를 Restart해야 한다는 문제점이 있다.
  Topology를 Restart하는 동안은 데이터 처리를 못하는 것은 당연하다. 그렇기 때문에 엠비안에서 진행한 Storm-ESPER에서는 Input과 Output부분에 Message Queue를 위치시켜서 Topology가 Restart되는 동안 발생할 수 있는 문제를 최소화 시켰다.
  
  Message Queue에 의해서 데이터가 유실되는 것이 아니기 때문에 대부분의 경우 Topology가 Restart되는 것에 대해서 문제가 발생하지 않는다. 단, Topology의 Hot Deploy는 Storm-ESPER에서는 불가능하다는 단점이 있다.
  
  
• Jetstream (eBay Pulsar)
  eBay Pulsar는 Pipeline의 설정이 모두 XML에서 정의한 Bean에 들어가있고 Bean은 Config에서 관리하도록 할 수 있기 때문에 Config만 활용한다면 Node가 추가되거나 Topology가 변경되는 상황이라 하더라도 Topology의 중단 없이 서비스가 가능하다.

비교 결과.

앞에서는 Storm-ESPER와 eBay Pulsar에 대해서 비용, 안정성, 확장성이란 주제로 비교를 해보았다. 비교 항목마다 점수를 준 것을 종합해보면 다음과 같다.

Storm-ESPER는 비용적인 측면에서 좋은 점수를 받았고 eBay Pulsar는 확장성 부분에서 좋은 점수를 받았다. 안정성은 eBay Pulsar가 조금 더 좋게 나왔다.

Storm-ESPER는 기본적인 Data Flow가 정의되어있기 때문에 Business Logic을 EPL을 통해서 적용만 하면 대부분의 환경에서 활용 가능하다는 장점이 있다. 이런 장점 때문에 비용적인 측면에서 좋은 점수를 받은 것으로 생각된다. 하지만 Storm이 가지는 Nimbus에 대한 문제점 등은 어쩔 수 없이 단점으로 가지고 있다.

eBay Pulsar는 Pipeline을 다양하게 구성할 수 있고 Config를 이용한 Hot Deploy가 가능하다는 것이 가장 큰 장점이라 할 수 있다. 하지만 eBay Pulsar는 예제 수준 정도이고 실제 사용하려면 Jetstream을 사용하여 Pipeline을 구성해야 한다. 통신 모델을 정의하고 데이터 형태를 정의하는 등의 작업을 XML 또는 Config에 대햐 한다는 단점이 있다.

그리고 눈에띄게 보이는 차이점은 Storm-ESPER는 EPL의 결과를 Output Queue에 던져서 다음 처리를 할 수 있도록 한 반면에 eBay Pulsar는 EPL의 결과를 outbound channel로 던지기 전에 다른 Processor로 전달해서 부가적인 처리 등을 할 수 있다는 것이다.

쉽고 빠르게 CEP 엔진을 구축하기 위해서는 Storm-ESPER를, 좀 더 유연한 CEP설계를 하고 싶을 때에는 eBay Pulsar를 쓰는 것이 유리하다.