[개발생각] Apache Camel에 대해서

아파치 카멜 처음 잠깐 써본게, 18년 정도 된거같은데... 최근에 각잡고 써보니 쓸만하다!!

 

인터넷 찾아보니, 최초 릴리즈가 2007년...ㅎㄷㄷ

잠깐 사용했을때가, 나온지 1-2년된 따끈따끈한때였구나 ㅋ

그때도 어느정도 성숙한 오픈소스여서, 꽤 유용했던것으로 기억한다.

특히 간단한 ETL, BATCH 잡에 사용하기 정말 강력했던 기억이다.

물론, 스프링배치가 배치쪽은 아직 꽉 잡고있다고는 하지만, 스프링배치는 너무 초기 러닝커브가 있다는 점이 아쉽다.

최근에 카멜을 다시 쓸일이 있어서, 좀 자세히 알아봤는데, 실시간 이벤트 처리에 관해서는 꽤 괜찮은 솔류션으로 보인다.

 

우선 병렬처리에 대한 접근이 쉽다.

샤딩을 직접 해서 대상을 만들거나, 파티션으로 데이터를 읽거나 하는 방법을 쓰지않아도 (물론 쓰면 더좋다),

설정 몇개로 병렬처리를 할수있다.

 

카멜에서 병렬처리는 크게 3가지로 나뉘는데,

 

1) Threads 옵션

   - 실행되는 Step단위로 병렬 처리

 

2) Split + ParallelProcessing 옵션

   - 대상 데이터들 각각 단위로 병렬로 처리

 

3) Seda 옵션

   - 메모리 큐를 통해, 컨슘을 병렬로 처리.

 

 

위 3개의 옵션으로 병렬처리를 통해, 데이터 처리 퍼포먼스를 크게 올릴수있다.

특히 3) Seda 옵션은 상당히 흥미롭다.

Seda 옵션만 잘사용해도 엄청난 퍼포먼스를 낼수있겠다고 추측한다.

Seda 옵션은 걸면, 옵션이 설정된 스텝은 메모리큐에 처리대상이 쌓이고, 그것을 컨슘하여 처리하도록 처리방식이 바뀐다.

 

기존에 만약 아래와 같은 Step3으로 구성된 배치잡이 있다고 생각해보자.

 

>>>>>>>>

Step 1) 카프카 토픽

Step 2) 데이터 컨슘

Step 3) 디비 저장

>>>>>>>>

 

여기서 퍼포먼스 병목이 일어나는 경우는 디비 저장이 느려질때이다.

카프카 컨슈머는 컨슘대상 토픽의 파티션갯수와 1:1로 연결이 되는 구조이기때문에, 퍼포먼스를 올리려면 토픽의 파티션갯수를 늘리는 방법이 가장 최선이다. 하지만 토픽의 파티션갯수는 무한정 늘릴수도없다.

파티션갯수가 늘어나면 카프카 노드간의 레플리카를 위해 통신해야하는 횟수도 따라서 올라가기때문이다.

(이부분이 은근히 서버 리소스를 엄청 많이 잡아먹는다)

게다가 Step 3) 디비 저장이 느려지면, 결국 병목이 더욱 심하게 된다. 

 

하지만, Seda가 출동하면 어떻게 될까?? (드.라.군)

 

아마 구조는 아래와 같이 만들수있을것이다.

 

>>>>>>>>

Step 1) 카프카 토픽

Step 2) 데이터 컨슘

Step 3) Seda 큐

Step 4) 디비 저장.

>>>>>>>>

 

카프카 토픽에서 컨슘한 데이터를 Seda 큐에 넣는다. 해당 Seda큐는 메모리 큐이고, 해당 메모리 큐에 컨슘을 여러 쓰레드가 나눠서 컨슘을 할수있다. Seda 큐에 컨슈머의 쓰레드갯수를 설정해 줄수있기에,

카프카 토픽에서 배치 사이즈 30으로 30개의 메세지를 받아서,

Seda큐에서 컨슈머 쓰레드 갯수를 30개로 설정하면, 30개의 병렬처리가 되는것이다.

 

이렇게 되면, 토픽의 파티션갯수를 늘리지 않고도 병렬처리의 갯수를 늘릴수있다.

물론 디비저장의 쓰레드 풀이나, 성능에 대한 튜닝은 추가로 해야하겠지만, 토픽 처리의 성능을 간단히 늘릴수있게 된다.

그리고 복잡한 여러개의 Step으로 구성된 배치잡이라면,

중간중간에 Seda큐를 이용해여 Staging 데이터를 메모리큐로 모았다가 병렬로 처리하도록 분산해주는 단계를 넣어주면,

각각의 Step들이 비동기 병렬처리로 동작하게 만들수있다.

 

배치잡에서 성능을 최대로 끌어올리는 방법으로 고려야 봐야하는 구조라고 생각이 든다.

물론, 메모리 큐를 사용하기에 메모리 사용량이 늘어날수있기에,

Throttle, Size등의 설정을 잘해야하는것은 당연히 고민해야하는 기본으로 본다.

 

좀더 잘 쓸수있도록 공부해야겠네!!