[프로젝트/기술적 의사결정] Kafka vs RabbitMQ, 대규모 트래픽 상황에 맞는 메세징 시스템 선택

요구 사항

사용자들이 주문 api 요청을 할 때, 사용자 트래픽이 몰리는 상황에서도 안정적인 주문 처리가 필요했다. 주문이 완료되면 재고를 차감하는 기능이 필요했고, 이때 효율적으로 주문을 처리하고 트래픽을 관리하기 위해 메시징 시스템을 도입하기로 결정했다.

 

기술 선택지

1. RabbitMQ
2. Kafka

 

선택한 기술 및 근거

두 가지 기술 선택지 중, 어떤 시스템이 더 적절한지 검토할 때 아래와 같은 상황을 고려했다.

▪️트래픽 처리 능력 : 높은 동시 요청 상황에서의 안정성이 필요하다.
▪️메세지 전달 보장 : 주문이 실패 없이 처리되어야 하며, 중복 주문이나 데이터 손실을 방지해야 한다.
▪️재고 관리 : 주문이 완료되었을 때 재고를 정확히 차감해야 한다.

 

이제 각 기술 선택지를 비교해보면서 결론을 내려보자.

 

 

1. RabbitMQ

적용 가능성

🔻 실시간 주문 처리
RabbitMQ는 빠르고 실시간으로 메시지를 처리하는 데 적합하며, 트래픽이 몰리는 순간에도 메시지 큐로 유입된 주문을 순차적으로 처리할 수 있다.

🔻 메세지 전송 보장
At-least-once 전송 모델을 통해 중복 주문을 방지하고, 실패 시 다시 시도할 수 있는 메커니즘을 제공할 수 있다.

🔻 단일 이벤트 처리
RabbitMQ는 주로 단일 이벤트 처리 (하나의 소비자가 메시지를 읽고, 처리가 끝나면 큐에서 삭제)하는 상황에서 적합하므로, 예약 구매 주문과 같은 개별 요청 처리에 유리하다.

 

한계점

대용량 트래픽 처리에서 RabbitMQ는 Kafka에 비해 확장성이 부족할 수 있다.

메시지가 처리된 후 삭제되므로, 만약 로그 기반의 주문 데이터 분석이나 장기 데이터를 저장해야 하는 경우에는 적합하지 않을 수 있다.

 

---

2. Kafka

적용 가능성

🔻대용량 트래픽 처리에 유리
Kafka는 수평 확장이 용이하며, 수백만 개의 메시지(주문)를 동시에 처리할 수 있어 트래픽 폭주 상황에서 안정적인성능을 발휘할 수 있다.

🔻재고 관리와 이벤트 소싱
Kafka는 이벤트 소싱 패턴에 적합하여, 각 주문 이벤트를 로그로 남겨두고 다양한 소비자가 이를 처리할 수 있다. 재고 감소와 같은 작업도 이벤트 기반으로 처리할 수 있다.

🔻중복 데이터 처리
Kafka는 중복 메시지 처리가 필요할 때 추가적인 설정을 통해 Exactly-once 메시지 전달을 보장할 수 있다.

🔻장기 데이터 보관
주문 이력을 로그로 저장하여 장기적으로 분석 및 재처리가 필요한 경우에도 적합하다.

 

한계점

RabbitMQ에 비해 구현 복잡성이 더 높을 수 있으며, 빠른 응답성이 필요한 소규모 실시간 시스템에서는 과할 수 있다.

Kafka는 메시지가 디스크에 저장된 후 처리되기 때문에 RabbitMQ보다는 약간의 지연 시간이 발생할 수 있다.

 

결론

 

초기 기획한 프로젝트 시스템은 트래픽이 어느 정도 있다는 가정 하에 기획 및 구현을 진행했다.

 

Kafka는 대규모 트래픽이 발생할 경우에도 RabbitMQ 보다 메세지 전송 용량이 우수하기 때문에 비교적 안정적으로 메세지를 처리할 수 있다. (즉, 주문 시 재고 관리를 안정적으로 처리할 수 있다는 말)

 

또한 이벤트 소싱을 활용해서 주문 처리 이력을 장기적으로 관리할 수 있고, 주문 데이터를 분석하거나 장기 보관할 필요성이 있다고 판단해서 초기 구현 복잡성이 높더라도 Kafka를 선택해서 진행하기로 결정했다. (고객의 주문 처리 이력은 고객 분석과 마케팅에도 사용될 수 있는 중요한 데이터일 것이다)

 

---

References

https://aws.amazon.com/ko/compare/the-difference-between-rabbitmq-and-kafka/

https://junuuu.tistory.com/786

https://www.youtube.com/watch?v=UNUz1-msbOM