RabbitMQ

개요

마이크로서비스 설계(또는 모듈러 설계라고도 불림)에서 각각의 모듈들은 독립되어 있습니다.

이러한 모듈은 완성된 소프트웨어 어플리케이션을 구성하거나, 독립된 동작이나, 인터페이스 같은

다양한 기능을 제공해줍니다.

큰 덩어리의 기능이 존재하는 하나의 모듈로 이루어진 단일 어플리케이션과는 다르게

마이크로서비스 어플리케이션은 기능들을 각각 다른 모듈로 분리시켜서 유지보수성과 사용의 쉬움을 증가시킵니다.

이제 대부분의 기업과 조직들이 마이크로서비스를 이용하는 숫자가 늘고 있는데,

소프트웨어 개발에 있어서 애자일(agile) 방식을 가능하게 하고, 유지보수성에 용이하기 때문입니다.

또한 마이크로서비스는 매주 업데이트가 되는 소프트웨어에서 업데이트도 용이하다는 장점이 있습니다.

마이크로서비스 설계의 장점

개발과 유지보수를 쉽게 만들어 준다.

만약 여러분이 인증 , 허가 ,부여 , 트랜잭션 기록 및 부여 등을 포함하는 큰 어플리케이션을 만든다고 가정해봅시다.

여러 개의 서비스로 어플리케이션을 나눈다면, 책임을 분리할 수 있고, 또한 개발자에게 특정한 서비스에만

코드를 집중할 수 있게 됩니다.

오류를 격리 시킬 수 있다.

또 다른 마이크로 서비스의 장점은 오류를 격리시켜준다는 것이다.

예를 들어 트랜잭션을 기록하는 서비스가 다운이 되었고, 다른 서비스는 계속 살아 있다면,

서비스를 계속 유지시킬 수 있습니다

생산성의 증가

MicroService는 관리하기 쉬운 모듈과 유지 보수가 쉬운 기능으로 애플리케이션을 분할하는 것입니다.

서로 다른 개발자들이 서로 다른 모듈을 같은 시간에 개발할 수 있습니다.

게다가 테스트의 속도도 증가하기 때문에, 전체적인 시스템을 읽을 필요 없이 각각의 모듈을 테스트 할 수 있습니다.

확장성의 향상

마이크로서비스는 또한 효과적으로 확장을 하게해줍니다. 만약 하나의 새로운 컴포넌트를 하나의 서비스에 추가 했다면,

다른 시스템은 바꿀 필요없이 변경이 가능합니다.

이해하기가 쉽다.

하나의 모듈은 하나의 기능을 나타내기 때문에, 관련있는 세부사항을 알기가 쉽습니다.

예를들어, 인증서비스를 위해 컨설턴트를 고용했다면, 그 컨설턴트는 모든 시스템에 대해 알 필요가 없습니다.

컨설턴트는 그저 하나의 모듈에만 익숙해지면 됩니다.

마이크로서비스 설계에서 message queue의 역할은?

전형적인 마이크로서비스 설계에서는, 하나의 서비스는 다른 서비스의 도움 없이는 자신의 기능을 수행하지 못하는 상호 의존성인 존재입니다.

응답에 의해 막힐 일 없이(without getting blocked by responses)서비스들이 계속 통신해야 하는 메카니즘을 가진

시스템에서는 굉장히 중요합니다.

Message queue는 비동기적으로 서비스에세 메시지를 푸시 해주고 올바른 목적지에 전달해주는 수단의 목적으로 사용합니다.

메세지 큐를 구현하기 위해서는 메세지 브로커(message broker)가 필요합니다.

우체국에서 우편을 배달하시는 우체부님들이라고 생각하면 됩니다.

그렇다면 RabbitMQ는 무엇일까요?

메시지 큐는 프로세스,어플리케이션 과 서버 사이에서 데이터를 교환하는 방법이며,

이는 마이크로 서비스 설계에서 중요한 모습을 보여주고 있습니다.

RabbitMQ는 가장 많이 사용되고 있는 메세지 브로커이며 스타트업이나 큰 회사 같이 전세계적으로 35,000개의

제품에 사용되고 있습니다.

RabbitMQ는 메세지브로커 또는 큐 매니저라고 불리는 메세지 큐 소프트웨어 입니다.

간단하게 말하자면 큐가 정의되어 있고, 큐가 어플리케이션에 연결되어 있고, 그 큐를 통해 메세지를 전달합니다.

메세지 큐는 메세지를 만들고,받는 다른 애플리케이션에게 직접적으로 통신하기 보다는

메세지 큐와 상호작용하는 비동기 통신을 합니다.

메세지는 아무정보나 가능합니다. 다른 어플리케이션에서 시작할 프로세스 정보에 대한 것도 가능하고,

