요약
MQTT 프로토콜은 거의 30년 동안 사용되어온 기술이지만, 자동화 엔지니어링의 최신 트렌드인 IIoT(Industrial Internet of Things) 애플리케이션 설계에 이상적인 프로토콜로 주목받고 있다.

 

이는 장치가 일정한 주기로 폴링(Polling)되는 ‘수동 알림(Passive Notification) 방식’과 달리, 필요할 때만 장치가 데이터를 제공하는 ‘액티브 알림(Active Notification) 방식’이 요구되는 애플리케이션에서 특히 관심을 모으고 있다. MQTT의 브로커/클라이언트 설계는 시스템의 모든 장치가 동시에 온라인으로 연결될 필요가 없다.

 

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

 

서문
사람들의 삶의 질을 향상시키고자 하는 요구는 항상 새롭고 발전된 기술을 추구하는 주요 동기 중 하나로 작용해 왔다. 그리고 지금은 점점 더 많은 장치들을 인터넷에 연결하고, IoT 애플리케이션을 위한 보다 나은 제품을 개발하는 것이 아주 뜨거운 주제가 되었다.

 

IIoT(Industrial Internet of Things) 엔지니어에게 가장 큰 과제 중 하나는 ‘엣지 장치’라고 하는 ‘사물’이 안정적인 유선 또는 무선 연결로 액세스되지 않을 수도 있다는 점이다. 엣지 장치는 중앙 시스템에 데이터(일반적으로 간헐적)를 공급하기 때문에 이러한 장치에서 데이터를 수집하는 방식은 중요한 관심 대상이 되고 있다.

 

MQTT, AMQP, CoAP와 같은 여러 프로토콜들이 IIoT 연결 요건을 충족할 수 있는 솔루션으로 고려되고 있지만, 대부분의 IIoT 애플리케이션에서는 MQTT가 우선적으로 채택되고 있다. 그림 1을 보면, IoT 개발자의 절반 이상이 MQTT를 통신 프로토콜로 사용하고 있는 것으로 나타나 있으며, 이는 MQTT가 IoT 애플리케이션에 가장 적합 프로토콜이라는 강력한 증거를 제공한다.

 

<그림1> MQTT는 IoT 애플리케이션을 위한 최고의 프로토콜이다.

 

MQTT는 무엇인가?

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

 

MQTT는 발행-구독 패턴(Publish-Subscribe Pattern)을 사용하여 메시지를 교환한다(그림 2 참조). 그림에서 보는 것처럼, MQTT 시스템은 하나의 브로커와 여러 클라이언트로 구성되며, 클라이언트는 발행자(Publisher) 또는 구독자(Subscriber)가 될 수 있다. 발행자는 ‘토픽(Topic)’ 및 ‘페이로드(Payload)’로 구성된 MQTT 패킷 형태로 데이터를 브로커에게 전송한다. 그런 다음 브로커는 관심을 표명한 토픽에 따라 구독자에게 데이터를 분배한다.

MQTT 프로토콜은 애플리케이션이 일반적으로 JSON 프로토콜이나 플레인 텍스트를 사용하는 것과 달리, 데이터 전송을 위한 표준 포맷을 지정하고 있지 않다. 다른 프로토콜과 비교해 MQTT는 IoT 애플리케이션과 완벽하게 부합하는 장점을 가지고 있다.

 

<그림2> 발행-구독 패턴(Publish-Subscribe Pattern)

 

발행-구독(Publish-Subscribe) 메시징 패턴
다른 요청-응답(Request-Response) 패턴 프로토콜과 비교해 MQTT에서 사용하는 발행-구독 패턴은 IoT 개발자들이 공통의 특정 연결 문제를 해결할 수 있도록 해준다.

 

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

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

 

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

 

