MQTT 추가 내용

*MQTT

- 자동화 엔지니어링의 최신 트렌드인 IIoT(Industrial Internet of Things) 애플리케이션 설계에 이상적인 프로토콜

-  장치가 일정한 주기로 폴링(Polling)되는 ‘수동 알림(Passive Notification) 방식’과 달리, 필요할 때만 장치가 데이터를 제공하는 ‘액티브 알림(Active Notification) 방식’이 요구되는 애플리케이션

- MQTT의 브로커/클라이언트 설계는 시스템의 모든 장치가 동시에 온라인으로 연결될 필요가 없음

- 클라이언트(장치 또는 사물)는 클라이언트 간에 메시지를 주고받을 수 있도록 중개인 역할을 하는 브로커와 직접 통신함

- IIoT(Industrial Internet of Things) 엔지니어에게 가장 큰 과제 중 하나는 ‘엣지 장치’라고 하는 ‘사물’이 안정적인 유선 또는 무선 연결로 액세스되지 않을 수도 있다는 점

- 엣지 장치는 중앙 시스템에 데이터(일반적으로 간헐적)를 공급하기 때문에 이러한 장치에서 데이터를 수집하는 방식은 중요한 관심 대상

- MQTT, AMQP, CoAP와 같은 여러 프로토콜들이 IIoT 연결 요건을 충족할 수 있는 솔루션으로 고려되고 있지만, 대부분의 IIoT 애플리케이션에서는 MQTT가 우선적으로 채택

- MQTT 메시징 프로토콜은 1999년에 IBM과 시러스 링크(Cirrus Link)가 처음으로 개발했으며, 버전 3.1을 시작으로 2013년에 ISO 표준으로 채택

- MQTT는 발행-구독 패턴(Publish-Subscribe Pattern)을 사용하여 메시지를 교환

- MQTT 시스템은 하나의 브로커와 여러 클라이언트로 구성되며, 클라이언트는 발행자(Publisher) 또는 구독자(Subscriber)가 될 수 있음

- 발행자는 ‘토픽(Topic)’ 및 ‘페이로드(Payload)’로 구성된 MQTT 패킷 형태로 데이터를 브로커에게 전송

- 브로커는 관심을 표명한 토픽에 따라 구독자에게 데이터를 분배

- MQTT 프로토콜은 애플리케이션이 일반적으로 JSON 프로토콜이나 플레인 텍스트를 사용하는 것과 달리, 데이터 전송을 위한 표준 포맷을 지정하고 있지 않음

 

*발행-구독(Publish-Subscribe) 메시징 패턴

- 요청-응답 패턴은 데이터가 성공적으로 전송 및 수신될 수 있도록 클라이언트와 서버가 동시에 온라인 상태에 있어야 한다. 그러나 특히 IIoT 애플리케이션의 경우, 장치가 필요한 데이터를 수신하도록 강력한 네트워크 연결을 유지하는 것이 불가능할 수 있기 때문에 요청-응답 패턴은 이러한 애플리케이션에 적합하지 않음

- MQTT의 발행-구독 패턴은 장치들이 동시에 네트워크에 연결되어 있지 않더라도 상황에 맞게 조정이 가능하다. 이 부분에서 MQTT 브로커가 중요하다. 브로커는 ‘발행자’로 지정된 클라이언트에서 전송된 데이터를 승인한 후 ‘가입자’로 지정된 클라이언트에 데이터를 전송하는 정보 센터의 역할을 함

- 브로커는 데이터를 구독자에게 전송할 때 대상 클라이언트가 온라인 상태인지를 먼저 확인한다. 온라인 상태가 아니라면, 브로커는 데이터를 보류한 다음, 구독자가 온라인 상태가 되면 데이터를 전송한다. 이러한 전략의 장점 중 하나는 브로커만 항상 온라인 상태를 유지하면 된다는 것이다. 발행자와 구독자 클라이언트 모두, 연결이 가능하거나 데이터를 보내거나 받을 때만 온라인에 접속하면 된다.

 

