Pub/Sub model

Ref. https://medium.com/zaneiru-tech-life-blog/pub-sub-모델에-대해서-daa3c5c52aa8

메시징 시스템을 구현하기 위해 공부를 하다보면 Pub/Sub 모델이란 단어가 나옵니다.

물론 이 글을 읽는 사용자들은 스마트해서 단번에 이해했으리라고 생각합니다만 저는 그리 똑똑하지 않기에 Pub/Sub 모델에 대해서 정리해보려고 합니다.

언제나 그렇듯 초보자의 관점에서 글을 작성하니 이미 Pub/Sub 모델에 대해서 잘 알고 있는 유저라면 과감하게 뒤로가기 버튼을 눌러주기를 바랍니다.

사전적 기본 개념

메시징과 관련된 IT서적을 보면 보통 아래와 같은 설명으로 Pub/Sub 모델을 설명하고 있습니다.

메시지를 보내고 (Publish : 발행) 받는 (Subscribe : 구독) 형태의 통신

실생활 예제를 통한 이해

형태의 특징을 아주 적절하게 표현한 설명이라고 할 수 있는데요. 
그럼 여기서 도대체 Publish와 Subscribe가 뭔가요? 의문을 가질 수 있습니다.
아래의 우편함 예제를 한번 보겠습니다.

우리가 우편(편지를 포함하여)의 경우 우체부가 집의 우편함에 우편을 넣으면 우리가 우편함에 있는 편지등을 취할 수 있게 됩니다. 우편을 받아보게 되는지 아래의 순서를 보면

1. 우체부(Pubisher)가 편지(Message)를 넣는다.
2. 편지(Message)는 우체통(Broker or Channel)에 넣는다.
3. 각 집의 호수(Topic)에 맞게끔 편지(Message)를 넣는다.
4. 우리(Subscriber)는 우체통에 들어 있는 편지를 가져간다.

즉, 우체부라고 불리는 Publisher가 편지라고 불리는 Message를 Channel 혹은 Broker라고 불리는 우체통에 넣으면 Subscriber라고 불리는 우리가 편지를 가져갈 수 있는것입니다.

보내는이, 보내는 물건, 받는이(취득자)가 있다면 이게 바로 Pub/Sub 모델인데요

일단 실생활 예제를 통한 설명은 여기까지 간략하게 끝마치고 좀 더 전문적인 이미지를 살펴 보겠습니다.

HiveMQ의 Pub/Sub 모델

그림 1
www.hivemq.com/blog/mqtt-essentials-part2-publish-subscribe 에서 발췌

위의 그림1 을 보면 temperature 센서가 HiveMQ라는 곳에 온도를 Publish하고 Laptop과 mobile 장치에서 HiveMQ로부터 temperature 센서가 보낸 온도를 받고 있습니다.

요즘 CF에도 많이 나오는 집안 온도를 밖에서도 알 수 있는 시스템같죠? 
중요한건 그게 아니라 이 모델이 바로 Pub/Sub 모델이라는 것입니다.

Publisher(우체부) : temperature sensor
Message(편지) : 온도
Broker or Channel(우체통) : MQTT-Broker
Subscriber(우리) : laptop 혹은 mobile device

라고 표현해 볼 수 있는데 보내는 측과 보내는 메시지 그리고 메시지를 받는측이 있다면 이것이 바로 Pub/Sub 모델입니다.

그런데 Topic(토픽)은 뭘까?

토픽은 우체통에 적힌 아파트 호수이다. 마치 101호처럼…

그런데 그림1에서 보면 정육각형중 2에 해당하는 텍스트중에 Topic라는것을 발견할 수 있는데요

토픽? 그게 뭐지? 해외 토픽감???

자! 다시 우체통 예제를 보면 우체부가 편지를 우체통에 넣으면 우리는 그것을 받아본다고 했습니다. 그럼 개인주택인 경우야 상관없지만 아파트인 경우 우체부는 어디에다가 그것을 넣을 것인가? 이미 눈치 채셨겠지만 우체통에는 아파트의 각 호수가 적힌 통이 나눠져 있습니다.
101호, 102호 이런식으로 말이죠.

만약에 호수별로 우체통이 나눠져 있지 않다면 우체부는 공용으로 사용하는 통에 편지를 넣을 것이고 우리는 그 통을 뒤져서 편지를 가져가려면 아마.. 아우 생각만 해도 끔찍하네요.

