Redis, RabbitMQ, Kafka를 각각 Message Queue로 사용할 때의 장단점

Message Queue를 신중히 선택해야 하는 이유

MSA 환경에서 비동기로 무언가를 처리하거나, Transaction을 처리하기 위해 많이 쓰이는 방식이 바로 Message Queue를 사용하는 방법입니다. Message Queue, 그거 아무거나 대충 쓰면 되지 왜 신중히 선택해야 할까요?

모든 SW 기술들이 그렇지만, 결국 장단점이 있기 때문입니다. 속도-비용-정합성 사이의 아찔한 줄타기를 이어간 결과, 크게 3가지 선택지가 주어지게 됐는데요. 이 3가지를 비교해 보고 어떤걸 선택해야 할지 알아보겠습니다.

---

Redis의 장단점

아무튼 빠름. 근데 잃어도 알빠?

 

Redis하면 보통 Cache를 떠올리시겠지만, Message Queue의 기능도 지원하기 때문에 Message Queue로도 사용할 수 있습니다.

Redis는 보통의 경우 Memory에 저장되기 때문에 빠릅니다. 하지만 Memory에 저장되기 때문에 잃을 가능성이 언제나 있습니다. 그래서 Cache랑 비슷하게, 빨라야 하지만 중요하지는 않은 데이터에 쓰는게 좋습니다.

---

Kafka의 장단점

겁나 비싸지만 안정성 하나는 보장해 줌

 

Kafka는 기업에서 많이 선택하는 Message Queue입니다. 이 사실에서 짐작하셨듯이 안정성을 위한 여러 장치들이 있습니다. 

우선, Scale-Out이 간편하고, Replication이 되어 있어 장애가 나도 데이터는 유실되지 않습니다. Offset을 관리하고 있어 특정 시점에서 Message를 다시 Consume할 수 있기도 합니다.

하지만 그만큼 복잡하고, 가격이 비쌉니다. DevOps 팀이 따로 없거나 Managed Solution을 쓰지 않는다면 현실적이지 않은 대안입니다.

---

RabbitMQ의 장단점

Redis와 Kafka의 중간?

 

RabbitMQ는 at least once delivery는 지원하지만, Kafka처럼 안정적이지는 않습니다. 또 message transformation, dead-letter queues는 지원하지만, Redis처럼 빠르지는 않습니다.

제 맘대로 Redis와 Kafka의 중간이라고 평가해 보고 싶습니다.

---

요약

---