Padrão de Carimbos de Implantação

Implante várias cópias independentes de componentes do aplicativo, incluindo armazenamentos de dados, como um único grupo de recursos. Cada cópia é chamada de carimbo ou, às vezes, uma unidade de serviço, uma unidade de escala ou uma célula. Em um ambiente multilocatário, cada selo atende a um número predefinido de locatários. Implantar mais carimbos permite escalar a solução de forma quase linear, atender a um número crescente de clientes, implantar instâncias em várias regiões e separar os dados dos clientes.

Observação

Para obter mais informações, consulte Arquitetar soluções multilocatários no Azure.

Contexto e problema

Ao hospedar um aplicativo na nuvem, considere o desempenho e a confiabilidade do aplicativo. Se você hospedar uma única instância da sua solução, as seguintes limitações poderão ser aplicadas:

• Limites de escala: Uma única instância do aplicativo pode atingir limites naturais de dimensionamento. Por exemplo, os serviços usados podem limitar o número de conexões de entrada, nomes de host, soquetes TCP (Protocolo de Controle de Transmissão) ou outros recursos.

• Custo ou dimensionamento não linear: Alguns dos componentes da solução podem não ser dimensionados linearmente com o número de solicitações ou a quantidade de dados. Em vez disso, o desempenho pode cair ou o custo pode aumentar depois que você atingir um limite. Por exemplo, você pode descobrir que adicionar mais capacidade a um banco de dados, ou seja, aumentar a escala verticalmente, torna-se proibitivamente caro e que aumentar a escala horizontalmente é mais econômico.

• Separação de clientes: Talvez seja necessário isolar os dados de um cliente dos dados de outro cliente. Você também pode ter clientes que consomem mais recursos do sistema do que outros. Você pode agrupá-los em diferentes conjuntos de infraestrutura.

• Instâncias de locatário único e multilocatário: Alguns clientes grandes podem precisar de suas próprias instâncias independentes da sua solução. Clientes menores podem compartilhar uma implementação multitenant.

• Requisitos complexos de implantação: Talvez seja necessário implantar atualizações em seu serviço de maneira controlada e implantar em diferentes subconjuntos de sua base de clientes em momentos diferentes.

• Frequência de atualização: Alguns clientes toleram atualizações frequentes, enquanto clientes avessos a riscos desejam atualizações pouco frequentes para o sistema que atende às suas solicitações. Você pode implantar esses clientes em ambientes isolados.

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

Essas limitações geralmente se aplicam a empresas de desenvolvimento de software que criam SaaS (software como serviço), que são geralmente projetados como multitenant. As mesmas limitações também podem se aplicar a outros cenários.

Solução

Para evitar esses problemas, considere agrupar recursos em unidades de escala e provisionar várias cópias de seus selos. Cada unidade de escala hospeda e atende a um subconjunto de seus locatários. Os carimbos são executados independentemente uns dos outros, e você pode implantá-los e atualizá-los de forma independente. Uma única região geográfica pode conter um selo ou vários selos que escalam horizontalmente dentro da região. Cada selo serve a um subconjunto de seus clientes.

O diagrama mostra cinco linhas empilhadas. Cada linha representa um carimbo de implantação. Cada linha tem um rótulo no canto superior esquerdo que nomeia o selo e sua região Azure, um rótulo no canto superior direito que lista os locatários que o selo serve e dois componentes abaixo dos rótulos, Serviço de Aplicativo do Azure à esquerda e um banco de dados SQL à direita. De cima para baixo, os selos são Carimbo 1 no Oeste dos EUA 2, que atende aos locatários A, B e C; Carimbo 2 no Oeste dos EUA 2, que serve o locatário D; Carimbo 3 no Leste dos EUA, que atende aos locatários E, F e G; Carimbo 4 na Europa Ocidental, que atende aos locatários H, I e J; e Carimbo 5 no Leste da Austrália, que atende aos locatários K, L e M. Os cinco selos compartilham a mesma composição interna, mas diferem na região e no conjunto de locatários atribuídos a eles, e a região Oeste dos EUA 2 contém dois selos separados, enquanto cada uma das outras regiões contém um selo.

