PUB/SUB 구조
Pub - Sub 구조
Pub/Sub 이란
Pub/Sub은 publisher/subscribe의 줄임말로, 비동기식 메시징 패턴입니다.
Publisher가 Message를 발행하면 해당 Message를 구독하고 있는 Subscriber가 해당 Message를 읽을 수 있고, 작업을 하게 됩니다.
이러한 구조에 의해 Publisher와 Subscriber는 서로 알 필요가 없습니다.
Publisher는 중간 컴포넌트(버스, 브로커)에게 메시지를 전달하면 중간 컴포넌트는 해당 Topic을 구독 중인 Subscriber에게 전달해줍니다.
즉, 발신자의 메시지는 특별한 수신자가 정해져 있지 않습니다.
비동기 메세징 패턴
- 동기 - 어떤 일의 수행과 동시에 결과가 나오는 것.
- 비동기 - 어떤 일의 수행 즉시 결과가 나오는 보장이 없는 것. (예, Node.js의 콜백)
Pub/Sub은 비동기식으로 동작하게 됩니다.
Publisher가 Topic(task)를 발행하면, 그 Topic(task)를 구독한 Subscriber가 받아 일을 처리합니다. 그 동안 Publisher는 다른 작업을 수행할 수 있습니다.
Subscriber가 Topic(task)를 작업하고 있으면,
이러한 구조는 비동기식으로 동작하는 장점을 가질 수 있습니다.
이러한 비동기식 Architecture는 확장성과 유연성을 제공하며 데이터 생산자와 소비자 간의 결합도를 낮추어 시스템을 모듈화하고 확장성을 확보할 수 있습니다.
MSA와 Pub/Sub
이러한 Pub/Sub은 Micro Service Architecture를 지향하는 현 시점에 중요한 Pattern 입니다.
MSA 구조에서 이러한 Pub/Sub이 유용한 상황을 떠올리면 다음과 같습니다.
User 서비스에서 회원 가입이 발생했을 때,
Coupon 서비스에서는 회원가입 기념 쿠폰을 발행하고,
Point 서비스에서는 회원가입 기념 Point를 유저에게 제공하는 상황에서 쓰일 수 있습니다.
Coupon 서비스와 Point 서비스는 회원 가입 Topic을 구독하는 Subscriber이고,
User 서비스는 회원 가입이라는 Topic에 대한 Message를 발행할 수 있는 Pubisher가 될 수 있습니다.
KAFKA vs Redis 간단 비교
대표적인 Pub/Sub 시스템으로는 Apache Kafka와 Google Cloud Pub/Sub, Amazon Simple Notification Service, Redis 등이 있습니다.
KAFKA
Kafka에서는 Producer/Consumer라는 개념이 등장하는데, 각각 Publisher/Subscriber와 그 기능이 동일합니다.
Producer는 Topic에 이벤트를 보내고, 이 이벤트는 Topic의 각 Partition에 분산 저장됩니다. Topic을 구독하고 있는 Consumer group 내의 Consumer는 각각 1개 이상의 partition으로부터 이벤트를 가져옵니다.
만약 partition 개수보다 consumer 개수가 많다면, 아무 일도 하지 않는 consumer가 생기기 때문에, 항상 partition 수를 consumer보다 같거나 크게 해주는 것이 좋습니다.
REDIS
Redis에는 그룹이라는 개념이 존재하지 않고, 각 subscriber가 channel(topic)을 구독하고 있습니다.
이때 중요한 점은, Channel은 이벤트를 저장하지 않는다는 것입니다.
만일 Channel에 이벤트가 도착했을 때, 해당 채널의 Subscriber가 존재하지 않는다면, 이벤트는 사라지게 됩니다.
따라서 현재 접속 중인 클라이언트에게 짧고 간단한 메시지를 빠르게 보내고 싶을 때, 그리고 전송된 메시지를 따로 저장하거나 수신 확인이 필요 없을 때, 마지막으로 100% 전송 보장은 하지 않아도 되는 데이터를 보낼 때 이용하면 유용합니다.
참고자료
https://redis.io/docs/interact/pubsub/
https://kafka.apache.org/documentation/#gettingStarted