[RabbitMQ] RabbitMQ 도입

Kim Hyen Su·2024년 6월 2일

🐰RabbitMQ

목록 보기

1/1

RabbitMQ

개요

Scheduling 관련 요청 시 서버 간의 의존도를 낮추기 위해 메시지 브로커의 도입을 결정했습니다.

이외에도 메시지 브로커 도입 시 장점은 다음과 같습니다.

데이터 유실 방지
수평적 확장 용이

메시지 브로커 중 가장 대표적으로 많이 사용되며 참고할 레퍼런스도 다양한 RabbitMQ, Apache Kafka 2가지 메시징 미들웨어 중 하나를 도입할 예정입니다.

두 플랫폼 기술의 차이점을 보면 다음과 같습니다.

RabbitMQ

메시지 기반의 미들웨어 아키텍처에서 사용되는 메시지 브로커입니다. Producer와 Consumer를 통해 메시지 큐를 거쳐 메시지를 통신합니다. Consumer가 메시지 큐에 있는 메시지를 가져가면 해당 큐 안에서 해당 메시지 정보는 사라집니다.

Kafka

메시지를 보관 시 인덱스를 지정하여 개별 엑세스를 관리합니다. RabbitMQ와 다르게 큐 안에 메시지를 가져가더라도 해당 큐 안에 메시지가 삭제되지 않습니다. 이로 인해서 장애 발생 시점부터 다시 작업을 수행할 수 있습니다.

차이점

RabbitMQ는 메시지를 큐 형태로 저장하고, Kafka는 로그 형태로 저장한다는 차이점이 있습니다.

RabbitMQ의 메시지들은 주로 메모리에 저장되기 때문에 처리가 빠르지만, 유실의 위험성도 있습니다.

반면에, Kafka는 메시지들을 디스크에 로그 형태로 저장합니다. 해당 메시지들은 컨슈밍 된다고 해서 로그에서 지워지지 않습니다.

또한, 해당 로그 데이터들은 각각의 오프셋(인덱스)을 갖는데, 컨슈머들이 자신이 받아간 마지막 오프셋을 기억함으로써 중복 없이 다음 메시지 요청이 가능합니다.

이처럼 오프셋으로 메시지들에게 접근하기 때문에 Kafka는 상대적으로 클러스터링이 쉽지만, RabbitMQ는 컨슈머가 받아간 메시지가 삭제되는 것까지 다른 브로커에 실시간으로 적용되어야 하기 때문에 클러스터링이 어렵습니다.

RabbitMQ를 그럼 왜 쓸까?

RabbitMQ 만의 장점이 있기 때문입니다.

우선, RabbitMQ는 시간이 걸리는 작업을 여러 워커들이 분산 처리하는 작업 큐를 지원합니다. 컨슈머에 있는 워커들이 작업을 하나씩 가져간 다음, 작업 완료시마다 브로커에 신호를 보내어 해당 메시지가 삭제되도록할 수 있습니다.

또한, 메시지 브로커로 메시지를 보내는 방식이 Kafka보다 다양하기 때문에 복잡한 메시징 라우팅이 필요한 서비스의 경우 Kafka보다 유리합니다.

또한, RabbitMQ는 메시지를 성공적으로 처리했는지 여부를 브로커에게 전달함으로써 신뢰성이 있는 전달을 보장할 수 있습니다. 트랜젝션과 같이 안정적인 처리가 필요한 작업에 적합합니다.

결론적으로 Task Scheduling 작업은 적은 데이터량을 안전하게 전달하는 것을 보장해야하는 경우가 많기 때문에, RabbitMQ를 도입할 것을 결정했습니다.

RabbitMQ 이란?

AMQP를 구현한 오픈소스 메시지 브로커입니다.

producer에 의해서 메시지를 메시지 큐에 저장해준 뒤 consumer에 의해서 메시지가 필요 서버로 전달되도록 해주는 중간 매개체입니다.

이 때, Producer와 메시지 브로커, 메시지 브로커와 Consumer 간의 통신은 AMQP를 사용한 프로토콜을 사용합니다.

💡 출처 : https://velog.io/@sdb016/RabbitMQ-%EA%B8%B0%EC%B4%88-%EA%B0%9C%EB%85%90

Producer : 메시지를 메시지 브로커로 전달.

Consumer : 메시지 브로커로부터 메시지를 처리.

Exchange : Producer로 부터 전달받은 메시지를 Binding에 의해 연결된 Queue로 메시지를 복사 및 전달.

Binding : Exchange와 Queue의 관계를 의미.

Queue : Consumer가 메시지를 consuming 할 때까지 보관.

모든 메시지는 Queue로 직접 전달되는 것이 아닌, Exchange를 거쳐서 Queue로 전달됩니다. 이 때, Exchange Type과 Binding 규칙에 따라 적절한 Queue로 전달됩니다.

💡 Exchange Type

Direct Exchange : 메시지에 포함된 routing key 기반으로 Queue로 전달.

Fanout Exchange : routing key 관계없이 연결된 모든 Queue에 동일한 메시지 전달.

Topic Exchange : routing key 전체가 일치하거나 일부 패턴과 일치하는 모든 Queue에 메시지 전달.

Headers Exchange : key:value 형태로 이뤄진 header 값을 기준으로 일치하는 Queue에 메시지 전달.