Padrão de Carimbos de Implantação

O padrão de selo 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 selo ou, às vezes, uma unidade de serviço, unidade de escala ou célula. Em um ambiente multilocatário, cada unidade de escala ou selo 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 da solução, permitir que você implante instâncias em várias regiões e separar 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 da sua solução, poderá estar sujeito às seguintes limitações:

• Limites de escala. A implantação de uma única instância do aplicativo pode resultar em limites de dimensionamento naturais. Por exemplo, você pode usar serviços que têm 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 com o número de solicitações ou a quantidade de dados. Em vez disso, pode haver uma diminuição repentina no desempenho ou aumento no custo depois que um limite for atendido. Por exemplo, você pode usar um banco de dados e descobrir que o custo marginal de adicionar mais capacidade (escalar verticalmente) torna-se proibitivo e que o dimensionamento é uma estratégia mais econômica.
• Separação de clientes. Pode ser 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 atendimento do que outros, e considerar a possibilidade de agrupá-los em conjuntos diferentes de infraestrutura.
• Manipular instâncias de locatário único e multilocatário. Você pode ter alguns clientes grandes que precisam de suas próprias instâncias independentes da solução. Você também pode ter um pool de clientes menores que podem compartilhar uma implantação multilocatário.
• Requisitos complexos de implantação. Pode ser que você precise implantar atualizações em seu serviço de maneira controlada e implantar em subconjuntos diferentes da sua base de clientes em momentos diferentes.
• Frequência de atualização. Você pode ter alguns clientes tolerantes a atualizações frequentes do sistema, enquanto outros podem ser avessos a riscos e desejar atualizações pouco frequentes no sistema que atende suas solicitações. Pode fazer sentido ter esses clientes implantados em ambientes isolados.
• Restrições geográficas ou geopolíticas. Para projetar para uma baixa latência ou cumprir os requisitos de soberania de dados, você pode implantar alguns de seus clientes em regiões específicas.

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

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 mistura de ambos. Normalmente, como as cargas de trabalho de IaaS exigem mais intervenção para dimensionar, o padrão pode ser útil para que cargas de trabalho pesadas de IaaS permitam o dimensionamento.

Os selos podem ser usados para implementar anéis de implantação. Se clientes diferentes desejarem receber atualizações de serviço em frequências diferentes, eles poderão ser agrupados em selos diferentes e cada selo poderá ter atualizações implantadas em diferentes cadências.

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

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

Os selos de implantação estão relacionados, mas são distintos dos nós geográficos. Em uma arquitetura de selo de implantação, várias instâncias independentes do sistema são implantadas e contêm um subconjunto de seus clientes e usuários. Nos nós geográficos, todas as instâncias podem atender a solicitações de qualquer usuário, mas essa arquitetura geralmente é mais complexa de se projetar e criar. Você também pode considerar a combinação dos dois padrões em uma solução; a abordagem de roteamento de tráfego descrita mais adiante neste artigo é um exemplo desse cenário híbrido.

Implantaçã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 a possibilidade de descrever sua infraestrutura como código, como usando Bicep, modelos ARM (Azure Resource Manager) do JSON, Terraform e scripts. Com essa abordagem, você pode garantir 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. Nesse caso, você pode considerar tecnologias como Bicep ou modelos do Resource Manager para coordenar a implantação de sua infraestrutura e aplicativos. Como alternativa, você pode decidir lançar gradualmente atualizações para alguns selos primeiro e, depois, progressivamente para outros. Considere usar uma ferramenta de gerenciamento de versão como o Azure Pipelines ou GitHub Actions para orquestrar implantações em cada selo. Para saber mais, veja:

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

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

• Geralmente, uma assinatura contém todos os recursos para uma única solução, considere, em geral, usar uma única assinatura para todos os selos. No entanto, alguns serviços do Azure impõem cotas em 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 selos em diferentes assinaturas.
• Os grupos de recursos geralmente são usados para implantar componentes com o mesmo ciclo de vida. Se você planeja implantar atualizações em todos os seus selos ao mesmo tempo, considere usar um único grupo de recursos para conter todos os componentes de todos os seus selos e usar convenções de nomenclatura de recursos e marcas para identificar os componentes que pertencem a cada selo. Como alternativa, se você planeja implantar atualizações em cada selo de forma independente, considere implantar cada selo em seu próprio grupo de recursos.

Planejamento da 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/locatários que um único selo pode acomodar ou nas métricas dos serviços que os componentes dentro do selo emitem. Verifique se você tem instrumentação suficiente para medir quando um determinado selo está se aproximando de sua capacidade e a capacidade de implantar novos selos rapidamente para responder à demanda.

Roteamento de tráfego

O padrão Selo de Implantação funcionará bem se cada selo for abordado de forma independente. Por exemplo, se a Contoso implantar o mesmo aplicativo de API em vários selos, poderá considerar o uso do DNS para rotear o tráfego para o selo 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.

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

