Considerações da plataforma de aplicativo para cargas de trabalho de missão crítica

Uma das principais áreas de design de qualquer arquitetura de missão crítica é a plataforma de aplicativos. A plataforma refere-se aos componentes de infraestrutura e serviços do Azure que devem ser provisionados para dar suporte ao aplicativo. Veja algumas recomendações abrangentes.

• Design em camadas. Escolha o conjunto correto de serviços, sua configuração e as dependências específicas do aplicativo. Essa abordagem em camadas ajuda na criação de segmentação lógica e física. É útil para definir papéis e funções, bem como atribuir privilégios apropriados e estratégias de implantação. Em última análise, essa abordagem aumenta a confiabilidade do sistema.

• Um aplicativo de missão crítica deve ser altamente confiável e resistente a falhas regionais e do datacenter. Construir redundância zonal e regional em uma configuração ativo-ativo é a principal estratégia. Ao escolher os serviços do Azure para a plataforma do seu aplicativo, considere o suporte a Zonas de Disponibilidade e os padrões operacionais e de implantação para usar várias regiões do Azure.

• Use uma arquitetura baseada em unidades de escala para lidar com o aumento da carga. As unidades de escala permitem agrupar logicamente os recursos e uma unidade pode ser dimensionada independentemente de outras unidades ou serviços dentro da arquitetura. Use seu modelo de capacidade e desempenho esperado para definir os limites, o número e a escala de linha de base de cada unidade.

Nessa arquitetura, a plataforma de aplicativos consiste em recursos globais, de carimbo de implantação e regionais. Os recursos regionais são provisionados como parte de um carimbo de implantação. Cada carimbo equivale a uma unidade de escala e, caso se torne não íntegro, pode ser totalmente substituído.

Os recursos em cada camada possuem características distintas. Para obter mais informações, consulte Padrão de arquitetura de uma carga de trabalho de missão crítica típica.

Características	Considerações
Tempo de vida	Qual é o tempo de vida esperado do recurso, em relação a outros recursos na solução? Ele deve sobreviver ou compartilhar o tempo de vida com todo o sistema ou região, ou deve ser temporário?
Estado	Qual impacto o estado persistente nessa camada terá na confiabilidade ou na capacidade de gerenciamento?
Reach	O recurso necessário deve ser distribuído globalmente? O recurso pode se comunicar com outros recursos, de forma global ou nas regiões?
Dependências	Qual é a dependência de outros recursos a nível global ou em outras regiões?
Limites de escala	Qual é a taxa de transferência esperada para esse recurso nessa camada? Quanta escala é fornecida pelo recurso para atender a essa demanda?
Disponibilidade/recuperação de desastre	Qual é o impacto na disponibilidade ou no desastre nessa camada? Isso causaria uma interrupção sistêmica ou apenas um problema de capacidade localizada ou de disponibilidade?

Recursos globais

Determinados recursos nessa arquitetura são compartilhados por recursos implantados nas regiões. Nessa arquitetura, eles são usados para distribuir o tráfego entre várias regiões, armazenar o estado permanente de todo o aplicativo e armazenar os dados estáticos globais em cache.

Características	Considerações de camada
Tempo de vida	Espera-se que esses recursos sejam de longa duração. Sua vida útil abrange a vida útil do sistema ou mais. Geralmente, os recursos são gerenciados com dados in-loco e atualizações do plano de controle, supondo que ofereçam suporte a operações de atualização sem tempo de inatividade.
Estado	Como esses recursos existem pelo menos durante a vida útil do sistema, essa camada geralmente é responsável por armazenar o estado global replicado geograficamente.
Reach	Os recursos devem ser distribuídos globalmente. Recomenda-se a comunicação desses recursos com recursos regionais ou outros com baixa latência e a consistência desejada.
Dependências	Os recursos devem evitar dependências de recursos regionais, pois sua indisponibilidade pode ser uma causa de falha global. Por exemplo, certificados ou segredos mantidos em um único cofre podem ter impacto global se houver uma falha regional onde o cofre está localizado.
Limites de escala	Muitas vezes, esses recursos são instâncias únicas no sistema e, como tal, devem ser capazes de dimensionar de tal forma que possam lidar com a taxa de transferência do sistema como um todo.
Disponibilidade/recuperação de desastre	Como os recursos regionais e de carimbo podem consumir recursos globais ou são liderados por eles, é fundamental que os recursos globais sejam configurados com alta disponibilidade e recuperação de desastres para a integridade de todo o sistema.

