Padrão de selos de implantação

O padrão de carimbo de implantação envolve provisionamento, gerenciamento e monitoramento de um grupo heterogêneo de recursos para hospedar e operar várias cargas de trabalho ou locatários. Cada cópia individual é chamada de carimbo ou, às vezes, unidade de serviço, unidade de escala ou célula. Em um ambiente multilocatário, cada carimbo ou unidade de escala pode atender a um número predefinido de locatários. Vários selos podem ser implantados para dimensionar a solução quase linearmente e atender a um número crescente de locatários. Essa abordagem pode melhorar a escalabilidade de sua solução, permitir que você implante instâncias em várias regiões e separe os dados do cliente.

Contexto e problema

Ao hospedar um aplicativo na nuvem, é importante considerar o desempenho e a confiabilidade do seu aplicativo. Se você hospedar uma única instância de sua solução, poderá estar sujeito às seguintes limitações:

• Limites de escala. A implantação de uma única instância do seu aplicativo pode resultar em limites naturais de dimensionamento. Por exemplo, você pode usar serviços que tenham limites no número de conexões de entrada, nomes de host, soquetes TCP ou outros recursos.
• Dimensionamento ou custo não linear. Alguns dos componentes da solução podem não ser dimensionados linearmente de acordo com o número de solicitações ou a quantidade de dados. Em vez disso, pode haver uma diminuição súbita no desempenho ou aumento no custo uma vez que um limite tenha sido atingido. Por exemplo, você pode usar um banco de dados e descobrir que o custo marginal da adição de mais capacidade (expansão) se torna proibitivo e que a expansão é uma estratégia mais econômica.
• Separação de clientes. Talvez seja necessário manter os dados de determinados clientes isolados dos dados de outros clientes. Da mesma forma, você pode ter alguns clientes que exigem mais recursos do sistema para atender do que outros e considerar agrupá-los em diferentes conjuntos de infraestrutura.
• Manipulação de instâncias de um e vários locatários. Você pode ter alguns clientes grandes que precisam de suas próprias instâncias independentes da sua solução. Você também pode ter um pool de clientes menores que podem compartilhar uma implantação multilocatário.
• Requisitos de implantação complexos. Talvez seja necessário implantar atualizações em seu serviço de maneira controlada e implantá-las em diferentes subconjuntos de sua base de clientes em momentos diferentes.
• Frequência de atualização. Você pode ter alguns clientes que são tolerantes a ter atualizações frequentes em seu sistema, enquanto outros podem ser avessos ao risco e querer atualizações pouco frequentes para o sistema que atende suas solicitações. Pode fazer sentido ter esses clientes implantados em ambientes isolados.
• Restrições geográficas ou geopolíticas. Para arquitetar para baixa latência ou para cumprir os requisitos de soberania de dados, você pode implantar alguns de seus clientes em regiões específicas.

Essas limitações geralmente são aplicáveis a fornecedores independentes de software (ISVs) que criam software como serviço (SaaS), que são freqüentemente projetados para serem multilocados. No entanto, as mesmas limitações também se podem 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 carimbos. Cada unidade de escala hospedará e servirá um subconjunto de seus locatários. Os selos operam independentemente uns dos outros e podem ser implantados e atualizados de forma independente. Uma única região geográfica pode conter um único carimbo ou vários carimbos para permitir a expansão horizontal dentro da região. Os selos contêm um subconjunto dos seus clientes.

Os carimbos de implantação podem ser aplicados independentemente de sua solução usar componentes de infraestrutura como serviço (IaaS) ou plataforma como serviço (PaaS) ou uma mistura de ambos. Normalmente, as cargas de trabalho de IaaS exigem mais intervenção para escalar, portanto, o padrão pode ser útil para cargas de trabalho pesadas de IaaS para permitir a expansão.

Os carimbos podem ser usados para implementar anéis de implantação. Se clientes diferentes quiserem receber atualizações de serviço em frequências diferentes, elas podem ser agrupadas em selos diferentes, e cada carimbo pode ter atualizações implantadas em cadências diferentes.

Como os selos são executados independentemente uns dos outros, os dados são implicitamente fragmentados. Além disso, um único carimbo pode fazer uso de fragmentação adicional para permitir internamente escalabilidade e elasticidade dentro do carimbo.

