Publish/Subscribe 와 Producer/Consumer 메시징 시스템

Publish/Subscribe 와 Producer/Consumer 메시징 시스템

Publish/Subscribe(이하 Pub/Sub) 메시징 시스템과 Producer/Consumer 메시징 시스템에 대해서는 대부분 Kafka나 RabbitMQ 등 여러 메시징 시스템을 리서치 후 선택할 때 자주 본 개념일 것입니다. 하지만, Kafka 도입을 위해서 살펴볼 때 Pub/Sub 메시징 시스템인데도 불구하고 Producer와 Consumer라는 개념을 맞닥뜨리게 될 때 '내가 잘 못 알고 있었나?'라는 생각이 들면서 다시 찾아보게 됩니다. 결론부터 얘기하면 Kafka의 기본 아키텍처와 데이터 처리 모델에 주안해서 네이밍을 했기 때문입니다. Kafka는 본질적으로 Publish-Subscribe 모델을 기반으로 하지만, 그 구현 방식과 사용 사례가 전통적인 Publish-Subscribe 시스템과는 다르게, 데이터 스트림의 생산(Production)과 소비(Consumption)에 중점을 두기 때문에 Producer/Consumer 구성요소를 가지게 되었습니다.
 
글의 목차는 아래와 같습니다.
- Publish/Subscribe Messaging Platform
- Produce/Consume Messaging Platform
- 두 시스템 간의 비교
- 왜 Kafka는 Pub/Sub 시스템인데 Producer/Consumer로 컴포넌트 이름을 지었을까?
 

Publish/Subscribe Messaging Platform

Publish-Subscribe (Pub-Sub) 메시징 모델에서, 메시지는 토픽을 기반으로 분류됩니다. 발행자(Publisher)는 특정 토픽에 메시지를 발행하고, 구독자(Subscriber)는 관심 있는 토픽을 구독하여 해당 토픽에 대한 메시지만을 수신합니다. 이 모델에서는 메시지가 특정 구독자에게 직접 전송되는 것이 아니라, 구독한 모든 구독자에게 전송됩니다. 이 방식은 느슨한 결합(loosely coupled) 아키텍처를 가능하게 하며, 발행자와 구독자 사이의 독립성을 보장합니다.

장점

• 확장성: 발행자는 구독자의 신원이나 수를 모르고도 많은 구독자에게 메시지를 보낼 수 있습니다.
• 분리: 발행자와 구독자가 서로에 대해 알 필요가 없어 시스템에 새로운 구성 요소를 추가하거나 제거하기가 더 쉽습니다.
• 유연성: 구독자는 어떤 주제를 구독할지 선택할 수 있고, 발행자는 어떤 주제로 메시지를 보낼지 선택할 수 있습니다.

 

대표적인 소프트웨어

• Apache Kafka: Kafka는 분산 스트리밍 플랫폼으로서, 고성능의 Pub-Sub 메시징을 지원합니다. Kafka는 대규모 메시지 처리에 적합하며, 내구성 있는 스토리지와 스트림 처리 기능을 제공합니다.
• Google Cloud Pub/Sub: Google Cloud Pub/Sub은 완전 관리형 글로벌 메시징 서비스로, 대규모 웹 애플리케이션의 이벤트 드리븐 아키텍처를 지원합니다. 간편한 API와 높은 확장성을 제공하여, 애플리케이션 간의 데이터 통신을 용이하게 합니다
• RabbitMQ: RabbitMQ는 AMQP(Advanced Message Queuing Protocol)를 기반으로 하는 오픈 소스 메시지 브로커입니다. 높은 유연성과 확장성을 가지며, 다양한 메시징 패턴을 지원합니다.

 

Produce/Consume Messaging Platform

Produce/Consume 메시징 모델에서, 생산자(Producer)는 메시지 큐에 메시지를 전송(produce)하고, 소비자(Consumer)는 큐로부터 메시지를 가져와(consume) 처리합니다. 이 모델은 일반적으로 점대점(point-to-point) 통신에 사용되며, 메시지는 소비자에게만 전달됩니다. 메시지 큐는 메시지의 순서를 유지하고, 소비자가 처리할 준비가 될 때까지 메시지를 저장합니다. 이 모델은 메시지의 신뢰성 있는 전송을 보장하며, 시스템 간의 결합을 줄이는 데 도움을 줍니다.

장점

