Google Cloud의 독립형 MQTT 브로커 아키텍처

Last reviewed 2024-08-09 UTC

MQTT는 게시 및 구독 브로커 아키텍처를 사용하여 양방향 메시지를 제공하는 연결된 기기 애플리케이션용 OASIS 표준 프로토콜입니다. MQTT 프로토콜은 네트워크 오버헤드를 줄이기 위한 경량 프로토콜로서 MQTT 클라이언트가 매우 작아 제한된 기기의 리소스 사용이 최소화됩니다. Google Cloud에서 연결된 기기 애플리케이션을 지원하려는 조직을 위한 한 가지 솔루션은 Compute Engine 또는 GKE에서 독립형 MQTT 브로커를 실행하는 것입니다. 조직에 MQTT 브로커를 배포하려면 전체 아키텍처에 영향을 미치는, 특히 부하 분산과 배포 환경에 관한 몇 가지 주요 결정을 내려야 합니다. 이 문서에서는 MQTT 배포의 핵심 애플리케이션인 MQTT 브로커를 Google Cloud에 배포하기 위한 아키텍처를 설명합니다. 또한 이 브로커를 배포할 때 결정해야 할 사항과 결정이 아키텍처에 미치는 영향을 설명합니다.

이 문서는 Google Cloud의 IoT 아키텍처에 대한 정보를 제공하는 문서 시리즈의 일부입니다. 이 시리즈의 다른 문서에는 다음이 포함됩니다.

다음 다이어그램은 Google Cloud에서 실행되는 MQTT 브로커 아키텍처를 보여줍니다.

(다음 텍스트에 설명된) MQTT 브로커 아키텍처 다이어그램

위 이미지의 아키텍처는 다음과 같이 구성됩니다.

  • MQTT 브로커는 Cloud Load Balancing 서비스에 연결된 세 인스턴스의 클러스터로 배포됩니다. 클라우드 부하 분산기의 경우 이 문서의 뒷부분에 설명된 여러 부하 분산 제품 중 하나를 선택할 수 있습니다.
  • 브로커 클러스터에는 기기 사용자 인증 정보 저장소와 기기 인증 및 승인 서비스가 포함됩니다. 클러스터는 Dataflow 또는 Pub/Sub를 통해 백엔드 워크로드와 연결됩니다.
  • 클라이언트 측에서 에지 게이트웨이는 TLS를 통해 MQTT로 에지 기기와 MQTT 브로커 클러스터 간의 양방향 통신을 제공합니다.

일반적으로 확장성을 위해 이 아키텍처의 MQTT 브로커 애플리케이션을 클러스터에 배포하는 것이 좋습니다. 클러스터링 기능, 수직 확장 및 축소 클러스터 관리, 데이터 동기화, 네트워크 파티션 처리와 같은 요소는 특정 브로커 구현(예: HiveMQ, EMQX, VerneMQ, mosquito 등)을 통해 처리합니다.

아키텍처 고려사항 및 선택

다음 섹션에서는 독립형 MQTT 브로커 아키텍처를 위한 다양한 아키텍처 선택 및 고려사항과 이러한 선택이 아키텍처에 미치는 영향을 설명합니다.

연결된 기기

인터넷 연결 에지 기기는 원격 분석 이벤트 및 기타 정보를 MQTT 브로커에 게시합니다. 이 문서에 설명된 독립형 MQTT 브로커 아키텍처를 구현하려면 기기에 MQTT 클라이언트, TLS 인증을 위한 서버 인증서 공개 키, MQTT 브로커에 인증하는 데 필요한 사용자 인증 정보가 있어야 합니다.

또한 에지 기기에는 일반적으로 로컬 센서, 온프레미스 데이터 시스템, 인터넷 액세스 또는 IP 연결이 없는 기타 기기에 대한 커넥터가 있습니다. 예를 들어 에지 기기는 BLE를 사용하여 게이트웨이에 연결된 다른 제한된 로컬 기기에 유선 연결 또는 다른 근거리 프로토콜로의 게이트웨이 역할을 할 수 있습니다. 연결된 기기 아키텍처의 세부 사양은 이 가이드에서 다루지 않습니다.

부하 분산

이 아키텍처에서는 공용 네트워크와 MQTT 브로커 클러스터 간에 외부 부하 분산 서비스가 구성됩니다. 이 서비스는 백엔드 노드 간에 수신 연결을 배포하고, 세션을 암호화하고, 인증하는 등 여러 가지 중요한 네트워킹 기능을 제공합니다.

