Padrão de selos de implantação

O padrão Deployment Stamps provisiona, gere e monitoriza um grupo de recursos para alojar e operar múltiplas cargas de trabalho ou inquilinos. Cada cópia individual é chamada de carimbo ou, às vezes, unidade de serviço, unidade de escala ou célula. Num ambiente multiinquilino, cada carimbo serve um número pré-definido de inquilinos. Utiliza-se múltiplos selos para escalar a solução quase linearmente e servir um número crescente de inquilinos. Esta abordagem pode melhorar a escalabilidade da sua solução, permitir-lhe implementar instâncias em várias regiões e separar os dados dos seus clientes.

Contexto e problema

Quando hospeda uma aplicação na cloud, considere o desempenho e a fiabilidade da sua aplicação. Se hospedar uma única instância da sua solução, podem aplicar-se as seguintes limitações:

• Limites de escala: Uma única instância da sua aplicação pode atingir limites naturais de escalabilidade. Por exemplo, os serviços que utiliza podem limitar o número de ligações de entrada, nomes de host, sockets do Protocolo de Controlo de Transmissão (TCP) ou outros recursos.

• Escalonamento ou custo não linear: Alguns dos componentes da sua solução podem não escalar linearmente com o número de pedidos ou a quantidade de dados. Em vez disso, o desempenho pode diminuir ou o custo pode disparar depois de atingir um determinado limite. Por exemplo, pode descobrir que adicionar mais capacidade a uma base de dados, ou expandir, se torna proibitivamente caro e que distribuir é mais rentável.

• Separação dos clientes: Pode ser necessário isolar os dados de um cliente dos de outro. Também podes ter clientes que consomem mais recursos do sistema do que outros. Pode agrupá-los em diferentes conjuntos de infraestruturas.

• Instâncias de inquilino único e multiinquilino: Alguns grandes clientes podem precisar das suas próprias instâncias independentes da sua solução. Clientes mais pequenos podem partilhar uma implementação multitenant.

• Requisitos complexos de implantação: Pode ser necessário implementar atualizações no seu serviço de forma controlada e implementar para diferentes subconjuntos da sua base de clientes em diferentes momentos.

• Frequência de atualização: Alguns clientes toleram atualizações frequentes, enquanto clientes avesses ao risco querem atualizações pouco frequentes no sistema que serve os seus pedidos. Pode implantar estes clientes em ambientes isolados.

• Restrições geográficas ou geopolíticas: Para alcançar baixa latência ou cumprir os requisitos de soberania dos dados, pode implantar alguns clientes em regiões específicas.

Estas limitações aplicam-se frequentemente a empresas de desenvolvimento de software que desenvolvem software como serviço (SaaS), que normalmente projetam como multiinquilino. As mesmas limitações podem aplicar-se a outros cenários.

Solução

Para evitar estes problemas, considere agrupar os recursos em unidades de escala e provisionar múltiplas cópias dos seus selos. Cada unidade de escala aloja e serve um subconjunto dos seus inquilinos. Os carimbos correm independentemente uns dos outros, e podes implementá-los e atualizá-los de forma independente. Uma única região geográfica pode conter um selo ou vários selos que se expandem horizontalmente dentro da região. Cada selo serve um subconjunto dos seus clientes.

Os selos de implementação podem aplicar-se quer a sua solução utilize componentes de infraestrutura como serviço (IaaS) ou de plataforma como serviço (PaaS), ou uma combinação de ambos. As cargas de trabalho IaaS normalmente requerem mais intervenção para escalar, pelo que este padrão pode ajudar cargas de trabalho pesadas em IaaS a escalar.

Podes usar carimbos para implementar anéis de implantação. Se diferentes clientes quiserem atualizações de serviço em frequências diferentes, agrupe-as em diferentes carimbos e implemente atualizações em cada carimbo com um ritmo diferente.

Os carimbos funcionam de forma independente, por isso implicitamente fragmentam os teus dados. Um único selo também pode usar fragmentação adicional internamente para dimensionar e permanecer elástico.

Implementar cópias idênticas dos mesmos componentes é complexo, por isso boas práticas DevOps são críticas. Descreva a sua infraestrutura como código para que a implementação de cada carimbo seja previsível e repetível.

