💡 들어가며
지난 포스팅에서 Kafka에 관해 알아보았다. 카프카는 Pub-Sub 구조의 메시지 큐 서비스를 제공한다고 소개했는데, 이 메시지 큐를 다룰 때 함께, 자주 언급되는 것이 Redis와 RabbitMQ이다. Redis와 RabbitMQ는 정확히 무엇이고 어떤 역할을 하는지, 또 MQ로써 각각은 어떤 공통점과 차이점을 가지는지 알아보자!

---

🎯 메시지 브로커 vs 이벤트 브로커

Redis, RabbitMQ, Kafka와 같이 메시지 기반 전달 기술들을 메시징 플랫폼이라고 부르는데, 메시지 플랫폼은 메시지 브로커 / 이벤트 브로커 2가지 종류로 나눌 수 있다. 메시지 브로커의 대표적인 예가 Redis, RabbitMQ이고 Kafka가 대표적인 이벤트 브로커인 것이다!

여기서 둘은 동작 방식에서 확연히 차이가 있다. 메시지 브로커는 이벤트 브로커로 사용할 수 없지만, 이벤트 브로커는 메시지 브로커로 사용할 수 있다 :D

→ 그래서 Kafka를 얘기할 때에도 메시지 브로커로서 기능한다는 설명이!😊

🧐 그래서, 메시지/이벤트 브로커가 뭔데?

Message Broker 메시지 브로커

Producer가 생산한 메시지를 큐에 저장하고, 저장된 데이터를 Consumer가 가져갈 수 있도록 중간 다리 역할을 해주는 브로커이다. 이는 대규모 메시지 기반 미들웨어 아키텍처에서 흔히 사용되어 왔다.

🔎 메시지 브로커는 어떻게 동작할까?

메시지 브로커를 사용하는 환경에서는 Producer가 메시지를 생성하면, 메시지 브로커 내에서 이 메시지를 어떤 큐에 발송할지 결정하는 Exchange를 하게 되고, 이렇게 큐에 들어간 메시지는 Consumer가 가져가게 된다.

→ Consumer가 메시지를 가져가면 큐에는 더이상 메시지가 남지 않고 사라지는 것이 특징이다.

Event Broker 이벤트 브로커

이벤트 브로커는 Kafka에서 다루었던 것처럼, 메시지 브로커의 큐 기능을 가지고 있으며 추가적으로 이벤트 별 관리가 가능하다. 메시지 브로커와 이벤트 브로커 모두 이벤트를 수신하고, 이것을 소비자에게 전달하는 데에 목적을 두고 있지만 작동 방식에 큰 차이가 있다!

Kafka에서 이미 다루었지만, 메시지 브로커와 비교할 겸 이벤트 브로커의 동작 방식을 짚고 넘어가 보자!

🔎 이벤트 브로커는 어떻게 동작할까?

이벤트 브로커는 메시지 브로커와 다르게 이벤트가 Topic 단위로 Event Streamer에 저장된다. Producer가 이벤트를 생성하면, Topic에 따라 분류되어 순서대로 기록된다. 그 후 해당 Topic을 구독한 Consumer가 이벤트를 가져가서 처리하는 방식이다.

→ 이벤트 브로커는 Producer가 생산한 이벤트를 처리한 후 바로 삭제하지 않는 것이 가장 큰 차이점이다!
이벤트를 처리 후 바로 삭제하지 않으므로, 이벤트를 처리한 후 장애가 발생했을 때 특정 시점의 이벤트부터 다시 접근할 수 있다. 장애가 어디에서 났는지 알 수 있으며, 장애 포인트에 찾아가서 장애 재처리도 가능하다.

이는 대용량 데이터 스트리밍의 처리 능력을 가지고 있다.

---

💡
이렇게 메시징 플랫폼은 크게 메시지 브로커, 이벤트 브로커로 나눌 수 있다는 사실과 각각의 간략한 개념, 그리고 이번에 알아볼 Redis / RabbitMQ는 메시지 브로커에 해당한다는 것을 알았다. 이제 Redis와 RabbitMQ에 관해 하나씩 파헤쳐보자!