*이벤트-기반 동작

- 발행-구독 패턴을 사용할 때 MQTT 클라이언트는 특정 조건이 충족되는 경우에만 데이터를 브로커에게 발행한다(예를 들어, 특정 장치의 온도가 너무 높을 때 경고신호 표시)

- 이러한 유형의 동작을 나타내는 또 다른 방식은 클라이언트가 다른 장치가 데이터를 요청할 때까지 수동적으로 기다리는 대신, 적극적으로 데이터를 업데이트하는 것이다. IoT 애플리케이션의 경우 전송되는 데이터 패킷의 수에 따라 통신 요금이 청구된다. 요청-응답 패턴과 비교해 MQTT는 데이터 전송을 완료하기 위해 단방향 통신만 필요하기 때문에 비용을 절감할 수 있다.

 

*다자간(Many-to-Many) 통신

- MQTT의 주요 장점 중 하나는 발행-구독 패턴을 사용하여 다자간(Many-to-Many) 통신을 손쉽게 구현할 수 있다는 것

- 다자간 통신을 실현한 M2M(Machine-to-Machine) 개념은 IIoT에서 가장 뜨거운 이슈 중 하나

- 공장의 M2M 애플리케이션에서 각 스테이션의 장비는 다른 스테이션의 장비와 프로세스 상태를 공유할 수 있음

- 이러한 방식으로 정보를 공유함으로써 작업자의 수동 입력없이 자동으로 생산을 최적화할 수 있음

- M2M 통신을 구현하는데 MQTT가 사용되기 때문에 장비를 서로 직접 연결하는 대신, 브로커와 연결만 이뤄지면 된다.

- 따라서 데이터 교환 작업 시간을 상당히 줄일 수 있다. 또한 하나의 브로커가 모든 장비들 간의 통신을 처리하기 때문에 데이터 전송이 보다 안정적이다.

 

*QoS 설계

- QoS 0 (최대 1회) : 이 경우 클라이언트는 메시지를 브로커에게 한 번만 발행한다. 브로커는 메시지 수신 여부를 알리거나 클라이언트에게 구독자와의 통신과 관련한 어떠한 알림도 제공하지 않는다. 유일한 보증은 발행자가 메시지를 전송했다는 것만 알 수 있으며, 브로커나 구독자가 메시지를 수신했는지는 알 수 없다. QoS 0가 서비스 품질 정책 중 가장 빠르지만, 안정성도 가장 낮다.

- QoS 1 (최소한 1회) : 이 경우 클라이언트가 브로커에게 메시지를 발행하면, 클라이언트는 브로커에게 클라이언트가 메시지를 수신했는지 여부를 확인하도록 요구한다. 발행자가 사전 설정된 시간 간격 내에 브로커로부터 확인여부를 수신하지 못하면, 승인이 수신될 때까지 계속해서 메시지를 다시 발행한다. QoS 0과 비교해 QoS 1은 시간이 지나면서 속도는 느려 지지만, 보다 안정적이다.

-  QoS 2 (정확하게 1회) : 이 경우 클라이언트와 브로커는 4개의 메시지를 교환한다. 클라이언트는 먼저 브로커에게 데이터를 발행한 다음, 클라이언트와 브로커가 PUBREC, PUBREL, PUBCOMP 등의 3개의 메시지를 교환함으로써 데이터가 단 한번만 전달되도록 한다. QoS 2는 MQTT 서비스 품질 정책 중 가장 느리지만, 가장 안정적이다.

 

*보안

- 보안은 IIoT 애플리케이션에서 최우선 고려사항

-  점점 더 많은 장치들이 인터넷에 연결되기 때문에 데이터 해킹 가능성을 최소화할 수 있는 방안을 모색하는 것이 가장 중요

- MQTT의 경우, 브로커는 권한이 없는 클라이언트가 브로커와 연결하여 토픽을 구독하는 것을 방지하기 위해 계정이름 및 비밀번호를 부여한다. 또한 MQTT는 데이터 전송을 위해 TLS 암호화를 지원하여 전송 중 데이터 해킹 가능성을 최소화한다.

 

