Este artigo descreve como implantar aplicativos Web críticos usando o Serviço de Aplicativo do Azure. A arquitetura usa o padrão de aplicativo Web confiável como ponto de partida. Use essa arquitetura se você tiver uma carga de trabalho herdada e deseja adotar serviços de PaaS (plataforma como serviço).
O padrão confiável de aplicativo Web para .NET fornece orientação para atualizar ou redefinir a plataforma de aplicativos Web que você transfere para a nuvem, minimizar as alterações de código necessárias e direcionar um SLO (objetivo de nível de serviço) de 99,9%. As cargas de trabalho críticas têm requisitos de alta confiabilidade e disponibilidade. Para atingir um SLO de 99,95%, 99,99% ou superior, você precisa aplicar padrões de design críticos suplementares e rigor operacional. Este artigo descreve as principais áreas técnicas e como implementar e introduzir práticas de design críticas.
Observação
As diretrizes neste artigo baseiam-se na metodologia e nas práticas recomendadas de design da série Carga de trabalho crítica do Well-Architected Framework.
As seções a seguir descrevem como fazer para:
- Revisar a carga de trabalho existente a fim de entender seus componentes, fluxos de usuário e sistema, bem como os requisitos de disponibilidade e escalabilidade.
- Desenvolver e implementa uma arquitetura de unidade de escala para otimizar a escalabilidade de ponta a ponta por meio da compartimentação e padronizar o processo de adição e remoção de capacidade.
- Implementar unidades de escala efêmeras e sem estado ou carimbos de implantação para permitir escalabilidade e implantações sem tempo de inatividade.
- Determinar se você pode dividir a carga de trabalho em componentes para se preparar para a escalabilidade. Componentes individuais são necessários para escalabilidade e separação de fluxos.
- Preparar-se para a distribuição global implantando uma carga de trabalho em mais de uma região do Azure a fim de melhorar a proximidade com o cliente e se preparar para possíveis interrupções regionais.
- Desacoplar componentes e implementar uma arquitetura orientada por eventos.
Arquitetura
O diagrama a seguir aplica as considerações anteriores ao padrão de aplicativo Web confiável.
Baixe um Arquivo Visio dessa arquitetura.
A caixa vermelha representa uma unidade de escala com serviços que se dimensionam juntos. Para dimensioná-los de forma eficaz, otimize o tamanho, o SKU e os endereços IP disponíveis de cada serviço. Por exemplo, o número máximo de solicitações que a Configuração de Aplicativos do Azure atende se correlaciona ao número de solicitações por segundo que uma unidade de escala fornece. Ao adicionar mais capacidade em uma região, você também deve adicionar mais unidades de escala individuais.
Essas unidades de escala individuais não têm interdependências e só se comunicam com serviços compartilhados fora da unidade de escala individual. Você pode testar unidades de escala independentes antecipadamente. Para evitar afetar outras áreas de implantação, distribua as unidades de escala independentes e introduza a opção de substituir serviços em uma nova versão.
Para cargas de trabalho críticas, as unidades de escala independentes são temporárias, o que otimiza os processos de distribuição e fornece escalabilidade dentro das regiões e entre elas. Evite armazenar o estado em unidades de escala independentes. Considere usar o Cache do Azure para Redis para armazenamento na unidade de escala e armazene apenas o estado crítico ou os dados que também são armazenados no banco de dados. Se houver uma interrupção da unidade de escala ou se você alternar para outra unidade de escala, poderá haver uma lentidão ou a necessidade de uma nova entrada, mas o Cache do Azure para Redis ainda será executado.
O Application Insights é excluído da unidade de escala. Exclua serviços que armazenam ou monitoram dados. Separe-os em seu próprio grupo de recursos com seu próprio ciclo de vida.
Ao substituir uma unidade de escala ou implantar uma nova, mantenha os dados históricos e use uma instância por região.
Para obter mais informações, confira Design de aplicativo de cargas de trabalho críticas no Azure.
Componentes
Essa arquitetura usa os componentes a seguir:
- O Serviço de Aplicativo é a plataforma de hospedagem de aplicativos.
- O Cache do Azure para Redis armazena solicitações em cache.
- A Configuração do Aplicativo armazena definições de configuração.
- O SQL do Azure é o banco de dados back-end.
- O Application Insights obtém telemetria do aplicativo.
Alternativas
No padrão de aplicativo Web confiável, você pode:
- Usar o AKS (Serviço de Kubernetes do Azure) em vez do Serviço de Aplicativo. Essa opção funciona bem para cargas de trabalho complexas que têm um grande número de microsserviços. O AKS fornece mais controle sobre a infraestrutura subjacente e permite configurações complexas de várias camadas.
- Conteinerizar a carga de trabalho. O Serviço de Aplicativo dá suporte à conteinerização, mas, neste exemplo, a carga de trabalho não é conteinerizada. Use contêineres para aumentar a confiabilidade e a portabilidade.
Para obter mais informações, confira Considerações sobre a plataforma de aplicativos para cargas de trabalho críticas no Azure.
Escolher a plataforma de aplicativos
O nível de disponibilidade depende da sua escolha e configuração da plataforma de aplicativos. Considere as seguintes diretrizes críticas:
- Usar zonas de disponibilidade quando possível.
- Selecionar o serviço de plataforma certo para sua carga de trabalho.
- Conteinerizar a carga de trabalho.
Os conjuntos de disponibilidade distribuem as implantações por vários domínios de falha e atualização em um datacenter. As zonas de disponibilidade distribuem implantações por datacenters individuais em uma região do Azure. As zonas de disponibilidade geralmente são priorizadas, mas a estratégia usada depende da carga de trabalho. Por exemplo, cargas de trabalho sensíveis à latência ou com ruídos podem se beneficiar da priorização de conjuntos de disponibilidade. Se você distribuir a carga de trabalho pelas zonas de disponibilidade, isso poderá aumentar a latência e o custo do tráfego entre as zonas. Ao usar zonas de disponibilidade, certifique-se de que elas sejam aceitas por todos os serviços em uma unidade de escala. Todos os serviços no padrão de aplicativo Web confiável aceitam as zonas de disponibilidade.
Escolher a plataforma de dados
A plataforma de banco de dados escolhida afeta a arquitetura geral da carga de trabalho, especialmente o suporte à configuração ativa-ativa ou ativa-passiva da plataforma. O padrão de aplicativo Web confiável usa o SQL do Azure, que não dá suporte nativo a implantações ativas-ativas com operações de gravação em mais de uma instância. Portanto, o nível do banco de dados é limitado a uma estratégia ativa-passiva. Uma estratégia ativa-ativa no nível do aplicativo será possível se houver réplicas somente leitura e você gravar somente em uma única região.
Baixe um Arquivo Visio dessa arquitetura.
Vários bancos de dados são comuns em arquiteturas complexas, como arquiteturas de microsserviços que têm um banco de dados para cada serviço. Vários bancos de dados permitem a adoção de um banco de dados de gravação multiprimário como o Azure Cosmos DB, o que melhora a alta disponibilidade e a baixa latência. A latência entre regiões pode criar limitações. É fundamental considerar requisitos não funcionais e fatores como consistência, operabilidade, custo e complexidade. Permita que serviços individuais usem armazenamentos de dados separados e tecnologias de dados especializadas para atender a seus requisitos exclusivos. Para obter mais informações, confira Considerações sobre a plataforma de dados para cargas de trabalho críticas no Azure.
Definir um modelo de integridade
Em cargas de trabalho complexas de várias camadas que são distribuídas por vários datacenters e regiões geográficas, você deve definir um modelo de integridade. Defina fluxos de usuário e sistema, especifique e compreenda as dependências entre os serviços, entenda o efeito que as interrupções ou uma degradação de desempenho em um dos serviços podem ter na carga de trabalho geral, bem como monitore e visualize a experiência do cliente para permitir o monitoramento adequado e melhorar as ações manuais e automatizadas.
O diagrama anterior mostra como uma interrupção ou uma degradação de um único componente, como a Configuração do Aplicativo, pode causar uma possível degradação do desempenho para o cliente.
Quando você separa componentes em unidades de escala, é permitido parar o envio do tráfego para a parte afetada do aplicativo, como uma unidade de escala afetada ou a região completa.
Para obter mais informações, confira Modelagem de integridade e observabilidade de cargas de trabalho críticas no Azure.
Rede e segurança
Há requisitos rígidos de rede e segurança para cargas de trabalho que migram de uma implantação corporativa local. Nem todos os processos locais estabelecidos são convertidos em um ambiente de nuvem. Avalie esses requisitos se eles forem aplicáveis em ambientes de nuvem.
A identidade geralmente é o principal perímetro de segurança para padrões nativos da nuvem. Os clientes empresariais podem precisar de medidas de segurança mais substanciais. Para atender aos requisitos de segurança de rede, a maioria dos serviços de PaaS do Azure pode usar o Link Privado do Azure para implementar a rede como um perímetro de segurança. O Link Privado pode garantir que os serviços sejam acessados apenas dentro de uma rede virtual. Todos os serviços podem ser acessados somente por meio de pontos de extremidade privados. O diagrama a seguir mostra como o único ponto de extremidade público voltado para a Internet é o Azure Front Door.
Baixe um Arquivo Visio dessa arquitetura.
Para que o padrão de aplicativo Web confiável configure uma rede como um perímetro de segurança, ele deverá usar:
- Link Privado para todos os serviços que o aceitam.
- Azure Front Door Premium como o único ponto de extremidade público voltado para a Internet.
- Jumpboxes para acessar serviços por meio do Azure Bastion.
- Agentes de compilação auto-hospedados que possam acessar os serviços.
Outro requisito de rede comum para aplicativos críticos é restringir o tráfego de saída para evitar a exfiltração de dados. Restrinja o tráfego de saída roteando um firewall do Azure por meio de um dispositivo de firewall adequado e filtrando-o com o dispositivo. A arquitetura de linha de base crítica do Azure com controles de rede usa um firewall e um Link Privado.
Implantação e teste
O tempo de inatividade causado por versões errôneas ou erro humano pode ser um problema para uma carga de trabalho que precisa estar sempre disponível. Veja algumas áreas principais a serem consideradas:
- Implantações sem tempo de inatividade
- Implantações azuis/verdes efêmeras
- Analisar o ciclo de vida de componentes individuais e agrupá-los
- Validação contínua
As implantações sem tempo de inatividade são fundamentais para cargas de trabalho críticas. Uma carga de trabalho que precisa estar sempre ativa e em execução não pode ter uma janela de manutenção para distribuição de versões mais recentes. Para contornar essa limitação, a arquitetura crítica do Azure segue o padrão de implantações sem tempo de inatividade. As alterações são distribuídas como novas unidades de escala ou carimbos que são testados de ponta a ponta antes que o tráfego seja roteado incrementalmente para eles. Depois que todo o tráfego é roteado para o novo carimbo, os carimbos antigos são desativados e removidos.
Para obter mais informações, confira Implantação e teste para cargas de trabalho críticas no Azure.
Próximas etapas
- Roteiro de aprendizagem: Criar cargas de trabalho críticas no Azure
- Projeto de desafio: Criar um aplicativo Web crítico
- Módulo do Learn: Criar um modelo de integridade para sua carga de trabalho crítica