Padrão geodo

O padrão Geode envolve a implantação de uma coleção de serviços de back-end em um conjunto de gode odes, cada um dos quais pode atender a qualquer solicitação para qualquer cliente em qualquer região. Esse padrão permite atender solicitações em um estilo ativo-ativo , melhorando a latência e aumentando a disponibilidade distribuindo o processamento de solicitações em todo o mundo.

Contexto e problema

Muitos serviços de grande escala têm desafios específicos em torno da geodisponibilidade e escala. Os designs clássicos geralmente trazem os dados para a computação armazenando dados em um servidor SQL remoto que serve como a camada de computação para esses dados, dependendo da expansão para crescimento.

A abordagem clássica pode apresentar uma série de desafios:

• Problemas de latência de rede para usuários vindos do outro lado do mundo para se conectar ao ponto de extremidade de hospedagem
• Gestão de tráfego para picos de procura que podem sobrecarregar os serviços numa única região
• Complexidade proibitiva de custo de implantar cópias da infraestrutura de aplicativos em várias regiões para um serviço 24 horas por dia, 7 dias por semana

A infraestrutura de nuvem moderna evoluiu para permitir o balanceamento de carga geográfica de serviços front-end, ao mesmo tempo em que permite a replicação geográfica de serviços de back-end. Para disponibilidade e desempenho, aproximar os dados do usuário é bom. Quando os dados são distribuídos geograficamente em uma base de usuários distante, os armazenamentos de dados geodistribuídos também devem ser colocalizados com os recursos de computação que processam os dados. O padrão geode traz a computação para os dados.

Solução

Implante o serviço em várias implantações de satélites espalhadas pelo mundo, cada uma das quais é chamada de geodo. O padrão geode aproveita os principais recursos do Azure para rotear o tráfego pelo caminho mais curto para um geodo próximo, o que melhora a latência e o desempenho. Cada geode está atrás de um balanceador de carga global e usa um serviço de leitura/gravação replicado geograficamente, como o Azure Cosmos DB , para hospedar o plano de dados, garantindo a consistência de dados entre geodos. Os serviços de replicação de dados garantem que os armazenamentos de dados sejam idênticos entre geodes, para que todas as solicitações possam ser atendidas a partir de todos os geodes.

A principal diferença entre um selo de implantação e um geodo é que os geodos nunca existem isoladamente. Deve haver sempre mais do que um geodo numa plataforma de produção.

Os geodos têm as seguintes características:

• Consistem em uma coleção de tipos diferentes de recursos, geralmente definidos em um modelo.
• Não têm dependências fora da pegada geoda e são independentes. Nenhum geodo depende de outro para operar, e se um morre, os outros continuam a operar.
• São acoplados de forma flexível por meio de uma rede de borda e backplane de replicação. Por exemplo, você pode usar o Azure Traffic Manager ou o Azure Front Door para frontar os geodes, enquanto o Azure Cosmos DB pode atuar como o backplane de replicação. Geodes não são o mesmo que clusters porque compartilham um backplane de replicação, então a plataforma cuida de problemas de quórum.

O padrão geode ocorre em arquiteturas de big data que usam hardware de mercadoria para processar dados colocalizados na mesma máquina e MapReduce para consolidar resultados entre máquinas. Outro uso é a computação near-edge, que aproxima a computação da borda inteligente da rede para reduzir o tempo de resposta.

Os serviços podem usar esse padrão em dezenas ou centenas de geodos. Além disso, a resiliência de toda a solução aumenta a cada geodo adicionado, uma vez que qualquer geodo pode assumir o controle se uma interrupção regional colocar um ou mais geodos offline.

Também é possível aumentar as técnicas de disponibilidade local, como zonas de disponibilidade ou regiões emparelhadas, com o padrão geode para disponibilidade global. Isso aumenta a complexidade, mas é útil se sua arquitetura for sustentada por um mecanismo de armazenamento, como o armazenamento de blobs, que só pode ser replicado para uma região emparelhada. Você pode implantar geodos em uma pegada intrazona, zonal ou regional, tendo em mente as restrições regulatórias ou de latência no local.

Problemas e considerações

Use as seguintes técnicas e tecnologias para implementar esse padrão:

• Práticas e ferramentas modernas de DevOps para produzir e implantar rapidamente geodes idênticos em um grande número de regiões ou instâncias.
• Dimensionamento automático para dimensionar instâncias de computação e taxa de transferência de banco de dados dentro de um geode. Cada geodo é dimensionado individualmente, dentro das restrições comuns do backplane.
• Um serviço front-end como o Azure Front Door que faz aceleração de conteúdo dinâmico, TCP dividido e roteamento Anycast.
• Um armazenamento de dados replicante como o Azure Cosmos DB para controlar a consistência dos dados.
• Tecnologias sem servidor sempre que possível, para reduzir o custo de implantação sempre ativo, especialmente quando a carga é frequentemente rebalanceada em todo o mundo. Esta estratégia permite que muitos geodos sejam implantados com investimento adicional mínimo. As tecnologias de faturamento sem servidor e baseadas no consumo reduzem o desperdício e o custo de implantações distribuídas geograficamente duplicadas.
• O Gerenciamento de API não é necessário para implementar o padrão de design, mas pode ser adicionado a cada geodo que faz frente ao Aplicativo de Função do Azure da região para fornecer uma camada de API mais robusta, permitindo a implementação de funcionalidades adicionais, como limitação de taxa, por exemplo.

