Este artigo descreve como implantar aplicativos Web de missão crítica 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 tiver uma carga de trabalho herdada e quiser adotar serviços de plataforma como serviço (PaaS).
O padrão de aplicativo Web confiável para .NET fornece orientação para atualizar ou reformular aplicativos Web que você move para a nuvem, minimizando as alterações de código necessárias e visando um SLO (objetivo de nível de serviço) de 99,9%. Cargas de trabalho de missão crítica têm altos requisitos de confiabilidade e disponibilidade. Para alcançar um SLO de 99,95%, 99,99% ou superior, você precisa aplicar padrões de projeto de missão crítica suplementares e rigor operacional. Este artigo descreve as principais áreas técnicas e como implementar e introduzir práticas de design de missão crítica.
Nota
As orientações neste artigo baseiam-se na metodologia de design e nas práticas recomendadas da série de carga de trabalho de missão crítica do Well-Architected Framework.
As seções a seguir descrevem como:
- Analise a carga de trabalho existente para entender seus componentes, fluxos de usuário e sistema e requisitos de disponibilidade e escalabilidade.
- Desenvolver e implementar 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.
- Implemente unidades de escala efêmeras e sem estado ou carimbos de implantação para permitir escalabilidade e implantações sem tempo de inatividade.
- Determine 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 fluxos de dissociação.
- Prepare-se para a distribuição global implantando uma carga de trabalho em mais de uma região do Azure para melhorar a proximidade com o cliente e preparar-se para possíveis interrupções regionais.
- Desacople componentes e implemente uma arquitetura orientada a eventos.
Arquitetura
O diagrama a seguir aplica as considerações anteriores ao padrão de aplicativo Web confiável.
Transfira um ficheiro do Visio desta arquitetura.
A caixa vermelha representa uma unidade de escala com serviços que são dimensionados em conjunto. Para dimensioná-los de forma eficaz, otimize o tamanho, a 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 Aplicativo do Azure atende está correlacionado 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.
Estas unidades de escala individuais não têm quaisquer interdependências e apenas comunicam com serviços partilhados fora da unidade de escala individual. Você pode testar unidades de escala independentes antecipadamente. Para evitar afetar outras áreas de implantação, implante unidades de escala independentes e introduza a opção de substituir serviços em uma nova versão.
Para cargas de trabalho de missão crítica, as unidades de escala independentes são temporárias, o que otimiza os processos de implantação e fornece escalabilidade dentro e entre regiões. Evite armazenar o estado em unidades de escala independentes. Considere usar o Cache Redis do Azure para armazenamento na unidade de escala e armazene apenas o estado crítico ou os dados que também estão armazenados no banco de dados. Se houver uma interrupção da unidade de escala ou você alternar para outra unidade de escala, pode haver uma lentidão ou uma nova entrada necessária, mas o Cache Redis do Azure ainda é 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 dados históricos e use uma instância por região.
Para obter mais informações, consulte Design de aplicativo de cargas de trabalho de missão crítica no Azure.
Componentes
Essa arquitetura usa os seguintes componentes.
- 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 as 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:
- Use o Serviço Kubernetes do Azure (AKS) 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.
- Contentores da carga de trabalho. O Serviço de Aplicativo oferece 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, consulte Considerações sobre a plataforma de aplicativos para cargas de trabalho de missão crítica no Azure.
Escolha a plataforma de aplicação
O nível de disponibilidade depende da sua escolha e configuração da plataforma de aplicação. Considere as seguintes orientações de missão crítica:
- Use zonas de disponibilidade sempre que possível.
- Selecione o serviço de plataforma certo para sua carga de trabalho.
- Contentores da carga de trabalho.
Os conjuntos de disponibilidade distribuem implantações por vários domínios de falha e atualização em um datacenter. As zonas de disponibilidade espalham implantações entre datacenters individuais dentro de uma região do Azure. As zonas de disponibilidade geralmente são priorizadas, mas a estratégia que você usa depende da sua carga de trabalho. Por exemplo, cargas de trabalho sensíveis à latência ou tagarelas 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 zonas. Ao usar zonas de disponibilidade, certifique-se de que todos os serviços em uma unidade de escala ofereçam suporte a elas. Todos os serviços no padrão de aplicativo Web confiável suportam zonas de disponibilidade.
Escolha a plataforma de dados
A plataforma de banco de dados escolhida afeta a arquitetura geral da carga de trabalho, especialmente o suporte à configuração ativo-ativo ou ativo-passivo da plataforma. O padrão de aplicativo Web confiável usa o SQL do Azure, que não oferece suporte nativo a implantações ativas-ativas com operações de gravação em mais de uma instância. Assim, o nível do banco de dados é limitado a uma estratégia ativo-passivo. Uma estratégia ativa-ativa no nível do aplicativo é possível se houver réplicas somente leitura e você gravar em uma única região.
Transfira um ficheiro do Visio desta 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, que melhora a alta disponibilidade e a baixa latência. A latência entre regiões pode criar limitações. É crucial 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 às suas necessidades exclusivas. Para obter mais informações, consulte Considerações sobre a plataforma de dados para cargas de trabalho de missão crítica no Azure.
Definir um modelo de integridade
Em cargas de trabalho complexas de várias camadas que se espalham por vários datacenters e regiões geográficas, você deve definir um modelo de integridade. Defina os fluxos do usuário e do sistema, especifique e compreenda as dependências entre os serviços, compreenda o efeito que interrupções ou uma degradação do desempenho em um dos serviços pode ter na carga de trabalho geral e 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 degradação potencial do desempenho para o cliente.
Quando você separa componentes em unidades de escala, isso permite que você pare de enviar tráfego para a parte afetada do aplicativo, como uma unidade de escala afetada ou a região completa.
Para obter mais informações, consulte Modelagem de integridade e observabilidade de cargas de trabalho de missão crítica no Azure.
Segurança e rede
Há requisitos rigorosos de rede e segurança para cargas de trabalho que migram de uma implantação corporativa local. Nem todos os processos locais estabelecidos se traduzem 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 corporativos podem precisar de medidas de segurança mais substanciais. Para atender aos requisitos de segurança de rede, a maioria dos serviços PaaS do Azure pode usar o Azure Private Link para implementar a rede como um perímetro de segurança. O Private Link pode garantir que os serviços só sejam acessíveis a partir de uma rede virtual. Todos os serviços são acessíveis apenas através de terminais privados. O diagrama a seguir mostra como o único ponto de extremidade público voltado para a Internet é o Azure Front Door.
Transfira um ficheiro do Visio desta arquitetura.
Para que o padrão de aplicativo Web confiável configure uma rede como um perímetro de segurança, ele deve usar:
- Private Link para todos os serviços que o suportam.
- Azure Front Door premium como o único ponto de extremidade público voltado para a Internet.
- Jumpboxes para aceder a serviços através do Azure Bastion.
- Agentes de compilação auto-hospedados que podem acessar os serviços.
Outro requisito de rede comum para aplicativos de missão crítica é 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 lançamentos errados ou erro humano pode ser um problema para uma carga de trabalho que precisa estar sempre disponível. Aqui estão algumas áreas-chave a considerar:
- Implantações sem tempo de inatividade
- Implantações efêmeras azuis/verdes
- Analisar o ciclo de vida de componentes individuais e agrupá-los
- Validação contínua
Implantações sem tempo de inatividade são essenciais para cargas de trabalho de missão crítica. Uma carga de trabalho que precisa estar sempre ativa e funcionando não pode ter uma janela de manutenção para lançar versões mais recentes. Para contornar essa limitação, a arquitetura de missão crítica do Azure segue o padrão de implantações sem tempo de inatividade. As alterações são implementadas como novas unidades de escala ou carimbos que são testados de ponta a ponta antes que o tráfego seja roteado incrementalmente para elas. Depois que todo o tráfego é encaminhado para o novo selo, os carimbos antigos são desativados e removidos.
Para obter mais informações, consulte Implantação e teste para cargas de trabalho de missão crítica no Azure.
Próximos passos
- Caminho de aprendizagem: Criar cargas de trabalho de missão crítica no Azure
- Projeto de desafio: Projetar uma aplicação Web de missão crítica
- Módulo de aprendizagem: Projetar um modelo de integridade para sua carga de trabalho de missão crítica