MQTT 메시징
MQTT는 OASIS 표준 기구가 관리하고 ISO에서 국제적으로 인정하는 개방형 표준으로, 장치와 애플리케이션이 도구와 IoT 통신하는 데 사용하는 주요 프로토콜입니다.
MQTT는 센서와 모바일 디바이스 간에 실시간에 가까운 데이터를 효율적으로 교환하도록 설계된 발행 및 구독 메시징 전송 프로토콜입니다. 자세한 정보는 OASIS MQTT (Message Queuing Telemetry Transport)를 참조하십시오.
MQTT는 TCP/IP를 통해 실행되며 TCP/IP에 직접 코딩할 수 있지만, MQTT 프로토콜의 세부사항을 처리하는 라이브러리를 사용하도록 선택할 수도 있습니다. 사용할 수 있는 MQTT 클라이언트 라이브러리는 다양합니다. IBM은 다음 사이트에서 사용 가능한 라이브러리를 비롯한 여러 클라이언트 라이브러리의 개발 및 지원에 기여하고 있습니다.
표준 및 요구사항
도구에서 IoT 지원하는 MQTT 버전에 대한 자세한 내용은 표준 및 요구 사항을 참조하십시오.
제한사항 및 한계
도구에 IoT 연결된 MQTT 클라이언트에 적용되는 제한 사항 및 제약 사항에 대한 자세한 내용은 제한 사항 및 제약 사항을 참조하십시오.
포트 보안
장치, 게이트웨이 및 애플리케이션은 MQTT 또는 HTTP 프로토콜을 사용하여 해당 IoT 도구에 연결합니다.
| 연결 유형 | 프로토콜 | 포트 번호 |
|---|---|---|
| 보안(TLS) | MQTT 및 HTTPS | 443 |
MQTT는 TCP 및 WebSocket에서 지원됩니다. MQTT 클라이언트에서는 디바이스 인증 토큰(디바이스의 경우) 및 API 키와 토큰(애플리케이션의 경우)과 같은 적절한 신임 정보를 사용하여 연결합니다. TLS 인증 정보는 보안 포트에서 전송될 때 항상 암호화됩니다.
포트 443에서 보안 MQTT 메시징을 사용할 경우, 최신 클라이언트 라이브러리는 해당 IoT 도구가 제시하는 기본 인증서를 자동으로 신뢰합니다. 고객 환경에서 해당 사항이 아닌 경우, 전체 인증서 체인을 에서 다운로드하여 사용할 messaging.pem 수 있습니다. 사용자 정의 인증서를 업로드하는 경우에는 적절한 신뢰 체인이 클라이언트 환경에 추가되었는지 확인해야 할 수 있습니다.
TLS
데이터를 안전하게 전송하지 않으려면 애플리케이션에서 TLS를 사용으로 설정해야 합니다.
자세한 정보는 다음 주제를 참조하십시오.
공정 사용 정책
8.10 및 이후 버전에서는 공정 사용 제한 기능이 연결 한도를 초과하는 연결에 대한 읽기 작업을 일시 중지합니다. 해당 IoT 도구의 스로틀링 제한은 장치별로 적용되며, 장치 클래스(예: 장치, 게이트웨이 또는 애플리케이션)를 기준으로 합니다. 이러한 제한은 장치로부터의 서비스 거부( DoS ) 공격을 방지하기 위해 사용됩니다. 스로틀링 제한은 도구 배포 IoT 규모에 따라 확장되지 않습니다. HTTP 메시징 클라이언트와 같은 소량의 메시지를 전송하는 단기 연결에는 스로틀링이 적용되지 않습니다. 자세한 내용은 할당량 항목을 참조하십시오.
메시지 전송률을 극대화하려면 도구 데이터 수집 IoT 애플리케이션이 여러 MQTT 장치 또는 애플리케이션에 부하를 분산하도록 하십시오. MQTT 서비스 도구는 IoT 각 기기가 낮은 속도로 데이터를 게시하는 다수의 기기 연결을 관리하도록 설계되었습니다.
MQTT 클라이언트 인증
각 MQTT 클라이언트에는 고유한 클라이언트 ID가 필요합니다. 이미 연결된 클라이언트 ID를 사용하여 조직의 클라이언트에 연결하면 첫 번째 연결이 끊깁니다.
도구에 IoT 직접 연결된 장치 및 게이트웨이는 연결 상태를 나타내는 상태 아이콘이 대시보드에 표시됩니다. 대시보드에서는 게이트웨이를 통해 연결된 디바이스를 인식하지 못하므로 게이트웨이를 통해 간접적으로 연결된 디바이스는 연결이 끊김으로 표시됩니다.
메시징 서비스 품질 (QoS) 레벨
| 레벨 | 설명 |
|---|---|
| 최대 한 번(QoS 0) | 서비스 품질 레벨 0 (QoS 0) 은 가장 빠른 전송 모드입니다. 메시지가 최대 한 번 전달되거나 전혀 전달되지 않습니다. 네트워크를 통한 전달은 수신확인 되지 않으므로 메시지가 저장되지 않습니다. 클라이언트의 연결이 끊어지거나 서버 장애가 발생하는 경우 메시지가 손실될 수 있습니다. MQTT 프로토콜에서는 서버가 서비스 품질 (QoS) 레벨 0의 발행물을 클라이언트에 전달할 필요가 없습니다. 서버가 공개를 수신할 때 클라이언트의 연결이 끊기면 서버 구현에 따라 공개가 삭제될 수 있습니다. 한 간격으로 실시간에 가까운 데이터가 전송되면 서비스 품질 (QoS) 레벨 0을 사용하십시오. 단일 메시지가 누락되는 경우에는 새 데이터를 포함하는 다른 메시지가 곧 전송되기 때문에 문제가 되지 않습니다. 이 시나리오에서는 더 높은 서비스 품질(QoS)을 사용하여 추가 비용을 들여도 가시적인 이점이 없습니다. |
| 최소 한 번(QoS 1) | 서비스 수준 1( QoS 1)에서는 메시지가 항상 최소한 한 번은 전달됩니다. 발신인이 수신확인을 받기 전에 장애가 발생하면 메시지를 여러 번 전달할 수 있습니다. 수신인이 메시지를 공개했음을 나타내는 확인을 발신인이 받을 때까지 메시지는 발신인이 로컬로 저장해야 합니다. 메시지를 다시 전송해야 하는 경우 메시지가 저장됩니다. MQTT 브로커에 메시지가 안정적으로 전달되었다고 해서 해당 브로커가 반드시 Maximo® Monitor 메시지를 처리한다는 의미는 아닙니다. |
| 정확히 한 번(QoS 2) | 서비스 수준 2(SLL 2, QoS 2)는 가장 강력한 신뢰성 있는 메시지 전달을 제공하지만, 동시에 가장 느린 전송 방식을 가집니다. 메시지는 정확히 한 번만 전송되며, 수신인이 메시지를 발행했다는 확인을 발신인이 수신할 때까지는 발신인이 로컬에 저장해야 합니다. 메시지를 다시 전송해야 하는 경우 메시지가 저장됩니다. 서비스 품질 레벨 2를 사용하면 메시지가 중복되지 않도록 레벨 1에 비해 더욱 정교한 응답 확인 방식과 수신확인 시퀀스가 사용됩니다. MQTT 브로커에 메시지가 안정적으로 전달되었다고 해서 해당 브로커가 반드시 Maximo Monitor 메시지를 처리한다는 의미는 아닙니다. 명령을 전송할 때 지정된 명령만 작동하고 한 번만 작동하는지 확인하려면 서비스 품질 레벨 2를 사용하십시오. 이 예에서, 레벨 2의 부가적인 오버헤드는 다른 레벨들에 비해 유리할 수 있다. |
- 디스크 I/O 성능은 QoS 1 및 QoS 2에 매우 중요합니다. 이는 해당 수준에서 도구 메시징 IoT 구성 요소 내 디스크 지속성이 요구되기 때문입니다.
- MQTT 스펙은 클라이언트와 서버 간의 프로토콜 레벨 플로우 제어 협상을 제공합니다. 클라이언트 및 서버는 세션에서 허용되는 수신확인되지 않은 메시지 수를 조정합니다. 클라이언트에 사용 가능한 메시지 ID가 없는 경우, 클라이언트는 ID가 사용 가능할 때까지 공개를 일시정지해야 합니다. 메시지 ID는 메시지 수신확인 (ACK) 이 수신될 때 사용 가능합니다. 자세한 정보는 OASIS 표준 MQTT 스펙을 참조하십시오.
데이터 수집 비율
더 높은 데이터 수집 비율을 달성하려면 MQTT 메시징 프로토콜을 사용하고 메시지를 발행하는 동안 디바이스 연결을 열린 상태로 유지하십시오.
MQTT CONNECT
MQTT PUBLISH
MQTT PUBLISH
MQTT PUBLISH
...MQTT CONNECT
MQTT PUBLISH
MQTT DISCONNECT
MQTT CONNECT
MQTT PUBLISH
MQTT DISCONNECT
...데이터 수집 비율에 영향을 주는 요인은 다음과 같습니다.
- 메시징 프로토콜입니다. MQTT는 높은 볼륨의 프로토콜입니다. HTTP 저용량 프로토콜입니다.
- 메시징 패턴입니다. 데이터 수집 비율을 개선하려면 각 메시지가 발행된 후 MQTT 세션을 닫지 마십시오. 연결을 열린 상태로 두십시오.
- 디바이스 수입니다. 데이터 수집 및 메시지 비율을 향상시키려면 더 많은 연결을 통해 로드를 분배하십시오.
- 디바이스 클래스입니다. 적정 사용 할당량 은 디바이스 클래스를 기반으로 합니다.
- QoS. 높은 수준의 메시징 신뢰성은 더 높은 비용을 필요로 합니다.