O padrão de carimbo de implantação é usado internamente por muitos serviços do Azure, incluindo o Serviço de Aplicativo, o Azure Stack e o Armazenamento do Azure.

Os selos de implantação estão relacionados, mas são distintos dos geodos. Em uma arquitetura de carimbo de implantação, várias instâncias independentes do seu sistema são implantadas e contêm um subconjunto de seus clientes e usuários. Em geodes, todas as instâncias podem atender a solicitações de qualquer usuário, mas essa arquitetura geralmente é mais complexa de projetar e construir. Você também pode considerar misturar os dois padrões dentro de uma solução; A abordagem de roteamento de tráfego descrita posteriormente neste artigo é um exemplo desse cenário híbrido.

Implementação

Devido à complexidade envolvida na implantação de cópias idênticas dos mesmos componentes, boas práticas de DevOps são essenciais para garantir o sucesso ao implementar esse padrão. Considere descrever sua infraestrutura como código, como usando Bicep, JSON Azure Resource Manager templates (modelos ARM), Terraform e scripts. Com essa abordagem, você pode garantir que a implantação de cada carimbo 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 carimbos em paralelo, caso em que você pode considerar tecnologias como modelos Bicep ou Resource Manager para coordenar a implantação de sua infraestrutura e aplicativos. Como alternativa, você pode decidir distribuir gradualmente atualizações para alguns selos primeiro e, em seguida, progressivamente para outros. Considere usar uma ferramenta de gerenciamento de versão, como o Azure Pipelines ou o GitHub Actions , para orquestrar implantações para cada carimbo. Para obter mais informações, consulte:

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

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

• Normalmente, uma assinatura contém todos os recursos para uma única solução, portanto, em geral, considere usar uma única assinatura para todos os selos. No entanto, alguns serviços do Azure impõem cotas para toda a assinatura, portanto, se você estiver usando esse padrão para permitir um alto grau de expansão, talvez seja necessário considerar a implantação de carimbos em assinaturas diferentes.
• Os grupos de recursos geralmente são usados para implantar componentes com o mesmo ciclo de vida. Se você planeja implantar atualizações para todos os seus carimbos de uma só vez, considere usar um único grupo de recursos para conter todos os componentes de todos os seus carimbos e use convenções de nomenclatura de recursos e tags para identificar os componentes que pertencem a cada carimbo. Como alternativa, se você planeja implantar atualizações para cada carimbo de forma independente, considere implantar cada carimbo em seu próprio grupo de recursos.

Planeamento da capacidade

Use testes de carga e desempenho para determinar a carga aproximada que um determinado carimbo pode acomodar. As métricas de carga podem ser baseadas no número de clientes/locatários que um único selo pode acomodar ou métricas dos serviços que os componentes dentro do carimbo emitem. Certifique-se de ter instrumentação suficiente para medir quando um determinado carimbo está se aproximando de sua capacidade e a capacidade de implantar novos carimbos rapidamente para responder à demanda.

Roteamento de tráfego

O padrão de carimbo de implantação funciona bem se cada carimbo for endereçado independentemente. Por exemplo, se a Contoso implantar o mesmo aplicativo de API em vários carimbos, eles podem considerar o uso do DNS para rotear o tráfego para o carimbo relevante:

• unit1.aus.myapi.contoso.com encaminha o tráfego para carimbar 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.

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

Se for necessário um único ponto de entrada para todo o tráfego, um serviço de roteamento de tráfego poderá ser usado 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 para o carimbo (por exemplo, usando um código de status de resposta HTTP 302), ou pode atuar como um proxy reverso e encaminhar 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 implantar o serviço de roteamento de tráfego em várias regiões (potencialmente incluindo todas as regiões nas quais os carimbos são implantados) e, em seguida, garantir que o armazenamento de dados (mapeando locatários para carimbos) seja sincronizado. O componente de roteamento de tráfego pode ser uma instância do padrão geode.

Por exemplo, o Gerenciamento de API do Azure pode ser implantado para atuar na função de serviço de roteamento de tráfego. Ele pode determinar o carimbo apropriado para uma solicitação pesquisando dados em uma coleção do Azure Cosmos DB armazenando o mapeamento entre locatários e carimbos. O Gerenciamento de API pode, então, definir dinamicamente a URL de back-end para o serviço de API do carimbo relevante.

