Google Cloud의 IoT 플랫폼 제품 아키텍처

Last reviewed 2024-08-09 UTC

IoT 플랫폼 제품은 일반적으로 기본적인 MQTT 및 HTTPS 데이터 연결을 제공합니다. 또한 기기를 프로비저닝할 수 있으며 인증 및 관리, 원격 분석 스토리지 및 시각화, 데이터 처리, 알림을 제공합니다. 독립형 MQTT 브로커가 사용 사례를 충족하기에 부족하고 더 완전한 IoT 플랫폼 제품이 필요한 경우 IoT 플랫폼을 사용하는 경우가 많습니다. IoT 플랫폼은 이기종 기기 모음을 관리할 수 있는 통합 인터페이스를 제공합니다. 이 인터페이스는 여러 연결된 기기 애플리케이션에 중요하며, IoT 플랫폼과 독립형 MQTT 브로커의 주요 차이점입니다. 이 문서에서는 Google Cloud에 IoT 플랫폼 제품 아키텍처를 배포하기 전에 고려해야 할 기본적인 아키텍처 고려사항과 권장사항을 설명합니다.

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

다음 다이어그램은 Google Cloud에서 실행되는 일반 IoT 플랫폼 제품이 포함된 아키텍처의 예시를 보여줍니다.

일반적인 IoT 플랫폼 아키텍처(다음 텍스트에서 설명하는 이벤트 흐름)

위의 다이어그램과 같이 IoT 플랫폼은 기기 연결을 위해 MQTT 브로커 또는 엔드포인트를 배포합니다. IoT 플랫폼은 에지 기기의 트래픽을 분산하도록 외부 프록시 네트워크 부하 분산기에 연결됩니다. 추가 IoT 애플리케이션은 Pub/Sub 또는 Dataflow MQTT 커넥터를 사용하여 IoT 플랫폼에 연결할 수 있습니다.

IoT 플랫폼은 기기 관리 서비스 모음을 제공합니다. 다이어그램에 표시되었듯이 이러한 서비스는 다음과 같습니다.

  • 기기 사용자 인증 정보 저장소
  • 규칙 엔진
  • 기기 인증 및 승인
  • 기기 구성 관리
  • 기기 레지스트리
  • 기기 업데이트 관리

IoT 플랫폼 제품에는 일반적으로 디지털 트윈 기능, 로우 코드 개발 인터페이스, 알림 기능, 기타 분석 기능과 같은 서비스가 포함됩니다.

아키텍처 고려사항 및 선택

다음 섹션에서는 IoT 플랫폼 제품 아키텍처를 위한 아키텍처 선택과 이러한 선택이 미치는 영향을 설명합니다.

수집 엔드포인트

대부분의 상용 IoT 플랫폼 애플리케이션에는 MQTT 엔드포인트와 일반적으로 연결된 기기에서의 데이터 수집용 HTTPS 엔드포인트가 포함되어 있습니다.

MQTT

IoT 플랫폼은 다음 방법 중 하나로 MQTT 엔드포인트를 구현합니다.

  • MQTT와 다른 메시지 서비스 간 커넥터
  • 전체 MQTT 사양을 구현하는 MQTT 브로커

상용 IoT 플랫폼을 평가할 때는 사용 사례에 미치는 영향을 판단할 수 있도록 공급업체가 제품에 선택한 이전 접근 방식을 이해하는 것이 중요합니다.

경우에 따라 MQTT 엔드포인트는 Kafka 또는 Pub/Sub와 같은 백엔드 메시지 서비스에만 MQTT 클라이언트를 연결합니다. 이러한 유형의 엔드포인트는 일반적으로 전체 MQTT 프로토콜 사양을 구현하지 않으며, QoS 수준 1 및 2 또는 공유 구독과 같은 기능을 포함하지 않을 때가 종종 있습니다. 이 접근 방식의 장점은 별도의 MQTT 브로커 애플리케이션이 없으므로 IoT 플랫폼의 복잡성이 줄어든다는 것입니다. 운영 비용이 더 낮고 플랫폼이 별도의 MQTT 브로커를 사용할 때보다 유지보수가 간단합니다. 하지만 고급 MQTT 프로토콜 기능에 대한 지원이 줄기 때문에 이 접근 방식은 전체 MQTT 사양을 구현하는 독립형 MQTT 브로커보다 MQTT 메시지 전송의 유연성과 기능이 적습니다.

