Server 08 - PUB/SUB


Publish / Subscribe

Publish의 사전적 의미는 출판하다, 발행하다, 공표하다로 나와있다. 그러니까, 이 단어를 행동으로 표현하면 어떤 것을 알리다라고 표현할 수 있겠다.
Subscribe는 책, 신문, 잡지등을 구매하여 본다라는 의미이다. 다른 말로는 구독하다란 이야기이며 행동으로 표현하면 어떤 것을 골라서 읽음으로써 받아들인다라고 표현할 수 있겠다.

위 두 단어가 합친게 Pub/Sub 구조이다. 어떤 이벤트를 통해 특정 메세지를 알리고 또 그 메세지를 읽는 행위를 담는 구조가 바로 Pub/Sub 구조이다.

pub-sub

Pub/Sub 구조

Pub/Sub (Publish/Subscribe)는 메시지 전송을 위한 비동기 통신 패턴이다. 이 패턴에서는 메시지를 전송하는 발행자(Publisher)와 수신하는 구독자(Subscriber)가 직접적으로 연결되지 않고, 중간에 메시지 브로커(Broker)가 중계하는 역할을 맡는다. 이를 통해 발행자는 구독자가 누군지 알 필요 없이 메시지를 브로커에게 전송하고, 브로커는 해당 메시지를 구독하고 있는 구독자들에게 전달한다.

  • 발행자 (Publisher)
    발행자는 메시지를 생성하고, 이를 브로커에게 전달하는 역할을 한다. 발행자는 메시지가 누구에게 전달될지에 대해 신경 쓸 필요가 없다.
  • 브로커 (Broker)
    브로커는 발행자가 보낸 메시지를 관리하고, 이를 적절한 구독자들에게 전달하는 중개자의 역할을 한다. 발행자와 구독자 사이의 의존성을 제거해 주는 핵심 요소
  • 구독자 (Subscriber)
    구독자는 특정 주제(Topic)나 채널에 대해 구독하고, 브로커가 해당 주제에 대한 메시지를 발행하면 이를 수신한다.

Pub/Sub 동작원리

Pub/Sub는 다음과 같은 순서로 동작한다

  1. 구독자는 특정 주제에 대한 구독을 신청한다.
  2. 발행자는 해당 주제에 대한 메시지를 브로커에게 발행한다.
  3. 브로커는 해당 주제에 구독한 모든 구독자에게 메시지를 전달한다.

이 과정에서 발행자는 구독자가 몇 명인지 또는 누가 구독하고 있는지 알 필요가 없으며, 구독자 또한 발행자의 존재를 인지하지 않아도 된다. 이를 통해 시스템의 유연성과 확장성을 높일 수 있다.

Pub/Sub의 장점

  1. 비동기성: 발행자는 메시지를 보내고 바로 다음 작업을 수행할 수 있다. 구독자가 언제 메시지를 받을지는 신경 쓰지 않아도 된다.
  2. 확장성: 다수의 발행자와 구독자가 존재할 수 있으며, 시스템은 발행자와 구독자 간의 직접적인 의존성이 없으므로 쉽게 확장할 수 있다.
  3. 유연성: 메시지를 수신하는 구독자의 수가 늘어나거나 줄어들어도 발행자는 동일한 방식으로 메시지를 발행할 수 있다.

Pub/Sub의 사용 예시

  • 실시간 알림 시스템: 사용자가 여러 장치에서 알림을 받을 수 있는 시스템에서는 Pub/Sub 패턴이 유용하다. 예를 들어, 모바일 앱, 웹 애플리케이션, 이메일 등 다양한 채널로 알림을 전송할 수 있다.
  • 이벤트 기반 시스템: 마이크로서비스 아키텍처에서 각 서비스가 서로 독립적으로 동작하면서도 특정 이벤트가 발생했을 때 다른 서비스에 알릴 수 있는 패턴으로 많이 사용된다.
  • 채팅 애플리케이션: 여러 사용자가 참여하는 채팅방에서 실시간으로 메시지를 전달하는 시스템에서 Pub/Sub 패턴이 활용된다.
  • SWT 이벤트 처리: 위의 이벤트 기반 시스템과 비슷하다. 이건 이전 회사 다니면서 사용했던 케이스 인데, SWT를 이용하여 뷰들의 동작들을 처리하는 방법으로 사용했다. SWT가 이벤트 처리 기반의 GUI가 동작하는 이클립스 기반의 GUI 툴킷이라, 어떤 컴포지트에서 특정 액션이 발생했을 때 특정 뷰 컴포지트에 변화를 주는 방식이 바로 Pub/Sub 방식이다.

Pub/Sub의 단점

  • 메시지 보장 문제: 기본적으로 Pub/Sub 패턴은 메시지의 전송을 보장하지 않는다. 구독자가 오프라인일 때 브로커가 메시지를 잃어버릴 수 있는 가능성이 있다. 이를 해결하기 위해서는 메시지 브로커가 메시지의 내구성을 보장하는 추가 메커니즘이 필요하다.
  • 구독자 관리: 구독자가 많아지면 브로커의 성능과 리소스 사용량이 증가할 수 있다. 이 경우 적절한 로드 밸런싱 및 메시지 큐 관리가 필요하다.

결론

Pub/Sub은 Publisher-Broker-Subscriber 구조로 되어있는 메시지 전송을 위한 비동기 통신 패턴 구조이다. 이 구조는 발행자와 구독자의 의존성을 제거하고 시스템의 확장성과 유연성을 높이는 데 매우 효과적이지만, 메시지 보장 문제구독자 관리와 같은 단점도 있으므로, 시스템 요구 사항에 맞는 적절한 설계가 필요하다.
이 구조는 Radis에서 주로 사용된다. 해서, 추후 Radis에서 Pub/Sub 구조를 어떻게 구현하는지에 대한 포스트로 다시 찾을 것이다.