[카프카] Pub/Sub 구조와 프로듀서, 컨슈머

카프카(Apache Kafka)를 만든 링크드인(Linkedin)은 초창기 Point to Point 구조를 사용하다가 모든 요구사항을 충족시키기 위한 카프카를 만들게 되면서 Pub/Sub 모델을 채용하게 된다.

 

Pub/Sub(펍섭) 모델은 Publish와 Subscribe를 의미하며 그림으로 설명하자면 아래와 같다.

 

point to point 구조와 pub/sub 구조

 

우측의 펍섭 구조를 보면 사실 그냥 중앙에 서버가 있고 통신을 하는 것처럼 보이며 사실 틀린말이 아니다. 카프카가 전송해주는 발신자와 수신자를 연결하는 것은 같기 때문이다. 하지만 펍섭의 모델은 우측의 모형처럼 통신이 양방향이 아니라 단방향으로 이루어지며 한가지 추가적인 기능이 존재한다.

 

발신자(Publish)

발신을 하는 역할을 하는 사람은 카프카에게 전송만하게 되고 수신자가 누구인지 알 필요가 없다. 그래서 특별히 수신자를 정해놓지 않고 서버에 전송하게 되는 매우 심플한 구조를 보여준다. 

 

카프카는 내부에 발신자의 메세지를 토픽(Topic)이라는 주소로 저장하게 되고, 발신자는 이 토픽에게 우체원이 우편함에 편지를 넣듯 저장을 한다.

 

수신자(Subscribe)

수신자는 카프카에 원하는 토픽을 구독한다. 즉 수신자 역시 발신자가 누구인지 관심은 없고 필요한 메세지만 구독을 하게 되는 것이다. 이를 통해 Point to Point 구조에 비해서 매우 단순해지고 유지보수 뿐만 아니라 에러의 발생, 네트워크 트래픽의 장점까지 얻게 된다.

 

 

현실과의 유사성, 아파트 택배 시스템

현실에서 Pub/Sub을 이해하기 위해서는 아파트 택배 시스템만큼 좋은게 없다고 본다. 모든 택배원들이 동과 호수를 방문하여 택배를 직접 놓게 된다면 택배 기사도 괴롭고, 그만큼 배송이 지연이 될 가능성도 있다. 하지만 특정 장소에 택배를 모와놓았다가 주민이 직접 가져가게 된다면 택배의 유실도 적어지고, 택배의 배송 물량도 더 많이 처리할 수 있을 것이다.

 

아파트 택배 공간

택배기사는 오로지 택배를 모와놓은 공간에 택배를 놓고 기록을 하며 수령인은 택배 공간에 주기적으로 들려 사인을 하고 택배를 찾아간다. 이것만큼 카프카 Pub/Sub 모델을 설명하기 좋은 예제도 없다고 본다.

 

프로듀서와 컨슈머

위 예제에서 Pub/Sub 모델이라고 했지만 카프카에서 Publish와 Subscribe의 명칭을 정해놓았다. Publish를 메세지를 일방적으로 보내는 입장이라서 프로듀서(Producer)라 말을 한다.

 

반대로 메시지를 일방적으로 읽는 구독자는 Subscribe 대신 컨슈머(Consumer)라 말을 한다. 즉 펍섭 모델은 프로듀서/컨슈머 모델이라 말을 할수도 있다.

 

프로듀서와 컨슈머

최종적으로 펍섭모델을 카프카의 프로듀서와 컨슈머 관계로 그린 카프카 구조는 위와 같이 그릴 수 있을 것이다. 토픽이니 파티션이니 헷갈릴 수 있는데 이에 대한 얘기는 다음 포스팅에 하는 걸로...