다른 IoT 플랫폼은 이 문서의 아키텍처 예시에 표시된 것처럼 플랫폼의 일부로 완전한 MQTT 브로커를 제공합니다. 이 브로커는 기존 오픈소스 브로커 중 하나이거나 독점 브로커를 구현한 것일 수 있습니다. 전체 MQTT 브로커는 앞에서 설명한 전체 양방향 MQTT 기능을 제공하지만 전체 브로커는 IoT 플랫폼 관리에 복잡성과 운영 비용을 추가할 수 있습니다.

HTTPS 및 기타 보조 프로토콜

MQTT 외에도 많은 IoT 플랫폼이 이 문서에서 설명하는 기본 아키텍처에 표시된 것보다 더 많은 데이터 수집 엔드포인트를 제공합니다.

HTTPS는 연결된 기기 사용 사례에서 MQTT를 대체하는 일반적인 프로토콜입니다. MQTT보다 오버헤드가 높지만 휴대전화와 같은 휴대기기, 웹브라우저, 기타 애플리케이션에서 더 광범위하게 지원됩니다. 특정 연결된 기기 애플리케이션에서 자주 사용되며 Eclipse Hono와 같은 오픈소스 플랫폼과 여러 상업용 제품에서 지원됩니다.

제약이 있는 많은 기기 애플리케이션이 RFC 7252에 정의된 CoAP(Constrained Application Protocol)을 MQTT 대안으로 사용합니다. CoAP는 내장형 기기 및 센서를 위한 오버헤드가 낮고 사용 공간이 적은 클라이언트를 대상으로 합니다. 많은 상용 IoT 플랫폼 애플리케이션에서도 CoAP 엔드포인트를 제공합니다.

부하 분산

아키텍처에 가장 적합한 부하 분산기 선택에 대한 자세한 내용은 Google Cloud의 독립형 MQTT 브로커 아키텍처의 부하 분산 섹션을 참조하세요. 이 고려사항은 이 사례에도 적용됩니다.

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

기기 사용자 인증 정보 및 인증 관리는 IoT 플랫폼 운영의 핵심 요소입니다. 연결된 기기에서 지원되는 인증 방법은 애플리케이션 및 기기 폼 팩터에 따라 크게 다릅니다. 대상 사용 사례에 적합한 인증 방법을 선택하고 선택한 인증 스키마를 올바르게 구현하는 것이 중요합니다.

독립형 MQTT 브로커와 달리 IoT 플랫폼은 기기 ID 및 사용자 인증 정보를 관리하는 통합 서비스를 제공합니다. 대부분의 IoT 플랫폼은 인증에 X.509 클라이언트 인증서 인증, (JWT 2.0과 결합할 때가 많은) JWT 토큰 기반 인증, 사용자 이름 및 비밀번호 인증을 사용합니다. 일부 플랫폼은 외부 LDAP 인증 제공업체와의 통합도 지원합니다.

이러한 스키마는 연결된 기기에서 더 적은 리소스를 필요로 하므로 일부 제한된 기기의 경우 JWT 또는 사용자 이름 및 비밀번호 인증이 더 적합할 수 있습니다. JWT 또는 사용자 이름 및 비밀번호 인증을 사용할 때는 이러한 인증 방법에서는 암호화된 연결을 요구하지 않기 때문에 mTLS 인증과 별도로 네트워크 연결을 암호화하는 것이 중요합니다. 반면에 X.509 인증서 인증은 연결된 기기에서 더 많은 리소스를 사용하지만 일반적으로 mTLS로 암호화된 연결에서 사용되므로 높은 수준의 보안을 제공합니다.

제조 시점에 에지 기기에 사용자 인증 정보를 프로비저닝하는 것도 연결된 기기 인증 스키마에서 중요한 부분이지만 이 문서에서는 다루지 않습니다.

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

연결된 기기 관리하기

일반적으로 연결된 기기는 MQTT와 같은 수집 엔드포인트 중 하나를 통해 원격 분석 이벤트 및 상태 정보를 플랫폼에 게시합니다. 멀티 프로토콜 IoT 플랫폼을 사용하는 경우 지원되는 프로토콜을 사용하여 기기에서 통신할 수 있습니다.