Nessa arquitetura, os recursos de camada global são o Azure Front Door, o Azure Cosmos DB, o Registro de Contêiner do Azure e o Log Analytics do Azure para armazenar logs e métricas de outros recursos de camada global.

Há outros recursos fundamentais nesse design, como o Microsoft Entra ID e o DNS do Azure. Eles foram omitidos nesta imagem por brevidade.

Balanceador de carga global

O Azure Front Door é usado como o único ponto de entrada para o tráfego do usuário. O Azure garante que o Azure Front Door entregará o conteúdo solicitado sem erros em 99,99% das vezes. Para obter mais detalhes, consulte Limites de serviço do Front Door. Se o Front Door ficar indisponível, o usuário final verá o sistema como inativo.

A instância do Front Door envia o tráfego para os serviços de back-end configurados, como o cluster de computação que hospeda a API e o SPA de front-end. Erros de configuração de back-end no Front Door podem levar a interrupções. Para evitar interrupções devido a configurações incorretas, você deve testar extensivamente suas configurações do Front Door.

Outro erro comum pode vir de certificados TLS mal configurados ou ausentes, o que pode impedir os usuários de usarem o front-end ou o Front Door se comunicando com o back-end. A mitigação pode exigir intervenção manual. Por exemplo, você pode optar por reverter para a configuração anterior e reemitir o certificado, se possível. Independentemente disso, espere indisponibilidade enquanto as alterações entram em vigor. O uso de certificados gerenciados oferecidos pelo Front Door é recomendado para reduzir a sobrecarga operacional, como a expiração de manuseio.

O Front Door oferece muitos recursos adicionais além do roteamento de tráfego global. Um recurso importante é o Firewall de Aplicativo Web (WAF), porque o Front Door é capaz de inspecionar o tráfego que está passando. Quando configurado no modo de Prevenção, ele bloqueará o tráfego suspeito antes mesmo de chegar a qualquer um dos back-ends.

Para obter informações sobre os recursos do Front Door, consulte Perguntas frequentes sobre o Azure Front Door.

Para obter outras considerações sobre a distribuição global do tráfego, consulte Orientação de missão crítica em uma Estrutura bem arquitetada: Roteamento Global.

Registro de Contêiner

O Registro de Contêiner do Azure é usado para armazenar artefatos da OCI (Open Container Initiative), especificamente gráficos de comando e imagens de contêiner. Ele não participa do fluxo de solicitações e só é acessado periodicamente. O registro de contêiner precisa existir antes que os recursos de carimbo sejam implantados e não deve ter dependência de recursos de camada regional.

Habilite a redundância de zona e a replicação geográfica de registros para que o acesso às imagens durante o tempo de execução seja rápido e resiliente a falhas. Em caso de indisponibilidade, a instância pode fazer failover para regiões de réplica e as solicitações são automaticamente redirecionadas para outra região. Espere erros transitórios ao extrair imagens até que o failover seja concluído.

Falhas também podem ocorrer se as imagens forem excluídas inadvertidamente, novos nós de computação não poderão extrair imagens, mas os nós existentes ainda poderão usar imagens armazenadas em cache. A principal estratégia para recuperação de desastres é a reimplantação. Os artefatos em um registro de contêiner podem ser regenerados a partir de pipelines. O registro de contêiner deve ser capaz de suportar muitas conexões simultâneas para oferecer suporte a todas as suas implantações.

