PUB/SUB 구조와 Redis, Kafka를 이해하기 위한 과정

PUB/SUB 구조

pubsub을 어렵게 받아들일 필요가 없다는 것을 이해하고 글을 써본다.

PUB/SUB의 구조는 유튜브 생태계로 이해해보자.

우리 곁에서 가장 쉽게 Publisher와 Subscriber의 관계를 볼 수 있는 곳은 바로 유튜브이다. 그럼 유튜브의 생태계에 빗대어 보자.

Publisher는 유튜버, Channel은 유튜브 채널, Event는 유튜브 영상, Subscriber는 구독자라고 생각하면 이해하기 쉽다. 

 

유튜버(=Publisher)는 자신의 유튜브 채널(=Channel)에 유튜브 영상(=Event)을 생성 및 업로드한다. 여기서 유튜브 영상을 하나의 이벤트(메세지)라고 이해할 수 있다. 특정 Channel을 구독하고 있는 구독자(=Subscriber)는 Channel에 올라온 유튜브 영상(=Event)을 볼 수 있다. (*물론 이 예시가 100%로 들어맞다고 할 순 없다. PUBSUB 구조도 서비스마다 다른 성격을 띄기 때문에 이 차이점을 확인해야한다.)

 

1. 이벤트(메시지)를 발행하는 Publisher가 존재하며, Pusblisher는 특정 Channel(혹은 Topic)에 이벤트를 전송한다.

2. 특정 Channel(혹은 Topic)을 구독하는 Subscriber가 존재하며, Publisher에 관계없이 발행된 이벤트를 받을 수 있다. 

 

위에서 말했다 싶이 PUB/SUB(발행/구독) 방식이 각 서비스마다 다른데, 대표적으로 Kafka와 Redis가 있다.

사실 이 글은 Kafka와 Redis가 뭔 차이가 ... (도대체 얘네들이 뭔지를 알기 위함..) 를 이해하기 위해 쓰여졌다.

 

Kafka

Kafka의 구조는 우체통의 편지를 넣고 꺼내는 구조로 이해해보자.

Kafka에서는 Producer와 Consumer라는 개념이 등장하는데, 각자 Publisher와 Subscriber와 그 기능이 동일하다.

 

1. 이벤트(메세지)를 발행하는 Producer가 존재하며, Producer는 특정 Topic에 이벤트를 전송한다. 이 이벤트는 Topic의 각 Partition에 분산되어 저장된다. 

2. 특정 Topic을 구독하고 있는 Consumer group 내의 Consumer는 각각 1개 이상의 partition으로부터 이벤트를 가져온다. 만약 partition 개수보다 consumer 개수가 많다면, 아무 일도 하지 않는 consumer가 생기기 때문에, 항상 partition 수를 consumer 보다 같거나 크게 해주는 것이 좋다. 

 

Kafka의 topic은 우체통이라고 생각하면 될 것이다.

철수(=Producer)는 편지를 써서 영희네 우체통(=Topic)에 넣었다. 이 때, 편지는 누군가에 의해 발견될 때까지 우체통에 있을 것이다. 

편지는 영희네 엄마(=Consumer1)가 먼저 발견할 수도 있고, 영희네 오빠(=Consumer2)가 먼저 발견할 수도 있다. 그들은 가족이니까(=Consumer Group). 만일 영희네 오빠가 편지를 먼저 발견한다면? 영희는 편지의 존재조차 모를 것이다.(ㅋ)

 

여기서 조금 헷갈릴 수 있는 부분을 짚고 넘어갈 수 있다. 

"만약 partition 개수보다 consumer 개수가 많다면, 아무 일도 하지 않는 consumer가 생기기 때문에, 항상 partition 수를 consumer 보다 같거나 크게 해주는 것이 좋다." 는 Topic의 Partition에 있는 이벤트는 Consumer Group에서 Consumer 중 하나가 처리함을 의미한다.

