Redis Pub/Sub

Redis의 Pub/Sub 구조는 메시지 발행/구독(Publish/Subscribe)을 기반으로 하는 메시징 패턴이다. 이 구조는 Kafka나 RabbitMQ와 같은 Pub/Sub 기반 메시징 시스템에서 주로 사용하는 Event-driven 방식의 한 예시로, 비동기 통신, 데이터 분산, 그리고 대용량 트래픽을 효과적으로 처리할 수 있다.

이 글을 읽기 전에 메세지 큐에 대한 글을 먼저 읽으면 해당 포스팅을 이해하는데 더 도움이 될 것이다.
메세지 큐 방식을 모르고 있다면 한 번 읽어보도록 하자.

Redis Pub/Sub 구조의 특징

1. 비동기 통신과 높은 성능

• Pub/Sub 구조는 비동기 방식으로 작동하기 때문에 매우 빠른 메시지 전달이 가능하다. 또한 Queue 구조를 활용하므로 메시지를 효율적으로 분산 처리할 수 있는 장점을 가진다.

2. 간단한 메시지 전송

• Redis의 Pub/Sub은 설정과 구현이 간단하며, 발행된 메시지를 동일 채널을 구독 중인 모든 인스턴스에 동시에 전송할 수 있다. 하나의 인스턴스가 메시지를 받았다고 해서 다른 인스턴스가 받지 못하는 구조가 아니기 때문에 모든 구독자가 메시지를 실시간으로 공유해야 하는 상황에서 유용하다.

2. Redis Pub/Sub 구조의 단점

1. 메시지 유실 가능성

• Redis Pub/Sub은 메시지를 저장하지 않기 때문에 메시지가 발행될 당시 구독자가 없으면 해당 메시지가 유실될 수 있다. Redis 공식 문서에서도 이러한 단점을 명시하고 있으며, 메시지 유실이 발생해서는 안 되는 시스템에서는 Pub/Sub 대신 Redis 스트림이나 Kafka를 사용할 것을 권장한다.

2. Atomic 보장 부족

• 비동기 방식이므로 데이터의 원자성을 보장하지 않는다. 원자성이 요구되는 작업에서는 Redis Mutex와 같은 기법을 활용해 보완해야 한다.

3. 메시지 저장 기능 제공 X

• Kafka나 RabbitMQ는 발행된 메시지를 수신될 때까지 보관하는 기능을 제공하지만, Redis Pub/Sub은 메시지를 즉시 삭제한다. 이로 인해 메시지 유실을 방지하려면 별도의 설계를 고려해야 한다.

3. 그렇다면 Redis의 Pub/Sub은 어디에 사용하면 좋을까??

• Redis Pub/Sub은 단순하고 빠르게 메시징 시스템을 구축할 수 있으며, 실시간 메시지 전송이 필요하지만 메시지 유실이 허용되는 환경에서 유용하다. 예를 들어, 실시간 알림, 로그 전송, 또는 상태 변경 이벤트를 다룰 때 적합하다.

정리

Redis Pub/Sub은 간단단 비동기 메시징 시스템을 제공하지만, 메시지 유실과 데이터 원자성을 보장하지 않으므로 사용 시 이러한 점을 반드시 고려해야 한다. 메시지가 반드시 전달되어야 하거나 복잡한 트랜잭션 처리가 필요한 경우에는 Kafka, RabbitMQ 또는 Redis 스트림과 같은 대안을 선택하는 것이 더 적합할 것이다.