Os carimbos de implantação relacionam-se, mas diferem dos geodos. Numa arquitetura de implantação por selo, cada instância independente do seu sistema atende a um subconjunto dos seus clientes e utilizadores. Numa arquitetura de geode, cada instância pode servir pedidos de qualquer utilizador, mas esta abordagem é tipicamente mais complexa de conceber e construir. Também podes combinar os dois padrões numa única solução. A abordagem de encaminhamento de tráfego descrita mais adiante neste artigo é um exemplo de tal cenário híbrido.

Problemas e considerações

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

• Processo de implementação: Quando implementas múltiplos carimbos, automatiza e repete totalmente os teus processos de implementação. Use módulos Bicep ou Terraform para definir declarativamente os seus carimbos e manter as definições consistentes.

• Operações de carimbo cruzado: Quando implementa a sua solução de forma independente em vários selos, pode ser difícil determinar quantos clientes tem em todos os seus selos. Pode ser necessário consultar cada carimbo e agregar os resultados. Em alternativa, pode fazer com que todos os selos publiquem dados num data warehouse centralizado para relatórios consolidados.

• Políticas de escalonamento: Os selos têm uma capacidade finita, que pode definir usando uma métrica proxy, como o número de inquilinos que pode ser implementado no selo. Monitorize a capacidade disponível e usada de cada carimbo e implemente proativamente mais selos para direcionar novos inquilinos para eles.

• Número mínimo de selos: Quando usar o padrão Deployment Stamps, implemente pelo menos dois carimbos da sua solução. Se implementar apenas um carimbo, poderá facilmente codificar pressupostos rígidos no seu código ou na configuração que não se aplicam quando expande a escala.

• Custo: O padrão Deployment Stamps implementa múltiplas cópias dos seus componentes de infraestrutura, o que aumenta substancialmente o custo de operação da sua solução.

• Mudança entre selos: Cada selo funciona de forma independente, por isso mover inquilinos entre selos pode ser difícil. A sua aplicação precisa de lógica personalizada para transmitir a informação do cliente para um carimbo diferente e depois remover a informação do inquilino do carimbo original. Este processo pode exigir um backplane para comunicar entre carimbos, o que aumenta ainda mais a complexidade da sua solução.

• Encaminhamento do tráfego: Como descrito anteriormente neste artigo, encaminhar o tráfego para o carimbo correto para uma determinada requisição pode exigir um componente extra que associa os clientes aos carimbos. Este componente pode também precisar de estar altamente disponível.

• Observabilidade entre carimbos: À medida que o número de selos aumenta, torna-se mais difícil compreender a saúde geral e detetar incidentes rapidamente. Use Azure Monitor para recolher e correlacionar métricas, registos, vestígios e alertas em todos os carimbos. Use estes dados para identificar carimbos pouco saudáveis e diagnosticar problemas.

• Impacto da falha regional: Os selos funcionam de forma independente, mas não são inerentemente redundantes entre regiões. Se uma região que alberga um ou mais selos ficar indisponível, os inquilinos desses selos perdem o acesso até que a região recupere ou até que migre os inquilinos para selos noutra região. Para planear este cenário, documente os seus procedimentos de recuperação, defina as expectativas dos inquilinos e considere se os inquilinos críticos precisam de colocar carimbos geo-redundantes.

• Componentes partilhados: Pode ter componentes que possa partilhar entre os selos. Por exemplo, se tiveres uma aplicação partilhada de página única para todos os inquilinos, implementa-a numa região e usa Azure Front Door cache de borda para a replicar globalmente.

• Desvio de governação e configuração: À medida que o número de carimbos aumenta, torna-se mais difícil manter políticas de segurança, atribuições de controlo de acesso baseadas em funções (RBAC), controlos de rede, definições de observabilidade e configurações de serviço consistentes. Use o Azure Policy para tratar a governação como código e valide continuamente cada carimbo para monitorar desvios, evitando comportamentos inconsistentes e lacunas de conformidade.

Quando utilizar este padrão

Utilize este padrão quando:

• A tua solução tem limites naturais de escalabilidade. Por exemplo, se alguns componentes não conseguem ou não devem escalar para além de um certo número de clientes ou pedidos, use carimbos para escalar.

• É preciso separar certos inquilinos de outros. Se preocupações de segurança o impedirem de colocar alguns clientes num carimbo multiinquilino, coloque-os no seu próprio carimbo isolado.

• Precisas de alojar alguns inquilinos em diferentes versões da tua solução ao mesmo tempo.

