[DevOps] - Pub / Sub (Publish-Subscribe)

메세지 큐(Message Queue) 란?

   MSA(Micro Service Architecture)구조에서는 하나하나의 애플리케이션끼리 통신을 해야 하거나 한 API에서 다른 API로 데이터를 넘겨야 하는 순간들이 생긴다. 메세지 큐는 프로세스 혹은 프로그램간 데이터 교환할 때 사용하는 통신 방법 중에 하나로, 메세지 지향 미들웨어(Message Oriented Middleware : MOM)을 구현한 시스템을 의미한다.

---

Pub/Sub(Publish-Subscribe) 이란?

  Pub/Sub (Publish-Subscribe)는 메시지 큐와 유사한 비동기 메시징 패턴으로, 생산자(publisher)가 메시지를 보내고, 구독자(Subscriber)가 해당 메시지를 받아 처리하는 구조를 가진다.

간단하게 본다면 Pub가 topic에 메시지를 보내면 해당 topic을 구독해놓은 Sub 모두에게 메시지가 전송되면서 데이터 교환이 이루어지는 방식이다.

이 방식은 발행(Publish)하는 시스템과 구독(Subscribe)하는 시스템이 직접 연결되지 않고, 메시지 브로커를 통해 간접적으로 연결된다는 점이 특징이다.

---

Pub/Sub의 구조

Google Cloud Platform - Pub/Sub

 

Publisher (게시자)

  → Publisher는 Message를 생성한 뒤에 Topic에 담아두도록 전달해주는 서버이다.

 

Message (메세지)

  → Mesage는 Publisher로부터 Subscriber에게 최종적으로 전달되는 데이터와 property의 조합이다. 쉽게 얘기하면 서로 다른 API끼리 통신을 할 데이터라고 할 수 있다.

 

Topic (토픽), Channel

  → Topic은 Task를 말한다. Publisher가 Message를 전달하는 리소스이다.

 

Subscription (구독)

  → Subscription은 Message 스트림이 Subscriber들에게 전달되는 과정을 나타내는 이름을 가지고 있는 리소스라고 할 수 있다.

 

Subscriber (구독자)

  → Subscriber는 Message를 수신하려는 서버이다.

 

 

 Publisher와 Subscriber은 서로에 대해 전혀 알 필요가 없다. 그렇다면 어떻게 Message를 주고받게 되는걸까?

→ 중간다리 역할을 해주는 브로커(Broker), 혹은 버스(Bus)라고 불리는 존재가 있다. 브로커나 버스는 Publisher와 Subscriber 모두가 서로 알고 있는 존재로, 브로커나 버스 역할을 해줄 Redis 혹은 Kafka에서 지원하는 서비스를 사용한다.

 

즉 동작을 살펴본다면 다음과 같다:

1. Publisher가 특정 토픽에 메시지를 발행한다.
2. Broker가 해당 메시지를 저장하고 관리한다.
3. 해당 토픽을 구독한 Subscriber들에게 메시지를 전달한다.

---

Pub/Sub 방식과 메세지 큐(Message Queue)의 차이

특징	Pub/Sub	메시지 큐 (Message Queue)
메시지 소비 형식	1개의 메시지를 여러 구독자가 받을 수 있음	1개의 메시지는 오직 1개의 소비자가 처리
구성 요소	Publisher, Broker, Subscriber	Producer, Queue, Consumer
메시지 전달	푸시(Push) 방식 (구독자에게 전달)	풀(Pull) 방식 (소비자가 직접 가져감)
메시지 순서	순서를 보장하지 않을 수 있다	일반적으로 FIFO(First-In, First-Out) 방식
예제	Kafka, Redis Pub/Sub, Google Cloud Pub/Sub	RabbitMQ, ActiveMQ, Amazon SQS

 

---

Pub/Sub의 장단점

✔️ Pub/Sub의 장점

• 확장성 (Scalability)
  • 여러 구독자가 동일한 메시지를 받을 수 있으므로 확장이 용이하다
  • 예를 들어, 한 시스템에서 데이터를 발행하면 다양한 서비스에서 이를 동시에 소비 가능하다
• 비동기 처리(Asynchronous Processing)
  • 발행자가 메시지를 보낸 후 즉시 다음 작업을 수행할 수 있어 성능이 향상된다
• 시스템 간 결합도 감소 (Loose Coupling)
  • 발행자와 구독자가 직접 통신하지 않고 브로커를 통해 간접적으로 연결된다
  • 시스템 변경이 용이하다

✔️ Pub/Sub의 단점

• 메시지 순서 보장이 어렵다
  • 메시지가 여러 노드에 분산되므로 순서를 맞추기 어렵다 (Kafka는 이를 해결할 수 있도록 파티션을 사용한다)
• 메시지 중복 가능성
  • 동일한 메시지가 여러 번 전달될 가능성이 있다 → 중복 메시지 처리를 고려해야 함
• 메시지 보장 설정 필요
  • 일반적으로 메시지는 특정 기간 동안만 유지되므로, 메시지를 보장하려면 추가적인 설정이 필요하다