Dispositivo na ligação do Pub/Sub a Google Cloud

Last reviewed 2024-08-09 UTC

Em vez de implementar uma arquitetura específica para ligar dispositivos a aplicações de estatísticas, algumas organizações podem beneficiar da ligação direta ao Pub/Sub a partir de dispositivos periféricos. Recomendamos esta abordagem para organizações que têm um pequeno número de dispositivos ligados que agregam dados de um número maior de dispositivos e sensores numa rede local ou no local. Esta abordagem também é recomendada quando a sua organização tem dispositivos ligados que se encontram num ambiente mais seguro, como uma fábrica. Este documento descreve as considerações arquitetónicas de alto nível que tem de fazer para usar esta abordagem para ligar dispositivos a Google Cloud produtos.

Este documento faz parte de uma série de documentos que fornecem informações sobre as arquiteturas de IoT no Google Cloud. Os outros documentos desta série incluem o seguinte:

Arquitetura

O diagrama seguinte mostra um dispositivo de agregação ou um gateway ligado que se liga diretamente ao Pub/Sub.

Arquitetura de gateway ou dispositivo de agregação ligada ao Pub/Sub (fluxo de eventos explicado no texto seguinte).

O fluxo de eventos no diagrama anterior é o seguinte:

  • Usa a API Identity and Access Management para criar um novo par de chaves para uma conta de serviço. A chave pública está armazenada no IAM. No entanto, tem de transferir a chave privada de forma segura e armazená-la no dispositivo de gateway para que possa ser usada para autenticação.
  • O dispositivo de agregação recolhe dados de vários outros dispositivos remotos e sensores localizados numa rede local segura. Os dispositivos remotos comunicam com o gateway através de um protocolo de limite local, como MODBUS, BACNET, OPC-UA ou outro protocolo local.
  • O dispositivo de agregação envia dados para o Pub/Sub através de HTTPS ou gRPC. Estas chamadas API são assinadas através da chave privada da conta de serviço mantida no dispositivo de agregação.

Considerações e escolhas arquitetónicas

Uma vez que o Pub/Sub é um serviço de streaming de dados sem servidor, pode usá-lo para criar sistemas bidirecionais compostos por produtores e consumidores de eventos (conhecidos como publicadores e subscritores). Em alguns cenários de dispositivos ligados, só precisa de um serviço de publicação e subscrição escalável para criar uma arquitetura de dados eficaz. As secções seguintes descrevem as considerações e as escolhas que tem de fazer quando implementa uma arquitetura de dispositivo para Pub/Sub no Google Cloud.

Pontos finais de carregamento

O Pub/Sub fornece bibliotecas cliente pré-criadas em vários idiomas que implementam as APIs REST e gRPC. Suporta dois protocolos para o carregamento de mensagens: REST (HTTP) e gRPC. Para que um dispositivo ligado envie e receba dados através do Pub/Sub, o dispositivo tem de conseguir interagir com um destes pontos finais.

Muitas aplicações de software têm suporte integrado para APIs REST, pelo que a ligação à API REST Pub/Sub é frequentemente a solução mais fácil. No entanto, em alguns casos de utilização, o gRPC pode ser uma alternativa mais eficiente e rápida. Uma vez que usa buffers de protocolo serializados para a carga útil da mensagem em vez de JSON, XML ou outro formato baseado em texto, o gRPC é mais adequado para as aplicações de largura de banda baixa que se encontram frequentemente em exemplos de utilização de dispositivos ligados. As ligações da API gRPC também são mais rápidas do que o REST para a transmissão de dados, e o gRPC suporta a comunicação bidirecional simultânea. Um estudo concluiu que o gRPC é até sete vezes mais rápido do que o REST. Como resultado, para muitos cenários de dispositivos ligados, o gRPC é uma melhor opção se um conetor gRPC estiver disponível ou puder ser implementado para a aplicação de dispositivo ligado.

Autenticação de dispositivos e gestão de credenciais