É recomendável usar a SKU Premium para habilitar a replicação geográfica. O recurso de redundância de zona garante resiliência e alta disponibilidade em uma região específica. Em caso de interrupção regional, as réplicas em outras regiões ainda estão disponíveis para operações de plano de dados. Com este SKU você pode restringir o acesso a imagens através de endpoints privados.

Para obter mais detalhes, consulte Práticas recomendadas para o Registro de Contêiner do Azure.

Backup de banco de dados

É recomendável que todos os estados sejam armazenados globalmente em um banco de dados separado dos carimbos regionais. Crie redundância implantando o banco de dados entre as regiões. Para cargas de trabalho de missão crítica, a sincronização de dados entre as regiões deve ser a principal preocupação. Além disso, em caso de falha, as solicitações de gravação no banco de dados ainda devem ser funcionais.

A replicação de dados em uma configuração ativa-ativa é altamente recomendada. O aplicativo deve ser capaz de se conectar instantaneamente com outra região. Todas as instâncias devem ser capazes de lidar com solicitações de leitura e gravação.

Para obter mais informações, consulte Plataforma de dados para cargas de trabalho de missão crítica.

Monitoramento global

O Log Analytics do Azure é usado para armazenar logs de diagnóstico de todos os recursos globais. É recomendável restringir a cota diária de armazenamento, especialmente em ambientes usados para teste de carga. Além disso, definir política de retenção. Essas restrições evitarão qualquer gasto excessivo incorrido com o armazenamento de dados que não sejam necessários além de um limite.

Considerações para serviços fundamentais

É provável que o sistema use outros serviços de plataforma críticos que podem fazer com que todo o sistema esteja em risco, como o DNS do Azure e o Microsoft Entra ID. O DNS do Azure garante 100% de disponibilidade SLA para solicitações DNS válidas. O Microsoft Entra garante pelo menos 99,99% de tempo de atividade. Ainda assim, você deve estar ciente do impacto no caso de uma falha.

Assumir a dependência dos serviços fundamentais é inevitável porque muitos serviços do Azure dependem deles. Espere interrupções no sistema se elas não estiverem disponíveis. Por exemplo:

• O Azure Front Door usa o DNS do Azure para acessar o back-end e outros serviços globais.
• O Registro de Contêiner do Azure usa o DNS do Azure para fazer failover de solicitações para outra região.

Nos dois casos, ambos os serviços do Azure serão afetados se o DNS do Azure não estiver disponível. A resolução de nomes para solicitações de usuários do Front Door falhará; As imagens do Docker não serão retiradas do registro. Usar um serviço DNS externo como backup não atenuará o risco porque muitos serviços do Azure não permitem essa configuração e dependem do DNS interno. Espere interrupção total.

Da mesma forma, o Microsoft Entra ID é usado para operações do plano de controle, como criar novos nós AKS, extrair imagens do Registro de Contêiner ou acessar o Key Vault na inicialização do pod. Se o Microsoft Entra ID não estiver disponível, os componentes existentes não deverão ser afetados, mas o desempenho geral poderá ser degradado. Novos pods ou nós AKS não serão funcionais. Portanto, caso as operações de expansão sejam necessárias durante esse período, espere uma experiência do usuário reduzida.

Recursos de carimbo de implantação regional

Nessa arquitetura, o carimbo de implantação implanta a carga de trabalho e provisiona recursos que participam da conclusão de transações comerciais. Um carimbo normalmente corresponde a uma implantação em uma região do Azure. Embora uma região possa ter mais de um carimbo.