이벤트-기반 동작

 발행-구독 패턴을 사용할 때 MQTT 클라이언트는 특정 조건이 충족되는 경우에만 데이터를 브로커에게 발행한다(예를 들어, 특정 장치의 온도가 너무 높을 때 경고신호 표시). 이러한 유형의 동작을 나타내는 또 다른 방식은 클라이언트가 다른 장치가 데이터를 요청할 때까지 수동적으로 기다리는 대신, 적극적으로 데이터를 업데이트하는 것이다. IoT 애플리케이션의 경우 전송되는 데이터 패킷의 수에 따라 통신 요금이 청구된다. 요청-응답 패턴과 비교해 MQTT는 데이터 전송을 완료하기 위해 단방향 통신만 필요하기 때문에 비용을 절감할 수 있다.

 

다자간(Many-to-Many) 통신
MQTT의 주요 장점 중 하나는 발행-구독 패턴을 사용하여 다자간(Many-to-Many) 통신을 손쉽게 구현할 수 있다는 것이다. 다자간 통신을 실현한 M2M(Machine-to-Machine) 개념은 IIoT에서 가장 뜨거운 이슈 중 하나다.

 

공장의 M2M 애플리케이션에서 각 스테이션의 장비는 다른 스테이션의 장비와 프로세스 상태를 공유할 수 있다. 이러한 방식으로 정보를 공유함으로써 작업자의 수동 입력없이 자동으로 생산을 최적화할 수 있다. M2M 통신을 구현하는데 MQTT가 사용되기 때문에 장비를 서로 직접 연결하는 대신, 브로커와 연결만 이뤄지면 된다.

 

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

 

QoS 설계
MQTT 프로토콜은 3가지 QoS 레벨을 사용하여 데이터의 우선순위를 지정한다.

 

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

<그림3> QoS 0 : 최대 1회

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

 

<그림4> QoS 1: 최소한 1회

 

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

 

<그림5> OoS 2: 정확하게 1회

 

보안
보안은 IIoT 애플리케이션에서 최우선 고려사항이다. 점점 더 많은 장치들이 인터넷에 연결되기 때문에 데이터 해킹 가능성을 최소화할 수 있는 방안을 모색하는 것이 가장 중요하다. 그림 6은 IoT 애플리케이션에서 보안이 가장 중요한 관심사라는 점을 분명히 보여준다. MQTT의 경우, 브로커는 권한이 없는 클라이언트가 브로커와 연결하여 토픽을 구독하는 것을 방지하기 위해 계정이름 및 비밀번호를 부여한다. 또한 MQTT는 데이터 전송을 위해 TLS 암호화를 지원하여 전송 중 데이터 해킹 가능성을 최소화한다.

 

<그림6> IoT 채택 시 가장 큰 관심사는 보안으로 나타났다.

 

MQTT 애플리케이션 아키텍처

이 글의 서두에서 지적했듯이, 기존의 OT 애플리케이션은 널리 사용되는 MQTT 프로토콜을 활용해 IIoT 애플리케이션을 구축하고 있다. 여기에는 두 가지 주요 시스템 아키텍처가 사용된다.

 

클라우드와 직접 연결
대부분의 공용 클라우드 서비스(AWS, 애저(Azure), 구글 클라우드, 알리바바 클라우드 등)는 엣지 장치와 클라우드를 직접 연결할 수 있도록 MQTT 프로토콜을 지원한다. 경쟁력을 유지하고, 미래 산업에 대응하기 위해 클라우드 서비스는 최소한 다음과 같은 이점을 제공해야 한다.

 

• 시간 절감
클라우드 서비스 제공업체들이 하드웨어(클라우드 서버, CPU, 메모리 등) 유지관리를 수행하기 때문에 사용자는 클라우드 서비스 IT 전문가들에게 보다 전문적인 유지관리 작업을 맡기고, 자체 솔루션 개발에 더 많은 시간을 할애할 수 있다.

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

