Tempo para sincronizar na consistência em sistemas IIoT

Um tópico importante (e muito debatido) no projeto de sistema distribuído é qual modelo de consistência usar. Os modelos de consistência influenciam muitas partes do design do sistema, e escolher um em vez do outro impacta coisas como disponibilidade do sistema e robustez contra falhas de rede. Este blog é destinado a arquitetos de sistemas que desejam entender melhor o que significa ser ou não consistente.

Primeiro, vamos esclarecer que este blog não é sobre o "C" no ACID (https://en.wikipedia.org/wiki/ACID). A consistência do ACID garante que as atualizações em um armazenamento de dados sejam válidas de acordo com um conjunto de restrições. Este blog se concentra no tipo de consistência que descreve o que acontece quando os dados são replicados entre lojas distribuídas. Acontece que o ACID faz diga algo sobre isso, mas é o "eu" (isolamento), não o "C". Está confuso? Um pouco, mas tenha paciência comigo.

O isolamento também é conhecido como consistência forte . Quando um sistema é fortemente consistente, todas as gravações e leituras entre armazenamentos distribuídos são executadas na mesma ordem para todos os aplicativos desse sistema. Essa é uma maneira elaborada de dizer que, quando um aplicativo escreve algo, todos os aplicativos que leem depois a gravação, têm a garantia de ver os novos dados.

Esta é uma propriedade incrivelmente útil em muitos sistemas. Ele garante que duas pessoas não possam pedir a mesma geladeira em um site de compras, nem mesmo quando compram exatamente ao mesmo tempo. A consistência forte impõe a mesma ordem de operações globalmente , portanto, duas compras são sempre processadas por todos no mesmo pedido. Na prática, isso significa que na segunda tentativa de compra é garantido que o refrigerador está esgotado.

Uma consistência forte parece uma coisa muito legal de se ter, então por que nem todos os sistemas a usam? É por causa de algo chamado teorema CAP (https://en.wikipedia.org/wiki/CAP_theorem). Em primeiro lugar, uma nota rápida:o CAP foi criticado com razão por muitos porque é muito simples descrever o comportamento de sistemas distribuídos complexos - portanto, tenha cuidado ao usá-lo - mas ele fornece uma estrutura útil para discutir modelos de consistência. Não vou entrar em detalhes sobre o CAP porque a internet tem muitos recursos que fazem um trabalho muito melhor do que eu poderia esperar fazer aqui.

Em resumo, o CAP nos diz o que acontece em sistemas distribuídos quando os aplicativos perdem temporariamente a capacidade de "falar", ou em outras palavras:quando a rede cai. Acontece que é impossível para um sistema ser fortemente consistente e sempre garanta o uptime, independentemente da perda de conectividade. Desapontamento.

Isso parece complexo, mas na verdade é bastante intuitivo. Lembra-se de como a consistência forte requer uma ordem global para todas as operações em um sistema? Isso significa que uma leitura obrigatória veja todas as gravações anteriores, de todos. Se nem todos os aplicativos estiverem conectados, isso se tornará impossível de garantir. Um aplicativo pode ter feito um pedido de geladeira, mas se nem todos os aplicativos tiverem recebido esse pedido ainda, eles não poderão fazer novos pedidos. Isso resulta em tempo de inatividade para o site de compras!

O tempo de inatividade pode ser mitigado aplicando mais recursos ao problema, como fazer a replicação do banco de dados (mais armazenamento) ou implantar servidores web redundantes (mais computação). Hoje, isso é quase trivial de fazer em infraestruturas de nuvem pública, embora se torne bastante caro e complexo quando um sistema tem muitas partes móveis, como em arquiteturas de microsserviço. Quando um sistema não está sendo executado em uma nuvem, adicionar mais recursos está longe de ser trivial, pois o armazenamento, a computação e a largura de banda são muito mais restritos em ambientes fora da nuvem.

Portanto, embora a consistência forte seja conveniente para os aplicativos, ela é desgastante para a infraestrutura (e sua carteira!). Para contornar esses problemas, pessoas inteligentes surgiram com soluções que não são tão pedantes quando se trata de consistência, mas ainda viáveis ​​do ponto de vista do aplicativo. Estamos falando de “consistência eventual”. É hora de outra definição.

Um sistema é eventualmente consistente quando, se não houver atualizações para um determinado item, todos os aplicativos eventualmente veem o mesmo valor. Ou em termos leigos:todos eventualmente verão os mesmos dados se esperarem o tempo suficiente. Isso significa que os aplicativos podem ler e escrever ao mesmo tempo, e podem fazê-lo mesmo quando a rede está desligada! Eventualmente, a infraestrutura do sistema fornece todas as atualizações para os aplicativos.

Como os aplicativos não precisam esperar uns pelos outros, o tempo de atividade de um sistema eventualmente consistente é teoricamente infinito - desde que seus aplicativos não travem nem ocorra queda de energia. Infinito não é prático; depois de algum tempo, você espera que seus aplicativos se reconectem. Portanto, sistemas eventualmente consistentes normalmente colocam um limite no tempo que pode levar para se tornarem consistentes. Quando esse limite expira e os aplicativos não têm a chance de sincronizar, ocorre a recuperação de falha.

A disponibilidade não é a única vantagem de sistemas eventualmente consistentes. Como as leituras e gravações não requerem sincronização, como é o caso de sistemas fortemente consistentes, elas são muito mais rápidas. A falta de sincronização também permite a comunicação ponto a ponto direta, o que melhora ainda mais o desempenho e, ao mesmo tempo, melhora a robustez, pois elimina a necessidade de um agente de mensagens centralizado, que introduz pontos únicos de falha.

Embora a consistência eventual não funcione para sites de compras, ao considerar suas vantagens (disponibilidade, desempenho, robustez, eficiência de recursos) não deve ser surpresa que seja muito usada em sistemas de missão crítica.

O RTI Connext Product Suite é a implementação líder do padrão OMG DDS, que é amplamente implantado como um protocolo em sistemas IoT industriais de missão crítica. Uma grande diferença entre OMG DDS e outros protocolos de conectividade, é que o DDS se comporta como um banco de dados distribuído que é continuamente sincronizado entre os aplicativos, enquanto outros protocolos normalmente fornecem uma interface para enviar mensagens e deixar o gerenciamento de estado para o aplicativo.

Se você acha que um banco de dados distribuído soa como algo que tem que lidar com consistência, você está certo. O RTI Connext DDS deve equilibrar constantemente disponibilidade e desempenho versus consistência para poder trabalhar nos ambientes de missão crítica mais exigentes. Por padrão, o RTI Connext DDS usa consistência eventual que garante que os aplicativos criados com ele não parem de funcionar quando a rede falhar, enquanto garante que todos os aplicativos eventualmente compartilhem a mesma visão de "mundo".

Agora você vê como algo que soa tão abstrato como "consistência" tem consequências de longo alcance e deve ser tratado como um tópico importante no projeto inicial do sistema. Infelizmente, nunca é tão simples quanto ser "fortemente consistente" ou "eventualmente consistente". Uma arquitetura lambda (https://en.wikipedia.org/wiki/Lambda_architecture) é apenas um exemplo que usa consistência forte e eventual para obter o melhor dos dois mundos. Com tantos tons de consistência, os arquitetos de sistema precisam tomar decisões complexas sobre quanta consistência seu sistema pode suportar.

Na RTI, nossa equipe de serviços profissionais ajuda você a tomar essas decisões, refletir sobre as consequências e configurar nossos produtos para criar uma solução de consistência que funcione para você.

Saiba mais sobre os serviços RTI aqui:https://www.rti.com/services