Google Cloud에서는 여러 가지 부하 분산기 유형을 지원합니다. 아키텍처에 가장 적합한 부하 분산기를 선택하려면 다음을 고려하세요.

  • mTLS. mTLS는 암호화 및 기기 인증 방법을 모두 처리하는 반면, 표준 TLS는 암호화만 처리하고 별도의 기기 인증 방법이 필요합니다.

  • HTTP(S) 엔드포인트. HTTP(S) 엔드포인트를 노출해야 하는 경우 이러한 엔드포인트에 별도의 외부 애플리케이션 부하 분산기를 구성하는 것이 좋습니다.

Cloud Load Balancing에서 지원하는 부하 분산기 유형에 대한 자세한 내용은 Google Cloud 부하 분산기 요약을 참고하세요.

부하 분산 전략

모든 부하 분산 서비스는 여러 알고리즘 또는 분산 모드 중 하나에 따라 클러스터의 여러 노드에 에지 기기의 연결을 분산합니다. MQTT의 경우 세션 어피니티 부하 분산 전략이 무작위 부하 분산보다 적합합니다. MQTT 클라이언트-서버 연결은 영구적인 양방향 세션이므로 상태가 연결을 중지하는 브로커 노드에서 유지됩니다. 클러스터링된 구성에서 클라이언트가 연결을 해제했다가 다른 노드에 다시 연결되면 세션 상태가 새 노드로 이동되어 클러스터에 부하가 추가됩니다. 이 문제는 세션 어피니티 부하 분산을 사용하여 대부분 방지할 수 있습니다. 클라이언트가 IP 주소를 자주 변경하면 연결이 끊어질 수 있지만 대부분의 경우 세션 어피니티가 MQTT에 더 적합합니다. 세션 어피니티는 모든 Cloud Load Balancing 제품에서 사용할 수 있습니다.

기기 인증 및 사용자 인증 정보 관리

MQTT 브로커 애플리케이션은 Google Cloud와 별도로 기기 인증 및 액세스 제어를 처리합니다. 브로커 애플리케이션은 자체 사용자 인증 정보 저장소 및 관리 인터페이스도 제공합니다. MQTT 프로토콜은 초기 Connect 패킷에서 기본 사용자 이름 및 비밀번호 인증을 지원하며, 이러한 필드는 X.509 인증서 또는 JWT 인증과 같은 다른 형태의 인증을 지원하기 위해 브로커 구현에서도 자주 사용됩니다. MQTT 5.0에서는 본인 확인 요청 응답 형식의 인증을 사용하는 향상된 인증 방법에 대한 지원도 추가합니다. 사용되는 인증 방법은 선택한 MQTT 브로커 애플리케이션과 연결된 기기 사용 사례에 따라 달라집니다.

브로커가 사용하는 인증 방법에 관계없이 브로커는 기기 사용자 인증 정보 저장소를 유지합니다. 이 저장소는 로컬 SQL 데이터베이스 또는 플랫 파일에 있을 수 있습니다. HiveMQ 및 VerneMQ를 비롯한 일부 브로커는 Cloud SQL과 같은 관리형 데이터베이스 서비스의 사용도 지원합니다. 기기 사용자 인증 정보 저장소를 관리하고 IAM과 같은 다른 인증 서비스와의 통합을 처리하려면 별도의 서비스가 필요합니다. 이 서비스의 개발은 이 가이드에서 다루지 않습니다.

인증 및 사용자 인증 정보 관리에 대한 자세한 내용은 Google Cloud에서 IoT 백엔드 실행 권장사항을 참조하세요.

백엔드 워크로드

연결된 기기 사용 사례에는 연결된 기기에서 수집된 데이터를 사용하는 하나 이상의 백엔드 애플리케이션이 포함됩니다. 이러한 애플리케이션에서 명령어 및 구성 업데이트를 기기에 보내야 하는 경우도 있습니다. 이 문서의 독립형 MQTT 브로커 아키텍처에서는 수신 데이터와 발신 명령어가 모두 MQTT 브로커를 통해 라우팅됩니다. 브로커의 주제 계층 구조 내에 데이터와 명령어를 구분하는 다양한 주제가 있습니다.

