Google Cloud에 대한 Pub/Sub 연결의 기기

일부 조직은 기기를 분석 애플리케이션에 연결하는 특정 아키텍처를 구현하는 대신 에지 기기에서 Pub/Sub에 직접 연결하는 것이 더 유용할 수 있습니다. 로컬 또는 온프레미스 네트워크의 대규모 기기 및 센서에서 데이터를 집계하는 연결된 기기의 수가 적은 조직에서 이 같은 방법을 사용하는 것이 좋습니다. 이 방법은 조직의 연결된 기기가 공장과 같이 더 안전한 환경에 있는 경우에도 권장됩니다. 이 문서에서는 이 접근 방식을 사용하여 기기를 Google Cloud 제품에 연결하는 데 필요한 대략적인 아키텍처 고려사항을 설명합니다.

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

• Google Cloud의 연결된 기기 아키텍처 개요
• Google Cloud의 독립형 MQTT 브로커 아키텍처
• Google Cloud의 IoT 플랫폼 제품 아키텍처
• Google Cloud에서 IoT 백엔드 실행 권장사항
• Google Cloud에 대한 Pub/Sub 아키텍처의 기기(이 문서)
• 에지/베어메탈 시스템 및 서버를 자동으로 프로비저닝 및 구성하기 위한 권장사항

아키텍처

다음 다이어그램은 Pub/Sub에 직접 연결되는 연결된 집계 기기 또는 게이트웨이를 보여줍니다.

위 다이어그램의 이벤트 흐름은 다음과 같습니다.

• Identity and Access Management API를 사용하여 서비스 계정의 새 키 쌍을 만듭니다. 공개 키는 IAM에 저장됩니다. 그러나 비공개 키를 인증에 사용할 수 있도록 안전하게 다운로드하여 게이트웨이 기기에 저장해야 합니다.
• 집계 기기는 안전한 로컬 네트워크 내에 있는 다른 여러 원격 기기 및 센서의 데이터를 수집합니다. 원격 기기는 MODBUS, BACNET, OPC-UA 또는 다른 로컬 프로토콜 등의 로컬 에지 프로토콜을 사용하여 게이트웨이와 통신합니다.
• 집계 기기는 HTTPS 또는 gRPC를 통해 Pub/Sub로 데이터를 전송합니다. 이러한 API 호출은 집계 기기에 저장된 서비스 계정 비공개 키를 사용하여 서명됩니다.

아키텍처 고려사항 및 선택

Pub/Sub는 서버리스 데이터 스트리밍 서비스이므로 이를 사용해 이벤트 제작자 및 소비자(게시자 및 구독자라고 함)로 구성된 양방향 시스템을 만들 수 있습니다. 일부 연결된 기기 시나리오에서는 확장 가능한 게시 및 구독 서비스만 있어도 효과적인 데이터 아키텍처를 만들 수 있습니다. 다음 섹션에서는 기기를 Google Cloud의 Pub/Sub 아키텍처에 구현할 때의 고려사항과 선택을 설명합니다.

수집 엔드포인트

Pub/Sub는 REST 및 gRPC API를 구현하는 여러 언어로 사전 빌드된 클라이언트 라이브러리를 제공합니다. 메시지 수집을 위한 두 가지 프로토콜인 REST(HTTP) 및 gRPC를 지원합니다. 연결된 기기가 Pub/Sub를 통해 데이터를 주고받으려면 기기가 이러한 엔드포인트 중 하나와 상호작용할 수 있어야 합니다.

대부분의 소프트웨어 애플리케이션에는 REST API가 기본적으로 지원되므로 Pub/Sub REST API를 사용해 연결하는 것이 가장 쉬운 솔루션일 때가 많습니다. 그러나 일부 사용 사례에서는 gRPC가 더 효율적이고 빠른 대안일 수 있습니다. gRPC는 JSON, XML 또는 다른 텍스트 기반 형식 대신 메시지 페이로드에 직렬화된 프로토콜 버퍼를 사용하기 때문에 일반적으로 연결된 기기 사용 사례에서 흔히 볼 수 있는 낮은 대역폭의 애플리케이션에 더 적합합니다. 또한 gRPC API 연결은 데이터 전송이 REST보다 빠르며 gRPC는 동시 양방향 통신을 지원합니다. 한 연구에 따르면 gRPC는 REST보다 최대 7배 더 빠르다고 합니다. 따라서 gRPC 커넥터를 사용할 수 있거나 연결된 기기 애플리케이션에 구현할 수 있다면 연결된 기기 시나리오에 gRPC가 더 적합한 옵션일 때가 많습니다.

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

Pub/Sub는 Google Cloud 외부에서 액세스할 수 있도록 여러 인증 방법을 지원합니다.