아, 한 가지 짚고 넘어갈 것은, 서론에서는 Redis를 메시지 브로커로서 소개했으나 Redis는 메시지 브로커가 아닌 다른 용도로도 다양하게 사용되는 하나의 DBMS이다! 혼동하지 말고, 우선 Redis 그 자체의 개념에 관해 모두 알아본 뒤 메시지 브로커로서의 Redis도 다루어 보자 :>

---

📮 Redis : Remote Dictionary Server

레디스는 Remote Dictionary Server의 약자이다. 직역하면 Remote 원격의, Dictionary 사전 (key-value) 구조 Server 서버, 즉 key-value 구조를 가지는 외부의 서버이다. 이는 한 마디로 정의하면 key-value 형태로 데이터를 저장하고 관리하는 비관계형 DB이다!

레디스는 앞서 언급했던 것처럼 메시지 브로커 뿐만 아니라 DB, 캐시의 역할도 한다. 이는 인메모리 데이터 구조를 가지고 있다는 것이 가장 큰 특징이다!

🚀사실 Redis는 개념은 몰라도 들어봤어! : 쿠팡
2019년 7월, 쿠팡에서 모든 물품이 품절로 표시되는 큰 이슈가 있었는데, 이 문제는 RedisDB 때문이라고 밝혀졌다.

레디스는 당시 Key값을 Int로 사용했는데, 쿠팡에서 사용하던 RedisDB의 key 개수가 32bit 최대 정수 값인 2147483647을 넘어서 발생한 문제였다! (이후 Int -> Long으로 변경되었다.)

Redis의 등장

Redis 하면 항상 캐싱의 개념이 따라 붙는다.

캐시는 간단히 말하자면, 특정 데이터에 대한 요청을 빠르게 처리하기 위해 임의의 저장공간에 데이터를 두는 것으로, 저장소에 접근할 필요 없이 데이터를 받아올 수 있어 처리 속도가 향상된다.

레디스는 "DB에 저장하던 정보를 캐시처럼 Main Memory에 두어 쉽고 빠르게 접근하자!" 라는 생각에서 등장했다. 더 자주 접근하고 덜 자주 바뀌는 데이터를 DB 대신 메인메모리에 저장하는 형태를 In-memory DB라 부르고, 그 대표적인 예가 Redis인 것이다! :>

---

Redis 특징 및 장단점

성능

Redis는 데이터를 인메모리에 저장하므로, 당연히 디스크에 비해 훨씬 빠르게 작업을 수행할 수 있다! 또한 key-value 형식으로 데이터가 저장되기 때문에 (연속적인 데이터 검색이 불필요하므로) 보다 빠르게 데이터에 접근할 수 있다.

다양한 데이터 타입 지원 (Redis 컬렉션)

Redis는 Key에 다양한 Collection을 지원한다! 위 사진 자료처럼, Key에 String, Hash, List, Set, Sorted Set과 같은 자료를 다양하게 사용할 수 있다. 이로써 개발 편의성을 극대화할 수 있다!✨

휘발성 / 영속성 보장

앞서 Redis는 Main Memory에 데이터를 저장한다고 했으며, 이는 휘발성을 가지는 것이 특징이다. 따라서 서버가 종료되거나 재시작되면 데이터가 모두 손실된다.

그러나 Redis를 사용하더라도 영속성을 보장해야 하는 경우가 필요한데, 이를 위해 Redis는 RDB와 AOF를 지원하여 영속성을 보장한다!👍

✅ RDB? AOF?
RDB 방식은 Snapshotting 방식이라고도 부르며, 순간적으로 메모리에 있는 내용 전체를 디스크에 담아 영구 저장하는 방식이다.

반면 AOF 방식은 Append On File의 약자로, 말 그대로 데이터가 변경되는 이벤트가 발생하면 이를 모두 로그에 저장하는 방식이다. 이는 모든 데이터의 변경 기록을 보관하고 있기 때문에 데이터를 유실할 가능성이 적다는 장점이 있으나, 같은 이유로 인해 RDB에 비해 파일 크기가 크고 속도가 느리다는 단점이 있다.

RDB, AOF 두 방식 각각의 장단점이 있지만, 간단하게 어떤 방식을 사용할지에 대해 설명하면 다음과 같다.

• RDB + AOF : 하드 디스트 DB와 같은 제일 강력한 내구성이 필요할 경우
• RDB만 사용 : 장애 발생 시, 백업은 필요하지만 어느 정도의 데이터 손실이 발생해도 괜찮은 경우
• AOF만 사용 : 장애 발생 직전까지 모든 데이터가 보장되어야 할 경우