*MQTT 애플리케이션 아키텍처(클라우드와 직접 연결)

- 대부분의 공용 클라우드 서비스(AWS, 애저(Azure), 구글 클라우드, 알리바바 클라우드 등)는 엣지 장치와 클라우드를 직접 연결할 수 있도록 MQTT 프로토콜을 지원

- 고객은 클라우드 서비스 제공업체에게 거의 100%에 달하는 안정성을 기대하기 때문에 신뢰성 및 네트워크 안정성이 가장 중요하다. 모든 클라우드 서비스 제공업체는 SLA(Service Level Agreement)를 통해 제공되는 서비스의 안정성 수준을 명확하게 명시하고 있다. 예를 들어, 아마존 컴퓨트(Amazon Compute) SLA의 경우 아마존은 월간 가동시간을 99.99%1로 보장하고 있으며, 이는 서비스 중단시간이 한 달에 4.32분 미만이 될 것으로 예상

- 풍부한 데이터 마이닝(Data Mining) 툴셋

 

*MQTT 애플리케이션 아키텍처(로컬 게이트웨이와 연결)

- 엣지 장치를 클라우드와 직접 연결함으로써 여러 이점을 얻을 수 있지만, IIoT 애플리케이션에 클라우드 서비스를 채택하는 경우 고려해야 할 다양한 문제들도 알고 있어야 한다

- 첫 번째 고려사항은 비용

- 두 번째 고려사항은 데이터 보안

- 대부분의 IIoT 애플리케이션은 엣지 장치의 데이터를 수집하거나 공장 현장의 M2M 통신을 구현하기 위해 현장에 게이트웨이를 설치함으로써 이러한 문제들을 방지할 수 있다. 게이트웨이는 보통 임베디드 컴퓨터에 해당하며, 반드시 MQTT 브로커 및 MQTT 클라이언트 역할로 구성될 필요는 없지만 이러한 구성도 가능하다.

- MQTT 브로커로서의 게이트웨이는 공장 현장에서 M2M 데이터 전송을 처리할 수 있다. MQTT 클라이언트로서의 게이트웨이는 필드 장치의 데이터를 수집하고, 유용한 데이터를 SCADA 시스템, HMI 또는 클라우드 서비스로 전송할 수 있다. 게이트웨이 솔루션은 MQTT를 이용하여 클라우드 대신 현장에서 M2M 통신을 구현할 수 있기 때문에 비용을 더욱 최소화할 수 있다.

 

*IIoT 애플리케이션으로의 전환 과제

- 현재 사용 중인 기존 장치는 MQTT를 지원하지 않는다.

- 기존 자동화 애플리케이션과 IT 통합은 간단한 문제가 아니다.

- 문제는 IT와 OT 산업은 서로 다른 전송 프로토콜을 사용한다는 점이다. OT 영역에서 가장 널리 사용되는 프로토콜 중 하나인 Modbus는 제한된 대역폭의 네트워크를 통해 패킷을 전송할 수 있도록 작은 헤더와 페이로드를 가진 데이터 패킷을 사용한다.

- 반면 IT 엔지니어는 MQTT, RESTful API, SNMP와 같은 IT 프로토콜을 사용해 데이터를 수집하기 때문에 대부분의 IT 엔지니어들은 Modbus에 익숙하지 않다.

- 보안은 최우선 관심사이다.

- 공장 인트라넷의 엣지 장치는 제한된 보안 기능만 갖추고 있을 뿐만 아니라 암호화되지 않는 프로토콜을 사용하는 경우가 많다. 예를 들어, Modbus는 일반적으로 엣지 장치와 데이터를 주고받는데 사용된다. 최근 몇 년 동안 주목을 끌었던 특정 사이버 공격으로 인해 산업용 네트워크의 보안 문제가 크게 대두되었다.