Pub/Sub 구조 이해하기

pub/sub (publish/subscribe) 구조는 게시자가 구독자를 알 필요 없이 Topic에 메시지를 보내는 반면, 구독자는 게시자를 알 필요 없이 관심 있는 주제로부터 메시지를 받는 메시징 패턴입니다.

게시자와 구독자를 분리하면 분산 시스템에서 확장 가능하고 유연한 통신이 가능해지는데요.

이번 포스트에서는 기존의 메시징 형태는 어떠했고 pub/sub 모델은 어떤 구조와 특징을 가지고 있는지 공부한 내용을 정리해보았습니다.

기존의 메시징 형태

Direct Communication

  • 직접 통신 모델에서는 생산자(발신자)가 소비자(수신자)에게 직접 메시지를 보냅니다.

Tight Coupling

  • 생산자와 소비자는 긴밀하게 연결되어 있습니다. 즉, 생산자는 소비자의 정확한 주소와 프로토콜을 알아야 합니다.

Scalability Issues

  • 각 생산자는 새로운 소비자 정보로 업데이트되어야 하므로 소비자를 추가하거나 제거하는 것은 복잡할 수 있습니다.

Limited Flexibility

  • 직접 통신에는 유연성이 부족하여 새로운 소비자를 추가하거나 메시지 경로를 동적으로 변경하기가 어렵습니다.

Error Handling

  • 생산자는 전달 실패 및 재시도를 처리해야 하므로 애플리케이션 로직의 복잡성이 증가합니다.

Pub/Sub 모델

Decoupling

  • 게시/구독(Pub/Sub) 모델은 생산자와 소비자를 분리합니다.
  • 생산자는 Topic에 메시지를 게시하고 소비자는 서로 알지 못한 채 이러한 Topic를 구독합니다.

Scalability

  • 새로운 소비자가 생산자를 변경하지 않고도 Topic를 구독할 수 있으므로 시스템을 쉽게 확장할 수 있습니다.
  • 생산자는 소비자 수에 관계없이 Topic에 게시할 수도 있습니다.

Flexibility

  • 소비자는 Topic를 동적으로 구독하거나 구독 취소할 수 있으므로 유연한 메시지 라우팅 및 처리가 가능합니다.

Fault Tolerance

  • 메시지 브로커는 종종 내결함성 기능을 제공하여 메시지가 안정적으로 전달되고 오류가 발생한 경우 재시도할 수 있도록 보장합니다.

Asynchronous Communication

  • Pub/Sub는 비동기식 통신을 지원하므로 생산자는 소비자가 메시지를 처리할 때까지 기다리지 않고 작업을 계속할 수 있습니다.

Load Balancing

  • 메시지는 소비자 그룹 내의 여러 소비자에게 분산되어 처리 로드의 균형을 맞추고 성능을 향상시킬 수 있습니다.

브로커 Broker 란

메시지 브로커

메시지 브로커는 서로 다른 애플리케이션, 서비스 또는 시스템 간의 메시지 교환을 용이하게 하는 미들웨어 시스템입니다.

미리 정의된 규칙이나 주제에 따라 생산자(발신자)에서 소비자(수신자)로 메시지를 라우팅합니다.

생산자와 소비자를 분리하여 서로에 대해 직접 알 필요 없이 상호 작용할 수 있도록 합니다.

안정적인 메시지 전달, 필요에 따른 실패 처리 및 재시도를 보장합니다.

필요한 경우 메시지를 변환하여 소비자의 요구에 맞게 데이터 형식이나 구조를 변환할 수 있습니다.

RabbitMQ, ActiveMQ, IBM MQ가 메시지 브로커의 대표적인 예입니다.

이벤트 브로커

이벤트 브로커는 이벤트 기반 아키텍처용으로 설계된 특수한 유형의 메시지 브로커입니다.

이벤트를 생산자에서 소비자에게 실시간으로 스트리밍합니다.

메시지 브로커와 달리 일정 기간 동안 이벤트를 저장하는 경우가 많습니다.

때문에 소비자가 이벤트를 다시 재생하거나 특정 시점부터 시작할 수 있습니다.

높은 처리량을 지원하고 수평으로 확장하여 대규모 이벤트를 처리할 수 있습니다.

Apache Kafka, Amazon Kinesis, Azure Event Hubs가 이벤트 브로커의 대표적인 예입니다.

AspectMessage BrokerEvent Broker
Primary Use Case메시지 분리 및 라우팅실시간 이벤트 스트리밍 및 처리
Message Durability메시지를 저장할 수도 있고 저장하지 않을 수도 있습니다재생 및 내구성을 위해 이벤트를 저장하는 경우가 많습니다
Interaction Pattern요청-응답, 지점 간, pub-sub주로 pub-sub
Scalability일반적으로 적당한 확장성을 위해 설계됨높은 확장성과 처리량을 위해 설계
ExamplesRabbitMQ, ActiveMQApache Kafka, Amazon Kinesis

Leave a Comment

목차