Padrão de Carimbos de Implantação

O padrão "Selos de Implantação" provisiona, gerencia e monitora um grupo de recursos para hospedar e operar múltiplas cargas de trabalho ou locatários. Cada cópia individual chama-se 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. Você implanta vários selos para dimensionar a solução quase linearmente e atender a um número crescente de locatários. Essa abordagem pode melhorar a escalabilidade da solução, permitir que você implante instâncias em várias regiões e separe os dados do cliente.

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 escalar para cima, torna-se proibitivamente caro e que o escalonamento horizontal é 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 selos 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. Normalmente, as cargas de trabalho de IaaS exigem mais intervenção para escalar, portanto, esse padrão pode ajudar as cargas de trabalho intensivas em 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 selos são executados de forma independente, de modo que eles fragmentam implicitamente seus dados. Um único carimbo também pode usar mais fragmentação internamente para dimensionar e permanecer elástico.

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. Como alternativa, você pode fazer com que todos os selos publiquem dados em um data warehouse centralizado para relatórios consolidados.

• Políticas de expansão: Os selos têm uma capacidade finita, que você pode definir usando uma métrica de 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 criar suposições de código rígido em seu código ou configuração que não se aplicam quando você escala horizontalmente.

• 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.

• Movendo-se entre selos: Cada selo é executado de forma independente, portanto, mover locatários entre selos 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 se comunicar entre módulos, 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 de uma determinada solicitação pode exigir um componente extra que resolve os locatários para carimbos. Esse componente também pode precisar estar altamente disponível.

• Observabilidade entre selos: À medida que o número de selos aumenta, torna-se mais difícil entender a integridade 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 da falha regional: Os selos 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 do locatário e considere se os locatários críticos precisam de posicionamento de selo 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.

• Descompasso de governança e configuração: À medida que o número de selos aumenta, fica mais difícil manter políticas de segurança, atribuições de RBAC (controle de acesso baseado em função), controles de rede, configurações de observabilidade e configurações de serviço consistentes. Use Azure Policy para tratar a governança como código e validar continuamente cada carimbo para desvio, a fim de evitar comportamentos e lacunas de conformidade inconsistentes.

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 forem dimensionados além de um determinado número de clientes ou solicitações, use selos para escalar horizontalmente.

• Você precisa separar determinados locatários de outros. Se as preocupações com a segurança impedirem que você implante alguns clientes em um selo multilocatário, implante-os em seu próprio selo 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 selos são executados de forma independente, portanto, se uma interrupção afetar um único selo, os locatários em outros selos não serão afetados. Esse isolamento contém o raio de explosão 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 selos entre regiões também fornece uma base para redundância e planejamento de recuperação, o que reduz o raio de explosão 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 selo 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 meio do diagrama contém três camadas regionais de roteamento de tráfego empilhadas verticalmente, uma para Estados Unidos Oeste 2, Estados Unidos Leste e Austrália Leste. Em cada camada, uma instância de Gerenciamento de API está à esquerda, e uma instância de Azure Cosmos DB está à direita. Uma seta de duas pontas, rotulada como consulta para o carimbo do locatário, as conecta. Setas de duas pontas verticais, rotuladas como replicação geográfica, vinculam as três instâncias do Azure Cosmos DB. Azure Front Door conecta-se a todas as três instâncias de Gerenciamento de API com setas bidirecionais. 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 análise, atender à solicitação porque armazena seus dados. O sistema de roteamento de tráfego roteia 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 lançamentos como Azure Pipelines ou GitHub Actions para orquestrar implantações em cada ambiente.

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 expansão, talvez seja necessário implantar selos em assinaturas diferentes.

• 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 as convenções e marcas de nomenclatura de recursos para identificar os componentes que pertencem a cada selo. 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 selo pode acomodar ou nas 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 Selos de Implantação funciona bem quando você aborda cada selo 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 roteia o tráfego para o selo unit1 dentro de uma região australiana.
• unit2.aus.myapi.contoso.com roteia o tráfego para o selo unit2 dentro de uma região australiana.
• unit1.eu.myapi.contoso.com roteia o tráfego para o selo unit1 dentro de 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ê poderá usar um serviço de roteamento de tráfego para resolver o carimbo de uma determinada solicitação, cliente ou locatário. 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 stamps, e sincronize o repositório de dados que mapeia inquilinos para stamps. 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 Gerenciamento de API determina o carimbo apropriado para uma solicitação pesquisando dados em uma coleção Azure Cosmos DB que armazena o mapeamento entre locatários e selos. Em seguida, o Gerenciamento de API define dinamicamente a URL de back-end para o serviço de API do selo 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. Nesta topologia, Azure Front Door usa origin groups, health probes e um método de routing apropriado para encaminhar solicitações para longe de gateways regionais de Gerenciamento de API não íntegros. Em seguida, o Gerenciamento de API roteia para o selo apropriado usando o mapeamento de tenant para selo e sua configuração de back-end (ou pools de back-end), incluindo regras de failover entre endpoints do selo, 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 incluir um serviço de roteamento de tráfego, considere se ele atua como um gateway e pode executar o descarregamento de gateway para os outros serviços, como validação de token, limitação e autorização.

Próximas etapas

• Azure Front Door
• Integrar Bicep com 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 o padrão sharding.
• 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.