Para habilitar a distribuição geográfica de solicitações e a redundância geográfica do serviço de roteamento de tráfego, o Gerenciamento de API pode ser implantado em várias regiões ou o Azure Front Door pode ser usado para direcionar o tráfego para a instância mais próxima. O Front Door pode ser configurado com um pool de back-end, permitindo que as solicitações sejam direcionadas para a instância de Gerenciamento de API disponível mais próxima. Se seu aplicativo não for exposto via HTTP/S, você poderá usar um Balanceador de Carga do Azure entre regiões para distribuir chamadas de entrada para Balanceadores de Carga do Azure regionais. O recurso de distribuição global do Azure Cosmos DB pode ser usado para manter as informações de mapeamento atualizadas em cada região.

Se um serviço de roteamento de tráfego estiver incluído em sua solução, considere se ele atua como um gateway e, portanto, pode executar o descarregamento de gateway para os outros serviços, como validação de token, limitação e autorização.

Exemplo de arquitetura de roteamento de tráfego

Considere o exemplo de arquitetura de roteamento de tráfego a seguir, que usa o Azure Front Door, o Gerenciamento de API do Azure e o Azure Cosmos DB para roteamento de tráfego global e, em seguida, uma série de carimbos específicos da região:

Suponha que um usuário normalmente reside em Nova York. Seus dados são armazenados no selo 3, na região Leste dos EUA.

Se o usuário viajar para a Califórnia e, em seguida, acessar o sistema, sua conexão provavelmente será roteada através da região Oeste dos EUA 2, porque isso é mais próximo de onde eles estão geograficamente quando fazem a solicitação. No entanto, o pedido tem de ser atendido pelo carimbo 3, porque é onde os seus dados são armazenados. O sistema de roteamento de tráfego garante que a solicitação seja encaminhada para o carimbo correto.

Problemas e considerações

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

• Processo de implantação. Ao implantar vários selos, é altamente aconselhável ter processos de implantação automatizados e totalmente repetíveis. Considere o uso de modelos Bicep, JSON ARM ou módulos Terraform para definir declarativamente seus carimbos e manter as definições consistentes.
• Operações de carimbo cruzado. Quando sua solução é implantada de forma independente em vários selos, perguntas como "quantos clientes temos em todos os nossos selos?" podem se tornar mais complexas de responder. As consultas podem precisar ser executadas em relação a cada carimbo e os resultados agregados. Como alternativa, considere fazer com que todos os carimbos publiquem dados em um data warehouse centralizado para relatórios consolidados.
• Determinação de políticas de expansão. Os carimbos têm uma capacidade finita, que pode ser definida usando uma métrica de proxy, como o número de locatários que podem ser implantados no carimbo. É importante monitorar a capacidade disponível e a capacidade usada para cada selo e implantar proativamente selos adicionais para permitir que novos locatários sejam direcionados a eles.
• Número mínimo de selos. Quando você usa o padrão Deployment Stamp, é aconselhável implantar pelo menos dois carimbos da sua solução. Se você implantar apenas um único carimbo, será fácil codificar acidentalmente suposições rígidas em seu código ou configuração que não se aplicarão quando você expandir.
• Custo. O padrão Deployment Stamp envolve a implantação de várias cópias do componente de infraestrutura, o que provavelmente envolverá um aumento substancial no custo de operação da solução.
• Movendo-se entre selos. Cada selo é implantado e operado de forma independente, portanto, mover locatários entre selos pode ser difícil. Seu aplicativo precisaria de lógica personalizada para transmitir as informações sobre um determinado cliente para um carimbo diferente e, em seguida, para remover as informações do locatário do carimbo original. Esse processo pode exigir um backplane para comunicação entre selos, aumentando ainda mais a complexidade da solução geral.
• Roteamento de tráfego. Conforme descrito anteriormente neste artigo, o roteamento do tráfego para o carimbo correto para uma determinada solicitação pode exigir um componente adicional para resolver locatários para carimbos. Este componente, por sua vez, pode precisar ser altamente disponível.
• Componentes compartilhados. Você pode ter alguns componentes que podem ser compartilhados entre selos. Por exemplo, se você tiver um aplicativo de página única compartilhado para todos os locatários, considere implantá-lo em uma região e usar a CDN do Azure para replicá-lo globalmente.