조직에서 다음과 같은 기능이 있는 IoT 플랫폼을 사용하는 것이 좋습니다.

  • 소프트웨어 및 시스템 업데이트: 연결된 기기에 대한 펌웨어, 소프트웨어, 애플리케이션 업데이트를 배포하고 롤백합니다. 이러한 업데이트에는 일반적으로 업데이트 자체의 스토리지와 관리도 포함됩니다.
  • 구성 업데이트: 연결된 기기에 배포된 애플리케이션 구성의 업데이트를 배포, 저장, 롤백합니다.
  • 사용자 인증 정보 만들기 및 관리: 새로운 기기 사용자 인증 정보를 만들고 연결된 기기에 사용자 인증 정보를 전송하고 기기 액세스 시도 및 활동을 감사하며 적시에 보안이 침해되거나 만료된 사용자 인증 정보를 취소합니다.
  • 규칙 엔진 및 데이터 처리: 데이터 기반 규칙 및 기타 데이터 처리 단계를 정의하고 실행합니다. 이 기능에는 규칙 및 데이터 처리 파이프라인을 정의할 수 있는 몇 가지 로우 코드 인터페이스 유형이 포함된 경우가 많습니다.

백엔드 워크로드

대부분의 IoT 플랫폼은 백엔드 워크로드 및 애플리케이션에 연결할 수 있게 해주는 자체 내부 데이터 스토리지 및 전송 기능을 제공합니다. 일반적으로 AMQP, RabbitMQ, Kafka가 내부 데이터 전송을 제공하는 데 사용됩니다. 모두 Pub/Sub SDK를 사용하여 Pub/Sub에 연결할 수 있습니다. PostgreSQL과 같은 통합 데이터베이스 시스템을 사용하여 플랫폼에 데이터를 저장할 수도 있습니다. 대부분의 경우 Cloud SQL, Firebase 또는 BigQuery와 같은 Cloud Storage 제품 중 하나를 직접 사용하도록 IoT 플랫폼을 구성할 수 있습니다.

IoT 플랫폼에 완전한 MQTT 브로커가 있는 경우 백엔드 애플리케이션이 플랫폼의 MQTT 기능을 사용하여 기기와 통신할 수도 있습니다. 애플리케이션에서 MQTT를 지원하는 경우 애플리케이션이 구독자로 브로커에 연결할 수 있습니다. MQTT가 지원되지 않는다면 Apache Beam에서 제공하는 MQTT 드라이버를 사용하면 됩니다. 이 드라이버는 Dataflow 및 다른 Beam 배포와의 양방향 통합을 지원합니다.

사용 사례

다음 섹션에서는 독립형 MQTT 브로커나 Pub/Sub에 대한 직접 연결보다 IoT 플랫폼이 아키텍처 선택 옵션으로 더 적합한 경우의 예시 시나리오를 설명합니다.

스마트 어플라이언스 관리

여러 스마트 어플라이언스를 관리하는 애플리케이션은 IoT 플랫폼에 적합합니다. 이러한 애플리케이션의 예시로는 식기 세척기 및 커피 메이커와 같은 주방 가전 관리 플랫폼이 있습니다. 이러한 기기는 일반적으로 Wi-Fi를 통해 직접 또는 저전력 블루투스(BLE)나 기타 로컬 프로토콜을 사용하는 로컬 게이트웨이를 통해 클라우드 기반 애플리케이션에 연결됩니다. 각 기기의 상태를 모니터링하고, 소프트웨어 업데이트 및 보안 패치를 관리하고, 기기 활동을 캡처하여 제조업체 및 고객에게 중요 인텔리전스를 제공하기 위해서는 IoT 플랫폼의 관리 기능이 중요합니다. 이러한 기능은 기본 MQTT 브로커의 범위를 벗어납니다. 성공적인 스마트 어플라이언스 플랫폼을 빌드하려면 최소한 기기 정보 저장소, 기기 상태 데이터베이스, 원격 분석 데이터 스토어, 분석 인터페이스가 모두 있어야 합니다.

물류 및 애셋 추적

물류 및 애셋 추적 애플리케이션의 경우 IoT 플랫폼 제품이 기본 MQTT 브로커보다 더 많은 기능을 제공하므로 이 사용 사례에 더 적합합니다. 대규모 자산의 현재 및 과거 상태와 위치를 모니터링하는 것은 강력한 기기 상태 데이터베이스와 ID 관리 시스템에 따라 좌우됩니다. 새 자산이 배치되면 최대한 불편 없이 플랫폼에 연결하고 자산 수명 주기 동안 모니터링해야 합니다. 대부분의 경우 애플리케이션에서 현지 온도, 습도, 기압 또는 3D 포지셔닝 및 가속 데이터 등 자산에 대한 기타 센서 정보를 수집하여 예상치 못한 변화나 감소를 감지합니다. 이 모든 데이터를 수집하고 백엔드 애플리케이션에서 분석할 수 있도록 올바른 자산과 연결해야 하므로 IoT 플랫폼에서 제공하는 모든 기능을 갖춘 기기 관리는 중요한 기능입니다.

다음 단계