Os selos de implantação podem ser aplicados se sua solução usa componentes de IaaS (infraestrutura como serviço) ou paaS (plataforma como serviço) ou uma combinação de ambos. As cargas de trabalho de IaaS normalmente exigem mais intervenção para escalar, portanto, esse padrão pode ajudar cargas de trabalho com uso intensivo de IaaS a escalar horizontalmente.

Você pode usar selos para implementar anéis de implantação. Se clientes diferentes desejarem atualizações de serviço em frequências diferentes, agrupe-as em selos diferentes e implante atualizações em cada selo em uma cadência diferente.

Os carimbos são executados independentemente, portanto, eles fragmentam implicitamente seus dados. Um único carimbo também pode usar fragmentação interna adicional para escalar e manter a elasticidade.

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

Os selos de implantação estão relacionados, mas diferem dos geodes. Em uma arquitetura de selo de implantação, cada instância independente do seu sistema atende a um subconjunto de seus clientes e usuários. Em uma arquitetura de geode, cada instância pode atender a solicitações de qualquer usuário, mas essa abordagem normalmente é mais complexa para projetar e compilar. Você também pode combinar os dois padrões em uma solução. A abordagem de roteamento de tráfego descrita posteriormente neste artigo é um exemplo desse cenário híbrido.

Problemas e considerações

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

• Processo de implantação: Ao implantar vários selos, automatize e repita totalmente os processos de implantação. Use módulos Bicep ou Terraform para definir declarativamente seus selos e manter as definições consistentes.

• Operações de carimbo cruzado: Quando você implanta sua solução de forma independente em vários selos, pode ser difícil determinar quantos clientes você tem em todos os seus selos. Talvez seja necessário consultar cada carimbo e agregar os resultados. Alternativamente, você pode fazer com que todos os carimbos publiquem dados em um data warehouse centralizado para geração de relatórios consolidados.

• Políticas de escalonamento horizontal: os Carimbos têm uma capacidade finita, que você pode definir usando uma métrica proxy, como o número de locatários que você pode implantar no Carimbo. Monitore a capacidade disponível e usada para cada selo e implante proativamente mais selos para direcionar novos locatários para eles.

• Número mínimo de selos: Ao usar o padrão Selos de Implantação, implante pelo menos dois selos da sua solução. Se você implantar apenas um único Carimbo, poderá facilmente inserir suposições fixas em seu código ou configuração que não se aplicam ao escalonamento horizontal.

• Custo: O padrão de Deployment Stamps implanta várias cópias dos seus componentes de infraestrutura, o que aumenta substancialmente o custo de operação da sua solução.

• Movimentação entre Carimbos: cada Carimbo é executado independentemente, portanto, mover locatários entre Carimbos pode ser difícil. Seu aplicativo precisa de lógica personalizada para transmitir as informações de um cliente para um carimbo diferente e, em seguida, remover as informações do locatário do carimbo original. Esse processo pode exigir um backplane para comunicação entre os Carimbos, o que aumenta ainda mais a complexidade da sua solução.

• Roteamento de tráfego: conforme descrito anteriormente neste artigo, rotear o tráfego para o Carimbo correto para uma determinada solicitação pode exigir um componente extra que resolva os locatários para os Carimbos. Esse componente também pode precisar estar altamente disponível.

• Observabilidade entre Carimbos: à medida que o número de Carimbos aumenta, torna-se mais difícil entender a saúde geral e detectar incidentes rapidamente. Use Azure Monitor para coletar e correlacionar métricas, logs, rastreamentos e alertas em todos os selos. Use esses dados para identificar selos não íntegros e diagnosticar problemas.

• Impacto de falhas regionais: os Carimbos são executados de forma independente, mas não são inerentemente redundantes entre regiões. Se uma região que hospeda um ou mais carimbos ficar indisponível, os locatários desses carimbos perderão o acesso até que a região se recupere ou você migre os locatários para carimbos em outra região. Para planejar esse cenário, documente seus procedimentos de recuperação, defina as expectativas dos locatários e considere se os locatários críticos precisam de posicionamento de Carimbos com redundância geográfica.