Se um único ponto de entrada para todo o tráfego for necessário, um serviço de roteamento de tráfego poderá ser usado para resolver o selo 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 selo (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 selo 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 a possibilidade de implantar o serviço de roteamento de tráfego em várias regiões (potencialmente incluindo todas as regiões em que os selos são implantados) e, em seguida, garantir que o armazenamento de dados (mapear locatários para selos) seja sincronizado. O componente de roteamento de tráfego pode ser em si uma instância do padrão de nó geográfico.

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 selo apropriado para uma solicitação pesquisando dados em uma coleção do Azure Cosmos DB armazenando o mapeamento entre locatários e selos. O Gerenciamento de API pode então definir dinamicamente a URL de back-end para o serviço de API do selo 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 mais próxima disponível. Se o aplicativo não for exposto via HTTP/S, você poderá usar um Azure Load Balancer entre regiões para distribuir chamadas de entrada para os Azure Load Balancers 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 na 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 selos específicos de região:

Suponha que um usuário resida normalmente 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 acessar o sistema, sua conexão provavelmente será roteada pela região Oeste dos EUA 2, porque é mais próxima de onde ele está geograficamente quando faz a solicitação. No entanto, a solicitação deve, em última análise, ser atendida pelo selo 3, pois é nele que os dados são armazenados. O sistema de roteamento de tráfego garante que a solicitação seja roteada para o selo correto.

Problemas e considerações

Os seguintes pontos devem ser considerados ao decidir como implementar esse 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 usar os modelos Bicep, modelos JSON do ARM ou Terraform para definir declarativamente seus carimbos e para manter as definições consistentes.
• Operações de selo 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 se responder. As consultas podem precisar ser executadas em relação a cada selo e nos resultados agregados. Como alternativa, considere a possibilidade de fazer com que todos os selos publiquem dados em um data warehouse centralizado para relatórios consolidados.
• Determinando políticas de expansão. Os selos 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 selo. É 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 selo de implantação, é aconselhável implantar pelo menos dois selos de sua solução. Se você implantar apenas um único carimbo, é fácil acidentalmente criar suposições de código rígido em seu código ou configuração que não se aplicarão quando você escalar horizontalmente.
• Custo. O padrão Selo de Implantação envolve a implantação de várias cópias do componente da infraestrutura, o que provavelmente envolverá um aumento substancial no custo de operação da solução.
• Movendo-se entre selos. Como cada selo é implantado e operado de forma independente, a movimentação de locatários entre selos pode ser difícil. Seu aplicativo precisaria de uma lógica personalizada para transmitir as informações sobre um determinado cliente para um selo diferente e, em seguida, para remover as informações do locatário do selo original. Esse processo pode exigir um backplane para a 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 selo correto de uma determinada solicitação pode exigir um componente adicional para resolver locatários para selos. Esse 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 usar esse padrão

Esse padrão é útil quando você tem:

• Limites naturais de escalabilidade. Por exemplo, se alguns componentes não podem ou não devem ser dimensionados além de um determinado número de clientes ou solicitações, considere o dimensionamento usando selos.
• Um requisito para separar determinados locatários de outros. Se você tiver clientes que não podem ser implantados em um selo multilocatário com outros clientes devido a preocupações de segurança, eles poderão ser implantados em seu próprio selo isolado.
• Uma necessidade de ter alguns locatários em versões diferentes da solução ao mesmo tempo.
• Aplicativos de várias regiões em que 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. Esse isolamento ajuda a conter o "raio de explosão" de um incidente ou interrupção.

Esse padrão não é adequado para:

• Soluções simples que não precisam ser dimensionadas em alto grau.
• Sistemas que podem ser facilmente dimensionados para baixo 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.
• Soluções nas quais os dados devem ser replicados em todas as instâncias implantadas. Considere o padrão de nó geográfico para esse cenário.
• Soluções nas quais 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 implantando uma nova cópia de todos os componentes da solução.
• Soluções compostas exclusivamente por conteúdo estático, como um aplicativo JavaScript de front-end. Considere armazenar esse conteúdo em uma conta de armazenamento e usar a CDN do Azure.

Design de carga de trabalho

Um arquiteto deve avaliar como o padrão Carimbos 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:

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.

Tecnologias de suporte

• 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 selo específico ou para um serviço de roteamento de tráfego.

Exemplo

O exemplo a seguir implanta vários selos de uma solução PaaS simples, com um serviço de aplicativo e um Banco de Dados SQL em cada selo. Embora os selos possam ser configurados em qualquer região que dê suporte aos serviços implantados no modelo, para fins ilustrativos, esse modelo implanta dois selos dentro da região Oeste dos EUA 2 e um selo adicional na região Oeste da Europa. Dentro de um selo, 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 selos.

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 selos de implantação para um aplicativo de API hipotético. Para permitir a distribuição geográfica de solicitações de entrada, o Front Door é implantado junto com várias instâncias de Gerenciamento de API na camada de consumo. Cada instância de Gerenciamento de API lê a ID do locatário da URL de solicitação e procura o selo relevante para a solicitação de um armazenamento de dados do Cosmos DB distribuído geograficamente. Em seguida, a solicitação é encaminhada para o selo de back-end relevante.

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

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

• John Downs | Gerente principal do programa

Outros colaboradores:

• Daniel Larsen | Engenheiro de cliente principal, FastTrack for 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 de Cliente Principal, FastTrack for Azure

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

Recursos relacionados

• A fragmentação pode ser usada 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 Selo de Implantação. Para obter mais informações, consulte Padrão de fragmentação.
• Se um serviço de roteamento de tráfego for implantado, os padrões de Roteamento de Gateway e Descarregamento de Gateway poderão ser usados juntos para fazer o melhor uso desse componente.