• Constróis aplicações multirregional que precisam de direcionar os dados e o tráfego de cada inquilino para uma região específica.

• Queres alcançar resiliência durante as falhas. Os selos funcionam de forma independente, por isso, se uma falha afetar um único selo, os utilizadores de outros selos não são afetados. Este isolamento contém o raio de explosão de um incidente ou interrupção.

Este padrão pode não ser adequado quando:

• A tua solução é simples e não precisa de escalar muito.

• Pode escalar o seu sistema dentro de uma única instância, por exemplo, aumentando o tamanho da camada de aplicação ou aumentando a capacidade reservada para bases de dados e a camada de armazenamento.

• Precisas de replicar os dados em todas as instâncias implementadas. Considere o padrão Geode para este cenário.

• Só precisas de escalar alguns componentes e não outros. Por exemplo, considere se pode escalar a sua solução ao fragmentar o armazenamento de dados em vez de implementar uma nova cópia de todos os componentes da solução.

• A sua solução consiste apenas em conteúdo estático, como uma aplicação JavaScript front-end. Entregue este conteúdo através de uma Rede de Distribuição de Conteúdos.

Design da carga de trabalho

Avalie como usar o padrão Deployment Stamps no design de uma carga de trabalho para abordar os objetivos e princípios abordados nos pilares do Framework Azure Well-Architected. A tabela a seguir fornece orientação sobre como esse padrão suporta as metas de cada pilar.

Se este padrão introduzir compensações dentro de um pilar, considere-as em relação aos objetivos dos outros pilares.

Exemplo

A arquitetura de exemplo seguinte utiliza Azure Front Door, API Management do Azure e Azure Cosmos DB para encaminhar tráfego globalmente para uma série de carimbos específicos de região.

Suponha que um utilizador reside em Nova Iorque. A Stamp 3, na região Leste dos EUA, armazena os seus dados.

Se o utilizador viajar para a Califórnia e aceder ao sistema, o sistema encaminha a sua ligação pela região West US 2 porque essa região é a mais próxima quando faz o pedido. No entanto, o carimbo 3 deve, em última análise, servir o pedido porque armazena os seus dados. O sistema de encaminhamento de tráfego encaminha o pedido para o selo correto.

Deployment

Descreva a sua infraestrutura como código, usando Bicep ou Terraform. Esta abordagem garante que a implementação de cada carimbo é previsível e repetível. Também reduz a probabilidade de erros humanos, como incompatibilidades acidentais na configuração entre selos.

Pode implementar atualizações automaticamente em todos os carimbos em paralelo. Tecnologias como Bicep podem coordenar a implementação da sua infraestrutura e aplicações. Alternativamente, pode decidir lançar atualizações gradualmente a alguns selos primeiro e depois progressivamente a outros. Considere usar uma ferramenta de gestão de lançamentos, como Azure Pipelines ou GitHub Actions, para orquestrar implementações para cada ambiente.

Considere cuidadosamente a topologia das assinaturas do Azure e dos grupos de recursos para suas implantações:

• Normalmente, uma subscrição contém todos os recursos para uma única solução, por isso considere usar uma única subscrição para todos os selos. No entanto, alguns serviços de Azure impõem quotas de subscrição. Se usar este padrão para permitir um elevado grau de escalabilidade, poderá precisar de distribuir selos em diferentes subscrições.

• Os grupos de recursos geralmente contêm componentes que partilham o mesmo ciclo de vida. Se planeia implementar atualizações para todos os carimbos ao mesmo tempo, pode usar um único grupo de recursos que contenha todos os componentes para todos os carimbos. Use convenções de nomenclatura de recursos e etiquetas para identificar os componentes que pertencem a cada selo. Alternativamente, se planeia implementar atualizações para cada carimbo de forma independente, pode integrar cada carimbo no seu próprio grupo de recursos.

Planejamento de capacidade

Use testes de carga e desempenho para determinar a carga aproximada que um determinado carimbo pode acomodar. As métricas de carga podem basear-se no número de clientes ou inquilinos que um único selo pode acomodar, ou nas métricas que os serviços emitem no selo. Prepare cada carimbo para que possa medir quando se aproxima da sua capacidade máxima e certifique-se de que pode implementar novos carimbos rapidamente para responder à procura.

Encaminhamento do tráfego

