Please enable JavaScript.

Coggle requires JavaScript to display documents.

Redis를 Message Broker로 사용하는 이유는 무엇인가요?, Redis는 그 속도와 단순성 덕분에 특정 실시간 메시징…

- - - - Redis는 인메모리 데이터 저장소의 특성상 매우 빠른 메시지 처리가 가능
- - - - 이는 시스템의 유연성과 확장성을 높여줍니다.
  - - - 이는 시스템의 응답성을 향상시키고 부하를 분산시킵니다.
  - - - 이는 시스템 장애 시에도 메시지 손실을 방지합니다. (Redis Pub/Sub은 기본적으로 내구성을 제공하지 않지만, 다른 메시지 브로커는 제공합니다.)
- - - - 모든 데이터가 메모리에 저장되기 때문에 메시지 발행 및 구독 처리 속도가 매우 빠릅니다.
        
        낮은 지연 시간을 요구하는 실시간 애플리케이션에 적합합니다.
    - - 복잡한 설정 없이 Redis 서버만 있으면 바로 Pub/Sub 기능을 사용할 수 있습니다.
        
        API도 매우 직관적
    - - 경량이며, 다른 메시지 브로커에 비해 적은 리소스를 사용
    - - Redis의 다른 데이터 구조(List, Set, Hash 등)와 함께 사용하여 메시징 외의 추가적인 기능(예: 최근 메시지 저장, 사용자 상태 관리)을 구현할 수 있습니다.
  - - - 메시지를 특정 channel에 발행
    - - 클라이언트가 특정 channel을 구독
    - - channel에 메시지가 발행되면, 해당 channel을 구독하고 있는 모든 클라이언트에게 메시지가 전달
  - - - Redis Pub/Sub은 메시지를 저장하지 않습니다.
        
        메시지가 발행되는 순간 구독하고 있는 클라이언트에게만 전달되며, 해당 시점에 구독하고 있지 않은 클라이언트는 메시지를 받지 못합니다.
        
        서버 재시작 시에도 메시지가 유실
    - - 메시지 전달이 최대 한 번만 보장
        
        네트워크 문제 등으로 인해 메시지가 유실될 수 있습니다. (정확히 한 번 또는 최소 한 번 전달 보장 X)
    - - 특정 채널을 구독하는 모든 클라이언트에게 메시지가 전달
        
        여러 소비자가 하나의 메시지를 분산 처리하는 소비자 그룹 패턴을 직접적으로 지원하지 않습니다. (Redis Streams는 이 부분을 개선했습니다.)
    - - 소비자가 메시지 처리 중 실패하더라도, 해당 메시지를 재처리할 수 있는 내장된 메커니즘이 없습니다.
- - - - AWS에서 제공하는 완전 관리형 메시지 큐 서비스
        
        분산 시스템 간의 메시지 교환을 위한 안정적이고 확장 가능한 큐를 제공
    - - 완전 관리형
        
        서버 관리나 스케일링에 대한 걱정 없이 사용할 수 있습니다.
      - 높은 가용성 및 확장성
        
        AWS 인프라를 기반으로 하여 대규모 트래픽을 안정적으로 처리할 수 있습니다.
      - 메시지 영속성
        
        메시지를 큐에 저장하여 소비자가 메시지를 가져갈 때까지 보관합니다.
      - At-least-once delivery
        
        메시지가 최소 한 번은 전달됨을 보장합니다.
      - Dead-Letter Queue (DLQ)
        
        메시지 처리 실패 시 재처리하거나, DLQ로 보내어 분석할 수 있습니다.
    - - 지연 시간
        
        Redis나 RabbitMQ에 비해 메시지 전달 지연 시간이 상대적으로 길 수 있습니다. (초 단위)
      - 비용
        
        사용량에 따라 비용이 발생
      - Pub/Sub 모델의 한계
        
        SQS는 기본적으로 Queue 모델(점대점)에 가깝습니다. Pub/Sub을 구현하려면 SNS(Simple Notification Service)와 SQS를 조합해야 합니다.
  - - - AMQP(Advanced Message Queuing Protocol)를 구현한 오픈소스 메시지 브로커
        
        유연한 라우팅, 메시지 영속성, 다양한 메시지 패턴 지원이 강점
    - - 다양한 메시지 패턴
        
        Pub/Sub, Work Queue, Routing, Topic 등 복잡한 메시지 라우팅 패턴을 지원
      - 메시지 영속성
        
        메시지를 디스크에 저장하여 서버 재시작 시에도 메시지 유실을 방지
      - 메시지 승인(Acknowledgement)
        
        소비자가 메시지를 성공적으로 처리했는지 확인할 수 있으며, 실패 시 재전송할 수 있습니다.
      - 고가용성
        
        클러스터링을 통해 고가용성 및 로드 밸런싱을 제공
      - Mature & Widely Used
        
        오랜 기간 사용되어 안정성이 검증되었고, 커뮤니티 지원이 활발
    - - 운영 복잡성
        
        직접 서버를 설치하고 관리해야 하므로 운영이 복잡할 수 있습니다.
      - 성능
        
        Redis보다는 빠르지 않고, Kafka보다는 처리량이 낮습니다.
  - - - 대용량 실시간 데이터 스트림 처리에 최적화된 분산 스트리밍 플랫폼
        
        메시지 큐보다는 "분산 로그" 개념에 가깝습니다.
    - - 영속성 및 내구성
        
        메시지를 디스크에 저장하고, 설정 가능한 보존 기간 동안 유지
      - 소비자 그룹
        
        여러 소비자가 동일한 토픽의 메시지를 병렬로 처리할 수 있는 강력한 소비자 그룹 기능을 제공
      - 높은 처리량 및 확장성
        
        초당 수백만 건의 메시지를 처리할 수 있으며, 수평 확장이 매우 용이합니다.
      - 재처리 기능
        
        메시지가 영속적으로 저장되므로, 소비자가 언제든지 과거 메시지를 다시 읽어와 재처리할 수 있습니다.
      - 실시간 스트림 처리
        
        KSQL, Kafka Streams 등 스트림 처리 프레임워크와 연동하여 실시간 데이터 분석 및 처리가 가능합니다.
    - - 낮은 지연 시간
        
        메시지 전달 지연 시간이 Redis나 RabbitMQ에 비해 상대적으로 길 수 있습니다. (밀리초 단위)
      - 설치 및 유지보수 비용
        
        리소스 요구사항이 높을 수 있습니다.
      - 운영 복잡성
        
        클러스터 설정 및 관리가 복잡하며, Zookeeper와의 연동이 필요