• Componentes compartilhados: Você pode ter componentes que podem ser compartilhados entre selos. Por exemplo, se você tiver um aplicativo de página única compartilhado para todos os locatários, implante-o em uma região e use o armazenamento em cache na borda do Azure Front Door para replicá-lo globalmente.

• Governança e desvio de configuração: à medida que o número de Carimbos aumenta, torna-se mais difícil manter as políticas de segurança, as atribuições de controle de acesso baseado em função (RBAC), os controles de rede, as configurações de observabilidade e as configurações de serviço consistentes. Use Azure Policy para tratar a governança como código e valide continuamente cada Carimbo em busca de desvios para evitar comportamentos inconsistentes e lacunas de conformidade.

Quando usar esse padrão

Use esse padrão quando:

• Sua solução tem limites naturais de escalabilidade. Por exemplo, se alguns componentes não puderem ou não deverem ser dimensionados além de um determinado número de clientes ou solicitações, use Carimbos para dimensionar horizontalmente.

• Você precisa separar determinados locatários de outros. Se as preocupações com segurança impedirem a implantação de alguns clientes em um Carimbo multilocatário, implante-os em seu próprio Carimbo isolado.

• Você precisa hospedar alguns locatários em versões diferentes da solução ao mesmo tempo.

• Você cria aplicativos de várias regiões que precisam direcionar os dados e o tráfego de cada locatário para uma região específica.

• Você deseja obter resiliência durante interrupções. Os carimbos são executados independentemente; portanto, se uma interrupção afetar um único carimbo, os locatários em outros carimbos permanecerão inalterados. Esse isolamento contém o raio de impacto de um incidente ou interrupção.

O padrão pode não ser adequado nestes casos:

• Sua solução é simples e não precisa ser escalada em grande escala.

• Você pode dimensionar o sistema para fora ou para cima em uma única instância, como aumentando o tamanho da camada de aplicativo ou aumentando a capacidade reservada para bancos de dados e a camada de armazenamento.

• Você precisa replicar dados em todas as instâncias implantadas. Considere o padrão geode para este cenário.

• Você só precisa dimensionar alguns componentes e não outros. Por exemplo, considere se você pode dimensionar sua solução fragmentando o armazenamento de dados em vez de implantar uma nova cópia de todos os componentes da solução.

• Sua solução consiste apenas em conteúdo estático, como um aplicativo JavaScript front-end. Forneça esse conteúdo por uma Rede de Distribuição de Conteúdo.

Design de carga de trabalho

Avalie como usar o padrão Deployment Stamps no design de uma carga de trabalho para cumprir os objetivos e princípios apresentados nos pilares do Azure Well-Architected Framework. A tabela a seguir fornece diretrizes sobre como esse padrão dá suporte às metas de cada pilar.

Pilar	Como esse padrão apoia os objetivos do pilar
As decisões de design de confiabilidade ajudam sua carga de trabalho a se tornar resiliente ao mau funcionamento e garantir que ela se recupere para um estado totalmente funcional após a ocorrência de uma falha.	Os selos operam de forma independente, portanto, uma falha em um carimbo é isolada e não afeta os locatários em outros selos. A implantação de vários carimbos em diferentes regiões também fornece uma base para redundância e planejamento de recuperação, o que reduz o raio de impacto de interrupções regionais. - RE:05 Redundância - RE:07 Autopreservação
A Excelência Operacional ajuda a fornecer qualidade da carga de trabalho por meio de processos padronizados e coesão de equipe.	Esse padrão oferece suporte a metas de infraestrutura imutáveis, modelos de implantação avançados e pode facilitar práticas de implantação seguras. - OE:05 Infraestrutura como código - OE:11 Práticas de implantação segura
A Eficiência de Desempenho ajuda sua carga de trabalho a atender com eficiência às demandas por meio de otimizações no dimensionamento, nos dados e no código.	Esse padrão geralmente se alinha às unidades de escala definidas em sua carga de trabalho. Quando você precisa de mais capacidade do que uma única unidade de escala fornece, você implanta outro carimbo para escalar horizontalmente. - PE:05 Dimensionamento e particionamento

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

