Padrão de geode

O padrão geode envolve a implantação de uma coleção de serviços de back-end em um conjunto de nós geográficos, cada um dos quais pode atender solicitações para qualquer cliente em todas as regiões. Esse padrão permite atender solicitações em um estilo ativo-ativo, melhorando a latência e aumentando a disponibilidade com a distribuição do processamento de solicitações por todo o mundo.

Contexto e problema

Muitos serviços de grande escala têm desafios específicos em relação à disponibilidade geográfica e à escala. Os designs clássicos geralmente trazem os dados para a computação por meio do armazenamento em um servidor SQL remoto que serve como camada de computação para esses dados, dependendo da escala vertical para o crescimento.

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

• Problemas com a latência de rede para usuários do outro lado do mundo que desejam se conectar ao ponto de extremidade de hospedagem
• Gerenciamento de tráfego para intermitências de demanda que podem sobrecarregar os serviços em uma única região
• Complexidade e custo muito elevado para a implantação de cópias da infraestrutura de aplicativo 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áfico em serviços de front-end, bem como a replicação geográfica dos serviços de back-end. Portanto, aproximar os dados do usuário é o melhor jeito de ter disponibilidade e desempenho. Quando os dados são distribuídos geograficamente em uma base de usuários vasta, os armazenamentos de dados distribuídos geograficamente também precisam ser colocados com os recursos de computação que processam os dados. O padrão de geode traz a computação para os dados.

Solução

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

A principal diferença entre um selo de implantação e um geode é que os geodes nunca existem isoladamente. Sempre deve haver mais de um geode em uma plataforma de produção.

Os geodes têm as seguintes características:

• São uma coleção de tipos diferentes de recursos, geralmente definidos em um modelo.
• Não têm dependências fora da área do geode e são autossuficientes. Nenhum geode depende de outro para operar, e se um falhar, os outros continuarão funcionando.
• São acoplados de modo flexível por meio de um backplane de rede de borda e replicação. Por exemplo, é possível usar o Gerenciador de Tráfego do Azure ou o Azure Front Door na frente dos geodes, enquanto o Azure Cosmos DB pode atuar como backplane de replicação. Os geodes não são iguais aos clusters porque compartilham um backplane de replicação; portanto, a plataforma cuida de problemas de quorum.

O padrão de geode ocorre em arquiteturas de Big Data que usam hardware comum para processar dados colocados no mesmo computador e MapReduce para consolidar resultados entre computadores. Outro uso é a computação nas proximidades da borda, o que aproxima a computação de borda inteligente da rede para reduzir o tempo de resposta.

Os serviços podem usar esse padrão em dezenas ou centenas de geodes. Além disso, a resiliência da solução aumenta a cada geode adicionado, visto que qualquer geode pode assumir o comando caso uma interrupção regional desconecte um ou mais geodes.

Também é possível aumentar as técnicas de disponibilidade local com o padrão de geode, como zonas de disponibilidade ou regiões emparelhadas, para ter disponibilidade global. Isso aumenta a complexidade, mas é útil se a arquitetura for sustentada por um mecanismo de armazenamento, como o armazenamento de blobs, que só pode ser replicado para uma região emparelhada. É possível implantar geodes em uma volumes intrazona, zonais ou regionais, sem esquecer das restrições regulatórias ou de latência no local.

Problemas e considerações

Siga estas técnicas e tecnologias para implementar o 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 escalar horizontalmente instâncias de computação e taxa de transferência de banco de dados em um geode. Cada geode é escalado horizontalmente de acordo com as restrições comuns para o backplane.
• Um serviço front-end como o Azure Front Door, que faz aceleração de conteúdo dinâmico, divisão de TCP e roteamento Anycast.
• Um armazenamento de dados de replicação 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 ativa, especialmente quando a carga é frequentemente rebalanceada em todo o mundo. Essa estratégia permite que muitos geodes sejam implantados com o mínimo de investimento adicional. As tecnologias de cobrança baseadas em consumo e sem servidor reduzem o desperdício e o custo de implantações duplicadas distribuídas geograficamente.
• O Gerenciamento de API não é necessário para implementar o padrão de design, mas pode ser adicionado a cada geode que está na frente do Aplicativo de Funções do Azure da região para fornecer uma camada de API mais robusta, permitindo a implementação de outras funcionalidades, como limitação de taxa, por exemplo.