• 풍부한 데이터 마이닝(Data Mining) 툴셋
클라우드 서비스는 플랫폼의 일부로 데이터 시각화, 데이터 알고리즘, 가상머신 및 머신러닝과 같은 풍부한 툴셋을 제공한다. 사용자는 이러한 툴에 액세스하여 다양한 애플리케이션을 보다 쉽게 구현할 수 있다. 예를 들어, 엔지니어는 데이터 마이닝(Data Mining)을 위해 클라우드 서비스를 이용함으로써 서버 유지관리 작업을 줄이고, 운용 효율성을 향상시킬 수 있다.

 

<그림7> 클라우드와 직접 연결할 수 있는 아키텍처

 

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

 

• 첫 번째 고려사항은 비용이다. 클라우드 서비스는 전송되는 데이터의 패킷 수에 따라 사용자에게 서비스 요금을 청구하기 때문에 엣지 장치에서 클라우드 서비스로 직접 데이터를 전송하는 것은 비용 효율적이지 않다. 엣지 장치가 셀룰러 네트워크를 통해 클라우드와 연결되는 경우에는 셀룰러 서비스 비용 또한 지불해야 한다.

• 두 번째 고려사항은 데이터 보안이다. 클라우드 서비스는 사용자의 데이터 저장을 위해 뛰어난 보호 환경을 제공하지만, 일부 사용자는 민감한 데이터를 클라우드에 업로드하는 것을 여전히 우려하고 있다.

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

 

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

 

<그림8> 로컬 게이트웨이와 연결할수 있는 아키텍처

 

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

기존의 OT 애플리케이션을 IIoT 애플리케이션으로 전환하는 경우 다음과 같은 문제 중 일부 또는 모든 사항들이 발생할 수 있다.

 

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

공장의 설비 엔지니어는 일반적으로 데이터 액세스 및 환경 모니터링을 위해 원격 I/O 설정을 이용한다. 또한 프로토콜 게이트웨이는 전력 미터기의 데이터를 수집하고, 에너지 소비를 모니터링하는데 사용된다.

 

IIoT로의 전환이 본격화되면서 MQTT 프로토콜을 사용해 데이터를 클라우드로 전송하고자 하는 설비 엔지니어는 먼저 MQTT를 지원하는 새로운 원격 I/O 제품 및 게이트웨이를 조사하고, 구매해야 한다.

 

전세계 공장 현장에는 여전히 상당히 많은 기존 장치들이 사용되고 있기 때문에 공장을 IIoT 기반 설정으로 변환하려면, 막대한 투자가 요구될 수 있다.

 

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

IIoT 애플리케이션의 가장 기본적인 측면 중 하나는 OT 데이터를 수집한 다음, 데이터 처리 및 분석을 위해 클라우드로 전송하는 것이다.

 

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

 

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

 

보안은 최우선 관심사이다

네트워크 보안을 유지하는 것은 IIoT 애플리케이션에서 가장 우선시되는 고려사항이다. 과거의 경험을 보면, 사이버 공격은 공장 외부에서 시작되기 때문에 사이버 보안을 개선하는 첫 번째 단계는 보안 라우터를 설치하고, 방화벽을 구성하여 해커를 차단하는 등 일반적으로 외부 공격을 방지하기 위한 보안 업그레이드에 주력했다.

 

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

 

예를 들어, 2018년 8월 TSMC는 워너크라이(WannaCry) 변종에 의한 사이버 공격으로 인해 약 2억 달러의 매출이 감소한 것으로 추정되고 있다2. 이 공격은 TSMC 인트라넷 상의 모든 장치가 최신 보안 패치를 설치하지 않았기 때문에 발생했다는 점에서 원칙적으로는 공격을 방지할 수 있었던 사례이다. 이 사건을 통해 배울 수 있는 중요한 교훈은 어떤 방식으로든 네트워크 보안을 엣지 장치 수준에서 구현해야 한다는 점이다.

 

Moxa의 솔루션

Moxa가 새로 출시한 ioThinx 4510 시리즈 모듈식 원격 I/O 장치는 IIoT 애플리케이션과 완벽하게 부합하는 주요 기능을 갖추고 있다.

 

MQTT 클라이언트 지원