Exemplo

A arquitetura de exemplo a seguir usa Azure Front Door, Gerenciamento de API do Azure e Azure Cosmos DB para rotear o tráfego globalmente para uma série de selos específicos da região.

Na extrema esquerda, Azure Front Door (global) representa o ponto de entrada. À direita, o centro do diagrama contém três camadas de roteamento de tráfego regional empilhadas verticalmente, uma para cada região: Oeste dos EUA 2, Leste dos EUA e Austrália Leste. Em cada camada, uma instância do API Management está à esquerda e uma instância do Azure Cosmos DB está à direita, e uma seta de duas pontas rotulada como "consulta para carimbo do locatário" as conecta. Setas verticais de duas pontas rotuladas como "georreplicação" conectam as três instâncias do Azure Cosmos DB. O Azure Front Door se conecta com setas de duas pontas a todas as três instâncias do API Management. Na extrema direita, cinco selos são empilhados verticalmente. Cada carimbo mostra seu nome e região, os locatários que ele atende e uma instância do Serviço de Aplicativo emparelhada com um banco de dados SQL. Os selos são Carimbo 1 (Oeste dos EUA 2) para locatários A, B e C; Carimbo 2 (Oeste dos EUA 2) para o locatário D; Carimbo 3 (Leste dos EUA) para locatários E, F e G; Carimbo 4 (Europa Ocidental) para locatários H, I e J; e Carimbo 5 (Leste da Austrália) para locatários K, L e M. As setas curvas levam das instâncias de Gerenciamento de API para os selos apropriados à direita.

Suponha que um usuário resida em Nova York. Stamp 3, na região Leste dos EUA, armazena seus dados.

Se o usuário viajar para a Califórnia e acessar o sistema, o sistema roteia sua conexão pela região Oeste dos EUA 2 porque essa região está mais próxima quando faz a solicitação. No entanto, o carimbo 3 deve, em última instância, atender à solicitação, pois armazena os dados. O sistema de roteamento de tráfego encaminha a solicitação para o carimbo correto.

Implantação

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

Você pode implantar atualizações automaticamente em todos os selos em paralelo. Tecnologias como Bicep podem coordenar a implantação de sua infraestrutura e aplicativos. Como alternativa, você pode decidir distribuir gradualmente as atualizações para alguns selos primeiro e, em seguida, progressivamente para outros selos. Considere usar uma ferramenta de gerenciamento de versão como o Azure Pipelines ou GitHub Actions para orquestrar implantações em cada selo.

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

• Normalmente, uma assinatura contém todos os recursos para uma única solução, portanto, considere usar uma única assinatura para todos os selos. No entanto, alguns serviços de Azure impõem cotas em toda a assinatura. Se você usar esse padrão para permitir um alto grau de escalabilidade horizontal, poderá precisar implantar carimbos em diferentes assinaturas.

• Os grupos de recursos geralmente contêm componentes que compartilham o mesmo ciclo de vida. Se você planeja implantar atualizações em todos os selos ao mesmo tempo, poderá usar um único grupo de recursos que contenha todos os componentes para todos os selos. Use convenções de nomenclatura de recursos e marcações para identificar os componentes que pertencem a cada carimbo. Como alternativa, se você planeja implantar atualizações em cada selo de forma independente, poderá implantar cada selo em seu próprio grupo de recursos.

Planejamento de capacidade

Use testes de carga e desempenho para determinar a carga aproximada que um determinado selo pode acomodar. As métricas de carga podem ser baseadas no número de clientes ou locatários que um único carimbo pode acomodar ou em métricas que os serviços no carimbo emitem. Instrumente cada selo para que você possa medir quando ele se aproximar de sua capacidade e certifique-se de que novos selos possam ser implantados rapidamente para atender à demanda.

Roteamento de tráfego

