rabbitmq 를 왜 써야 하는지

프로젝트를 하면서 rabbitmq, activemq 등 뒤에 MQ라고 붙은 단어들을 많이 들어왔다.

 

난 모르니깐 그냥 넘어가야지, 머 그냥 Message Queue 아닌가 하고 넘어갔는데 

 

이번에 발표 준비를 하면서 한번 제대로 해보자라는 마음이 생겼다. 

 

 

일단 카카오 메시징 서버 직군에서 지원 자격중에 MQ에 대한 경험이 들어가 있다. 

 

엄청난 트레픽을 받는 네이버 웹툰에서도 웹 서비스 인프라 이해 쪽에 Message Queue에 이해를 원하는 

 

자격 요건도 볼 수 있다. 

 

이 두가지 사례만 봐도 Mq에 대한 이해는 선택이 아닌 필수로 다가 오고 있다.

 

어차피 알아두어야 할 기술 확실히 알아 두자.

 

* rabbitmq가 필요한 이유

     기존 상태의 문제점 

         -> 애플리케이션과 강하게 결합되어 있으면 db서버가 응답할 때 까지 기다려야 한다.

         -> db 장애시 애플리케이션에도 장애가 발생한다. 

  

   

     mq 를 이용하면 애플리케이션의 의존성을 제거 할 수 있다. 

       -> 느슨하게 결합된 설계

       -> 애플리케이션 아키텍처는 더 이상 데이터 베이스 쓰기 성능에 영향을 받지 않는다.

    

        1. 느슨하게 결합 구조의 애플리캐이션은 rabbitmq에 메시지를 발행한다.

        2. 구독하고 있는 소비자에게 메세지를 전달한다. 

        3. 소비자가 처리해야할 양이 많아지면 소비자 애플리케이션의 처리량을 제어하거나 중지한다. 

 

 

       메세지를 발행하는 애플리케이션은 변동 없이 이전과 같은 방식으로 데이터를 발행한다. 

       rabbitmq는 소비자를 추가해서 메세지를 전달한다. 

       새로 추가한 소비자에게 메시지를 발행하는 애플리케이션을 수정 할 필요가 없다.

 

 

 

* 추가로 Federation 플러그인을 사용하면 다른 데이터센터의 rabbitmq 서버 또는 클러스터를 쉽게 추가할 수 있다.