ioThinx 4510 시리즈는 MQTT 클라이언트를 지원하기 때문에 ioThinx 4510과 연결된 장치들은 쉽게 클라우드 서비스와 연결할 수 있다. ioThinx 4510 시리즈는 엔트리-레벨 원격 I/O 제품으로 공급되고 있지만, MQTT를 지원한다는 점은 강력한 무기가 되고 있다.

 

실제로 ioThinx 4510의 사용자 인터페이스를 사용하면, 자체 MQTT 토픽을 정의한 다음, 이 토픽을 기반으로 어떤 클라이언트가 어떤 데이터를 구독할지를 결정할 수 있다. 또한 채널 데이터 외에도 ioThinx 4510 시리즈는 구독자에게 채널 모드, 최대 또는 최소값 등과 같은 데이터 속성을 제공하여 IT 유형의 장치가 MQTT를 통해 ioThinx 4510 제품의 최신 상태를 파악할 수 있도록 해준다.

 

MQTT 페이로드는 오늘날 IT 산업에서 널리 사용되는 JSON 포맷을 사용한다. 구독자가 MQTT 패킷을 수신하면, 특정 키워드 ‘값(Value)’으로 데이터를 검색하여 페이로드에서 찾고자 하는 데이터를 쉽게 찾을 수 있다.

 

<그림9> 로컬 게이트웨이와 연결할 수 있는 아키텍처

 

통합 Modbus 게이트웨이

ioThinx 4510 시리즈는 Modbus 게이트웨이를 구현하는데 사용할 수 있는 3개의 직렬 인터페이스가 통합되어 있다. 단 한 번의 클릭으로 직렬 Modbus 장치에서 데이터를 수집할 수 있도록 ioThinx 4510을 구성할 수 있다.

 

I/O 데이터와 마찬가지로 직렬 Modbus 데이터는 MQTT로 액세스된다. 이러한 기능 덕분에 I/O와 직렬 데이터를 모두 단일 ioThinx 4510 시리즈 장치를 이용해 수집할 수 있으며, 시스템의 복잡성과 비용을 크게 줄일 수 있다. ioThinx 4510 시리즈는 Modbus 데이터와 함께 Modbus/TCP, RESTful API, SNMP를 비롯한 다른 프로토콜에도 액세스할 수 있다. 따라서 ioThinx 4510 시리즈를 이용하면, 직렬 데이터를 클라우드로 쉽고, 간단하게 제공할 수 있다.

 

보안 강화

사용자 데이터를 보호하기 위해 ioThinx 4510 시리즈는 MQTT로 전송되는 데이터를 암호화할 수 있도록 TLS v1.2를 지원한다. 이 데이터 암호화 기술은 이미 널리 사용되는 검증된 기술로, 해커로부터 네트워크로 전송되는 데이터를 보호할 수 있다.

 

또한 ioThinx 4510은 브로커의 계정이름과 비밀번호를 지원하여 인증되지 않은 브로커에게 데이터가 발행되는 것을 방지하며, https 및 SNMPv3를 통해 RESTful API를 지원함으로써 지원되는 모든 IT 프로토콜이 암호화된 데이터로 전송될 수 있도록 해준다. 데이터가 플레인 텍스트로 전송되는 Modbus/TCP 프로토콜의 경우, ioThinx 4510 시리즈는 ioThinx 4510에 액세스할 수 있는 권한이 부여된 IP 주소목록을 기반으로 액세스 제어 기능을 제공하기 때문에 보안 운영을 강화할 수 있다.

이러한 첨단 기능과 다양한 I/O 모듈에 대한 지원을 통해 ioThinx 4510 시리즈는, IT 엔지니어가 공장 현장의 데이터를 수집하는 것은 물론, OT 엔지니어가 클라우드 서비스로 데이터를 안전하게 전달할 수 있도록 해준다. 실제로 ioThinx 4510 시리즈는 IT 및 OT 영역 간의 격차를 완전히 해소할 수 있다.