O padrão Carimbos de Implantação funciona bem quando você aborda cada carimbo de forma independente. Por exemplo, se a Contoso implantar o mesmo aplicativo de API em vários selos, a Contoso poderá usar o DNS (Sistema de Nomes de Domínio) para rotear o tráfego para o carimbo relevante:

• unit1.aus.myapi.contoso.com encaminha o tráfego para o carimbo unit1 em uma região australiana.
• unit2.aus.myapi.contoso.com encaminha o tráfego para o carimbo unit2 em uma região australiana.
• unit1.eu.myapi.contoso.com encaminha o tráfego para o carimbo unit1 em uma região europeia.

Em Azure, você pode hospedar esses registros em DNS do Azure e usar uma convenção de subdomínio consistente para cada região e carimbo. Essa abordagem mantém operações e roteamento previsíveis.

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

Se sua solução exigir um único ponto de entrada para todo o tráfego, você pode usar um serviço de roteamento de tráfego para resolver o carimbo para uma determinada região. O serviço de roteamento de tráfego direciona o cliente para a URL relevante do carimbo (por exemplo, retornando um código de status de resposta HTTP 302) ou atua como um proxy reverso 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 a ser desenvolvido, especialmente quando uma solução é executada em várias regiões. Considere implantar o serviço de roteamento de tráfego em várias regiões, potencialmente incluindo todas as regiões que hospedam carimbos, e sincronize o armazenamento de dados que mapeia locatários para carimbos. O componente de roteamento de tráfego pode ser uma instância do padrão Geode.

Por exemplo, você pode implantar o Gerenciamento de API para atuar como o serviço de roteamento de tráfego. O API Management determina o carimbo apropriado para uma solicitação consultando dados em uma coleção do Azure Cosmos DB que armazena o mapeamento entre locatários e carimbos. O API Management então define dinamicamente a URL de back-end para o serviço de API do carimbo relevante.

Para distribuir as solicitações geográficas e fornecer redundância geográfica para o serviço de roteamento de tráfego, deploy API Management em várias regiões e use Azure Front Door para direcionar o tráfego para o gateway de Gerenciamento de API mais próximo. Nessa topologia, o Azure Front Door usa grupos de origem, sondas de integridade e um método de roteamento apropriado para direcionar solicitações para longe de gateways regionais do API Management não íntegros. O API Management então roteia para o carimbo apropriado usando o mapeamento de locatário para carimbo e sua configuração de back-end (ou pools de back-end), incluindo regras de failover entre pontos de extremidade de carimbo, conforme necessário. Se o aplicativo não for exposto por HTTP ou HTTPS, você poderá usar um balanceador de carga Azure de região cruzada para distribuir chamadas de entrada para balanceadores de carga regionais do Azure. Use o recurso de distribuição global de Azure Cosmos DB para manter as informações de mapeamento atualizadas em cada região.

Se sua solução inclui um serviço de roteamento de tráfego, considere se ele atua como um gateway e pode realizar descarregamento de gateway para os outros serviços, como validação de token, limitação de taxa e autorização.

Próximas etapas

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

Contributors

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

• John Downs | Principal Engenheiro de Software, Padrões do Azure & Práticas

Outros colaboradores:

• Federico Arambarri | Desenvolvedor sênior de software, Clarius Consulting
• Daniel Larsen | Engenheiro de Cliente Principal, FastTrack para Azure
• Angel Lopez | Engenheiro de Software Sênior, Padrões e Práticas do Azure
• Paolo Salvatori | Engenheiro de Cliente Principal, FastTrack for Azure
• Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure

Para ver perfis de LinkedIn não públicos, entre em LinkedIn.

Recursos relacionados

• Você pode usar a fragmentação como outra abordagem mais simples para escalar horizontalmente sua camada de dados. Os selos fragmentam implicitamente seus dados, mas a fragmentação não requer um carimbo de implantação. Para obter mais informações, consulte Padrão de fragmentação.
• Se sua solução implantar um serviço de roteamento de tráfego, você poderá combinar os padrões de Roteamento de Gateway e Descarregamento de Gateway para fazer o melhor uso desse componente.