아파치 카프카(Kafka) : 설치 및 실행 - 1 of 3

아마도 카프카는 여러 용도(높은 처리량이 필요한 통계 집계&처리, 메세지 처리 등)가 있지만

플룸과 비교했을때 목적이 다소 다르다. (많이 다르다고 해야할수도)

어느쪽으로 전달하게 된다는 주 목적은 같지만

어느 정도의 용량을 어떻게 분산처리할까 말까에 대한 선택지에서의 대용량 분산처리와 메세지 처리라면 카프카쪽이,

단순히 로그파일의 적재에 따른 전달, 분류, 적재에만 포커스를 맞춘면 플룸쪽이 나을 것으로 판단된다. 

(말은 누가 못하리)

 

 

 

이벤트 버스, 이벤트 드리븐, 옵저버 패턴이 시조새

 

안드로이드 개발을 하다보면 정말 한번쯤은 들어볼수밖에 없는 라이브러리가 있는데 다름아닌,

바로 "이벤트 버스(event bus)"이다.

 

 

아주 간단히 설명하자면, 버스는 정해진 목적지(밤깊은 마포종점~)를 가지고 계속 한쪽 방향으로 이동한다.

물론 회차점이 있지만, 그 회차가 없다면 일단은 목적지까지 계속 정류장마다 정차하여 사람들을 태우고 이동한다.

그 버스는 그 손님이 있을때 정류장에 서서 문을 열고 승객을 태운다.

 

정류장에 서서 기다리다가 내가 타려는 버스가 아니라면 버스 기사아저씨를 배려하기 위해 지갑도 꺼내지 않고 먼산을 바라보거나 정류장에서 한발짝 물러서서 폰을 만지작 거리는 등의 암묵적인 행위(?)를 해야만 그 버스 아저씨도 아.. 저 학생이 이 버스를 타려는게 아닌가보군 바로 출발해야지 하며 배차간격 줄이기 캠페인을 도모할 수 있다.

 

그런데,  이번에는 정말 저 그 버스 타려고요하는 제스쳐, 지갑을 꺼내고 나는 지금 당장 그 버스카드단말기에 태그를 할 준비가 되어 있으며, 버스에 위험하리만큼 한발짝 다가서는 동작을 취하는 순간 그 버스를 나라는 승객을 태우고 출발하게 된다.

 

이러한 정류장의 암묵적인 룰이 존재하기에 승객과 버스는 목적지까지 서로의 약속을 지킬 수 있는데, 

안드로이드에도 이러한 개념이 있다.

 

제일 처음에 이야기한 바로 "이벤트 버스"이다.

이벤트는 곧 버스를 타고자하는 승객이며, 버스는 말그대로 이 이벤트라는 승객을 태우고 가는 운송수단이다.

 

자바에는 옵저버 패턴이라는 프로그램 디자인 패턴이 존재하는데,

이 이벤트 버스도 옵저버 패턴을 기반으로 하고 있다.

 

1차적으로 조금 어려운말로 바꾸어 보자면, 

이벤트라는 승객이 발생하면 버스는 정류장에서 기다리고 있는 그 이벤트를 태우고 특정 동작을 수행하는데,

이벤트라는 승객이 없을때에도 항상 정류장을 언제든 지나치다가 승객이 나타나면 바로 태우고 떠나게 된다.

 

2차적으로 더 어렵게 말하자면,

이벤트를 발생시키는 배포자, Publisher가 이벤트 버스에게 지갑을 꺼내어 나 태워주세요라고 "발행"이라는 행위를 하면 이를 이벤트버스라는 버스 운송수단이 감지하여, 배포자의 행위(동작)를 승차시켜서 목적지 정류장의 Subscriber에게 전달(하차)한다.

 

거기에 추가적으로 버스는 보통 그냥 승객을 내려놓고 떠나지만, 이 이벤트 버스의 마지막 과정은 그 정류장에 승객이 도착했다고 "통보"를 해준다.