Single Thread 방식

Redis는 단일 스레드이기 때문에, 1번에 1개의 명령어만 실행할 수 있다.
따라서 Atomic(원자성)을 보장할 수 있으며, 멀티 스레드를 사용하면서 발생하는 컨텍스트 스위칭과 메모리 사용을 줄일 수 있어 빠르게 응답할 수 있다.

그러나 당연히 다중 처리나 동시성이 요구되는 작업에는 적합하지 않다. 여러 개의 CPU 코어를 활용하여 병렬 처리를 할 수 없는 한계가 있다. 따라서, 하나의 요청이 병목되면 그 다음 요청들이 계속 밀리게 되므로 복잡도가 O(n)인 명령어의 사용은 주의해야 한다.

*원자성 : 하나의 작업(작업 단위)이 중간에 끊기지 않고 완전히 수행되거나 전혀 수행되지 않음을 보장하는 성질

Pub/Sub

Redis는 Pub - Channel - Sub 구조를 갖고 있다.
publisher가 Channel에 메시지를 발행하면 해당 Channel을 구독하는 Subscriber들에 메세지를 전송한다.
이 기능은 실시간 채팅, 실시간 스트리밍, 실시간 알림, SNS 피드 등에 사용할 수 있다.

---

Redis 사용 시 주의할 점

O(n) 시간복잡도 명령어 사용 금지

Redis는 단일 스레드로 동작하기 때문에 시간 복잡도를 고려해야 한다.
단일 스레드로서 동시에 단 1개의 명령어만 처리할 수 있다 했다. 그렇기 때문에, 하나의 명령어를 처리하는 속도가 오래 걸릴 경우 나머지 명령어들은 모두 대기 상태로 전환되는데, 데이터의 수가 많은 경우 큰 속도 저하를 야기할 수 있다.
따라서, 특히 O(n)의 시간복잡도를 갖는 대표적인 명령어들(key, flushAll, flushDB, delete collections, get all collections)는 운영환경에서 사용을 금지한다!

메모리 관리

비교적 작은 공간에 빠르게 접근하는 In-memory 특성 상 메모리 단편화 문제가 발생할 수 있다. 이는 메모리를 할당받고 반환하는 과정에서 필수적으로 발생하며, 그 정도가 심할 경우 Process가 Memory에 올라가지 못하고 죽어버리는 경우가 발생할 수 있다.
따라서 Redis를 사용할 때에는 메모리 공간을 적당히, 여유 있게 사용해야 한다!😎

메시지 브로커로서의 Redis

이번 글에서는 Redis와 RabbitMQ를 함께 알아보는 것이 목표이므로, Redis에서는 메시지 브로커의 얘기가 가장 중요한 부분이 되겠다!

이전에 다루었던 Kafka와 마찬가지로 Redis도 메시지를 다룰 때 Pub-Sub 구조를 갖춘다. 그런데 하나 유의할 점은, Redis의 Pub-Sub 시스템은 매우 단순한 구조로 되어 있다는 것이다.

메시지 브로커로서의 Redis는 하나의 TV 채널과 같다.

기본적으로 Pub-Sub 구조에서 Publisher는 채널에 구독 신청을 한 모든 Subscriber에게 메시지를 전달한다. 그런데 Redis의 채널은 메시지를 따로 보관하지 않는다. 즉, 수신자(클라이언트 : Subscriber)가 메시지를 받는 것을 보장하지 않아서 subscribe 대상이 하나도 없는 상황에서 메시지를 publish해도 역시 사라진다. 즉, 일반 메시지 큐와 달리 수신 확인을 하지 않아 전송이 보장되지 않는다!⚡

간단히 정리하자면, 메시지를 보내는 쪽도 보내고 끝, 받는 쪽도 받고 끝으로 아주 심플한 구조이다!✨

💡
이렇게 단순한 기능만 제공하는데 메시지 브로커로서 장점이 있을까?

🥕!! Redis가 높은 입지를 다진 데에는 다 이유가 있다.
웹소켓을 이용할 경우 추가적인 네트워크 통신이 필요하기에 레이턴시가 약간 생길 수 있다. 반면 Redis는 In-Memory 기반이기에 매우 빠르게 메시지를 받을 수 있다는 장점이 있다. 따라서, 다음의 경우에 Redis를 이용하는 것이라면 괜찮다!