데이터와 명령어는 여러 가지 방법 중 하나로 브로커와 백엔드 애플리케이션 간에 전송될 수 있습니다. 애플리케이션 자체가 MQTT를 지원하거나 MQTT를 지원하도록 수정할 수 있는 경우 애플리케이션에서 브로커를 클라이언트로 직접 구독할 수 있습니다. 이 접근 방식을 사용하면 애플리케이션을 사용하여 연결된 기기에서 데이터를 수신하고 연결된 기기에 명령어를 전송하여 MQTT Pub/Sub 양방향 메시지 기능을 직접 사용할 수 있습니다.

애플리케이션에서 MQTT를 지원하지 않는 경우 다른 여러 옵션이 있습니다. 이 문서에 설명된 아키텍처에서는 Apache Beam이 Dataflow 및 기타 Beam 배포와의 양방향 통합을 허용하는 MQTT 드라이버를 제공합니다. 또한 많은 브로커에 Google Pub/Sub와 같은 서비스와의 통합을 지원하는 플러그인 기능이 있습니다. 일부 브로커는 양방향 통합을 지원하지만 보통은 데이터 통합을 위한 단방향 통합입니다.

사용 사례

MQTT 브로커 아키텍처는 다음 섹션에서 설명하는 기기 사용 사례에 특히 적합합니다.

이기종 기기의 표준 기반 데이터 수집

다양한 이기종 기기에서 데이터를 수집하고 분석하려는 경우 MQTT 브로커가 좋은 솔루션일 때가 많습니다. MQTT는 널리 채택되고 구현된 표준이기 때문에 많은 에지 기기에서 기본적으로 지원되며, 그렇지 않은 기기에도 경량 MQTT 클라이언트를 사용하여 MQTT 지원을 추가할 수 있습니다. 게시 및 구독 패러다임도 MQTT 표준에 포함되어 있으므로 MQTT 지원 기기는 추가 구현 작업 없이 이 아키텍처를 활용할 수 있습니다. 반면 Pub/Sub에 연결하는 기기는 Pub/Sub API를 구현하거나 Pub/Sub SDK를 사용해야 합니다. 따라서 표준 호환 MQTT 브로커를 Google Cloud에서 실행하면 다양한 기기에서 데이터를 수집하는 간단한 솔루션이 제공됩니다.

연결된 기기를 애플리케이션에서 제어하지 않고 서드 파티에서 제어하는 경우, 사용자에게 기기 시스템 소프트웨어에 대한 액세스 권한이 없을 수 있으며 해당하는 서드 파티에서 기기 자체의 관리를 책임집니다. 이 경우 MQTT 브로커를 실행하고 서드 파티에 사용자 인증 정보를 제공하여 기기와 클라우드 간 통신 채널을 설정하는 것이 좋습니다.

다자간 애플리케이션 통합을 위한 양방향 통신

MQTT의 양방향 메시지 기능은 주문형 음식 배달 또는 대규모 웹 채팅 애플리케이션과 같은 다자간 모바일 애플리케이션 사용 사례에 매우 적합합니다. MQTT는 프로토콜 오버헤드가 낮고 MQTT 클라이언트는 리소스 수요가 낮습니다. 또한 MQTT는 게시 및 구독 라우팅, 여러 서비스 품질(QoS) 수준, 기본 제공되는 메시지 보관, 광범위한 프로토콜 지원 기능을 제공합니다. MQTT 브로커는 주문형 서비스 애플리케이션 및 유사한 사용 사례를 위한 확장 가능한 메시지 플랫폼의 핵심 구성요소일 수 있습니다.

에지 및 클라우드 간 통합 메시지

MQTT는 표준화와 낮은 오버헤드를 제공하기 때문에 온프레미스 및 클라우드 기반 메시지 애플리케이션을 통합하는 데 좋은 솔루션일 수 있습니다. 예를 들어 공장 운영자는 온프레미스 환경에 여러 MQTT 브로커를 배포하여 방화벽 뒤에 있는 센서, 머신, 게이트웨이, 기타 기기에 연결할 수 있습니다. 로컬 MQTT 브로커는 온프레미스 인프라의 모든 양방향 명령어와 제어 및 원격 분석 메시지를 처리할 수 있습니다. 로컬 브로커는 양방향 구독을 통해 클라우드의 병렬 MQTT 브로커 클러스터에 연결할 수 있으므로 온프레미스 기기 및 시스템을 공개 인터넷에 노출하지 않고도 클라우드 및 에지 환경 간 통신이 가능합니다.

다음 단계