보통 앱개발을 하다보면 필연적으로 접하게 되는 클릭이벤트의 interface 의 콜백 함수나 delegate 같은 개념이다.

승객이 도착했다고 알려달라고 누군가 미리 약속을 등록 해놓으면 그 버스가 승객을 하차시키며 승객 내려요~ 데려가요~ 하고 알려주는 역할이 있는 것이다.

 

이 과정을 이벤트 버스 라이브러리는 아래와 같이 도식화 한다.

 

 

이미지 출처 : https://greenrobot.org/eventbus/

 

 

 

왜 이렇게 장대하게 설명을 했느냐면, 앞으로 알아볼 카프카라는 녀석의 경우도 이러한 이벤트 버스 (자바로 치면 아까 이야기한 옵저버 패턴)모델을 기반으로 하고 있기때문이다.

 

보통은 이벤트 드리븐(Event Driven)이라고도 표현하는데, 의미하는 바는 같다.

 

카프카의 홈페이지에도 아래와 같은 이미지로 도식화하고 있는데,

화살표의 방향을 잘 인식할 필요가 있다.

 

 

이미지 출처 : https://kafka.apache.org/intro

 

 

용어는 발행자에서 생산자(Producers) 로 바뀌었지만, 결국 하고자 하는 궁극적인 목적은 같다. 

어떠한 생산자가 생산을 해내면 카프카가 소비자(통보를 최종적으로 받는)와 연결자(Connector), stream Processors와 주고받게 된다.

 

그럼 카프카가 뭐고 무슨 동작을 하는 녀석이길래

카프카의 기본 골자, 기본 동작은 

"
producer 가 특정한 메시지를 생성하여 전달 > 파티션별로 분산처리 (ZooKeeper와 같은) > 각서버에 분산처리 > 메세지를 구독하는 Consumer 가 메시지를 가져가서 처리
"

라고 할 수 있다.

그래서 아래와 같은 비스무리한 그림 한장으로 설명이 끝난다(아아 다시 셋팅과의 싸움인가...)

 

 

 

 

어쩌면 이벤트 버스 모델을 기반으로 하는 "신문 구독"을 생각하는게 더 딱 맞을 개념이다.

좋아하는 연예인 뉴스를 구독하겠다고 등록해놓으면 그 연예인이 언급된 뉴스가 자동으로 알람으로 온다고나 할까?

나의 최애 오마이걸의 아린이를 등록해놓으니 새로운 웹드라마를 촬영하기 시작했다고 알람이 오는...

 

그런데 엄밀히 말하면 

이벤트버스와 조금 다른것은, 카프카의 발행자와 구독자는 토픽이라는 하나의 "주제"로 서로 연결되어는 있지만,

서로의 존재는 알지 못한다. 각자 토픽만 바라볼뿐 서로는 아는 상태가 아니다.

발행자도 토픽만 바라보고 발행(Push)하면, 구독자도 토픽만 바라보고 이를 당겨(Pull)온다.

 

그래서 카프카 클러스터라는 거대한 시스템 안에서 브로커 (Broker)라는 녀석이 바삐 토픽을 처리하고 중재할 뿐이다.

이 브로커들은 토픽을 파티션별로 분산처리하여 관리 및 모니터링하는데, 이를 주키퍼(ZooKeeper)라는 라이브러리가 담당한다.

 

 

자,

대략적인 개념은 이해했으니 다음 시간의 요리 순서는 아마도

 

1. 카프카, 주키퍼 설치

2. 프로듀서 클래스 생성

3. 토픽 생성

4. 컨슈머 클래스 생성 

 

가 될 것 같다.

 

컵라면에 물붓기보다는 쉬울수도 있지만..

한번 첫 셋팅에서부터 꼬이기 시작하면 ..

컵라면에 스프까지 다 풀었는데 찬물을 부어서 버려버리는 정도의,

참깨라면의 참기름 봉지를 뜯지도 않은채로 뜨거운물을 붓고 다 먹고 나서 알게된 정도의 스트레스가 밀려올수있다..

심호흡을 합시다.