MQTT(Message Queuing Telemetry Transport)의 개념

MQTT란?(참고)

MQTT(메시지 큐잉 텔레메트리 트랜스포트, Message Queuing Telemetry Transport)는 ISO 표준(ISO/IEC PRF 20922) 발행-구독 기반의 메시징 프로토콜이다. TCP/IP 프로토콜 위에서 동작한다. "작은 코드 공간"(small code footprint)이 필요하거나 네트워크 대역폭이 제한되는 원격 위치와의 연결을 위해 설계되어 있다. 발행-구독 메시징 패턴은 메시지 브로커가 필요하다.

메시지 큐란?(참고1 , 참고2)

메시지 발행 클라이언트와 메시지 소비 클라이언트의 중개자 역할을 하게 됨으로써 마이크로서비스의 특징인 ‘비동기성’, ‘느슨한 결합’, ‘유연성’, ‘확장성’을 제공하게 된다.

 

① 비동기성(Asynchronous): Queue에 넣기 때문에 나중에 처리할 수 있다.

② 느슨한 결합(Decoupling): 애플리케이션과 분리할 수 있다.

③ 유연성(Resilience): 일부가 실패 시 전체에 영향을 받지 않는다.

④ 확장성(Scalable): 다수의 프로세스들이 큐에 메시지를 보낼 수 있다.

메시지 큐의 종류

RabbitMQ, Kafka, ActiveMQ, ZeroMQ, EMQ X

발행-구독 메시징 패턴이란?(참고)

발행-구독 모델은 비동기 메시징 패러다임이다. 발행-구독 모델에서 발신자의 메시지는 특별한 수신자가 정해져 있지 않다. 대신 발행된 메시지는 정해진 토픽에 따라, 각 토픽에 대한 구독을 신청한 수신자에게 전달된다. 수신자는 발행자에 대한 지식이 없어도 원하는 메시지만을 수신할 수 있다. 이러한 발행자와 구독자의 디커플링은 더 다이나믹한 네트워크 토폴로지와 높은 확장성을 허용한다.

브로커란?(참고)

메시지 브로커(message broker), 인터페이스 엔진(interface engine)은 송신자의 이전 메시지 프로토콜로부터의 메시지를 수신자의 이전 메시지 프로토콜로 변환하는 중간 컴퓨터 프로그램 모듈이다.

QoS란?(참고)

MQTT와 AMQP 비교(참고1, 참고2, 참고3)

	AMQP	MQTT
정의	여러 상황에 적합	주로 임베
배경	오픈 소스	IBM 개발
프로토콜 디자인	벤더에 상관없이 비동기 메시지 전송을 위해 TCP를 이용	벤더에 상관없이 비동기 메시지 전송을 위해 TCP를 이용
프레임워크 최적화	버퍼 접근을 가진 wire of data에 최적화되어 서버 성능 향상	동일하나 최소 메모리의 장비에 최적화됨
메시지 서비스	라이프 사이클의 영향 받지 않음, 메시지 라운드 로빈, 클래식 or 트래디셔널 메시지 큐, 결합, 저장,  포워드, 멱등성 메시지, 그루핑 메시지	매우 일시적, traditional extended life message queuing 에 적용됨
메시지 트랜잭션	다양한 ack, 트랜잭션 지원, 성능 조정을 위해 만료된 것을 확인해야 함	일반적인 ack만 지원하고 어떤 트랜잭션도 지원하지 않음
접속 보안	TLS, SASL을 적용할 수 있고, 성능을 위해 제거할 수 있음	보안 조치를 취하지 않음
사용자 보안	프로토콜의 변경없이 SASL 메소드 사용, 같은 네트워크의 컴포넌트들에 각각 다른 이름을 제공, 이는 중첩된 방화벽과 게이트키퍼를 제공, 메시지를 브로드 캐스트하기 전에 사용자를 인증함	최소한의 사용자 이름과 패스워드만 제공
Last value queues	last value 지원하지 않음	retain command 제공, last value 지원
메시지 전송 보장	fire and forgot policy(Qos 0)	Qos 0, 1, 2제공
메시지 내 네임스페이스	노드나 큐 같은 여러 방법으로 찾을 수 있음	계층 전송 메시지로 네임스페이스 사용함
추가 속성	p2p 접속, 로드 밸런싱, 멀티플렉싱, 컨테이너 사용, 토픽은 쌍대칭이다	DNS 서버의 요건을 제공, 비대칭, 다른 특징 없음
구현	컴포넌트의 램을 최대 64kb만 사용할 수 있음	디바이스의 램을 최대 64kb만 사용할 수 있음
확장성	특정 인프라에 확장성 있음	프로토콜의 전체 초안 필요
Job Queue(부하 분산)	O	X
No TCP/IP 운용 가능	X	O
응용 계층 프로토콜	O	O

MQTT와 HTTP 비교(참고)

MQTT Getting Started(참고)

“MQ” refers to the MQ Series, a product IBM developed to support MQ telemetry transport. When Andy and Arlen created their protocol in 1999, they named it after the IBM product. Many sources label MQTT incorrectly as a message queue protocol. That is simply not true. MQTT is not a traditional message queuing solution (although it is possible to queue messages in certain cases, a fact that we discuss in detail in an upcoming post). Over the next ten years, IBM used the protocol internally until they released MQTT 3.1 as a royalty-free version in 2010. Since then, everyone is welcome to implement and use the protocol.

 

 

 

www.hivemq.com/blog/mqtt-essentials-part2-publish-subscribe/

Publish & Subscribe - MQTT Essentials: Part 2

The publish/subscribe pattern (also known as pub/sub) provides an alternative to traditional client-server architecture. In the client-sever model, a client communicates directly with an endpoint.

 

Scalability

Message filtering

OPTION 1: SUBJECT-BASED FILTERING

OPTION 2: CONTENT-BASED FILTERING

OPTION 3: TYPE-BASED FILTERING

MQTT

 

MQTT uses subject-based filtering of messages. Every message contains a topic (subject)

 

To handle the challenges of a pub/sub system, MQTT has three Quality of Service (QoS) levels.

 

Distinction from message queues

There is a lot of confusion about the name MQTT and whether the protocol is implemented as a message queue or not. We will try to shed some light on the topic and explain the differences. In our last post, we mentioned that MQTT refers to the MQseries product from IBM and has nothing to do with “message queue“. Regardless of where the name comes from, it’s useful to understand the differences between MQTT and a traditional message queue:

A message queue stores message until they are consumed When you use a message queue, each incoming message is stored in the queue until it is picked up by a client (often called a consumer). If no client picks up the message, the message remains stuck in the queue and waits to be consumed. In a message queue, it is not possible for a message not to be processed by any client, as it is in MQTT if nobody subscribes to a topic.

A message is only consumed by one client Another big difference is that in a traditional message queue a message can be processed by one consumer only. The load is distributed between all consumers for a queue. In MQTT the behavior is quite the opposite: every subscriber that subscribes to the topic gets the message.

Queues are named and must be created explicitly A queue is far more rigid than a topic. Before a queue can be used, the queue must be created explicitly with a separate command. Only after the queue is named and created is it possible to publish or consume messages. In contrast, MQTT topics are extremely flexible and can be created on the fly.

If you can think of any other differences that we overlooked, we would love to hear from you in the comments.

 

 

mycup.tistory.com/251

Rabbit MQ