Características	Considerações
Tempo de vida	Espera-se que os recursos tenham uma vida útil curta (efêmera) com a intenção de poderem ser adicionados e removidos dinamicamente enquanto os recursos regionais fora do selo continuam a persistir. A natureza efêmera é necessária para fornecer mais resiliência, escala e proximidade com os usuários.
Estado	Como os selos são efêmeros e podem ser destruídos a qualquer momento, um selo deve ser apátrida o máximo possível.
Reach	Pode se comunicar com recursos regionais e globais. No entanto, a comunicação com outras regiões ou outros selos deve ser evitada. Nessa arquitetura, não há necessidade de que esses recursos sejam distribuídos globalmente.
Dependências	Os recursos do selo devem ser independentes. Ou seja, não devem contar com outros selos ou componentes em outras regiões. É esperado que tenham dependências regionais e globais. O principal componente compartilhado é a camada de banco de dados e o registro de contêiner. Este componente requer sincronização em tempo de execução.
Limites de escala	A taxa de transferência é estabelecida por meio de testes. A taxa de transferência do carimbo geral é limitada ao recurso de menor desempenho. A taxa de transferência de selos precisa levar em conta o alto nível estimado de demanda e qualquer failover como resultado caso outro carimbo na região ficar indisponível.
Disponibilidade/recuperação de desastre	Devido à natureza temporária dos carimbos, a recuperação de desastres é feita reimplantando o carimbo. Se os recursos estiverem em um estado não íntegro, o carimbo, como um todo, pode ser destruído e implantado novamente.

Nessa arquitetura, os recursos de carimbo são o Serviço de Kubernetes do Azure, os Hubs de Eventos do Azure, o Key Vault do Azure e o Armazenamento de Blobs do Azure.

Unidades da escala

Um selo também pode ser considerado como uma unidade de escala (SU). Todos os componentes e serviços dentro de um determinado carimbo são configurados e testados para atender às solicitações em um determinado intervalo. Aqui está um exemplo de uma unidade de escala usada na implementação.

Cada unidade de escala é implantada em uma região do Azure e, portanto, está lidando principalmente com o tráfego dessa determinada área (embora possa assumir o tráfego de outras regiões quando necessário). Essa dispersão geográfica provavelmente resultará em padrões de carga e horários comerciais que podem variar de região para região e, como tal, cada UA é projetado para escalar/reduzir quando estiver ocioso.

Você pode implantar um novo carimbo para dimensionar. Dentro de um selo, os recursos individuais também podem ser unidades de escala.

Aqui estão algumas considerações sobre dimensionamento e disponibilidade ao escolher os serviços do Azure em uma unidade:

• Avaliar as relações de capacidade entre todos os recursos em uma unidade de escala. Por exemplo, para lidar com 100 solicitações de entrada, seriam necessários 5 pods de controlador de entrada e 3 pods de serviço de catálogo e 1000 RUs no Azure Cosmos DB. Portanto, ao dimensionar automaticamente os pods de entrada, espere o dimensionamento do serviço de catálogo e dos RUs do Azure Cosmos DB considerando esses intervalos.

• Fazer um teste de carga dos serviços para determinar um intervalo dentro do qual as solicitações serão atendidas. Com base nos resultados, configure instâncias mínimas e máximas e métricas de destino. Quando a meta for atingida, você pode optar por automatizar o dimensionamento de toda a unidade.

• Revisar os limites de escala de assinatura e as cotas do Azure para dar suporte ao modelo de capacidade e custo definido pelos requisitos de negócios. Verifique também os limites dos serviços individuais em consideração. Como as unidades geralmente são implantadas juntas, considere os limites de recursos de assinatura necessários para implantações canárias. Para obter mais informações, confira os limites do serviço do Azure.

• Escolha serviços que ofereçam suporte a zonas de disponibilidade para criar redundância. Isso pode limitar suas opções de tecnologia. Consulte Zonas de Disponibilidade para mais detalhes.

Para obter outras considerações sobre o tamanho de uma unidade e a combinação de recursos, consulte Orientação de missão crítica em Estrutura bem arquitetada: Arquitetura de unidade de escala.

Cluster de computação

Para conteinerizar a carga de trabalho, cada carimbo precisa executar um cluster de computação. Nessa arquitetura, o Serviço de Kubernetes do Azure (AKS) é escolhido porque o Kubernetes é a plataforma de computação mais popular para aplicativos modernos e conteinerizados.

