2016년 11월 30일 수요일

mybatis-guice에 bonecp 연동

mybatis-guice는 mybatis sql mapper와 google guice를 함께 사용하는 프레임워크다.

제 생각대로 mybatis-guice의 장점을 간단하게 정리하자면 다음과 같다.

mybatis는 알려진 대로 sql문을 xml 파일로 따로 관리할 수 있게 해주는 라이브러리인데 여기에 guice를 사용하여 xml을 사용하지 않고 java코드에서 sql문을 관리할 수 있게 해준다. xml 파일로 관리 하는 것 자체가 짜증스럽고 mybatis로 시작하는 것 자체가 어렵게 느껴진다면 mybatis-guice가 좀 더 간단하고 편안하게 다가올 수 있다.

다음 url에서 mybatis-guice에 대한 더 많은 내용을 확인할 수 있다.
http://www.mybatis.org/guice/


이번 글에서는 이 mybatis-guice에 DB connection pool 라이브러리인 bonecp를 연동하는 방법에 대해 간다하게 알아보겠다. mybatis-guice 홈페이지에 자세한 내용이 없어 여기에 간단하게 남기려고 한다.



위의 코드에서와 같이 간단하게 bonecp를 연동해서 사용할 수 있다.
간단하지만 홈페이지엔 어떻게 하는 건지 잘 나와 있지 않아 쪼~금 애를 먹었다. 암튼 알아두면 용이할 듯.

나머지 mybatis-guice를 사용하는 방법은 홈페이지를 참고하면 된다.

2016년 11월 6일 일요일

삼성전자 spark-cep 테스트

삼성전자 spark-cep란?

삼성전자에서 오픈소스로 만든 spark 기반의 cep 엔진이다. Esper 처럼 쿼리문에 WINDOW, SLIDE 기능이 있어 5분 또는 10분 간격으로 처리 구간을 지정하여 쿼리를 실행할 수 있게 해준다.
Github에 오픈소스로 있으면 다음 url에서 확인할 수 있다.

테스트 목적

삼성의 spark-cep를 테스트한 목적은 현재 이글루의 rule base 엔진을 spark-cep를 사용하여 대체가능한 지에 대해 확인하기 위해서이다.
이를 위해 다음과 같은 기술적인 부분들에 대한 확인이 필요하다.
  1. 실시간으로 다수의 rule을 처리할 수 있는가?
  2. 처리할 수 있다면 그 성능은 빠른가?
  3. Rule의 적용 및 수정이 용이한가?
따라서 이 테스트의 목적은 위 세가지에 대해 기능 및 성능을 확인하여 spark-cep를 활용할 수 있는 지를 판단하기 위함이다.

테스트 구성

spark-cep에서는 레디스를 사용하므로 레디스를 구성해야 했다.
레디스 클러스터를 다음과 같이 노드 sn1, sn2, sn3 세 개에 구성하였다.


그런데 테스트 시에 spark-cep에서 레디스 클러스터에 접속할 수가 없어 확인해보니 spark-cep 자체에서 레디스 클러스터를 지원하지 않게 되어 있었다.
레디스 클러스터 구성을 삭제하고 다음과 같이 하나의 노드만 사용하도록 하였다.


테스트 결과

우선, 위 테스트 목적의 세 가지 항목에 대한 답은 다음과 같다.
  1. 없다. 구조 상 1개만 가능하다. 아니면 하나의 쿼리에 여러가지를 처리할 수 있게 만들어야 한다.
  2. 1에서 처리가 되지 않으므로 성능 테스트를 진행할 수 없었다.
  3. Standard한 sql 문을 사용하므로 적용 및 수정에 용이하다.
위 내용에 대해 몇 가지 덫붙이자면, spark-cep란 오픈소스로는 WINDOW와 SLIDE 쿼리문을 사용하여 시간간격을 지정해서  데이터를 분석할 수 있지만 다수의 쿼리를 처리할 수는 없었다.
그리고 레디스를 활용하여 데이터 분석에 대해 성능적으로 도움을 주는 부분이 있을 거라 생각했지만 해당 부분은 spark의 원래 기능인 DataFrame을 그대로 사용하고 있어 spark의 원기능이 제공해주는 성능에서 크게 벗어나지 않고 있음을 알 수 있었다.
레디스는 분석한 결과를 저장하는 용도로 사용하고 있다.
spark 버전도 1.5 버전을 사용하고 있어 현재 cloudera 장비에 설치된 1.6 버전에서는 구동이 잘 되지 않았다. 그래서 장비에 spark 1.5 버전을 따로 올려서 테스트하였다.
spark-cep 코드를 컴파일할 때에도 1.6 버전을 사용하면 에러가 발생하여 빌드를 할 수가 없었다.
현재 spark가 2.0 버전에서는 structured streaming 기능이 추가되어 spark-cep에서 제공하는 WINDOW, SLIDE 쿼리문 같은 기능을 사용할 수 있게 되었다. 이런 상황에서 spark를 활용한 실시간 분석을 사용한다면 2.0에서 코드를 개발해서 하는 게 현재 spark-cep의 분석처리 성능보다 더 나을 거라고 보인다.
spark-cep도 코드를 마지막으로 커밋한 게 2015년 11월 4일로 1년이 넘었다. 이를 봐서는 여기서 더 발전시켜 나갈 의향이 없어보인다.
또한 머신러닝으로 실시간 이상 현상을 탐지하는 보안 기술을 가진 제품이 나오는 추세에 cep를 사용하는 것 자체가 시대에 뒤떨어지고 기술적, 보안적으로 확장성이 떨어진다고 생각된다.