pub/sub 구조에 대해서 알아보기 전에 Message Queue라는 것이 무엇인지를 알아야한다.
메시지 큐는 MSA 구조에서 어플리케이션들끼리 통신을 해야하는 상황에서 데이터를 교환할 때 사용하는 통신 방법 중 하나이다.
Pub/Sub
pub/sub은 메시징 패턴 중 하나이다. 구조에 대해서 간단히 설명하면 아래와 같다.
1. 이벤트를 발행하는 Publisher가 특정 channel(혹은 topic)에 이벤트를 전송한다.
2. 특정 channel(혹은 topic)을 구독하는 모두에게 해당 메시지가 전송되며 데이터 교환이 이루어진다.
아래의 구조를 가지고 살펴보자.
publisher
publisher는 전송하려는 메시지를 topic에 전송한다.
subscriber
message를 수신하려는 서버로 topic으로부터 메시지를 전달 받는다.
publisher와 subscriber는 서로에 대해서 전혀 알 필요가 없다.
publisher와 subscriber의 관심사가 분리되어있기에 느슨한 결합을 가진다고 표현할 수 있으며 비동기식 메시지 패턴이다.
중간에 브로커를 두고 메시지를 전달 받는데, 이때 브로커는 publisher와 subscriber에 대해서 모두 알고 있는 존재이다.
이러한 브로커의 역할로 redis 혹은 kafka를 사용한다.
여기까지만 살펴보면 대충은 알겠지만, 브로커와 토픽에 대해서 정확히 이해하지 못할 수 있다.
예시를 들어서 설명을 해보자면 아래와 같다.
| Publisher | 가수 혹은 공연 주최측 |
| Topic | 공연 정보 |
| Broker | 인터파크 티켓 (메시지 전달 플랫폼) |
| Subsciber | 팬 |
데이식스 팬들은 데이식스의 채널을 구독하게 됩니다.
가수 혹은 공연 주최측은 새로운 공연에 대한 정보를 게시합니다.
구독하고 있는 모든 팬들에게 자동으로 메시지가 전달되게 됩니다.
이때, 브로커가 없다면?
데이식스가 직접 팬들에게 이메일을 보내야합니다.
하지만 브로커가 있기 때문에, 데이식스는 팬들의 정보를 하나하나 알 필요 없고,
팬들은 공연에 대한 정보를 받아볼 수 있습니다.
Redis vs Kafka
Redis
Kafka
Kakfa에서는 publisher/subscriber 대신 producer/consumer라는 개념을 사용한다. 기능을 동일하다.
producer는 topic에 이벤트를 전송하고, 이 이벤트들은 topic에 partition에 분산되어 저장된다.
topic을 구독하고 있는 consumer group내의 consumer는 각 1개 이상의 partition으로부터 이벤트를 전달받게 된다.
만약, partition의 갯수보다 consumer의 갯수가 많다면, 아무 일도 하지 않는 consumer가 생기기 때문에 항상 partition의 수를 consumer의 수보다 크게 해주는 것이 좋다.