• 현재 접속 중인 클라이언트들에게 짧고 간단한 메시지를 빠르게 보내고 싶을 때
• 전송된 메시지를 따로 저장하거나 수신 확인이 필요 없을 때
• 전송 보장은 하지 않아도 되는 데이터를 보낼 때

---

✍️
Redis에 관한 내용이 상당히 길고 방대했다...! 잠깐 머릿속을 정리해 보자:)

메시징 플랫폼은 크게 메시지 브로커 / 이벤트 브로커로 나눌 수 있었고, 전에 알아본 Kafka가 이벤트 브로커, 오늘 알아볼 Redis/RabbitMQ가 메시지 브로커에 해당했다.

Redis는 key-value로 데이터를 저장하고 관리하는 비관계형(NoSQL) DBMS로서, 메시지 브로커 뿐만 아니라 DB, 캐시 등의 역할도 하며, 인메모리 구조를 가진다. 메시지 브로커로서의 Redis는 일반적인 메시지 브로커와 달리 메시지 전송을 보장하지 않는다는 특징도 알 수 있었다!✨

Redis에 관한 개념을 잡았으니, 이제 또 다른 메시지 브로커인 RabbitMQ에 관해서도 파헤쳐보자 :D

---

🐰 RabbitMQ

RabbitMQ란?

: AMQP를 따르는 오픈소스 메시지 브로커!

RabbitMQ는 주로 다음과 같은 경우에 사용한다.

• 메시지를 많은 사용자에게 전달할 때
• 요청에 대한 처리 시간이 길어서 해당 요청을 다른 API에게 위임하고 빠른 응답을 할 때

AMQP?
AMQP 수신 확인 모델
: AMQP는 네트워크에 문제가 발생하거나 요청을 처리하지 못했을 경우를 대비해 2가지 수신 확인 모델을 가진다.

• Consumer가 메세지를 받으면 브로커에게 통지하고, 브로커는 통지를 받았을 때만 queue에서 해당 메세지 삭제
• 브로커가 메세지를 전달하면 자동으로 삭제

RabbitMQ 주요 개념

RabbitMQ의 구조나 동작방식을 이해하기 위해서는, 몇가지 개념에 대한 이해가 필요하다! 하나씩 차근차근 짚어보자 :>
(Kafka에서 다루었던 내용이라도 함께 정리함!)

아래의 그림을 기준으로 살펴보자!
기본적으로 지금까지 봐온 Kafka, Redis와 동일하게 Pub-Sub 구조를 가지는 것을 확인할 수 있다.

• Producer : 메시지를 생성해서 보내는 주체이다. Pub-Sub 구조에서 Publisher에 해당한다. 이 메시지는 Queue에 저장이 되는데, 주의할 점은 RabbitMQ에서 Producer는 Queue에 직접 접근하지 않고, 항상 Exchange를 통해 접근한다는 것이다!😎

• Consumer : 최종적으로 메시지를 받는 주체이다. Consumer는 Queue에 직접 접근해서 메시지를 가져온다.

• Queue : Producer들이 보낸 메시지들이 보관되는 장소이며, Consumer가 소비하면 메시지가 사라진다. Queue는 이름으로 구분된다.

• Exchange : Producer들에게서 전달받은 메시지들을 어떤 Queue에게 보낼지 결정하는 객체이다. 일종의 라우터라고 이해하면 편하겠다. Exchange는 네 가지의 타입이 있는데, 이는 아래에서 자세히 다뤄보자!

• Binding : Exchange와 Queue를 연결하는 관계이다. 모든 메시지는 Exchange가 가장 먼저 수신하는데, Exchange 타입과 binding 규칙에 따라 적절한 Queue에 전달된다. binding이 되어 있어야 Exchange가 Queue에게 메시지를 전달할 수 있다.

→ Exchange는 규칙으로 어떻게 라우팅이 될지 결정하는 것이라면, Binding은 결정된 메시지를 어떤 Queue에게 전달할지 라우팅할 규칙을 결정하는 것이다.