아키텍처에 Active Directory 또는 로컬 Kubernetes 클러스터와 같은 외부 ID 공급업체가 포함된 경우 워크로드 아이덴티티 제휴를 사용해 Pub/Sub 액세스를 관리할 수 있습니다. 이 접근 방식을 사용하면 연결된 기기를 위한 단기 액세스 토큰을 만들 수 있습니다. 또한 서비스 계정 키를 사용하는 데 따른 관리 및 보안 오버헤드 없이 연결된 기기에 IAM 역할을 부여할 수 있습니다.

외부 ID 공급업체를 사용할 수 없는 경우에는 서비스 계정 키가 유일한 인증 옵션입니다. 서비스 계정 키를 올바르게 관리하지 않으면 보안 위험이 될 수 있으므로 연결된 기기에 서비스 계정 키를 배포할 때는 보안 권장사항을 따르는 것이 좋습니다. 자세한 내용은 서비스 계정 키 관리 권장사항을 참조하세요. 서비스 계정은 제한된 리소스이며 모든 Cloud 프로젝트에서는 사용자 관리 서비스 계정의 할당량이 제한되어 있습니다. 따라서 이 접근 방식은 연결해야 할 기기가 적은 배포에만 사용할 수 있습니다.

백엔드 애플리케이션

데이터가 Pub/Sub 주제에 수집된 후에는 적절한 사용자 인증 정보와 액세스 권한이 있는 Google Cloud에서 실행되는 모든 애플리케이션에서 데이터를 사용할 수 있습니다. 애플리케이션에 Pub/Sub API 이외의 추가 커넥터는 필요하지 않습니다. 백엔드 인프라 전반의 여러 애플리케이션에서 병렬 처리 또는 알림뿐만 아니라 아카이브 스토리지와 기타 분석을 위해 메시지를 사용할 수 있습니다.

사용 사례

다음 섹션에서는 기기에서 Pub/Sub로 직접 연결하는 것이 연결된 기기 사용 사례에 적합한 시나리오 예시를 설명합니다.

온프레미스 데이터 기록에서 일괄 데이터 수집

기기와 Pub/Sub 간 연결은 대량의 데이터를 전송하는 엔드포인트 수가 적은 애플리케이션에 가장 적합합니다. 운영 데이터 히스토그램은 Google Cloud로 전송해야 하는 많은 데이터를 저장하는 온프레미스 시스템의 좋은 예입니다. 이 사용 사례에서는 서비스 계정 인증을 위한 일반 매개변수 내에 있는 소수의 연결된 기기에 소수의 엔드포인트를 보통 하나씩 인증해야 합니다. 이러한 시스템에는 일반적으로 Google Cloud와 통신하는 데 필요한 Pub/Sub API 연결을 구현할 수 있는 모듈식 아키텍처도 있습니다.

공장의 로컬 게이트웨이 데이터 집계

로컬 게이트웨이에서 공장 센서 데이터를 집계하는 것 또한 직접 Pub/Sub 연결에 적합한 사용 사례입니다. 이 경우 로컬 데이터 관리 및 집계 시스템이 공장의 게이트웨이 기기에 배포됩니다. 이 시스템은 일반적으로 다양한 로컬 센서 및 머신에 연결되는 소프트웨어 제품입니다. 이 제품은 데이터를 수집하여 클라우드 애플리케이션에 전달하기 전에 표준화된 표현으로 변환하는 경우가 많습니다.

이 시나리오에서는 많은 기기를 연결할 수 있습니다. 그러나 이러한 기기는 일반적으로 로컬 게이트웨이에만 연결되고 해당 기기의 소프트웨어로 관리되므로 클라우드 기반 관리 애플리케이션이 필요하지 않습니다. MQTT 브로커 아키텍처와 달리 이 사용 사례에서는 게이트웨이가 데이터를 집계 및 변환하는 데 적극적인 역할을 수행합니다.

게이트웨이는 Google Cloud에 연결될 때 서비스 계정 키를 통해 Pub/Sub에 인증됩니다. 이 키는 추가 처리를 위해 집계 및 변환된 데이터를 클라우드 애플리케이션에 전송합니다. 연결된 게이트웨이 수는 보통 서비스 계정 인증을 위한 일반적인 범위에 해당하는 수십에서 수백 개의 기기 범위 내에 속합니다.

다음 단계

• 서비스 계정 키 관리 권장사항을 알아보세요.
• 외부 워크로드의 ID 제휴 개요를 읽어보세요.
• Pub/Sub에 대해 자세히 알아보세요.
• Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항을 살펴보세요. Cloud 아키텍처 센터를 확인하세요.
• 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.