• 비동기 처리: 생산자와 소비자가 독립적으로 작동할 수 있어 메시지의 비동기 처리를 가능하게 합니다.
• 자원 관리: 공유 버퍼는 생산자가 메시지로 소비자를 압도하는 것을 방지하는 스로틀 역할을 할 수 있습니다.
• 부하 분산: 여러 소비자가 동일한 버퍼에서 메시지를 소비할 수 있어 부하 분산과 중복을 가능하게 합니다.

 
대표적인 소프트웨어

• Amazon SQS (Simple Queue Service): Amazon SQS는 AWS에서 제공하는 완전 관리형 메시지 큐 서비스입니다. SQS는 분산 시스템, 서버리스 애플리케이션, 마이크로서비스 간의 분리된 컴포넌트의 통신을 용이하게 합니다.

 

Publish/Subscribe vs Produce/Consume

두 패턴 모두 유사점을 공유하지만 메시징 분배하는 방법에 차이가 있습니다. 이에 따라 특정 상황에 더 적합하게 만드는 몇 가지 핵심 차이점이 있습니다. 
- 통신 스타일: 발행-구독은 일대다 통신 패턴이며, 생산자-소비자는 일대일 또는 일대다 통신 패턴입니다.

- 비동기 처리: 생산자-소비자는 메시지의 비동기 처리를 허용하는 반면, 발행-구독은 메시지의 실시간 처리에 더 적합합니다. 여기서 동기 처리라는 것은 실시간에 가까운 처리를 의미합니다. 예를 들면, 특정 서비스에서 이메일을 발송 목적으로 하는 Produce/Consume Messaging Plafrom은 주문 후 1분 후에 주문 완료 메일이 발송되는 것도 상관없으나, 검색 엔진의 실시간 동기화 목적의 Publish/Subscribe Messaging Plaform은 실시간 가깝게 처리해야 합니다.
- 데이터 분배: 발행-구독은 많은 소비자에게 데이터를 방송하는 데 더 적합하며, 생산자-소비자는 하나 또는 소수의 소비자에게 데이터를 분배하는 데 더 적합합니다.
- 분리: 발행-구독은 발행자와 구독자 사이에 더 나은 분리를 제공하는 반면, 생산자-소비자는 생산자와 소비자 사이에 더 나은 분리를 제공합니다.
 

왜 Kafka는 Pub/Sub 시스템인데 Producer/Consumer로 컴포넌트 이름을 지었을까?

Kafka에서 "Producer"와 "Consumer"라는 용어의 사용은 Kafka의 다양한 기능과 분산 데이터 처리에 대한 강조점을 반영합니다. 이 용어들은 Kafka가 단순한 메시징 시스템을 넘어서, 높은 처리량의 실시간 데이터 스트림 처리를 지원하는 포괄적인 플랫폼임을 강조합니다. 제가 생각했을 때는 Kafka는 Consumer는 message를 읽을 때 Pull-based로 동작하는데 이는 subscriber보다는 consumer라는 용어가 더 잘 맞는 것 같습니다. 원할 때 message를 읽는 방식이기 때문이죠. 이 관점에서 보면 메시지를 생산하고 소비하는 구조의 메시징 플랫폼이라고 생각할 수 있을 것 같습니다.

결론적으로 특별한 이유보다는 kafka는 단순한 Publish-Subscribe 메시징 시스템 이상의 기능과 유연성을 제공하고, 데이터 스트림을 생산하고 소비한다는 개념에서 component의 이름을 지은 것 같습니다. (즉 Producer/Consumer라고 지었을 때 "Kafka가 Produce/Consume Messaging System 하고 헷갈리지 않을까"를 생각하기보다는 해당 컴포넌트의 역할에 맞는 이름을 명명하는데 집중한 것 같습니다! 

주의! 이 섹션은 저의 생각이 포함되어 있습니다. 혹시, 관련해서 첨언해주실 분이 있다면 댓글로 부탁드려요!

 

 

같이 읽으면 좋은글

- Python Kafka Consumer 라이브러리 Faust PoC하기 (Feat. Django)

참조

- https://www.simplilearn.com/kafka-vs-rabbitmq-article

Apache Kafka Vs RabbitMQ: Main Differences You Should Know

- https://medium.com/codex/asynchronous-communication-why-does-kafka-use-a-pull-based-message-consumer-442c19a70f58

Kafka — Why does it use a pull-based message consumer?