Na altura de decidir como implementar este padrão, considere os seguintes pontos:

• Escolha se deseja processar dados localmente em cada região ou distribuir agregações em um único geodo e replicar o resultado em todo o mundo. O processador de feed de alterações do Azure Cosmos DB oferece esse controle granular usando seu conceito de contêiner de concessão e o leasecollectionprefix na associação correspondente do Azure Functions. Cada abordagem tem vantagens e desvantagens distintas.
• Os Geodes podem trabalhar em conjunto, usando o feed de alterações do Azure Cosmos DB e uma plataforma de comunicação em tempo real como o SignalR. Os geodos podem se comunicar com usuários remotos através de outros geodos em um padrão de malha, sem saber ou se importar onde o usuário remoto está localizado.
• Este padrão de design desacopla implicitamente tudo, resultando numa arquitetura ultra-altamente distribuída e dissociada. Considere como controlar diferentes componentes da mesma solicitação, pois eles podem ser executados de forma assíncrona em instâncias diferentes. É crucial uma estratégia de acompanhamento adequada. O Azure Front Door e o Azure Cosmos DB podem ser facilmente integrados ao Log Analytics e o Azure Functions deve ser implantado junto com o Application Insights para fornecer um sistema de monitoramento robusto em cada componente da arquitetura.
• As implantações distribuídas têm um número maior de segredos e pontos de entrada que exigem medidas de segurança de propriedade. O Key Vault fornece uma camada segura para gerenciamento secreto e cada camada dentro da arquitetura da API deve ser protegida corretamente para que o único ponto de entrada para a API seja o serviço front-end, como o Azure Front Door. O Azure Cosmos DB deve restringir o tráfego para os Aplicativos de Função do Azure e os aplicativos de Função para a Porta da Frente do Azure usando a ID do Microsoft Entra ou práticas como restrição de IP.
• O desempenho é drasticamente afetado pelo número de geodos implantados e pelos Planos do Serviço de Aplicativo específicos aplicados à tecnologia de API em cada geode. A implantação de geodos adicionais ou o movimento em direção a níveis premium vêm com custos maiores para a memória e computação adicionais, mas não o fazem por transação. Considere o teste de carga da arquitetura de API uma vez implantada e compare o aumento do número de geodos com o aumento da camada de preços para que o modelo mais econômico seja usado para suas necessidades.
• Determine os requisitos de disponibilidade para seus dados. O Azure Cosmos DB tem sinalizadores opcionais para habilitar a gravação em várias regiões, zonas de disponibilidade e muito mais. Eles aumentam a disponibilidade para a instância do Azure Cosmos DB e criam uma camada de dados mais resiliente, mas vêm com custos adicionais.
• O Azure oferece uma variedade de balanceadores de carga que fornecem diferentes funcionalidades para distribuição de tráfego. Use a árvore de decisão para ajudar a selecionar a opção certa para o front-end da sua API.

Quando utilizar este padrão

Utilize este padrão:

• Implementar uma plataforma de alta escala que tenha utilizadores distribuídos por uma vasta área.
• Para qualquer serviço que exija extrema disponibilidade e características de resiliência, porque os serviços baseados no padrão geode podem sobreviver à perda de várias regiões de serviço ao mesmo tempo.

Este padrão pode não ser adequado para

• Arquiteturas que têm restrições para que todos os geodos não possam ser iguais para armazenamento de dados. Por exemplo, pode haver requisitos de residência de dados, um aplicativo que precisa manter um estado temporário para uma sessão específica ou um peso pesado de solicitações para uma única região. Nesse caso, considere o uso de carimbos de implantação em combinação com um plano de roteamento global que esteja ciente de onde os dados de um usuário estão, como o componente de roteamento de tráfego descrito no padrão de carimbos de implantação.
• Situações em que não é necessária uma distribuição geográfica. Em vez disso, considere zonas de disponibilidade e regiões emparelhadas para clustering.
• Situações em que uma plataforma legada precisa ser adaptada. Esse padrão funciona apenas para desenvolvimento nativo da nuvem e pode ser difícil de adaptar.
• Arquiteturas e requisitos simples, onde a redundância geográfica e a distribuição geográfica não são necessárias ou vantajosas.

Design da carga de trabalho

Um arquiteto deve avaliar como o padrão Geode pode ser usado no design de sua carga de trabalho para abordar as metas e os princípios abordados nos pilares do Azure Well-Architected Framework. Por exemplo:

Como em qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com esse padrão.

Exemplos

• O Windows Ative Directory implementa uma variante inicial desse padrão. A replicação multiprimária significa que todas as atualizações e solicitações podem, em teoria, ser atendidas a partir de todos os nós passíveis de manutenção, mas as funções FSMO (Flexible Single Master Operation, operação mestre única) significam que todos os geodos não são iguais.
• O acelerador de padrão de geode no GitHub mostra esse padrão de design na prática e foi projetado para ajudar os desenvolvedores a implementá-lo com APIs do mundo real.
• Um aplicativo de exemplo QnA no GitHub mostra esse padrão de design na prática.