O tempo de vida do cluster AKS está ligado à natureza efêmera do selo. O cluster não é monitorado pelo estado e não tem volumes persistentes. Ele usa discos efêmeros do sistema operacional em vez de discos gerenciados, pois não é esperado que eles recebam manutenção no nível do aplicativo ou do sistema.

Para aumentar a confiabilidade, o cluster é configurado para usar todas as três zonas de disponibilidade em uma determinada região. Isso possibilita que o cluster use o AKS Uptime SLA que garante 99,95% de disponibilidade de SLA do plano de controle AKS.

Outros fatores, como limites de escala, capacidade de computação e cota de assinatura também podem afetar a confiabilidade. Se não houver capacidade suficiente ou se os limites forem atingidos, as operações de dimensionamento e expansão falharão, mas é esperado que a computação existente funcione.

O cluster tem o dimensionamento automático habilitado para permitir que os pools de nós se expandam automaticamente, se necessário, o que melhora a confiabilidade. Ao usar vários pools de nós, todos os pools de nós devem ser dimensionados automaticamente.

No nível de pod, o HPA (Dimensionador Automático de Pod Horizontal) dimensiona os pods com base em métricas personalizadas, memória ou CPU configuradas. Faça um teste de carga dos componentes da carga de trabalho para estabelecer uma linha de base para os valores de escalonamento automático e HPA.

O cluster também é configurado para atualizações automáticas de imagem de nó e para dimensionar adequadamente durante essas atualizações. Esse dimensionamento permite zero tempo de inatividade enquanto as atualizações estão sendo executadas. Se o cluster em um carimbo falhar durante uma atualização, outros clusters em outros carimbos não deverão ser afetados, mas as atualizações entre os carimbos deverão ocorrer em momentos diferentes para manter a disponibilidade. Além disso, as atualizações de cluster são roladas automaticamente entre os nós para que não fiquem indisponíveis ao mesmo tempo.

Alguns componentes, como cert-manager e ingress-nginx, exigem imagens de contêiner de registros de contêiner externos. Se esses repositórios ou imagens não estiverem disponíveis, novas instâncias em novos nós (onde a imagem não está armazenada em cache) talvez não consigam iniciar. Esse risco pode ser atenuado importando essas imagens para o Registro de Contêiner do Azure do ambiente.

A observabilidade é crítica nessa arquitetura porque os carimbos são efêmeros. As configurações de diagnóstico são definidas para armazenar todos os dados de log e métricas em um espaço de trabalho regional do Log Analytics. Além disso, o AKS Container Insights é habilitado por meio de um Agente OMS no cluster. Esse agente permite que o cluster envie dados de monitoramento para o espaço de trabalho do Log Analytics.

Para outras considerações sobre o cluster de computação, consulte Orientação crítica para missão em estrutura Bem arquitetada: Orquestração de Contêineres e Kubernetes.

Key Vault

O Key Vault do Azure é usado para armazenar segredos globais, como cadeias de conexão para o banco de dados e segredos de carimbo, como a cadeia de conexão dos Hubs de Eventos.

Essa arquitetura usa um driver CSI do Secrets Store no cluster de computação para obter segredos do Key Vault. Segredos são necessários quando novos pods são gerados. Se o Key Vault não estiver disponível, novos pods podem não ser iniciados. Como resultado, pode haver ruptura; as operações de expansão podem ser afetadas, as atualizações podem falhar, não é possível executar novas implantações.

O Key Vault tem um limite no número de operações. Devido à atualização automática de segredos, o limite pode ser atingido se houver muitos pods. Você pode optar por diminuir a frequência de atualizações para evitar essa situação.

Para outras considerações sobre gerenciamento de segredos, consulte Orientações críticas para missão em Estrutura bem arquitetada: Proteção da integridade dos dados.

Hubs de Eventos

O único serviço com monitoração de estado no carimbo é o agente de mensagens, Hubs de Eventos do Azure, que armazena solicitações por um curto período. O agente atende à necessidade de buffering e mensagens confiáveis. As solicitações processadas são persistentes no banco de dados global.