O Pub/Sub suporta vários métodos de autenticação para acesso a partir do exterior Google Cloud.

Se a sua arquitetura incluir um fornecedor de identidade externo, como o Active Directory ou um cluster local do Kubernetes, pode usar a federação de identidades de cargas de trabalho para gerir o acesso ao Pub/Sub. Esta abordagem permite-lhe criar tokens de acesso de curta duração para dispositivos ligados. Também pode conceder funções do IAM aos seus dispositivos ligados, sem a sobrecarga de gestão e segurança da utilização de chaves de contas de serviço.

Nos casos em que um fornecedor de identidade externo não está disponível, as chaves da conta de serviço são a única opção para autenticação. As chaves de contas de serviço podem tornar-se um risco de segurança se não forem geridas corretamente. Por isso, recomendamos que siga as práticas recomendadas de segurança para implementar chaves de contas de serviço em dispositivos ligados. Para saber mais, consulte o artigo Práticas recomendadas para gerir chaves de contas de serviço. As contas de serviço também são um recurso limitado e qualquer projeto na nuvem tem uma quota limitada de contas de serviço geridas pelo utilizador. Consequentemente, esta abordagem só é uma opção para implementações que tenham um pequeno número de dispositivos que precisam de ser ligados.

Aplicações de back-end

Depois de os dados serem carregados para um tópico do Pub/Sub, ficam disponíveis para qualquer aplicação que seja executada e que tenha as credenciais e os privilégios de acesso adequados. Google Cloud Não são necessários conetores adicionais, exceto a API Pub/Sub na sua aplicação. As mensagens podem ser disponibilizadas a várias aplicações na sua infraestrutura de back-end para processamento paralelo ou alertas, bem como armazenamento de arquivo e outras estatísticas.

Exemplos de utilização

As secções seguintes descrevem cenários de exemplo em que uma ligação direta de dispositivos ao Pub/Sub é adequada para casos de utilização de dispositivos ligados.

Carregamento de dados em massa a partir de um histórico de dados no local

Uma ligação de dispositivo para o Pub/Sub é mais adequada para aplicações com um pequeno número de pontos finais que transmitem grandes volumes de dados. Um histórico de dados operacionais é um bom exemplo de um sistema no local que armazena muitos dados que têm de ser transmitidos para Google Cloud. Para este exemplo de utilização, é necessário autenticar um pequeno número de pontos finais, normalmente um a alguns dispositivos ligados, o que se enquadra nos parâmetros típicos para a autenticação de contas de serviço. Estes sistemas também têm normalmente arquiteturas modulares, o que lhe permite implementar a ligação da API Pub/Sub de que precisa para comunicar com o Google Cloud.

Agregação de dados de gateway local para uma fábrica

A agregação de dados de sensores de fábrica num gateway local é outro exemplo de utilização adequado para uma ligação direta do Pub/Sub. Neste caso, é implementado um sistema de gestão e agregação de dados locais num dispositivo de gateway na fábrica. Normalmente, este sistema é um produto de software que se liga a uma grande variedade de sensores e máquinas locais. O produto recolhe os dados e transforma-os frequentemente numa representação padronizada antes de os transmitir à aplicação na nuvem.

Neste cenário, é possível ligar muitos dispositivos. No entanto, esses dispositivos estão normalmente ligados apenas ao gateway local e são geridos pelo software nesse dispositivo, pelo que não é necessária uma aplicação de gestão baseada na nuvem. Ao contrário do que acontece numa arquitetura de agente MQTT, neste exemplo de utilização, o gateway desempenha um papel ativo na agregação e transformação dos dados.

Quando o gateway se liga ao Google Cloud, autentica-se com o Pub/Sub através de uma chave de conta de serviço. A chave envia os dados agregados e transformados para a aplicação na nuvem para processamento adicional. Normalmente, o número de gateways ligados também está no intervalo de dezenas a centenas de dispositivos, o que está dentro do intervalo típico para a autenticação de contas de serviço.

O que se segue?