즉, 영희네 집에서는 엄마, 아빠, 오빠 중 누구나 받아도 상관없지만 프로세스 관점으로 본다면 Consumer 하나가 놀고 있는 상황이기에 [parition 수 > consumer 수] 가 효율적이다. 

 

Redis

Redis의 구조는 TV의 Channel을 보는 구조로 이해하자. 

Redis에는 그룹이라는 개념이 존재하지 않고, 각 Subscriber가 Channel을 구독하고 있다. 

이 때 중요한 점은, Channel은 이벤트를 저장하지 않는다. 만일 Channel에 이벤트가 도착했을 때, 해당 채널의 Subscriber가 존재하지 않는다면, 이벤트는 사라진다. 

 

1. 이벤트(메세지)를 발행하는 Publisher가 존재하며, Producer는 특정 Channel에 이벤트를 전송한다. 

2. 특정 Channel(혹은 Topic)을 구독하는 Subscriber가 존재하며, Publisher에 관계없이 발행된 이벤트를 받을 수 있다. 

 

Redis의 Channel은 말 그대로, TV의 Channel을 생각하면 된다. 

하루 종일 TV에서는 수백 개의 채널에서 방송이 방영된다. 각 방송사(Publisher)에서 방영하는 라이브 방송은 해당 채널을 시청 중일 때, 같은 시간대에 같은 채널의 시청자들은 모두 같은 방송을 볼 수 있다.

 

Kafka vs Redis

구조적으로 봤을 때 Kafka와 Redis의 주된 차이점은 다음과 같다.

 

1. 이벤트의 저장 여부

2. 한 이벤트를 받을 수 있는 Subscriber(Consumer의 개수)

 

이벤트의 저장 여부

1. Kafka는 이벤트를 저장하는 데이터 스트림 플랫폼으로, 토픽에 이벤트가 저장된다. 

예를 들어, 온라인 쇼핑 사이트에서 주문 이벤트를 Kafka 토픽에 저장하고, 이벤트를 분석하거나 주문 내역을 추적하는데 활용한다,.

 

2. Redis는 메모리 기반 데이터 베이스로, Redis PUB/SUB은 데이터를 저장하지 않고, 실시간 통신을 위한 메커니즘을 제공한다.

예를 들어, 실시간 채팅 애플리케이션에서 메시지가 발행되고, 채팅 참여자들에게 실시간으로 전달된다. 메시지는 디스크에 영구적으로 저장되지 않는다.

 

한 이벤트를 받을 수 있는 Subscriber(Consumer의 개수)

1. Kafka에서는 Topic의 각 파티션에 대해 하나의 Consumer만 메시지를 처리할 수 있다. 

 

2. Redis PUB/SUB은 특정 채널을 구독하는 모든 Subscriber에게 메시지를 전달한다. 따라서 Redis는 다수의 Subscriber가 동일한 메시지를 동시에 받을 수 있다. 

 

 

마치며

결론적으로

Kafka는 대용량 데이터 스트림 처리 및 데이터 보존이 필요한 시나리오에 적합하며,

Redis는 실시간 통신 및 브로드캐스팅과 같은 실시간 응용 프로그램에 적합하다.

 

이처럼 PUB/SUB 패턴은 대규모 시스템에서 실시간 이벤트 처리, 메시지 큐, 실시간 통지 등 다양한 응용 분야에서 활용된다.

 

Kafka와 Redis 구조의 간단한 이해는 마쳤다. 배운게 도둑질이라고 잘 작성된 글을 다시 작성해보는 것마냥 일로는 그쳐서 안 된다. 직접 해보지 않으면 남는게 없을지도 모른다. 빠른 시일 내에 로컬에서 구현해보는 것이 목표이다. 

 

Reference

https://medium.com/frientrip/pub-sub-%EC%9E%98-%EC%95%8C%EA%B3%A0-%EC%93%B0%EC%9E%90-de9dc1b9f739