- Prologue
- Redis as MessageQueue
- Pub/Sub vs Stream
- Redis Stream vs Kafka
- Pub/Sub vs List
- List vs Stream
- 메시지 순서 보장
- Summary
- Reference
Prologue
-
이전에 포스팅 한 “Redis를 MessageQueue로 활용하는 방법“글에서
Redis를 MessageQueue로 사용하는 3가지 방법에 대해 알아봤다.
-
사실 각 개념으로 보면 다 비슷해보이는 기능이라
언제 어떻게 다르게 사용해야하는거지?라는 생각이 들었고
그래서 각 방법별로 비교해보는 글을 작성하기로 하였다.
Redis as MessageQueue
- Redis를 MQ로 사용하는 방법으로는 3가지가 있다.
-
Pub/Sub
-
List
-
Stream
Pub/Sub vs Stream
Pub/Sub
메시지 전달 방식
-
실시간 메시징 : Pub/Sub은 메시지를 실시간으로 전달한다.
컨슈머의 상태를 바라보지 않고 프로듀서는 메시지를 발행하므로 놓칠 가능성이 있다.
구독 모델
-
컨슈머는 특정 채널에 대해 구독을 설정하고
메시지는 모든 구독자에게 동시에 전송되므로
여러 구독자가 동시에 같은 메시지를 수신할 수 있다.
사용 사례
- 채팅 시스템, 실시간 알림, 실시간 데이터 스트리밍 등 즉각적인 메시지 전달이 필요한 경우
Stream
메시지 전달 방식
-
영구적 메시징: Stream은 메시지를 로그에 저장한다.
그래서 메시지가 삭제되기 전까지는 Stream에 저장되어 있으므로
컨슈머는 메시지를 나중에 읽을 수 있다.
소비 모델
-
메시지는 하나 이상의 소비 그룹(Consumer Group)에 의해 소비될 수 있다.
각 그룹은 자신의 읽기 위치를 관리한다.
-
메시지를 소비한 후에도 삭제되지 않으며
명시적으로 삭제하거나 보존 정책(Retention Policy)에 의해 삭제될 때까지 유지된다.
-
소비자 그룹을 사용하여 작업을 분산 처리할 수 있으며
각 소비자는 그룹 내에서 메시지를 나누어 처리한다.
사용 사례
-
로그 데이터 수집, 이벤트 소싱, 작업 큐, 데이터 스트리밍 처리 등
메시지의 순서가 중요하고 나중에 재처리해야 하는 경우
요약
-
Pub/Sub은 실시간 통신에 적합하며 메시지를 즉시 소비해야 할 때 사용된다.
Stream은 메시지를 지속적으로 저장하고 이후에 접근하여 처리할 수 있어야 하는 경우에 적합하다.
-
두 가지 메커니즘 모두 Redis의 강력한 메시징 기능을 제공하지만
각각의 특징과 용도에 맞게 선택하여 사용해야 한다.
Redis Stream vs Kafka
Redis Stream
설계 철학
-
Redis는 인메모리 데이터 구조를 사용하여
주로 간단한 사용 사례와 빠른 성능을 위해 설계되었다.
데이터 저장
-
인메모리 저장이 기본이며
필요에 따라 디스크에 스냅샷을 저장하거나 AOF(Append-Only File)를 사용해 지속성을 유지한다.
-
메시지는 Stream 내에 순차적으로 추가되며
수동으로 또는 자동 보존 정책에 따라 삭제된다.
성능
-
Redis는 낮은 지연 시간과 높은 처리량을 제공하지만
대규모 데이터 집합의 경우 메모리 사용량이 제한적이다.
복잡성 및 운영
-
상대적으로 설정과 운영이 간단하며
단일 노드부터 시작하여 클러스터로 확장할 수 있다.
사용 사례
- 실시간 로그 분석, 작업 큐, 이벤트 소싱, 간단한 데이터 스트리밍 및 분산 처리
Kafka
설계 철학
-
분산형 스트리밍 플랫폼으로
대규모 데이터 스트리밍 및 실시간 데이터 파이프라인을 처리하기 위해 설계되다.
데이터 저장
-
주로 디스크를 기반으로 데이터를 저장하며
데이터를 분산된 클러스터에 복제하여 내구성을 보장한다.
-
각 메시지는 토픽으로 구성된 로그에 순차적으로 저장되며
컨슈머는 자신의 오프셋을 관리하여 메시지를 읽는다.
성능
-
높은 처리량과 확장성을 제공하며
수백 테라바이트의 데이터를 처리할 수 있다.
-
디스크 기반 저장을 통해 대용량 데이터를 효율적으로 처리할 수 있다.
복잡성 및 운영
-
설정과 운영이 복잡하며 클러스터 설정 및 관리가 필요하다.
-
Zookeeper(또는 Kafka Raft Controller)와 함께 사용되어 클러스터 메타 데이터를 관리한다.
사용 사례
- 대규모 데이터 스트리밍, 이벤트 소싱, 로그 수집, 실시간 데이터 파이프라인, 분산 처리 시스템
요약
-
두 시스템은 설계 철학, 기능, 사용 사례에 차이점이 있다.
-
Redis Stream은 상대적으로 간단한 설정과 빠른 인메모리 성능을 제공하며
중소규모의 실시간 데이터 처리 및 간단한 메시징 시스템에 적합하다.
-
Apache Kafka는 대규모 데이터 스트리밍 및 복잡한 실시간 데이터 파이프라인을 처리하는 데 적합하며
높은 내구성과 확장성을 제공한다.
Pub/Sub vs List
차이점
데이터 저장 vs 실시간 메시징
-
List는 데이터를 저장하고 관리하는 데 중점을 둔다.
List에 남아 있는 데이터는 지속적으로 접근할 수 있다.
-
Pub/Sub은 실시간 메시징을 목적으로 하며
메시지는 발행되면 즉시 컨슈머에게 전달되고 삭제된다.
-
Pub/Sub은 메시지를 저장하지 않으므로
컨슈머는 메시지를 놓치면 나중에 다시 받을 수 없다.
영속성
-
List는 저장된 데이터를 Disk에 저장하며
명시적으로 삭제하지 않으면 유지된다.
Pub/Sub 메시지는 컨슈머에게 전달된 후 삭제된다.
List vs Stream
차이점
데이터 구조 및 모델
-
List는 단순한 선형 데이터 구조로
순차적으로 데이터를 추가하고 제거하는 작업에 적합하다.
-
Stream은 더 복잡한 데이터 모델로 각 데이터마다 고유한 ID를 가진다.
데이터 유지 및 관리
-
List는 삽입된 데이터가 그대로 유지되며 필요한 경우 명시적으로 삭제해야 한다.
-
Stream은 데이터는 삭제 정책에 따라 오래된 데이터를 자동으로 삭제할 수 있다.
소비자 그룹
-
List는 단일 소비자 또는 단순한 생산자-소비자 패턴에 적합하다.
-
Stream은 소비자 그룹을 통해
여러 소비자가 동일한 Stream을 병렬로 처리할 수 있으며
각 소비자는 자신이 처리한 메시지를 어디까지 소비하였는지 관리해야 한다.
사용 사례
-
List는 단순한 작업 대기열, 버퍼, 또는 순차적인 데이터 저장에 사용된다.
-
Stream은 복잡한 이벤트 처리, 실시간 로그 수집, 데이터 파이프라인, 메시징 시스템 등에서 사용된다.
메시지 순서 보장
Pub/Sub
순서 보장
-
Pub/Sub 시스템에서는 발행된 메시지가 구독자에게 순서대로 전달된다.
-
즉 A, B, C 순서로 메시지를 발행하면
컨슈머는 동일한 순서인 A, B, C 메시지를 받게 된다.
제한 사항
-
컨슈머가 메시지를 받을 준비가 되지 않은 상태에서
메시지가 발행되면 해당 메시지를 놓치게 되며
메시지 저장이나 재전송이 없으므로
일시적인 네트워크 문제나 구독자의 비동기 처리 때문에 순서가 보장되지 않을 수도 있다.
List
순서 보장
-
List는 순서를 엄격히 보장한다.
List의 앞이나 뒤에서 요소를 추가하거나 제거할 수 있으며
삽입된 순서대로 데이터를 유지한다.
제한 사항
-
List는 데이터 저장 및 관리에 초점을 맞추므로
여러 클라이언트가 동시에 작업 시 순서를 보장하기 위해 추가적인 동기화가 필요할 수 있다.
Stream
순서 보장
-
스트림 또한 순서를 보장한다.
각 메시지는 고유한 ID를 가지며
이 ID는 시간 기반이므로 시간 순서대로 정렬된다.
제한 사항
-
스트림은 여러 소비자 그룹을 지원하고
각 그룹 내에서 여러 소비자가 병렬로 데이터를 처리할 수 있다.
-
이 경우 소비자 간의 메시지 처리 순서는 보장되지만
개별 소비자가 데이터를 처리하는 순서는 보장되지 않을 수 있다.
요약
-
Pub/Sub : 순서를 보장하지만
메시지가 발행된 후 저장되지 않으므로
컨슈머가 준비되지 않은 상태에서는 순서가 보장되지 않을 수 있다.
-
List : 데이터 삽입 순서와 접근 순서를 엄격히 보장한다.
-
Stream : 시간 기반 ID를 통해 순서를 보장하며
컨슈머 그룹 내에서도 순서를 보장하지만
병렬 처리 시 주의가 필요하다.
Summary
-
각 방법별로 차이점에 대해 알아봤다.
공통적인 속성이 있지만 미묘하게 다른 부분이 있으니
현재 상황에 맞는 방법을 택하면 되겠다.