Quando utilizar este padrão

Esse padrão é útil quando você 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, considere a expansão usando selos.
• Um requisito para separar certos inquilinos de outros. Se você tiver clientes que não podem ser implantados em um carimbo multilocatário com outros clientes devido a preocupações de segurança, eles podem ser implantados em seu próprio carimbo isolado.
• A necessidade de ter alguns locatários em diferentes versões da sua solução ao mesmo tempo.
• Aplicativos de várias regiões onde os dados e o tráfego de cada locatário devem ser direcionados para uma região específica.
• Um desejo de alcançar resiliência durante interrupções. Como os selos são independentes uns dos outros, se uma interrupção afetar um único selo, os locatários implantados em outros selos não devem ser afetados. Este isolamento ajuda a conter o "raio de explosão" de um incidente ou interrupção.

Este padrão não é adequado para:

• Soluções simples que não precisam de escalar em grande grau.
• Sistemas que podem ser facilmente expandidos ou aumentados em uma única instância, como aumentando o tamanho da camada de aplicativos ou aumentando a capacidade reservada para bancos de dados e o nível de armazenamento.
• Soluções nas quais os dados devem ser replicados em todas as instâncias implantadas. Considere o padrão geode para este cenário.
• Soluções em que apenas alguns componentes precisam ser dimensionados, mas não outros. Por exemplo, considere se sua solução pode ser dimensionada fragmentando o armazenamento de dados em vez de implantar uma nova cópia de todos os componentes da solução.
• Soluções compostas apenas por conteúdo estático, como um aplicativo JavaScript front-end. Considere armazenar esse conteúdo em uma conta de armazenamento e usar a CDN do Azure.

Design da carga de trabalho

Um arquiteto deve avaliar como o padrão de Selos de Implantação 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.

Tecnologias de apoio

• Infraestrutura como código. Por exemplo, Bicep, modelos do Resource Manager, CLI do Azure, Terraform, PowerShell, Bash.
• Azure Front Door, que pode rotear o tráfego para um carimbo específico ou para um serviço de roteamento de tráfego.

Exemplo

O exemplo a seguir implanta vários carimbos de uma solução PaaS simples, com um serviço de aplicativo e um Banco de Dados SQL em cada carimbo. Embora os selos possam ser configurados em qualquer região que ofereça suporte aos serviços implantados no modelo, para fins de ilustração, esse modelo implanta dois selos na região Oeste dos EUA 2 e um carimbo adicional na região Europa Ocidental. Dentro de um carimbo, o serviço de aplicativo recebe seu próprio nome de host DNS público e pode receber conexões independentemente de todos os outros carimbos.

Clique no link abaixo para implantar a solução.

Exemplo de abordagem de roteamento de tráfego

O exemplo a seguir implanta uma implementação de uma solução de roteamento de tráfego que pode ser usada com um conjunto de carimbos de implantação para um aplicativo de API hipotético. Para permitir a distribuição geográfica das solicitações recebidas, o Front Door é implantado ao lado de várias instâncias do Gerenciamento de API na camada de consumo. Cada instância de Gerenciamento de API lê a ID do locatário da URL da solicitação e, em seguida, procura o carimbo relevante para a solicitação de um armazenamento de dados do Azure Cosmos DB distribuído geograficamente. O pedido é então encaminhado para o carimbo de back-end relevante.

Clique no link abaixo para implantar a solução.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• John Downs - Brasil | Gerente de Programa Principal

Outros contribuidores:

• Daniel Larsen - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
• Angel Lopez - Brasil | Engenheiro de Software Sénior, Azure Patterns and Practices
• Paolo Salvatori - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
• Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Recursos relacionados

• O compartilhamento pode ser usado como outra abordagem mais simples para dimensionar sua camada de dados. Os carimbos fragmentam implicitamente seus dados, mas a fragmentação não requer um carimbo de implantação. Para mais informações, veja Padrão de fragmentação.
• Se um serviço de roteamento de tráfego for implantado, os padrões Roteamento de Gateway e Descarregamento de Gateway poderão ser usados juntos para fazer o melhor uso desse componente.