Nessa arquitetura, a SKU Padrão é usada e a redundância de zona é habilitada para alta disponibilidade.

A integridade dos Hubs de Eventos é verificada pelo componente HealthService em execução no cluster de computação. Ele executa verificações periódicas em vários recursos. Isso é útil na detecção de condições não íntegras. Por exemplo, se as mensagens não puderem ser enviadas para o hub de eventos, o carimbo ficará inutilizável para quaisquer operações de gravação. O HealthService deve detectar automaticamente essa condição e relatar o estado não íntegro ao Front Door, que tirará o carimbo da rotação.

Para escalabilidade, recomenda-se ativar a ampliação automática.

Para obter mais informações, consulte Serviços de mensagens para cargas de trabalho de missão crítica.

Para outras considerações sobre mensagens, consulte Orientação de missão crítica em Estrutura bem arquitetada: Mensagens assíncronas.

Contas de armazenamento

Nessa arquitetura, duas contas de armazenamento são provisionadas. Ambas as contas são implantadas no modo de redundância de zona (ZRS).

Uma conta é usada para o ponto de verificação dos Hubs de Eventos. Se essa conta não for responsiva, o carimbo não poderá processar mensagens dos Hubs de Eventos e poderá até afetar outros serviços no carimbo. Essa condição é verificada periodicamente pelo HealthService, que é um dos componentes do aplicativo em execução no cluster de computação.

O outro é usado para hospedar o aplicativo de página única da interface do usuário. Se a veiculação do site estático tiver algum problema, o Front Door detectará o problema e não enviará tráfego para essa conta de armazenamento. Durante esse tempo, o Front Door pode usar conteúdo armazenado em cache.

Para obter mais informações sobre recuperação, confira Recuperação de desastre e failover de conta de armazenamento.

Recursos regionais

Um sistema pode ter recursos que são implantados na região, mas sobrevivem aos recursos de carimbo. Nessa arquitetura, os dados de observabilidade para recursos de carimbo são guardados em armazenamentos de dados regionais.

Características	Consideração
Tempo de vida	Os recursos compartilham o tempo de vida da região e sobrevivem aos recursos do selo.
Estado	O estado armazenado em uma região não pode viver além do tempo de vida da região. Se o estado precisar ser compartilhado entre regiões, considere o uso de um armazenamento de dados global.
Reach	Os recursos não precisam ser distribuídos globalmente. A comunicação direta com outras regiões deve ser evitada a todo custo.
Dependências	Os recursos podem ter dependências de recursos globais, mas não de recursos de selos, pois eles devem ter vida curta.
Limites de escala	Determine o limite de escala dos recursos regionais combinando todos os selos dentro da região.

Dados de monitoramento para recursos de carimbo

A implantação de recursos de monitoramento é um exemplo típico de recursos regionais. Nessa arquitetura, cada região tem um espaço de trabalho individual do Log Analytics configurado para armazenar todos os dados de log e métricas emitidos pelos recursos de carimbo. Como os recursos regionais sobrevivem aos recursos de carimbo, os dados ficam disponíveis mesmo quando o carimbo é excluído.

O Log Analytics do Azure e o Application Insights do Azure são usados para armazenar logs e métricas da plataforma. É recomendável restringir a cota diária de armazenamento, especialmente em ambientes usados para teste de carga. Além disso, defina a política de retenção para armazenar todos os dados. Essas restrições evitarão qualquer gasto excessivo incorrido com o armazenamento de dados que não sejam necessários além de um limite.

Da mesma forma, o Application Insights também é implantado como um recurso regional para coletar todos os dados de monitoramento de aplicativos.

Para obter recomendações de design sobre monitoramento, consulte Orientação para missão crítica em Estrutura bem arquitetada: Modelagem de integridade.

Próximas etapas

Implante a implementação de referência para obter uma compreensão completa dos recursos e sua configuração usados nessa arquitetura.

Implementação: Missão Crítica Online