✉️ 메시지 전달의 흐름을 정리해보자면!
Produce가 메시지를 Exchange에게 전달 → Exchange가 Binding에 따라 메시지를 Queue로 라우팅 → Queue에 메시지가 저장 → Consumer가 Queue에서 메시지를 가져가서 처리

Exchange와 Queue의 속성

Excgabge와 Queue는 생성 시 속성을 지정할 수 있다. 어떤 속성이 있는지 짚어보자!

Exchange

• Name : Exchange 이름
• Type : 메시지 전달 방식
  - Direct
  - Fanout
  - Topic
  - Headers
• Durability : 브로커가 재시작될 때 남아있는지 여부
  - Durable : 브로커가 재시작되어도 디스크에 저장되어 남아있음
  - Transient : 브로커가 재시작되면 사라짐
• Auto-delete : 마지막 Queue 연결이 해제되면 삭제

Queue

• Name : Queue 이름
• Durability : 브로커가 재시작될 때 남아있는지 여부
  - Durable : 브로커가 재시작되어도 디스크에 저장되어 남아있음
  - Transient : 브로커가 재시작되면 사라짐
• Auto delete : 마지막 Consumer가 consume을 끝낼 경우 자동 삭제
• Argument : 메시지 TTL, Max Length 같은 추가 기능 명시

RabbitMQ의 4가지 Exchange 타입

1.Fanout Exchange

Fanout은 Exchange에 등록된 모든 queue에게 동일한 메세지를 보내는 방식이다.
→ 전체메세지 같은 것이다!

2.Direct Exchange

Direct는 Routing key를 활용하여 라우팅 하는 방식이다.

🔑 Routing Key 🔑
: 메시지를 특정 큐로 라우팅(전달)할 때 사용하는 식별자이다. 라우팅 키는 Direct와 Topic 방식에서 주로 사용된다. 하나의 큐에 여러 개의 라우팅 키를 지정할 수 있으며, 여러 큐에 동일한 라우팅 키를 지정하는 것도 가능하다.
즉, 라우팅 키를 기반으로 Exchange와 Queue를 1:N으로 바인딩할 수 있다.

다시 말해, Direct Exchange 방식은 Exchange에서 보낸 메시지를 식별자인 routing key를 통해 queue와 직접 잇는(바인딩하는) 것이다.

RabbitMQ에서 Default Exchange는 이름이 없는 Direct Exchange이다. 생성되는 queue가 자동으로 바인딩되며, 이때 rounting key는 각 큐의 이름으로 지정된다.

3.Topic Exchange

Topic은 Routin Key 패턴이 일치하는 큐에 메시지를 전달하는 방식이다.
→ Direct는 라우팅 키가 완전히 같은 큐들에게 메시지를 전달하는 방식이라면, Topic은 특정 패턴만 일치하면 해당 큐들에게 메시지를 전달하는 방식!👍

라우팅 키 패턴의 규칙

• * : 단어 1개를 대체
• # : 0개 이상의 단어를 대체

4.Headers Exchange

Header는 key-value로 정의된 헤더에 의해 메시지를 queue에 전달하는 방식이다.
producer쪽에서 정의하는 header의 key-value와 consumer쪽에서 정의된 argument의 key-value가 일치하면 바인딩이 된다.

Producer에서 정의하는 헤더는 메시지와 함께 전송되고, Consumer쪽에서는 exchange와 queue가 바인딩되는 시점에 argument를 정의한다.

이때 header에는 x-match라는 key가 있으며 값으로는 any 또는 all이 들어갈 수 있다. all의 경우 header의 key-value와 argument의 key-value가 정확히 일치해야 바인딩되며, any의 경우 header의 key-value와 argument의 key-value 사이에 하나라도 일치하는 것이 있으면 바인딩된다.

---

🌟 Redis와 RabbitMQ 비교&정리!

기본 개념

• Redis : key-value 형태로 데이터를 저장하고 관리하는 비관계형 DB, 메시지 브로커 뿐만 아니라 DB, 캐시의 역할도 한다.
• RabbitMQ : 오픈소스 메시지 브로커

이벤트 저장

• Redis : 저장하지X. 심지어 channel에 이벤트가 도착했을 때 해당 채널의 subscriber가 존재하지 않으면 이벤트 사라진다.
• RabbitMQ : 메세지가 성공적으로 전달되었다고 판단될 경우 메세지가 큐에서 삭제되기 때문에 재처리가 어렵다.

---