Dispositivo na conexão do Pub/Sub com o Google Cloud

Last reviewed 2023-01-26 UTC

Em vez de implementar uma arquitetura específica para conectar dispositivos a aplicativos de análise, algumas organizações podem se beneficiar da conexão direta ao Pub/Sub a partir de dispositivos de borda. Recomendamos essa abordagem para organizações que tenham um pequeno número de dispositivos conectados que agregam dados de um número maior de dispositivos e sensores em uma rede local. Essa abordagem também é recomendada quando sua organização tem dispositivos conectados que estão em um ambiente mais seguro, como uma fábrica. Este documento descreve as considerações de arquitetura de alto nível que você precisa fazer para usar essa abordagem para conectar dispositivos a produtos do Google Cloud.

Este documento faz parte de uma série de documentos que fornecem informações sobre arquiteturas de IoT no Google Cloud e como migrar do IoT Core. Os outros documentos desta série incluem:

Arquitetura

O diagrama a seguir mostra um gateway ou dispositivo de agregação conectado diretamente ao Pub/Sub.

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

O fluxo de eventos no diagrama anterior é o seguinte:

  • Use a API Identity and Access Management para criar um novo par de chaves para uma conta de serviço. A chave pública é armazenada no IAM. No entanto, você precisa fazer o download da chave privada com segurança e armazená-la no dispositivo de gateway para que ela possa ser usada para autenticação.
  • O dispositivo de agregação coleta dados de vários outros dispositivos e sensores remotos localizados em uma rede local segura. Os dispositivos remotos se comunicam com o gateway usando um protocolo de borda local, como MODBUS, BACNET, OPC-UA ou outro protocolo local.
  • O dispositivo de agregação envia dados ao Pub/Sub por HTTPS ou gRPC. Essas chamadas de API são assinadas usando a chave privada da conta de serviço contida no dispositivo de agregação.

Considerações e escolhas sobre arquitetura

Como o Pub/Sub é um serviço de streaming de dados sem servidor, ele pode ser usado para criar sistemas bidirecionais compostos por produtores e consumidores de eventos (conhecidos como editores e assinantes). Em alguns cenários de dispositivos conectados, você só precisa de um serviço de publicação e assinatura escalonável para criar uma arquitetura de dados eficaz. As seções a seguir descrevem as considerações e escolhas que você precisa fazer ao implementar um dispositivo na arquitetura do Pub/Sub no Google Cloud.

Endpoints de ingestão

O Pub/Sub fornece bibliotecas de cliente pré-criadas em várias linguagens que implementam as APIs REST e gRPC. Ele é compatível com dois protocolos para ingestão de mensagens: REST (HTTP) e gRPC. Para que um dispositivo conectado envie e receba dados pelo Pub/Sub, ele precisa interagir com um desses endpoints.

Muitos aplicativos de software têm compatibilidade integrada com APIs REST. Portanto, a conexão com a API REST do Pub/Sub geralmente é a solução mais fácil. Em alguns casos de uso, no entanto, o gRPC pode ser uma alternativa mais eficiente e mais rápida. Como ele usa buffers de protocolo serializados para o payload da mensagem em vez de JSON, XML ou outro formato baseado em texto, o gRPC é mais adequado para os aplicativos de baixa largura de banda que são comumente encontrados nos casos de uso de dispositivos conectados. As conexões da API gRPC também são mais rápidas do que o REST para transmissão de dados, e o gRPC é compatível com a comunicação bidirecional simultânea. Um estudo descobriu que o gRPC é até sete vezes mais rápido que o REST. Como resultado, para muitos cenários de dispositivos conectados, o gRPC é uma opção melhor se um conector gRPC estiver disponível ou puder ser implementado no aplicativo de dispositivo conectado.

Autenticação de dispositivos e gerenciamento de credenciais

O Pub/Sub é compatível com vários métodos de autenticação para acesso de fora do Google Cloud.

Se a arquitetura incluir um provedor de identidade externo, como o Active Directory ou um cluster local do Kubernetes, será possível usar a federação de identidade da carga de trabalho para gerenciar o acesso ao Pub/Sub. Essa abordagem permite criar tokens de acesso de curta duração para dispositivos conectados. Também é possível conceder papéis do IAM aos dispositivos conectados, sem a sobrecarga de gerenciamento e segurança do uso de chaves da conta de serviço.

Quando um provedor de identidade externo não está disponível, as chaves da conta de serviço são a única opção de autenticação. As chaves de conta de serviço podem ser um risco de segurança se não forem gerenciadas corretamente. Portanto, siga as práticas recomendadas de segurança para implantar chaves de conta de serviço em dispositivos conectados. Para saber mais, consulte Práticas recomendadas para gerenciar chaves de conta de serviço. As contas de serviço também são um recurso limitado, e qualquer projeto na nuvem tem uma cota limitada de contas de serviço gerenciadas pelo usuário. Consequentemente, essa abordagem é apenas uma opção para implantações com um pequeno número de dispositivos que precisam ser conectados.

Aplicativos de back-end

Depois que os dados são ingeridos em um tópico do Pub/Sub, eles são disponibilizados para qualquer aplicativo executado no Google Cloud que tenha as credenciais e os privilégios de acesso apropriados. Nenhum outro conector é necessário além da API Pub/Sub no seu aplicativo. As mensagens podem ser disponibilizadas a vários aplicativos em toda a infraestrutura de back-end para processamento paralelo ou alertas, assim como armazenamento em arquivo e outras análises.

Casos de uso

As seções a seguir descrevem cenários de exemplo em que uma conexão direta dos dispositivos com o Pub/Sub é adequada para casos de uso de dispositivos conectados.

Ingestão de dados em massa de um histórico de dados no local

Um dispositivo para conexão com o Pub/Sub é mais adequado para aplicativos que têm um pequeno número de endpoints que transmitem grandes volumes de dados. Um histórico de dados operacionais é um bom exemplo de um sistema local que armazena muitos dados que precisam ser transmitidos para o Google Cloud. Para este caso de uso, um pequeno número de endpoints precisa ser autenticado, geralmente de um a poucos dispositivos conectados, o que está dentro dos parâmetros típicos para a autenticação da conta de serviço. Esses sistemas também costumam ter arquiteturas modulares que permitem implementar a conexão da API Pub/Sub que você precisa para se comunicar com o Google Cloud.

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

A agregação de dados do sensor de fábrica em um gateway local é outro caso de uso adequado para uma conexão direta do Pub/Sub. Nesse caso, um sistema local de gerenciamento e agregação de dados é implantado em um dispositivo de gateway na fábrica. Esse sistema geralmente é um produto de software que se conecta a uma grande variedade de sensores e máquinas locais. O produto coleta os dados e os transforma com frequência em uma representação padronizada antes de transmiti-la ao aplicativo na nuvem.

Muitos dispositivos podem ser conectados neste cenário. No entanto, esses dispositivos geralmente são conectados apenas ao gateway local e gerenciados pelo software nesse dispositivo. Portanto, não é necessário um aplicativo de gerenciamento baseado na nuvem. Ao contrário de uma arquitetura de agente MQTT, neste caso de uso, o gateway desempenha um papel ativo na agregação e transformação dos dados.

Quando o gateway se conecta ao Google Cloud, ele é autenticado no Pub/Sub usando uma chave de conta de serviço. A chave envia os dados agregados e transformados para o aplicativo em nuvem para processamento adicional. O número de gateways conectados geralmente está na faixa de dezenas a centenas de dispositivos, o que está dentro do intervalo típico de autenticação de contas de serviço.

A seguir