RabbitMQ와 Redis의 차이점은 무엇인가요?
RabbitMQ는 메시지 브로커이며, 원격 사전 서버(Redis)는 인 메모리 키-값 데이터 스토어입니다. 하지만 두 기술 모두 게시/구독(pub/sub) 메시징 시스템을 구축하는 데 사용할 수 있으므로 두 기술을 비교할 수 있습니다. 최신 클라우드 아키텍처에서는 애플리케이션이 서비스라고 불리는 더 작고 독립적인 빌딩 블록으로 분리됩니다. 게시/구독 메시징은 이러한 분산 시스템을 위한 즉각적인 이벤트 알림을 제공합니다. RabbitMQ는 여러 소스에서 스트리밍 데이터를 수집하고 처리를 위해 다른 대상으로 라우팅하는 분산 메시지 브로커입니다. Redis는 이벤트 발생 시 게시자가 모든 구독자에게 메시지를 배포하는 푸시 기반 시스템을 지원합니다.
작동 방식: RabbitMQ와 Redis
RabbitMQ와 Redis를 사용하면 애플리케이션, 마이크로서비스 및 소프트웨어 구성 요소가 다양한 방식으로 메시지를 교환할 수 있습니다.
RabbitMQ 워크플로
RabbitMQ는 Advanced Message Queuing Protocol(AMQP)을 사용하여 메시지 브로커를 통해 안전하게 메시지를 전송합니다. 메시지 브로커는 교환과 대기열로 구성됩니다. 프로세스는 다음과 같이 작동합니다.
- 데이터 생산자가 RabbitMQ에 메시지를 전송합니다.
- 교환은 바인딩이라는 일련의 규칙에 따라 데이터를 수신하고 해당 대기열로 라우팅합니다.
- 메시지는 RabbitMQ 소비자가 수신할 때까지 대기열에 상주합니다.
대기열이 최대 용량에 도달하면 RabbitMQ는 읽지 않은 메시지를 소비자가 처리할 때까지 생산자가 메시지를 게시하지 못하게 합니다. 또한 RabbitMQ는 소비자가 메시지를 읽기 전에 교환이 실패할 경우 메시지를 복원할 수 있습니다.
Redis 워크플로
Redis는 목록, 세트, 해시 및 비트맵과 같은 다양한 데이터 구조를 지원하는 데이터 구조 서버로 설계되었으며, 클라이언트 애플리케이션이 거의 모든 데이터 유형을 저장, 검색 및 처리할 수 있게 합니다. Redis는 저장된 데이터를 키-값 페어로 구성하여 구독 클라이언트 애플리케이션을 위한 구조화된 배열을 제공합니다.
예를 들어 전자 상거래 데이터를 고객 이름, 이메일, 구매한 품목 및 피드백 키로 분리할 수 있습니다. 그런 다음 각 키별로 관련 데이터를 게시합니다.
Redis를 사용하면 짧은 보존 메시지를 실시간으로 교환할 수 있습니다. Redis는 다음과 같이 작동합니다.
- 데이터 생산자가 Redis에 메시지를 전송합니다.
- Redis 노드가 메시지 키를 검사하여 관심 있는 구독자를 식별합니다.
- Redis가 연결된 모든 구독자에게 메시지를 전송합니다.
메시지 처리 방식: RabbitMQ와 Redis 게시/구독
Redis와 RabbitMQ는 모두 애플리케이션이 클라우드 환경 전체에 메시지를 배포할 수 있도록 게시-구독(pub/sub) 메커니즘을 제공합니다. 하지만 메시지 처리 방식은 크게 다릅니다.
메시지 전송
RabbitMQ는 Advanced Message Queuing Protocol(AMQP)을 사용하여 복잡한 라우팅 로직을 지원합니다. 지점 간에 메시지를 전송하거나 단일 생산자의 메시지를 여러 소비자에게 전송할 수 있습니다. 어떤 방법을 사용하든 모든 소비자는 읽기가 성공했는지 확인하기 위해 생산자에게 메시지 승인을 보냅니다. 생산자가 확인을 받지 못하면 다양한 간격으로 여러 번 재시도합니다.
반면, Redis는 단순히 연결된 모든 구독자에게 메시지를 푸시할 뿐, 메시지 전송을 보장하지는 않습니다. 들어오는 메시지를 수신하려면 구독자가 Redis 서버에 연결되어 있어야 합니다. Redis의 연결이 끊어지면 모든 메시지를 검색하지 못할 수 있습니다.
메시지 크기
RabbitMQ는 큰 성능 저하 없이 크기가 큰 메시지를 전송할 수 있습니다. 처음에는 최대 2GB 크기의 메시지를 처리하도록 설계되었지만, 나중에는 128MB로 제한되었습니다.
반대로 Redis는 저장되는 메시지에 대한 한도를 정의하지 않지만, 1MB를 초과하는 메시지의 경우 상당한 지연 시간이 발생합니다. 따라서 개발자는 일반적으로 Redis를 캐시로 사용하여 문자열, 해시, 목록 및 세트와 같은 데이터 세트를 처리합니다.
메시지 지속성
RabbitMQ는 영구 메시지와 임시 메시지를 지원합니다. 영구 대기열에 메시지를 전송할 경우, 데이터가 도착하자마자 영구 스토리지에 데이터를 씁니다. 또한 RabbitMQ는 메시지가 메모리 용량을 초과하는 경우에만 임시 메시지를 디스크에 씁니다.
반면, Redis는 기본적으로 영구 메시지를 지원하지 않습니다. 개발자는 Redis Database(RDB)라는 기능을 활성화하여 RAM의 주기적인 스냅샷을 생성하고 디스크에 저장해야 합니다. Redis에서 데이터 지속성을 활성화하면 데이터 작업의 오버헤드가 가중되어 메시지 전송 속도가 느려집니다. 또 다른 대안은 비동기 복제와 같은 복구 기술을 사용하는 것입니다.
메시지 암호화
RabbitMQ는 SSL을 사용하여 생산자, 브로커 및 소비자 간에 전송되는 데이터를 암호화합니다. 메시지 암호화는 조직이 기밀 정보를 보호하고 데이터 위험을 줄이는 데 도움이 됩니다.
반면 Redis는 SSL을 기본적으로 지원하지 않고, Redis 버전 6.0 이상에서만 SSL을 지원합니다. SSL을 활성화하려면 개발자가 Redis 클러스터에서 SSL 인증서를 가져와 데이터베이스에 대한 클라이언트 인증서를 생성해야 합니다.
성능: RabbitMQ와 Redis 게시/구독
메시지 처리 방식의 차이는 다양한 시나리오에서 RabbitMQ와 Redis의 성능에 영향을 미칩니다.
속도
Redis는 주로 메모리에서 메시지를 처리하므로 RabbitMQ보다 훨씬 빠릅니다. 하지만 Redis 서버에 장애가 발생하면 읽지 않은 메시지가 손실될 위험이 있습니다.
반대로 지속 모드에서 작동하는 경우 RabbitMQ는 다음 메시지를 보내기 전에 각 소비자의 승인을 기다립니다. 또한 RabbitMQ는 메시지를 디스크에 저장하는 데 시간이 더 걸리므로 평균적인 메시지 교환 속도가 더 느립니다.
Redis는 초당 최대 수천만 개의 메시지를 전송할 수 있는 반면, RabbitMQ는 초당 최대 수만 개의 메시지만 처리할 수 있습니다.
가용성
메시지 브로커 시스템이 노드를 복제할 수 있도록 하는 클러스터링은 RabbitMQ와 Redis에서 서로 다른 방식으로 처리됩니다.
RabbitMQ의 경우 관련 데이터와 함수를 포함하는 다중 노드가 클러스터에 복제됩니다. 하지만 메시지 대기열은 피어 관계를 공유하는 이러한 노드 간에 복제되지 않습니다. 이를 위해 개발자는 복제를 지원하는 특수한 메시지 대기열을 사용합니다.
반면, Redis 클러스터는 특정 버전 이상의 Redis에서 도입된 기능입니다. 각 리더 노드의 데이터를 하나 또는 여러 개의 팔로워에 복사합니다. 리더 노드에 장애가 발생하면 팔로워가 대신 고가용성 메시지 전송 기능을 제공합니다.
사용 사례: RabbitMQ와 Redis 게시/구독
RabbitMQ는 많은 영역에서 Redis를 능가하지만, 그렇다고 해서 RabbitMQ가 모든 애플리케이션에 더 나은 메시지 배포 시스템이라는 의미는 아닙니다.
Redis는 실시간 데이터 처리 및 지연 시간이 짧은 캐싱이 요구되는 엔터프라이즈 애플리케이션에서 더 뛰어난 성능을 제공합니다. 인 메모리 데이터 스토어와 다양한 데이터 구조를 지원하는 Redis는 저수준 데이터 계산을 수행하는 데 적합합니다. 예를 들어 금융 기관은 Redis를 사용하여 거래 데이터를 캐싱함으로써 실시간 사기 탐지를 지원합니다.
한편, 코드 및 시스템 구축을 지원하는 비동기 통신 메커니즘을 갖춘 전용 마이크로서비스 메시지 브로커가 필요한 경우 RabbitMQ를 선택해야 합니다. 또한 RabbitMQ는 애플리케이션 간에 대용량 파일을 전송하는 데 Redis보다 더 적합합니다. 예를 들어 여러 마이크로서비스 간에 데이터를 안정적으로 전송해야 하는 시스템의 경우 RabbitMQ를 선택할 수 있습니다. 그러면 시스템에서 RabbitMQ의 내결함성, 더 큰 파일 처리 용량 및 보장된 메시지 전송 메커니즘이라는 이점을 얻을 수 있습니다.
차이점 요약: RabbitMQ와 Redis 게시/구독
| RabbitMQ |
Redis |
|
| 메시지 전송 |
메시지 전송을 보장합니다. 복잡한 로직을 지원합니다. |
메시지 전송을 보장하지 않습니다. 구독자의 활성 연결이 필요합니다. |
| 메시지 크기 |
메시지 크기가 128MB로 제한됩니다. 대용량 메시지를 처리할 수 있습니다. |
메시지 한도는 없지만 대용량 메시지(1MB 이상)의 경우 성능이 저하됩니다. |
| 메시지 지속성 |
영구 메시지 및 일시적 메시지를 지원합니다. 영구 메시지를 디스크에 씁니다. |
기본적으로 영구 메시지를 지원하지 않습니다. |
| 메시지 암호화 |
SSL 암호화를 지원합니다. |
SSL 암호화는 Redis 버전 6.0 이상에서 사용할 수 있습니다. |
| 속도 |
초당 수만 개의 메시지를 지원합니다. |
초당 최대 수백만 개의 메시지를 지원합니다 |
| 가용성 |
클러스터에 여러 P2P 노드를 생성합니다. |
클러스터링 시에 리더-팔로워 모델을 사용합니다. |
AWS는 RabbitMQ 및 Redis 요구 사항을 어떻게 지원하나요?
Amazon Web Services(AWS)는 오픈 소스 메시지 브로커 시스템을 대규모로 실행하는 관리형 서비스를 제공합니다. 게시-구독(pub/sub) 서비스를 손쉽게 설정하여 다른 AWS 서비스와 통합할 수 있습니다.
Redis 및 RabbitMQ에 사용할 수 있는 AWS 제품은 다음과 같습니다.
- Amazon MemoryDB for Redis를 사용하면 Redis에서 메시지를 전송할 때 내구성을 높일 수 있습니다. 미디어 및 엔터테인먼트 애플리케이션을 위해 높은 동시성의 스트리밍 데이터 피드를 실행해 사용자 활동을 수집하고 매일 수백만 개의 요청을 지원할 수 있습니다.
- Amazon MQ를 사용하면 시간이 많이 걸리는 설정 작업 없이 RabbitMQ 브로커를 프로비저닝할 수 있습니다. 전송 중이거나 저장된 RabbitMQ 메시지를 암호화하므로, AWS 가용 영역 전반에서 고가용성 데이터 파이프라인을 보장하는 데 도움이 됩니다.
Redis 또는 RabbitMQ 대신 Amazon Simple Notification Service(SNS)를 사용하여 게시/구독 메시징 시스템을 구축할 수도 있습니다. 확장 가능하고 비용 효율적인 방법으로 애플리케이션에서 고객 또는 다른 애플리케이션에 메시지를 직접 전송할 수 있습니다.
Amazon SNS는 다음과 같은 몇 가지 기능을 제공합니다:
- 분산된 시스템, 마이크로서비스 및 이벤트 중심의 서버리스 애플리케이션 간의 스루풋이 높은 푸시 기반의 다대다 메시징
- 메시지 암호화 및 트래픽 프라이버시
- 분석, 컴퓨팅, 컨테이너, 데이터베이스, 사물 인터넷(IoT), 기계 학습, 보안, 스토리지와 같은 AWS 카테고리 전반에 걸친 팬아웃 기능
지금 바로 계정을 만들어 AWS에서 게시/구독, Redis 및 RabbitMQ를 시작하세요.
