Essa arquitetura fornece diretrizes para criar uma carga de trabalho crítica de missão no Azure. Ele usa recursos nativos de nuvem para maximizar a confiabilidade e a eficácia operacional. Ele aplica a metodologia de design para cargas de trabalho críticas bem arquitetados a um aplicativo voltado para a Internet, em que a carga de trabalho é acessada em um ponto de extremidade público e não requer conectividade de rede privada com outros recursos da empresa.
Importante
As diretrizes são apoiadas por uma implementação de exemplo de nível de produção que mostra o desenvolvimento crítico de aplicativos no Azure. Essa implementação pode ser usada como base para desenvolvimento de soluções adicionais em sua primeira etapa em direção à produção.
Camada de confiabilidade
A confiabilidade é um conceito relativo e, para que uma carga de trabalho seja adequadamente confiável, ela deve refletir os requisitos de negócios ao seu redor, incluindo SLO (Objetivos de Nível de Serviço) e SLA (Contratos de Nível de Serviço), para capturar o percentual de tempo que o aplicativo deve estar disponível.
Essa arquitetura tem como destino um SLO de 99,99%, que corresponde a um tempo de inatividade anual permitido de 52 minutos e 35 segundos. Todas as decisões de design englobadas destinam-se, portanto, a atingir esse SLO de destino.
Dica
Para definir um SLO realista, é importante entender o SLA de todos os componentes do Azure dentro da arquitetura. Esses números individuais devem ser agregados para determinar um SLA composto que deve se alinhar aos destinos de carga de trabalho.
Consulte Cargas de trabalho críticas de missão bem arquiteta: Design para requisitos de negócios.
Principais estratégias de design
Muitos fatores podem afetar a confiabilidade de um aplicativo, como a capacidade de se recuperar de falhas, disponibilidade regional, eficácia da implantação e segurança. Essa arquitetura aplica um conjunto de estratégias de design abrangentes destinadas a abordar esses fatores e garantir que a camada de confiabilidade de destino seja alcançada.
Redundância em camadas
Implantar em várias regiões em um modelo ativo-ativo. O aplicativo é distribuído em duas ou mais regiões do Azure que lidam com o tráfego de usuário ativo.
Utilize Zonas de Disponibilidade (AZs) para todos os serviços considerados para maximizar a disponibilidade em uma única região do Azure, distribuindo componentes entre data centers fisicamente separados dentro de uma região.
Escolha os recursos que dão suporte à distribuição global.
Consulte Cargas de trabalho críticas de missão bem arquiteta: distribuição global.
Selos de implantação
Implante um carimbo regional como uma unidade de escala em que um conjunto lógico de recursos pode ser provisionado independentemente para acompanhar as alterações na demanda. Cada selo também aplica várias unidades de escala aninhadas, como as APIs de front-end e processadores em segundo plano que podem ser dimensionados de forma independente.
Consulte Cargas de trabalho críticas de missão bem arquiteta: arquitetura de unidade de escala.
Implantações confiáveis e repetíveis
Aplique o princípio de IaC (infraestrutura como código) usando tecnologias, como o Terraform, para fornecer controle de versão e uma abordagem operacional padronizada para componentes de infraestrutura.
Implementar pipelines de implantação azul/verde de tempo de inatividade zero. Os pipelines de build e lançamento devem ser totalmente automatizados para implantar selos como uma única unidade operacional, usando implantações azul/verde com validação contínua aplicada.
Aplique consistência de ambiente em todos os ambientes considerados, com o mesmo código de pipeline de implantação em ambientes de produção e pré-produção. Isso elimina os riscos associados à implantação e às variações de processo entre ambientes.
Tenha validação contínua integrando testes automatizados como parte de processos de DevOps, incluindo testes de carga e caos sincronizados, para validar totalmente a integridade do código do aplicativo e da infraestrutura subjacente.
Consulte Cargas de trabalho críticas bem arquitetas: implantação e teste.
Insights operacionais
Ter workspaces federados para dados de observabilidade. Os dados de monitoramento para recursos globais e recursos regionais são armazenados de forma independente. Um repositório de observabilidade centralizado não é recomendado para evitar um único ponto de falha. A consulta entre workspaces é usada para obter um coletor de dados unificado e um único painel de vidro para operações.
Construa um modelo de integridade em camadas que mapeia a integridade do aplicativo para um modelo de semáforo para contextualização. As pontuações de integridade são calculadas para cada componente individual e agregadas em um nível de fluxo do usuário e combinadas com os principais requisitos não funcionais, como desempenho, como coeficientes para quantificar a integridade do aplicativo.
Consulte Cargas de trabalho críticas de missão bem arquiteta: modelagem de integridade.
Arquitetura
*Baixe um arquivo do Visio dessa arquitetura.
Os componentes dessa arquitetura podem ser amplamente categorizados dessa maneira. Para obter a documentação do produto sobre os serviços do Azure, consulte Recursos relacionados.
Recursos globais
Os recursos globais são de longa duração e compartilham o tempo de vida do sistema. Eles têm a capacidade de estar globalmente disponíveis dentro do contexto de um modelo de implantação de várias regiões.
Aqui estão as considerações de alto nível sobre os componentes. Para obter informações detalhadas sobre as decisões, consulte Recursos globais.
Balanceador de carga global
Um balanceador de carga global é essencial para rotear o tráfego de forma confiável para as implantações regionais com algum nível de garantia com base na disponibilidade de serviços de back-end em uma região. Além disso, esse componente deve ter a capacidade de inspecionar o tráfego de entrada, por exemplo, por meio do firewall do aplicativo Web.
O Azure Front Door é usado como o ponto de entrada global para todo o tráfego HTTP(S) de cliente de entrada, com recursos de Firewall de Aplicativo Web (WAF) aplicados para proteger o tráfego de entrada da Camada 7. Ele usa o TCP Anycast para otimizar o roteamento usando a rede de backbone da Microsoft e permite failover transparente em caso de integridade regional degradada. O roteamento depende de investigações de integridade personalizadas que marcar a integridade composta dos principais recursos regionais. O Azure Front Door também fornece uma CDN (rede de distribuição de conteúdo) interna para armazenar em cache ativos estáticos para o componente do site.
Outra opção é o Gerenciador de Tráfego, que é um balanceador de carga de Camada 4 baseado em DNS. No entanto, a falha não é transparente para todos os clientes, pois a propagação de DNS deve ocorrer.
Consulte Cargas de trabalho críticas de missão bem arquiteta: roteamento de tráfego global.
Banco de dados
Todo o estado relacionado à carga de trabalho é armazenado em um banco de dados externo, o Azure Cosmos DB for NoSQL. Essa opção foi escolhida porque tem o conjunto de recursos necessário para ajuste de desempenho e confiabilidade, tanto nos lados do cliente quanto do servidor. É altamente recomendável que a conta tenha várias master gravação habilitadas.
Observação
Embora uma configuração de gravação de várias regiões represente o padrão ouro para confiabilidade, há uma compensação significativa sobre o custo, que deve ser considerada corretamente.
A conta é replicada para cada selo regional e também tem redundância zonal habilitada. Além disso, o dimensionamento automático é habilitado no nível do contêiner para que os contêineres dimensionem automaticamente a taxa de transferência provisionada conforme necessário.
Para obter mais informações, consulte Plataforma de dados para cargas de trabalho críticas.
Registro de contêiner
Registro de Contêiner do Azure é usado para armazenar todas as imagens de contêiner. Ele tem recursos de replicação geográfica que permitem que os recursos funcionem como um único registro, atendendo várias regiões com registros regionais de várias master.
Como medida de segurança, permita apenas o acesso a entidades necessárias e autentique esse acesso. Por exemplo, na implementação, o acesso de administrador está desabilitado. Portanto, o cluster de computação pode efetuar pull de imagens somente com atribuições de função do Azure Active Directory.
Consulte Cargas de trabalho críticas de missão bem arquiteta: Registro de contêiner.
Recursos regionais
Os recursos regionais são provisionados como parte de um carimbo de implantação para uma única região do Azure. Esses recursos não compartilham nada com recursos em outra região. Eles podem ser removidos ou replicados independentemente para regiões adicionais. Eles, no entanto, compartilham recursos globais entre si.
Nessa arquitetura, um pipeline de implantação unificado implanta um selo com esses recursos.
Aqui estão as considerações de alto nível sobre os componentes. Para obter informações detalhadas sobre as decisões, consulte Recursos de selo regionais.
Front-end
Essa arquitetura usa um SPA (aplicativo de página única) que envia solicitações para serviços de back-end. Uma vantagem é que a computação necessária para a experiência do site é descarregada para o cliente em vez de seus servidores. O SPA é hospedado como um site estático em uma Conta de Armazenamento do Azure.
Outra opção é Aplicativos Web Estáticos do Azure, que apresenta considerações adicionais, como como os certificados são expostos, conectividade com um balanceador de carga global e outros fatores.
Normalmente, o conteúdo estático é armazenado em cache em um repositório próximo ao cliente, usando uma CDN (rede de distribuição de conteúdo), para que os dados possam ser atendidos rapidamente sem se comunicar diretamente com servidores de back-end. É uma maneira econômica de aumentar a confiabilidade e reduzir a latência de rede. Nessa arquitetura, os recursos internos da CDN do Azure Front Door são usados para armazenar em cache o conteúdo do site estático na rede de borda.
Cluster de computação
A computação de back-end executa um aplicativo composto por três microsserviços e é sem estado. Portanto, a conteinerização é uma estratégia apropriada para hospedar o aplicativo. Serviço de Kubernetes do Azure (AKS) foi escolhido porque atende à maioria dos requisitos de negócios e o Kubernetes é amplamente adotado em muitos setores. O AKS dá suporte a topologias avançadas de escalabilidade e implantação. A camada SLA de tempo de atividade do AKS é altamente recomendada para hospedar aplicativos críticos de missão porque fornece garantias de disponibilidade para o plano de controle do Kubernetes.
O Azure oferece outros serviços de computação, como Azure Functions e serviços de Azure App. Essas opções descarregam responsabilidades de gerenciamento adicionais para o Azure ao custo de flexibilidade e densidade.
Observação
Evite armazenar o estado no cluster de computação, tendo em mente a natureza efêmera dos selos. Tanto quanto possível, persista o estado em um banco de dados externo para manter as operações de dimensionamento e recuperação leves. Por exemplo, no AKS, os pods mudam com frequência. Anexar o estado aos pods adicionará a carga de consistência de dados.
Consulte Cargas de trabalho críticas de missão bem arquiteta: Orquestração de Contêiner e Kubernetes.
Agente de mensagens regional
Para otimizar o desempenho e manter a capacidade de resposta durante a carga de pico, o design usa mensagens assíncronas para lidar com fluxos intensivos do sistema. Como uma solicitação é rapidamente reconhecida de volta para as APIs de front-end, a solicitação também é enfileirada em um agente de mensagens. Essas mensagens são consumidas posteriormente por um serviço de back-end que, por exemplo, manipula uma operação de gravação em um banco de dados.
O carimbo inteiro é sem estado, exceto em determinados pontos, como esse agente de mensagens. Os dados são enfileirados no agente por um curto período de tempo. O agente de mensagens deve garantir pelo menos uma entrega. Isso significa que as mensagens estarão na fila, se o agente ficar indisponível depois que o serviço for restaurado. No entanto, é responsabilidade do consumidor determinar se essas mensagens ainda precisam de processamento. A fila é esvaziada depois que a mensagem é processada e armazenada em um banco de dados global.
Nesse design, Hubs de Eventos do Azure é usado. Uma conta adicional do Armazenamento do Azure é provisionada para ponto de verificação. Hubs de Eventos é a opção recomendada para casos de uso que exigem alta taxa de transferência, como streaming de eventos.
Para casos de uso que exigem garantias de mensagens adicionais, é recomendável Barramento de Serviço do Azure. Ele permite commits em duas fases com um cursor do lado do cliente, bem como recursos como uma fila interna de mensagens mortas e recursos de eliminação de duplicação.
Para obter mais informações, consulte Serviços de mensagens para cargas de trabalho críticas.
Repositório de segredos regional
Cada selo tem seu próprio Key Vault do Azure que armazena segredos e configuração. Há segredos comuns, como cadeias de conexão com o banco de dados global, mas também há informações exclusivas para um único selo, como a cadeia de conexão dos Hubs de Eventos. Além disso, os recursos independentes evitam um único ponto de falha.
Consulte Cargas de trabalho críticas de missão bem arquiteta: proteção de integridade de dados.
Pipeline de implantação
Os pipelines de build e lançamento de um aplicativo crítico devem ser totalmente automatizados. Portanto, nenhuma ação deve precisar ser executada manualmente. Esse design demonstra pipelines totalmente automatizados que implantam um carimbo validado consistentemente todas as vezes. Outra abordagem alternativa é implantar apenas atualizações sem interrupção em um carimbo existente.
Repositório de código-fonte
O GitHub é usado para controle do código-fonte, fornecendo uma plataforma baseada em git altamente disponível para colaboração no código do aplicativo e no código de infraestrutura.
Pipelines de CI/CD (Integração Contínua/Entrega Contínua)
Pipelines automatizados são necessários para criar, testar e implantar uma carga de trabalho de missão em ambientes de pré-produção e produção. O Azure Pipelines é escolhido devido ao conjunto de ferramentas avançado que pode ser direcionado ao Azure e a outras plataformas de nuvem.
Outra opção é GitHub Actions para pipelines de CI/CD. O benefício adicional é que o código-fonte e o pipeline podem ser colocados. No entanto, o Azure Pipelines foi escolhido devido aos recursos de CD mais avançados.
Consulte Cargas de trabalho críticas de missão bem arquiteta: processos de DevOps.
Agentes de compilação
Os agentes de build hospedados pela Microsoft são usados por essa implementação para reduzir a complexidade e a sobrecarga de gerenciamento. Agentes auto-hospedados podem ser usados para cenários que exigem uma postura de segurança protegida.
Observação
O uso de agentes auto-hospedados é demonstrado na implementação de referência Mission Critical – Connected .
Recursos de observabilidade
Os dados operacionais do aplicativo e da infraestrutura devem estar disponíveis para permitir operações eficazes e maximizar a confiabilidade. Essa referência fornece uma linha de base para alcançar a observabilidade holística de um aplicativo.
Coletor de dados unificado
- O Azure Log Analytics é usado como um coletor unificado para armazenar logs e métricas para todos os componentes de aplicativo e infraestrutura.
- Aplicativo Azure Insights é usado como uma ferramenta de Gerenciamento de Desempenho de Aplicativos (APM) para coletar todos os dados de monitoramento de aplicativos e armazená-los diretamente no Log Analytics.
Os dados de monitoramento para recursos globais e recursos regionais devem ser armazenados de forma independente. Um único repositório de observabilidade centralizado não é recomendado para evitar um único ponto de falha. A consulta entre workspaces é usada para obter um único painel de vidro.
Nessa arquitetura, os recursos de monitoramento em uma região devem ser independentes do selo em si, pois se você derrubar um selo, ainda deseja preservar a observabilidade. Cada selo regional tem seu próprio Application Insights dedicado e workspace do Log Analytics. Os recursos são provisionados por região, mas sobrevivem aos selos.
Da mesma forma, dados de serviços compartilhados como, Azure Front Door, Azure Cosmos DB e Registro de Contêiner são armazenados na instância dedicada do Workspace do Log Analytics.
Arquivamento e análise de dados
Os dados operacionais que não são necessários para operações ativas são exportados do Log Analytics para contas de armazenamento do Azure para fins de retenção de dados e para fornecer uma fonte analítica para a AIOps, que pode ser aplicada para otimizar o modelo de integridade do aplicativo e os procedimentos operacionais.
Consulte Cargas de trabalho críticas de missão bem arquiteta: ação preditiva e operações de IA.
Fluxos de solicitação e processador
Esta imagem mostra a solicitação e o fluxo de processador em segundo plano da implementação de referência.
A descrição desse fluxo está nas seções a seguir.
Fluxo de solicitação de site
Uma solicitação para a interface do usuário da Web é enviada para um balanceador de carga global. Para essa arquitetura, o balanceador de carga global é o Azure Front Door.
As Regras do WAF são avaliadas. As regras do WAF afetam positivamente a confiabilidade do sistema protegendo-se contra uma variedade de ataques, como XSS (script entre sites) e injeção de SQL. O Azure Front Door retornará um erro ao solicitante se uma regra waf for violada e o processamento for interrompido. Se não houver regras de WAF violadas, o Azure Front Door continuará processando.
O Azure Front Door usa regras de roteamento para determinar para qual pool de back-end encaminhar uma solicitação. Como as solicitações são correspondidas a uma regra de roteamento. Nessa implementação de referência, as regras de roteamento permitem que o Azure Front Door encaminhe solicitações de interface do usuário e de API de front-end para diferentes recursos de back-end. Nesse caso, o padrão "/*" corresponde à regra de roteamento de interface do usuário. Essa regra roteia a solicitação para um pool de back-end que contém contas de armazenamento com sites estáticos que hospedam o SPA (Aplicativo de Página Única). O Azure Front Door usa a Prioridade e o Peso atribuídos aos back-ends no pool para selecionar o back-end para rotear a solicitação. Métodos de roteamento de tráfego para a origem. O Azure Front Door usa investigações de integridade para garantir que as solicitações não sejam roteada para back-ends que não estejam íntegros. O SPA é atendido na conta de armazenamento selecionada com o site estático.
Observação
Os termos pools de back-end e back-end no Azure Front Door Classic são chamados de grupos de origem e origens nas camadas Standard ou Premium do Azure Front Door.
O SPA faz uma chamada à API para o host de front-end do Azure Front Door. O padrão da URL de solicitação de API é "/api/*".
Fluxo de solicitação de API de front-end
As Regras do WAF são avaliadas como na etapa 2.
O Azure Front Door corresponde à solicitação à regra de roteamento de API pelo padrão "/api/*". A regra de roteamento de API roteia a solicitação para um pool de back-end que contém os endereços IP públicos para controladores de entrada NGINX que sabem como rotear solicitações para o serviço correto no AKS (Serviço de Kubernetes do Azure). Como antes, o Azure Front Door usa a Prioridade e o Peso atribuídos aos back-ends para selecionar o back-end correto do Controlador de Entrada NGINX.
Para solicitações GET, a API de front-end executa operações de leitura em um banco de dados. Para essa implementação de referência, o banco de dados é uma instância global do Azure Cosmos DB. O Azure Cosmos DB tem vários recursos que o tornam uma boa opção para uma carga de trabalho crítica, incluindo a capacidade de configurar facilmente regiões de várias gravações, permitindo failover automático para leituras e gravações em regiões secundárias. A API usa o SDK do cliente configurado com lógica de repetição para se comunicar com o Azure Cosmos DB. O SDK determina a ordem ideal das regiões disponíveis do Azure Cosmos DB para se comunicar com base no parâmetro ApplicationRegion.
Para solicitações POST ou PUT, a API front-end executa gravações em um agente de mensagens. Na implementação de referência, o agente de mensagens é Hubs de Eventos do Azure. Você pode escolher o Barramento de Serviço como alternativa. Posteriormente, um manipulador lerá mensagens do agente de mensagens e executará todas as gravações necessárias no Azure Cosmos DB. A API usa o SDK do cliente para executar gravações. O cliente pode ser configurado para novas tentativas.
Fluxo de processador em segundo plano
Os processadores em segundo plano processam mensagens do agente de mensagens. Os processadores em segundo plano usam o SDK do cliente para executar leituras. O cliente pode ser configurado para novas tentativas.
Os processadores em segundo plano executam as operações de gravação apropriadas na instância global do Azure Cosmos DB. Os processadores em segundo plano usam o SDK do cliente configurado com a tentativa de se conectar novamente ao Azure Cosmos DB. A lista de regiões preferidas do cliente pode ser configurada com várias regiões. Nesse caso, se uma gravação falhar, a repetição será feita na próxima região preferencial.
Áreas de design
Sugerimos que você explore essas áreas de design para obter recomendações e diretrizes de práticas recomendadas ao definir sua arquitetura crítica.
| Área de design | Descrição |
|---|---|
| Design do aplicativo | Padrões de design que permitem dimensionamento e tratamento de erros. |
| Plataforma de aplicativos | Opções e mitigações de infraestrutura para possíveis casos de falha. |
| Plataforma de dados | Opções em tecnologias de armazenamento de dados, informadas avaliando as características necessárias de volume, velocidade, variedade e veracidade. |
| Rede e conectividade | Considerações de rede para rotear o tráfego de entrada para selos. |
| Modelagem de integridade | Considerações sobre observabilidade por meio da análise de impacto do cliente correlacionaram o monitoramento para determinar a integridade geral do aplicativo. |
| Implantação e teste | Estratégias para pipelines de CI/CD e considerações de automação, com cenários de teste incorporados, como teste de carga sincronizado e teste de injeção de falha (caos). |
| Segurança | Mitigação de vetores de ataque por meio do modelo do Microsoft Confiança Zero. |
| Procedimentos operacionais | Processos relacionados à implantação, gerenciamento de chaves, aplicação de patch e atualizações. |
** Indica considerações de área de design específicas para essa arquitetura.
Recursos relacionados
Para obter a documentação do produto sobre os serviços do Azure usados nessa arquitetura, consulte estes artigos.
- Azure Front Door
- Azure Cosmos DB
- Registro de Contêiner do Azure
- Azure Log Analytics
- Cofre da Chave do Azure
- Barramento de Serviço do Azure
- Serviço de Kubernetes do Azure
- Azure Application Insights
- Hubs de eventos do Azure
- Armazenamento de Blobs do Azure
Implantar essa arquitetura
Implante a implementação de referência para obter uma compreensão completa dos recursos considerados, incluindo como eles são operacionalizados em um contexto crítico. Ele contém um guia de implantação destinado a ilustrar uma abordagem orientada a soluções para o desenvolvimento de aplicativos críticos no Azure.
Próximas etapas
Se você quiser estender a arquitetura de linha de base com controles de rede no tráfego de entrada e saída, consulte essa arquitetura.