[개발생각] 아파치 카멜 사용 후기

아파치 카멜을 본격적으로 써봤다. 스프링배치를 사용하려고 했는데, 이런저런 이유로 아파치 카멜을 사용하게 됐고, 후기를 남겨본다

 

 

카멜 vs 스프링배치

 

카멜은 DSL방식의 이벤트의 흐름을 정의하고, 이벤트의 라우팅을 쉽게 해주는 여러 컴포넌트를 제공하기에,

실시간성 이벤트 처리에 적합하다.

스프링배치는 청크단위 배치사이즈단위의 롤백처리라던가 재처리등을 할수있고,

이런 기능등을 활용하여 좀더 대용량처리에 적합하게 사용할수있다는 장점이 있지만,

실시간성 처리 (즉, 실시간으로 바로바로 처리를 해야하고, 최악의 경우는 문제가 되는 데이터처리는 스킵하면서,

실시간 처리를 해야할수도있는 경우)에는 다소 무거운, 그리고 러닝커브가 많은 솔류션으로 이해했다.

 

 

내가 카멜을 도입한 부분은 위에 말한 장점을 살리기 위한 판단이었다.

 

1) jms, file, api, kafka, db등을 통한 데이터를 reader해야하고, 또한 writer를 해야하는 경우가 많다.

2) 각각의 router를 하나의 통합된 방식을 통해, 정리된 룰로 동작하도록 하고 싶다. (유지보수를 위해)

3) 병렬처리/비동기처리등을 도입할때, 러닝커브가 최대한 없고, 직접 해당 처리를 제어하지는 않았으면 좋겠다.

4) reader의 다양한 소스에 따른 쉬운 라우팅방식을 제공하는 솔류션이면 좋겠다.

 

위의 판단으로 카멜을 사용했고, 그에 따른 후기는 아래와 같다.

 

장점)

 

1) 러닝커브가 상당히 적다. DSL을 통한 직관적인 이벤트의 흐름을 정의할수있어, 데이터의 흐름이 한눈에 보이게 된다.

2) 병렬처리가 상당히 쉽다. 

- 쓰레드설정을 해당 스텝에서 설정만으로 쉽게 적용이 가능하다.

- 다양한 stream source에 대해서도, 쓰레드풀 설정을 쉽게 적용할수있다.

- 병렬처리뿐아니라, 이후에 병렬처리된 데이트를 다시 어그리게이션하는 기능도 있기에, 데이터의 분산, 통합등을 자유자재로 제어할수있다.

3) 예외처리와 서킷등의 기본적인 처리또한 일관되게 처리할수있다.

- 글로벌 예외설정을 할수도있고, 서킷설정도 각각의 스텝에서 별개로 설정할수있다.

4) 이벤트의 흐름에 따른 잡을 나눌수있고, 비동기로 처리되는 잡들을 동기처리와 동일하게 흐름을 쉽게 파악할수있게 잡을 설정할수있다.

- 기존 listener, templete등을 이용하면, cosumer등이 분산되고, 처리 프로세스도 분산되기에 이벤트의 흐름이 한눈에 보이지 않지만,

카멜은 DSL로 흐름을 정의해야하기에, 비동기 흐름도 한눈에 파악이 가능하다.

 

 

 

단점)

 

1) 에어플로우같은 스케줄러와 같이 사용을 해야할듯한다.

- 스케줄링 솔류션을 같이 사용해야 강력하다. 자체적으로 리스타트나, 재처리등의 기능을 직접 구현해야하는 부분이 있기에, 이런 부분을 상쇄할수있는 스케줄러 솔류션을 같이 사용하는게 더 좋은것 같다.

2) 병렬처리가 되면, 아래 이벤트 흐름도 모두 병렬프로세스의 스레드를 따라가기때문에, 병렬처리가 시작되는 부분과 끝나는 부분을 잘 관리를 해야하는 부분이 있다. (안그러면, 스레드풀 고갈 원인이 될수있음, 트랜잭션 문제가 발생하거나..)

3) DSL로 흐름을 정의하다보니, 복잡하거나 반복되는 코드에 따라, 코드가 지저분해지는 느낌을 받는다.

이건 성향이나 개인의 차이가 있겠지만, 구현코드가 service등으로 구분되지않고,

DSL내에 process블럭에 코드가 작성되게 되니, 좀 지저분한 부분이 생긴다.

(물론, process블록에서 service클래스를 호출하게 하면 된다.

하지만, 내가 생각하는 좋은 방향은 최대한 DSL의 블록에서 표현을 하는것이 가장 좋은 방법이라고 생각을 한다.

- 최대한 camel을 dsl문법을 활용)

 

장단점이 있지만, 현재 사용한 후기로는 나름 좋은 중소형 이벤트 처리 솔류션으로는 좋은 포지션인것으로 보인다.