그렇기 때문에 우체통은 각 호수별로 나눠져 있고 Pub/Sub 모델에서의 메시지통도 마찬가지로 나눠져 있습니다.

Topic라는 주소를 정해놓고 Publisher쪽은 특정 topic에 Publish를 하고 Subscriber도 그 특정 Topic을 뒤져서 메시지를 가겨가면 되는 것입니다.

그럼 좋은점과 나쁜점은 없을까?

모든 세상 이치가 그렇듯 모든 사물, 현상등에는 장/단점이 있기 마련입니다.

장점 => 안정적이다. 확장성이 용이하다.
단점 => 느리다.

나쁜점과 좋은점을 한꺼번에 이해하자!

자! 다시 우체통의 예제를 들어보겠습니다.

만약에 우체통이 없이 우체부와 직접 편지를 주고 받으면 어떻게 될까? 우체부는 직접 집으로 와서 편지를 전해줄 것입니다. (이 경우엔 토픽이 없다. 우체통이라는 Broker 혹은 Channel도 없고 우체통에 할당된 호수(Topic)도 없다.)

우체부가 직접 편지를 주게 되면 굳이 우체통까지 편지를 가지러 갈 필요가 없죠. 아주 직접적인 행동(Action)이라고 볼수 있습니다. 마치 택배처럼…

그럼 우체통에 들어왔는지 기다릴 필요 없이 직접 편지를 받게 되니 매우 빠르게 전달 받을 수 있을 것인데요

이렇 듯 Pub/Sub (with topics in broker or channel) 이 아닌경우는 직접 시스템간에 메시지를 주고 받으면 중간에 적재되는 공간이 없기 때문에 굉장히 속도가 빠르다고 할 수 있습니다.

거꾸로 말하면 중간 저장소(Broker or Channel)를 거치게 되는 Pub/Sub 모델은 그만큼 느리다는 뜻도 됩니다.

다만, 요즘 시대에는 서버 혹은 그에 준하는 인프라 사양들이 너무 좋기 때문에 크게 고려할 사항은 아니라고 생각됩니다.

단점 : 느리다.

자 그럼 여기서! 의문이 생기게 될 것인데요.

만약에 집에 사람이 없다면 우체부는 어떻게 할 것인가? 이 경우를 시스템에 비유하자만 Subscriber의 장애(다운)으로 표현해보면 될 것 같습니다.

그럼 Publish 즉, 우체부는 편지를 받아갈 사람을 한없이 기다려야 하나?
아니면 편지를 집 현관문 앞에 던져놓고 다른 사용자를 위해 편지를 전해주러 가야 하나?

이런 문제점을 해결하기 위해 우체통(Broker or Channel) 이 생겼으며 각각의 호수에 사람이 있을수도 있고 없을 수도 있기에 우체통 호수(Topic)이 생겨난 것입니다.

설사 사람이 집에 없더라도 그리고 우체부는 그걸 신경쓰지 않고 우체통에 안전하게 편지를 넣어주기만 하면 되는것이죠. 그럼 집에 사람이 없어도 편지를 계속해서 보관될 것입니다.

장점 : 안정적이다.

So! what is pub/sub messaging pattern?

• Topic이 있는 Broker 혹은 Channel을 이용한 메시징 시스템이다.
  중간 저장소(Broker 혹은 Channel)존재하기 때문에 느리면서도 안정적이다.
• 메시지를 보내는 측(Publisher)와 메시지를 받는 측(Subscriber)으로 구성된다.
  보내는 행동은 Publish라고 하며 받는 행동은 Subscribe라고 한다.
• 이를 통틀어 Pub/Sub 모델이라 지칭한다.

마지막으로…

이런 Pub/Sub 모델의 대표 주자에는 몇가지 메시징 시스템들이 있는데ActiveMQ, MSMq, RabbitMQ, Apache Kafka등이 있는데 그 중에 요즘에 가장 널리 쓰이고 있는 Apache Kafka에 대해서 알아보고 싶은 분은 다음의 링크로 들어가서 Apache Kafka의 등장 배경과 설치 그리고 설정 및 운영 방법등에 대해서 차례대로 알아볼 수 있습니다.

Apache Kafka : https://medium.com/@zaneiru/apache-kafka-%EC%9D%98-%EB%93%B1%EC%9E%A5-%EB%B0%B0%EA%B2%BD-%EC%84%9C%EB%A1%A0-8e10e3d8ed38