Arquitetura de linha de base crítica no Azure
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 Well-Architected cargas de trabalho críticas 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 de aplicativos críticos 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 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 alvo 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 realizar esse SLO de destino.
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 destinos de carga de trabalho.
Consulte Well-Architected cargas de trabalho críticas: Design para requisitos de negócios.
Estratégias-chave 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 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 recursos que dão suporte à distribuição global.
Consulte Well-Architected cargas de trabalho críticas: distribuição global.
Selos de implantação
Implante um carimbo regional como uma unidade de escala em que um conjunto lógico de recursos possa ser provisionado independentemente para acompanhar as alterações na demanda. Cada carimbo também aplica várias unidades de escala aninhadas, como as APIs front-end e processadores em segundo plano que podem ser dimensionados de forma independente.
Consulte Well-Architected cargas de trabalho críticas: arquitetura de unidade de escala.
Implantações confiáveis e repetíveis
Aplique o princípio da 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 dos 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 Well-Architected cargas de trabalho críticas: implantação e teste.
Insights operacionais
Ter workspaces federados para dados de observabilidade. Os dados de monitoramento de 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 requisitos não funcionais importantes, como desempenho, como coeficientes para quantificar a integridade do aplicativo.
Consulte Well-Architected cargas de trabalho críticas: 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 vida longa e compartilham o tempo de vida do sistema. Eles têm a capacidade de estar globalmente disponíveis 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 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 funcionalidades de WAF (Firewall de Aplicativo Web) aplicadas 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 verificam 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 Well-Architected cargas de trabalho críticas: roteamento de tráfego global.
Base 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 tem o conjunto de recursos necessário para ajuste de desempenho e confiabilidade, tanto no lado do cliente quanto do servidor. É altamente recomendável que a conta tenha a gravação de vários mestres habilitada.
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 a plataforma de dados para cargas de trabalho críticas.
Registro de contêiner
O 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 a várias regiões com registros regionais de vários mestres.
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 Microsoft Entra.
Consulte Well-Architected cargas de trabalho críticas: 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 de forma independente para regiões adicionais. Eles, no entanto, compartilham recursos globais entre si.
Nessa arquitetura, um pipeline de implantação unificada 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 os recursos de carimbo 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 é os Aplicativos Web Estáticos do Azure, que introduzem considerações adicionais, como como os certificados são expostos, conectividade com um balanceador de carga global e outros fatores.
O conteúdo estático normalmente é 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 não tem estado. Portanto, a contêinerização é uma estratégia apropriada para hospedar o aplicativo. O AKS (Serviço de Kubernetes do Azure) foi escolhido porque atende à maioria dos requisitos de negócios e o Kubernetes é amplamente adotado em vários 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 da missão, pois 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 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 são alterados com frequência. Anexar o estado aos pods adicionará a carga de consistência de dados.
Consulte Well-Architected cargas de trabalho críticas: Orquestração de Contêiner e Kubernetes.
Agente de mensagens regional
Para otimizar o desempenho e manter a capacidade de resposta durante o pico de carga, o design usa mensagens assíncronas para lidar com fluxos intensivos do sistema. Como uma solicitação é rapidamente confirmada 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 este 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 é esvaziada 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 adicional do Armazenamento do Azure é provisionada para o ponto de verificação. Os Hubs de Eventos são 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, 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 letras mortas interna e recursos de eliminação de duplicação.
Para obter mais informações, consulte serviços de mensagens para cargas de trabalho críticas.
Consulte Well-Architected cargas de trabalho críticas: arquitetura orientada a eventos flexívelmente acoplada.
Repositório de segredos regional
Cada selo tem seu próprio Azure Key Vault 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, os recursos independentes evitam um único ponto de falha.
Consulte Well-Architected cargas de trabalho críticas: 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 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 seu conjunto de ferramentas avançado que pode ter como destino o Azure e outras plataformas de nuvem.
Outra opção é o GitHub Actions para pipelines de CI/CD. O benefício adicionado é que o código-fonte e o pipeline podem ser agrupados. No entanto, o Azure Pipelines foi escolhido devido aos recursos mais avançados de CD.
Consulte Well-Architected cargas de trabalho críticas: processos de DevOps.
Compilar Agentes
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 efetivas 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.
- O Azure Application 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 de recursos globais e recursos regionais devem ser armazenados independentemente. 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 dentro de uma região devem ser independentes do próprio selo, pois se você derrubar um carimbo, ainda deseja preservar a observabilidade. Cada selo regional tem seu próprio Workspace dedicado do Application Insights e do Log Analytics. Os recursos são provisionados por região, mas sobrevivem aos selos.
Da mesma forma, os dados de serviços compartilhados, como o Azure Front Door, o Azure Cosmos DB e o 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 o fluxo de solicitação e 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 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á sendo processado.
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 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 da 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 roteados para back-ends que não estejam íntegros. O SPA é servido na conta de armazenamento selecionada com o site estático.
Observação
Os termos de 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 da 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). Assim 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 de missão, 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 é os 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ática recomendada ao definir sua arquitetura crítica.
| Área de design | Descrição |
|---|---|
| Design de Aplicativo | Padrões de design que permitem dimensionamento e tratamento de erros. |
| Plataforma de aplicativo | 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 avaliando as características necessárias de volume, velocidade, variedade e veracidade. |
| Rede e conectividade | Considerações de rede para roteamento de tráfego de entrada para selos. |
| 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 por meio do modelo de Confiança Zero do Microsoft. |
| Procedimentos operacionais | Processos relacionados à implantação, gerenciamento de chaves, aplicação de patch e atualizações. |
** Indica considerações da á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 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.