Essa arquitetura fornece orientação para projetar uma carga de trabalho de missão crítica no Azure. Ele usa recursos nativos da nuvem para maximizar a confiabilidade e a eficácia operacional. Ele aplica a metodologia de design para cargas de trabalho de missão crítica bem arquitetadas a um aplicativo voltado para a Internet, em que a carga de trabalho é acessada por um ponto de extremidade público e não requer conectividade de rede privada com outros recursos da empresa.
Importante
A orientação é apoiada por uma implementação de exemplo no nível de produção que mostra o desenvolvimento de aplicativos de missão crítica no Azure. Essa implementação pode ser usada como base para o desenvolvimento de soluções adicionais na sua primeira etapa para 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 que a cercam, incluindo SLO (Objetivos de Nível de Serviço) e SLA (Contratos de Nível de Serviço), para capturar a porcentagem de tempo em que o aplicativo deve estar disponível.
Essa arquitetura visa um SLO de 99,99%, o que corresponde a um tempo de inatividade anual permitido de 52 minutos e 35 segundos. Todas as decisões de projeto englobadas são, portanto, destinadas a cumprir esse SLO de meta.
Dica
Para definir um SLO realista, é importante entender os objetivos de confiabilidade de todos os componentes do Azure e outros fatores dentro do escopo da arquitetura. Para saber mais, confira Recomendações para definir destinos de confiabilidade. Esses números individuais devem ser agregados para determinar um SLO composto que deve se alinhar com as metas de carga de trabalho.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: Design para requisitos de negócios.
Principais estratégias de design
Muitos fatores podem afetar a confiabilidade de um aplicativo, como a capacidade de recuperação de falhas, a disponibilidade regional, a eficácia da implantação e a 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
Implante 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 para todos os serviços considerados para maximizar a disponibilidade em uma única região do Azure, distribuindo componentes em data centers fisicamente separados dentro de uma região.
Escolha recursos que ofereçam suporte à distribuição global.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: distribuição global.
Carimbos 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 mudanças na demanda. Cada carimbo também aplica várias unidades de escala aninhadas, como as APIs de Front-end e os processadores em segundo plano, que podem ser dimensionados de forma independente.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: arquitetura de unidade de escala.
Implantações confiáveis e repetíveis
Aplicar o princípio de Infraestrutura como código (IaC) usando tecnologias, como Terraform, para fornecer controle de versão e uma abordagem operacional padronizada para componentes de infraestrutura.
Implemente pipelines de implantação azul/verde sem tempo de inatividade. Os pipelines de compilação e liberação devem ser totalmente automatizados para implantar selos como uma única unidade operacional, usando implantações azuis/verdes 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 dos processos de DevOps, incluindo testes sincronizados de carga e caos, para validar totalmente a integridade do código do aplicativo e da infraestrutura subjacente.
Consulte: Cargas de trabalho de missão crítica bem arquitetadas: implantação e teste.
Insights operacionais
Ter espaços de trabalho federados para dados de observabilidade. Os dados de monitoramento de recursos globais e recursos regionais são armazenados de forma independente. Um armazenamento de observabilidade centralizado não é recomendado para evitar um único ponto de falha. A consulta entre espaços de trabalho é usada para obter um coletor de dados unificado e um único painel de vidro para operações.
Construa um um modelo de integridade em camadas que mapeie 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, em seguida, agregadas em um nível de fluxo de 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 de missão crítica bem arquitetadas: 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 os Recursos relacionados.
Recursos globais
Os recursos globais são de longa duração e compartilham a vida útil do sistema. Eles têm a capacidade de estar disponíveis globalmente no 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 é fundamental para rotear de forma confiável o tráfego 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) do cliente de entrada, com recursos do WAF (Web Application Firewall) 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 no caso de integridade regional degradada. O roteamento depende de testes de integridade personalizados que verificam a integridade composta dos principais recursos regionais. O Azure Front Door também fornece uma CDN (rede de entrega 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, uma vez que a propagação de DNS deve ocorrer.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: Roteamento de tráfego global.
Backup de banco de dados
Todo o estado relacionado à carga de trabalho é armazenado em um banco de dados externo, o Azure Cosmos DB para NoSQL. Essa opção foi escolhida porque possui o conjunto de recursos necessários para o ajuste de desempenho e confiabilidade, tanto no lado do cliente quanto no servidor. É altamente recomendável que a conta tenha gravação multimestre habilitada.
Observação
Embora uma configuração de gravação em várias regiões represente o padrão ouro de confiabilidade, há um trade-off significativo no custo, que deve ser devidamente considerado.
A conta é replicada para cada carimbo 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 de missão crítica.
Registro de contêiner
O Registro de Contêiner do Azure é usado para armazenar todas as imagens de contêiner do Docker. Ele tem recursos de replicação geográfica que permitem que os recursos funcionem como um único registro, atendendo a várias regiões com registros regionais multimestres.
Como medida de segurança, permita apenas o acesso às entidades necessárias e autentique esse acesso. Por exemplo, na implementação, o acesso de administrador é desabilitado. Assim, o cluster de computação pode extrair imagens somente com atribuições de função do Microsoft Entra.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: 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 de outra região. Eles podem ser removidos independentemente ou replicados para regiões adicionais. Eles, no entanto, compartilham recursos globais entre si.
Nessa arquitetura, um pipeline de implantação unificado implanta um carimbo 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 carimbo regional.
Front-end
Essa arquitetura usa um aplicativo de página única (SPA) 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 está hospedado como um site estático em uma conta do Armazenamento do Azure.
Outra opção são os Aplicativos Web Estáticos do Azure, que introduz 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 entrega de conteúdo), para que os dados possam ser servidos rapidamente sem se comunicar diretamente com os servidores back-end. É uma maneira econômica de aumentar a confiabilidade e reduzir a latência da rede. Nessa arquitetura, os recursos internos de CDN do Azure Front Door são usados para armazenar em cache o conteúdo estático do site 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 monitoração de estado. Portanto, a conteinerização é uma estratégia apropriada para hospedar o aplicativo. O 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 oferece suporte a topologias avançadas de escalabilidade e implantação. A camada de SLA de tempo de atividade do AKS é altamente recomendada para hospedar aplicativos de missão crítica porque fornece garantias de disponibilidade para o plano de controle do Kubernetes.
O Azure oferece outros serviços de computação, como o Azure Functions e os Serviços de Aplicativo do Azure. Essas opções transferem 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 carimbos. Na medida do 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 estado a pods adicionará a carga de consistência de dados.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: Orquestração de contêineres e Kubernetes.
Agente de mensagens regional
Para otimizar o desempenho e manter a capacidade de resposta durante o pico de carga, o projeto 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 subsequentemente consumidas 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 monitoração de 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 vez a 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 é drenada depois que a mensagem é processada e armazenada em um banco de dados global.
Nesse design, os Hubs de Eventos do Azure são usados. Uma conta de Armazenamento do Azure adicional é 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 mensagem adicionais, o Barramento de Serviço do Azure é recomendado. Ele permite confirmações em duas fases com um cursor do lado do cliente, bem como recursos como uma fila de mensagens mortas interna e recursos de eliminação de duplicação.
Para obter mais informações, consulte Serviços de mensagens para cargas de trabalho de missão crítica.
Loja secreta regional
Cada carimbo tem seu próprio Cofre de Chaves do Azure que armazena segredos e configuração. Há segredos comuns, como cadeias de conexão para o banco de dados global, mas também há informações exclusivas para um único carimbo, como a cadeia de conexão dos Hubs de Eventos. Além disso, recursos independentes evitam um único ponto de falha.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: Proteção da integridade de dados.
Pipeline de implantação
Os pipelines de criação e liberação para um aplicativo de missão crítica devem ser totalmente automatizados. Portanto, nenhuma ação deve precisar ser executada manualmente. Esse projeto demonstra pipelines totalmente automatizados que implantam um carimbo validado de forma consistente sempre. Outra abordagem alternativa é implantar apenas atualizações contínuas 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 em código de aplicativo e código de infraestrutura.
Pipelines de integração contínua/entrega contínua (CI/CD)
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 seu rico conjunto de ferramentas que pode ter como alvo o Azure e outras plataformas de nuvem.
Outra opção é 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 por causa dos recursos de CD mais avançados.
Consulte: Cargas de trabalho de missão crítica bem arquitetadas: processos de DevOps.
Agentes de Build
Os agentes de compilação hospedados pela Microsoft são usados por essa implementação para reduzir a complexidade e a sobrecarga de gerenciamento. Os agentes auto-hospedados podem ser usados para cenários que exigem uma postura de segurança reforçada.
Observação
O uso de agentes auto-hospedados é demonstrado na implementação de referência Missão Crítica - Conectada .
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 de todos os componentes de aplicativos e infraestrutura.
- O Azure Application Insights é usado como uma ferramenta de Gerenciamento de Desempenho de Aplicativo (APM) para coletar todos os dados de monitoramento de aplicativos e armazená-los diretamente no Log Analytics.
Os dados de monitoramento de recursos globais e recursos regionais devem ser armazenados de forma independente. Um armazenamento de observabilidade centralizado, único, não é recomendado para evitar um único ponto de falha. A consulta entre espaços de trabalho é usada para obter um único painel de vidro.
Nessa arquitetura, os recursos de monitoramento dentro de uma região devem ser independentes do próprio carimbo, porque se você derrubar um carimbo, ainda assim deseja preservar a observabilidade. Cada selo regional tem seu próprio Application Insights e Log Analytics Workspace dedicados. Os recursos são provisionados por região, mas sobrevivem aos selos.
Da mesma forma, os dados de serviços compartilhados, como Azure Front Door, Azure Cosmos DB e Registro de Contêiner, são armazenados em instância dedicada do Log Analytics Workspace.
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 as Contas de Armazenamento do Azure para fins de retenção de dados e para fornecer uma fonte analítica para AIOps, que pode ser aplicada para otimizar o modelo de integridade do aplicativo e os procedimentos operacionais.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: ação preditiva e operações de IA.
Fluxos de solicitação e processador
Esta imagem mostra a solicitação e o fluxo do 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 do site
Uma solicitação para a interface do usuário da Web é enviada a um balanceador de carga global. Para esta 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 contra vários ataques, como scripts entre sites (XSS) e injeção de SQL. O Azure Front Door retornará um erro ao solicitante se uma regra do WAF for violada e o processamento for interrompido. Se não houver nenhuma regra de WAF violada, o Azure Front Door continuará o processamento.
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. Nesta implementação de referência, as regras de roteamento permitem que o Azure Front Door roteie solicitações de API de interface do usuário e front-end para diferentes recursos de back-end. Nesse caso, o padrão "/*" corresponde à regra de roteamento da interface do usuário. Esta 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 testes de integridade para garantir que as solicitações não sejam roteadas para back-ends que não estejam íntegros. O SPA é servido a partir da conta de armazenamento selecionada com site estático.
Observação
Os termos pools de back-end e back-ends 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 de API para o host front-end do Azure Front Door. O padrão da URL de solicitação da 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 a 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 Serviço de Kubernetes do Azure (AKS). 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 frontend 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 de missão 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 com as quais se comunicar com base no parâmetro ApplicationRegion.
Para solicitações POST ou PUT, a API de front-end executa gravações em um agente de mensagens. Na implementação de referência, o agente de mensagens são os Hubs de Eventos do Azure. Você pode escolher o Barramento de Serviço como alternativa. Um manipulador lerá posteriormente as mensagens do agente de mensagens e executará 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 tentativas.
Fluxo do 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 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 nova tentativa para se conectar 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 nova tentativa será feita na próxima região preferida.
Áreas de design
Sugerimos que você explore essas áreas de design para obter recomendações e orientações de práticas recomendadas ao definir sua arquitetura de missão 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 de infraestrutura e mitigações para possíveis casos de falha. |
| Plataforma de dados | Opções em tecnologias de armazenamento de dados, informadas pela avaliação das 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 carimbos. |
| Modelagem de integridade | Considerações de 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 através do modelo Microsoft Zero Trust. |
| Procedimentos operacionais | Processos relacionados à implantação, gerenciamento de chaves, aplicação de patches 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
- Azure Key Vault
- 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 de missão crítica. Ele contém um guia de implantação destinado a ilustrar uma abordagem orientada a solução para o desenvolvimento de aplicativos de missão crítica 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 esta arquitetura.