아니면 그저 심플한 텍스트 메세지도 가능합니다.

rabbitmq

교환(Exchanges)

메세지는 직접적으로 큐에 들어가지 않고, 메세지 생산자(producer)가 메세지를 교환소(Exchange)에게 보내줍니다.

교환소는 각각의 다른 큐에 메세지를 라우팅하는 책임을 갖고 있습니다.

교환소의 작업은 생산자(producer)로부터 오는 메세지를 받고, 적절한 메세지 큐에 라우팅을 해주는 역할입니다.

교환소는 바인딩(binding) 라우팅 키(routing key)의 도움을 받습니다.

바인딩(binding)은 큐와 교환소 사이의 연결을 말합니다.

RabbitMQ 안에서 메세지 흐름

1. 메세지 생산자는 교환소에게 메세지를 전달하비다.. 교환소를 생성할때는 타입을 지정해줘야 합니다.

2. 교환소는 메세지를 받으면, 메세지를 라우팅할 책임이 있습니다.. 교환소 타입에따라 메세지의 속성과 키를 분류합니다.

3. 이번 예제에선, 교환소에 두개의 다른 큐로 두개를 바인딩합니다. 교환소는 메세지를 속성에 따라 적절한 큐에 넣어줍니다.

4. 메세지는 컨슈머(consumer)가 건들때까지 큐에 남아 있습니다.

5. 컨슈머가 메세지를 건들면 큐에서 삭제합니다.

RabbitMQ 안에서의 메세지 흐름

교환소의 타입들

• Direct : 다이렉트 교환소(direct exchange)는 메세지의 라우팅 키에따라 메세지 큐에 전달해줍니다. 다이렉트 교환소에서 메세지는 바인딩 키가 메세지의 라우팅 키와 정확히 일치하는 큐로 라우팅됩니다. 교환소의 바인딩 키가 pdfprocess 이고, 메세지의 라우팅 키가 pdfprocess면, pdfprocess라는 이름을 가진 큐에 라우팅 됩니다.
• Topic : topic exchange는 라우팅 키와 라우팅 패턴 사이에 와일드카드를 이용해 매칭되는 메세지를 라우팅 합니다.
• Fanout : Routing Key에 상관없이 교환소에 바인딩되어 있는 모든 queue에 메세지를 라우팅 합니다.
• Header

3개의 교환소들 : direct, topic, fanout

용어정리

제대로 RabbitMQ를 알기전에 용어정리를 해보고 가겠습니다!

• Producer : 앞에서 생산자라는 단어를 많이 언급했는데요, 애플리케이션에서 메세지를 보내는 주체입니다.
• Consumer : 컨슈머는 메세지를 받는 애플리케이션을 말합니다.
• Queue : 메세지를 저장하는 버퍼입니다.
• Message : RabbitMQ를 생산자가 컨슈머에게 보내는 데이터를 말합니다.
• Connection : 애플리케이션과 RabbitMq 브로커가 연결되는 TCP 연결을 말합니다.
• Channel : 채널은 커넥션 안에 존재하는 가상연결 입니다. 메세지를 보내거나 받거나, 아니면 큐를 구독(subscribe)할 때 채널에서 이루어집니다.
• Exchange : 생산자로부터 받은 메지를 교환소 타입의 규칙에따라 큐에 넣어줍니다. 큐는 메세지를 받으려면 적어도 한개의 교환소에 바운딩 되야합니다.
• Binding : 큐와 교환소 사이의 링크역할을 합니다.
• Routing key : 교환소가 메세지를 어떻게 큐에 라우팅 할지 정하는 규칙같은(?) 키 입니다. 메세지의 목적지 주소라고 생각하시면 됩니다.
• AMQP : Advanced Message Queing Protocol의 약자입니다. RabbitMq에서 메시징을 위해 사용하는 기본 프로토콜입니다.
• Users : RabbitMQ에 접속할 수 있는 권한을 가진 사람을 말합니다. 유저에 따라 읽기 쓰기 설정 권한을 줄 수 있습니다.
• Vhost, virtual host : 가상 호스트는 동일한 RabbitMq 인스턴스를 사용하는 응용 프로그램을 분리하는 방법을 제공합니다. 서로 다른 사용자는 서로 다른 가상 호스트와 대기열에 대해 서로 다른 액세스 권한을 가질 수 있으며 가상 호스트가 하나의 가상 호스트에만 존재할 때만 만들 수 있습니다.
• Acknowledgments and Confirms : Acknowledgments and Confirms는 메세지를 받았거나, 어떠한 동작을 했을 때 알려줍니다. Acknowledgments는 컨슈머는 서버에게 메시지를 수신 / 처리할때 알려주며, 서버가 생산자에게 동일하게 이 소식을 알려줄 수 있습니다.