O padrão "Deployment Stamps" funciona bem quando se endereça cada carimbo de forma independente. Por exemplo, se a Contoso implementar a mesma aplicação API em múltiplos carimbos, pode usar o Sistema de Nomes de Domínio (DNS) para encaminhar o tráfego para o carimbo relevante:

• unit1.aus.myapi.contoso.com encaminha o tráfego para o rótulo unit1 dentro de uma região australiana.
• unit2.aus.myapi.contoso.com encaminha o tráfego para carimbar unit2 dentro de uma região australiana.
• unit1.eu.myapi.contoso.com encaminha o tráfego para carimbar unit1 dentro de uma região europeia.

Em Azure, pode hospedar estes registos em DNS do Azure e usar uma convenção consistente de subdomínio para cada região e carimbo. Esta abordagem mantém roteamentos e operações previsíveis.

Os clientes são responsáveis por conectar ao selo correto.

Se a sua solução exigir um único ponto de entrada para todo o tráfego, pode usar um serviço de encaminhamento de tráfego para resolver o carimbo de um determinado pedido, cliente ou inquilino. O serviço de encaminhamento de tráfego ou direciona o cliente para a URL relevante do carimbo (por exemplo, retornando um código de estado de resposta HTTP 302), ou atua como um proxy inverso e encaminha o tráfego para o carimbo relevante sem que o cliente esteja ciente.

Um serviço de roteamento de tráfego centralizado pode ser um componente complexo de projetar, especialmente quando uma solução é executada em várias regiões. Considere implementar o serviço de encaminhamento de tráfego em várias regiões, potencialmente incluindo todas as regiões que hospedam stamps, e sincronizar o armazenamento de dados que associa os inquilinos aos stamps. O componente de encaminhamento de tráfego pode ser, por si só, uma instância do padrão Geode.

Por exemplo, pode implementar a API Management para atuar como serviço de encaminhamento de tráfego. A Gestão da API determina o carimbo apropriado para um pedido consultando dados numa coleção Azure Cosmos DB que armazena o mapeamento entre inquilinos e carimbos. Gestão de APIs define então dinamicamente o URL de back-end para o serviço API do selo relevante.

Para geodistribuir os pedidos e fornecer geo-redundância ao serviço de encaminhamento de tráfego, implemente o API Management em múltiplas regiões e use o Azure Front Door para direcionar o tráfego para o gateway de API Management mais próximo. Nesta topologia, o Azure Front Door utiliza grupos de origem, sondas de saúde e um método de encaminhamento apropriado para desviar pedidos de gateways regionais de Gestão de API pouco saudáveis. A Gestão de API redireciona então para a marca apropriada usando o mapeamento tenant-to-stamp e a sua configuração de back-end (ou pools de back-end), incluindo regras de failover entre endpoints de marca conforme necessário. Se a sua aplicação não estiver exposta via HTTP ou HTTPS, pode usar um balanceador de Azure carga cross-region para distribuir as chamadas recebidas para os balanceadores de carga Azure regionais. Utilize a funcionalidade de distribuição global global do Azure Cosmos DB para manter a informação de mapeamento atualizada em cada região.

Se a sua solução incluir um serviço de encaminhamento de tráfego, considere se este atua como gateway e pode realizar gateway offloading para os outros serviços, como validação de token, limitação (throttling) e autorização.

Passos seguintes

• Azure Front Door
• Integrar Bicep com Azure Pipelines
• Integrar modelos JSON ARM com o Azure Pipelines

Contributors

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

• John Downs | Engenheiro de Software Principal, Azure Patterns & Practices

Outros contribuidores:

• Federico Arambarri | Desenvolvedor Sénior de Software, Clarius Consulting
• Daniel Larsen | Engenheiro de Clientes Principal, FastTrack for Azure
• Angel Lopez | Engenheiro de Software Sénior, Azure Patterns and Practices
• Paolo Salvatori | Principal Customer Engineer, FastTrack for Azure
• Arsen Vladimirskiy | Engenheiro de Clientes Principal, FastTrack for Azure

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Recursos relacionados

• Podes usar sharding como uma abordagem mais simples para escalar a tua camada de dados. Os stamps particionam implicitamente os seus dados, mas o sharding não requer um stamp de implementação. Para obter mais informações, consulte Padrão de compartilhamento.
• Se a sua solução implementar um serviço de encaminhamento de tráfego, pode combinar os padrões Roteamento de Gateway e Descarregamento de Gateway para aproveitar ao máximo este componente.