Considere os seguintes pontos ao decidir como implementar esse padrão:

• Escolha se quer processar dados localmente em cada região ou distribuir agregações em um único geode e replicar o resultado em todo o mundo. O processador do feed de alterações do Azure Cosmos DB oferece esse controle granular com seu conceito de contêiner de concessão e o leasecollectionprefix na associação de Azure Functions correspondente. Cada abordagem tem vantagens e desvantagens diferentes.
• Os geodes podem funcionar 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 geodes podem se comunicar com usuários remotos por meio de outros geodes em um padrão de malha, sem saber ou se importar com o local do usuário remoto.
• Esse padrão de design separa tudo implicitamente, resultando em uma arquitetura ultra-altamente distribuída e desacoplada. Pense em como rastrear diferentes componentes da mesma solicitação, já que eles podem ser executados de maneira assíncrona em instâncias distintas. É crucial ter uma estratégia de monitoramento adequada. O Azure Front Door e o Azure Cosmos DB podem ser facilmente integrados ao Log Analytics, e o Azure Functions deve ser implantados junto com o Application Insights para fornecer um sistema de monitoramento robusto em cada componente na 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 cria uma camada segura para o gerenciamento de segredos e cada camada dentro da arquitetura de API deve ser protegida corretamente para que o único ponto de entrada para a API seja o serviço de front-end, como o Azure Front Door. O Azure Cosmos DB deve restringir o tráfego para os Aplicativos de Funções do Azure e dos aplicativos de funções para o Azure Front Door usando o Microsoft Entra ID ou práticas como restrição de IP.
• O desempenho é radicalmente afetado pelo número de geodes implantados e pelos planos de Serviço de Aplicativo específicos aplicados à tecnologia de API em cada geode. A implantação de geodes adicionais ou a migração para camadas premium geram custos maiores para a memória e a computação adicionais, mas não por transação. Faça um teste de carga na arquitetura da API após a implantação e compare duas situações: o aumento do número de geodes e o aumento do tipo de preço. Assim, é possível identificar o modelo mais econômico e adequado às suas necessidades.
• Defina os requisitos de disponibilidade para os dados. O Azure Cosmos DB conta com sinalizadores opcionais para habilitar a gravação em várias regiões, as zonas de disponibilidade e muito mais. Esses recursos aumentam a disponibilidade da instância do Azure Cosmos DB e criam uma camada de dados mais resiliente, mas geram custos adicionais.
• O Azure oferece uma variedade de balanceadores de carga com funcionalidades diferentes para a distribuição de tráfego. Use a árvore de decisão e selecione a opção ideal para o front-end da API.

Quando usar esse padrão

Use este padrão:

• Para implementar uma plataforma de alta escala com usuários distribuídos em uma área ampla.
• Em serviços que exigem alta disponibilidade e resiliência, pois os serviços baseados no padrão de geode podem sobreviver à perda de várias regiões de serviço ao mesmo tempo.

Esse padrão pode não ser adequado para

• Arquiteturas que têm restrições, de modo que todos os geodes 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 durante uma sessão específica ou um número elevado de solicitações em uma única região. Nesse caso, examine o uso de selos de implantação junto com um plano de roteamento global que reconheça o local em que ficam os dados de um usuário, como o componente de roteamento de tráfego descrito no padrão de selos de implantação.
• Situações em que não há necessidade de distribuição geográfica. Nesse caso, considere zonas de disponibilidade e regiões emparelhadas para clustering.
• Situações em que uma plataforma herdada precisa ser modernizada. Esse padrão funciona apenas para desenvolvimento nativo de nuvem e pode ser difícil de readequar.
• Arquiteturas e requisitos simples, em que a redundância e a distribuição geográficas não são necessárias ou vantajosas.

Design de 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:

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

Exemplos

• O Windows Active 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 de todos os nós operacionais, mas as funções da FSMO (Flexible Single Master Operation) significam que todos os geodes não são iguais.
• O acelerador de padrões de geode no GitHub mostra esse padrão de design na prática e foi projetado para ajudar desenvolvedores a implementá-lo com APIs do mundo real.
• Um aplicativo de exemplo QnA no GitHub demonstra esse padrão de design na prática.