Como escalar para 1 milhão de dispositivos

Escalando o USP para 1 milhão de dispositivos

Alcançar a escalabilidade necessária para suportar um milhão de dispositivos exige testes robustos de carga e estresse. Para o Oktopus Controller, utilizamos o OBUSPA projeto para simular dispositivos USP, conduzindo testes para entender os limites de desempenho e introduzir as salvaguardas necessárias contra picos de conexões de dispositivos.

A partir desses testes, nossa equipe desenvolveu diversas melhorias arquiteturais que serão discutidas mais adiante neste texto. Neste artigo, você encontrará informações detalhadas sobre a configuração do USP Controller e as metodologias por trás de nossos testes de estresse.

Dois grandes provedores de nuvem foram utilizados: Google Cloud Platform e AWS, com recursos implantados em várias regiões. Utilizamos a linguagem Terraform para subir instâncias executando contêineres OBUSPA. Essa configuração permitiu um controle preciso sobre as taxas de implantação de contêineres, oferecendo insights valiosos sobre o comportamento e a escalabilidade do sistema.

A arquitetura do Oktopus compreende microsserviços baseados em Golang interconectados através do sistema de mensagens NATS. Cada módulo de Protocolo de Transferência de Mensagens (MTP) inclui um tradutor que converte mensagens USP de protocolos como MQTT, STOMP e WebSockets para o formato NATS. Essa abordagem modular facilita a criação de microsserviços escaláveis que podem lidar com dados de dispositivos independentemente do tipo de conexão.

A comunicação entre o Core e a Edge do sistema é abstraída e independente. Gerenciar milhões de conexões sem tempo de inatividade é um desafio fundamental. Para resolver esse problema, o Oktopus conta com múltiplos MTPs distribuídos em regiões próximas ao dispositivo: o que chamamos de Camada de Borda (Edge Layer). Cada dispositivo possui uma conexão MTP redundante, portanto, mesmo que um servidor caia por qualquer motivo, ainda há outro caminho de conexão disponível.

Ainda é possível manter a conexão com outros controladores, criando uma conexão paralela com o dispositivo, sem comprometer o desempenho e sem ficar preso a um único ecossistema, como pode ser visto na imagem abaixo.

Para aqueles que buscam ir além, o Oktopus oferece o plano Enterprise, onde o foco é garantir entrega, redundância, segurança e confiabilidade. Nosso uso de padrões de projeto garante suporte e configuração para múltiplos locais e multi-tenancy, adaptando-se imediatamente a erros ao redirecionar para localizações geográficas alternativas caso um data center fique offline.

No próximo exemplo, você encontrará outro cenário com alguns possíveis pontos de falha. Como existe apenas um núcleo Oktopus, todo o tráfego fica concentrado em uma única instância principal.

Para uma confiabilidade ideal, a implementação de múltiplos núcleos de site é fundamental. Uma arquitetura distribuída mitiga pontos de falha e garante a comunicação contínua dos dispositivos, mesmo durante interrupções. A ilustração a seguir mostra os benefícios desta arquitetura:

Os dispositivos podem se conectar através de múltiplos MTPs usando diferentes protocolos, proporcionando resiliência. Com essas múltiplas conexões, temos diversas possibilidades. Exemplo: se uma porta for bloqueada acidentalmente, protocolos alternativos estarão disponíveis. Se a conexão entre o Edge e o Core falhar, o tráfego é redirecionado para o cluster operacional mais próximo. Estas estratégias são exemplos de como otimizamos as soluções de confiabilidade de nível empresarial do Oktopus.

Afinal, quais são os requisitos de recursos do sistema?

Após extensos testes e otimizações, nossa avaliação de desempenho é segmentada no uso de recursos do Core e do Edge:

Camada Edge: Responsável por manter as conexões dos dispositivos, cada uma utilizando cerca de 40 kBytes de memória. Para cada 10 conexões por segundo, o uso da CPU aproxima-se de 15% de 1 vCPU; portanto, quanto mais conexões por segundo, maior o uso da CPU. Em caso de falhas de rede, os pacotes são redirecionados para outros clusters ou retidos até a reconexão.

Camada Core: Implementada com Kubernetes para escalabilidade automatizada conforme a demanda, cada microsserviço lida com suas responsabilidades individualmente, permitindo um escalonamento preciso por nível de atividade. Portanto, o uso de recursos depende do número de operadores do sistema, da quantidade e tipos de dispositivos e das integrações específicas presentes. Para configurações locais (on-premises), usamos o K3S, e para implantações em nuvem, usamos o EKS, cada um oferecendo benefícios distintos.