Essa arquitetura fornece as diretrizes para o projeto de uma solução de nível de operadora para um caso de uso de telecomunicações. As opções de design se concentram na alta confiabilidade, minimizando os pontos de falha e, em última análise, o tempo de inatividade geral utilizando os recursos nativos do Azure.
Importante
A arquitetura se baseia nos princípios de design de uma carga de trabalho de classe de operadora. É altamente recomendável ler as diretrizes sobre Well-Architected para cargas de trabalho de classe de operadora para entender as escolhas de design feitas nessa arquitetura.
Caso de uso
Essa arquitetura de referência destina-se a uma solução de correio de voz. Ela oferece funcionalidades comuns, como: reproduzir saudações e gravar correio de voz, recuperar correio de voz pelo telefone ou aplicativo, configurar recursos, entre outros.
Vários clientes podem se conectar à carga de trabalho usando vários protocolos. Os protocolos podem ser HTTP ou outros, como SIP ou IMAP. Uma conexão pode modificar o estado persistente, que pode ser a configuração do cliente, mensagens e metadados relacionados.
Requisitos de carga de trabalho
- A carga de trabalho deve ter uma meta de Objetivo de Nível de Serviço de 99,999%, o que equivale a uma duração total esperada de interrupção de menos de 5 minutos por ano.
- As solicitações de aplicativo para todos os protocolos compatíveis devem ter a carga balanceada em todos os carimbos ativos.
- A replicação de operações de gravação em dados de assinante deve ser quase instantânea entre as regiões. Na maioria dos casos, os dados de leitura de um carimbo devem ser fornecidos com a versão mais recente e atualizada dos dados do assinante.
- Se ocorrer uma falha no meio de uma sessão de caixa postal do assinante ativo, o chamador precisará se reconectar. A carga de trabalho não será necessária para manter o estado de sessão ativo para mensagens em curso.
Principais estratégias de design
- Implantação com várias regiões ativa-ativa. Implante várias instâncias de aplicativos em várias regiões para minimizar a interrupção regional como um único ponto de falha. Em um modelo ativo-ativo, não há um procedimento de failover separado, portanto, o tratamento de falhas é rápido e confiável.
- Armazenamento replicado. Mantenha o próprio aplicativo sem estado. Os dados são persistentes no âmbito regional ou global, e a redundância é criada com a replicação entre regiões.
- A consistência eventual dos dados é forçada pelo teorema CAP (consistência, disponibilidade e tolerância de partição). Implemente a lógica do aplicativo que usa tipos de dado replicado sem conflito (CRDTs) e a lógica do aplicativo para processar estados intermediários.
- Evite modos de falha correlacionados. Pegue elementos independentes e combine-os para atingir uma meta de maior confiabilidade.
- Destino compartilhado dentro de cada carimbo. Agregue todas as dependências do carimbo dentro desse carimbo. Isso elimina a sobrecarga de lidar com falhas parciais. Se uma instância estiver inativa, um novo carimbo substituirá a instância não íntegra.
Arquitetura
A carga de trabalho está hospedada na infraestrutura do Azure, e vários serviços do Azure participam do processamento de solicitações e do fornecimento da funcionalidade do serviço. Os componentes dessa arquitetura podem ser amplamente categorizados da seguinte maneira. Para obter a documentação do produto sobre os serviços do Azure, consulte os Recursos relacionados.
Recursos globais
Esses recursos fornecem uma funcionalidade que é compartilhada por recursos implantados em todas as regiões. Por exemplo, o balanceador de carga global que distribui o tráfego para várias regiões. Serviços básicos dos quais outros serviços dependem, como a plataforma de identidade (Microsoft Entra ID) e o DNS. Os recursos globais também incluem serviços que mantêm a consistência funcional entre regiões, como repositórios de estado e bancos de dados compartilhados.
Gerenciador de Tráfego do Azure
O balanceador de carga global que usa o roteamento baseado em DNS para enviar tráfego para o carimbo do aplicativo que tem pontos de extremidade públicos. O monitoramento de ponto de extremidade de integridade está habilitado para garantir que o tráfego seja enviado para instâncias de back-end íntegras.
Azure Cosmos DB
Armazena metadados de carga útil do aplicativo e dados de provisionamento do usuário final. Também usado pelos serviços dependentes listados acima. A gravação em várias regiões é habilitada para que os dados sejam replicados para cada região, instantaneamente. Além disso, a redundância de zona é habilitada por meio do modo de armazenamento com redundância de zona (ZRS).
Componente de gateway
Um componente de solução personalizado, como um controlador de borda de sessão (SBC) que existe fora da nuvem. O gateway serve como o único ponto de extremidade para clientes que usam protocolos diferentes de HTTP. Ele monitora a integridade dos pontos de extremidade de back-end e roteia o tráfego para as instâncias íntegras.
Importante
O roteamento global é tratado por meio de DNS. Se algum serviço global ou básico não estiver disponível, todo o sistema será afetado.
Recursos regionais
Esse conjunto de serviços implantados em cada região e o respectivo tempo de vida útil estão vinculados a essa região.
Serviço de gerenciamento
Trata-se de um serviço personalizado que fornece os aspectos de gerenciamento, implantação e monitoramento para o aplicativo. Mais de um carimbo de gerenciamento pode atender a uma única instância de aplicativo em qualquer região.
Registro de Contêiner do Azure
Armazena todas as imagens de contêiner. A redundância de zona é habilitada para proteger contra falhas zonais.
Azure Key Vault
Armazena segredos globais, como cadeias de conexão para o banco de dados global e segredos regionais.
Azure Monitor
Coleta logs e métricas emitidos pela carga de trabalho e pelos recursos do Azure. Os dados são armazenados nos Logs do Azure Monitor e em um Workspace do Log Analytics.
Conjunto de escala de máquina virtual
É executado como instâncias de jump box para executar ferramentas no cluster, como kubectl.
Armazenamento de Blobs do Azure
Armazena grandes dados de payload, dados de métricas de longo prazo, imagens de máquinas virtuais, despejos de núcleo de aplicativos e pacotes de diagnóstico. Considere o uso do SKU Premium para desempenho, dependendo dos padrões de uso esperados. O armazenamento é configurado para armazenamento com redundância de zona (ZRS), replicação de objeto (OR) entre regiões e manipulação no nível de aplicativo.
Azure Functions
Aciona a funcionalidade específica do aplicativo conforme desejado.
Armazenamento de Filas do Azure
Fornece durabilidade adicional por meio de um mecanismo distinto de modo que a mensagem seja retida com segurança caso o mecanismo de armazenamento principal não esteja disponível no ponto de depósito da mensagem.
Importante
Os recursos regionais são independentes, de modo que a indisponibilidade de um recurso em uma região não afeta (na medida do possível) os recursos em outra região. Pode haver interrupções simultâneas em várias regiões, mas espera-se que sejam extremamente raras.
Os recursos podem ainda ser categorizados por sua exigência funcional. O Armazenamento de Blobs do Azure, o Azure Cosmos DB, o Azure Functions e o Armazenamento de Filas do Azure participam do processamento de uma solicitação. Outros componentes, como Key Vault, Monitor e Registro de Contêiner, são usados indiretamente e durante operações de gerenciamento.
Recursos de carimbo regionais
Dentro de cada região, um conjunto de recursos é implantado como parte de um carimbo de implantação para fornecer mais resiliência e escala. Os recursos devem ser efêmeros. Eles são destruídos e recriados dinamicamente, enquanto os recursos regionais fora do carimbo (mantendo o estado do aplicativo) continuam persistindo.
Computação de carga de trabalho
As máquinas virtuais e os contêineres são usados para hospedar a carga de trabalho. As opções de tecnologia são a Máquina Virtual do Azure padrão e o Serviço de Kubernetes do Azure (AKS), respectivamente. O AKS foi escolhido como o orquestrador de contêineres, pois é amplamente adotado e oferece suporte a topologias avançadas de escalabilidade e implantação.
Design de carga de trabalho
O aplicativo faz parte do carimbo e, portanto, é imutável. Os carimbos de aplicativo fornecem a função real do aplicativo. Qualquer carimbo de aplicativo pode atender a uma solicitação do cliente. Os carimbos são implantados e monitorados pelo serviço de gerenciamento.
Considerações de resiliência
Os serviços são implementados como microsserviços, conteinerizados em um cluster AKS regional. O padrão de microsserviço permite a separação de elementos de processamento e estado para que a falha em um componente não afete os demais. O aplicativo é sem estado, e o estado de longa duração é armazenado em um banco de dados externo.
Para criar redundância, os carimbos são implantados em várias zonas de disponibilidade e regiões em um modelo ativo-ativo. Ou seja, há um carimbo em cada zona de disponibilidade de cada região na implantação; todos os carimbos estão ativos, e a carga é balanceada em todos eles.
Os componentes dentro de cada carimbo usam um modelo de compartilhamento de destino, que simplifica os fluxos lógicos e os caminhos de conexão, eliminando a necessidade de código de caso especial para lidar com condições de falha parcial.
Monitoramento
Essa implementação tem um modelo de integridade em vigor para garantir que as solicitações do cliente não sejam enviadas para instâncias não íntegras. O serviço de gerenciamento examina os carimbos do aplicativo em intervalos regulares e mantém um status de integridade. Se o estado de integridade de um carimbo específico for degradado, o serviço de gerenciamento deixará de responder à solicitação de sondagem do Gerenciador de Tráfego, e o tráfego não será roteado para essa instância.
Gerenciamento de tráfego
O aplicativo é liderado por uma camada de gerenciamento de tráfego, que fornece balanceamento de carga. O tráfego de entrada pode ser categorizado com base no tipo de protocolo:
O Protocolo A acessa o aplicativo por meio de um componente de gateway intermediário fora da nuvem. O design usa o padrão de roteamento do gateway, e o gateway serve como ponto de extremidade único e roteia o tráfego para vários carimbos de back-end.
O Protocolo B roteia o tráfego HTTP ou não-HTTP para o aplicativo em várias regiões. O Gerenciador de Tráfego do Azure é usado como balanceador de carga global e roteia o tráfego com base no DNS.
O balanceador de carga interno distribui as solicitações de entrada para os pods de carimbo. Os serviços podem ser acessados por meio dos respectivos nomes DNS atribuídos por objetos nativos do Kubernetes.
Considerações sobre a confiabilidade
O Gerenciador de Tráfego do Azure está no caminho crítico para os clientes. Se o Gerenciador de Tráfego não estiver disponível, o sistema aparecerá como offline para os clientes. Portanto, ao calcular a meta composta de SLA (Contrato de Nível de Serviço) para o sistema, o SLA do Gerenciador de Tráfego deverá ser considerado, e atenção cuidadosa deverá ser dada à configuração TTL, períodos de repetição do cliente e assim por diante.
Assim como o Gerenciador de Tráfego do Azure, o gateway também é um único ponto de falha e, portanto, deve ser projetado com redundância interna. A falha afetará novas conexões de cliente e clientes existentes depois que a entrada DNS armazenada em cache expirar.
Se um serviço de back-end não estiver disponível, o Gerenciador de Tráfego e o gateway não atualizarão o registro DNS até que o tempo de vida (TTL) do DNS tenha expirado. Então, esse tempo deve ser curto. Os clientes continuarão chegando ao último endereço conhecido. Use as políticas do Azure para impor o encerramento de chamadas de longa duração ou conexões que ainda existem.
Tanto o Gerenciador de Tráfego quanto o gateway dependem do DNS do Azure, como um serviço fundamental, para reduzir a complexidade e fornecer um SLA mais alto. Em princípio, uma interrupção do DNS do Azure poderia levar a uma interrupção total. O DNS do Azure é altamente disponível, e os clientes com conexões existentes ou cache apropriado poderão continuar operando mesmo se o DNS estiver indisponível por um curto período.
Para obter informações sobre SLAs para serviços do Azure, consulte os Contratos de Nível de Serviço (SLA) para serviços online.
Monitoramento da integridade
O modelo de integridade garante que as solicitações do cliente não sejam roteadas para instâncias não íntegras. A camada de gerenciamento de tráfego sonda o serviço de gerenciamento de back-end antes de rotear o tráfego.
Para o Protocolo A, o gateway é responsável pelo monitoramento do ponto de extremidade. Ele recebe uma lista priorizada de pontos de acesso de carimbo de um servidor DNS e usa a sondagem ativa para determinar a vida útil do carimbo.
Para o Protocolo B, o Gerenciador de Tráfego do Azure tem recursos internos de sondagem que minimizam a chance de enviar tráfego para um carimbo que não responde. Os pontos de extremidade não íntegros são excluídos na resposta DNS aos clientes. Essa abordagem ajuda na confiabilidade, pois a primeira tentativa de um cliente de acessar um servidor provavelmente será bem-sucedida.
Coerência de dados
Para cargas de trabalho de classe de operadora, recomenda-se que os dados cruciais relacionados à carga de trabalho sejam armazenados externamente (o padrão sem estado). Gravar no banco de dados é um processo crítico para esse caso de uso.
Os dados devem ser replicados regionalmente em uma configuração ativa-ativa, para que sejam rapidamente sincronizados entre regiões. O banco de dados deve ser configurado com várias regiões de gravação. Tanto a leitura quanto a gravação podem ser executadas em todas as regiões. Isso garante que, se houver uma falha de carga de trabalho ou banco de dados em qualquer região, a carga de trabalho poderá continuar atendendo a solicitações de outras regiões perfeitamente.
Nessa arquitetura, o Azure Cosmos DB foi escolhido como o banco de dados global, pois oferece suporte ao modelo de várias regiões de gravação. Se houver uma interrupção global, dados consistentes estarão disponíveis em várias regiões quase instantaneamente. Além disso, a redundância zonal é garantida por meio do uso do armazenamento com redundância de zona (ZRS).
Essa arquitetura também usa o Armazenamento de Blobs do Azure para armazenar dados complementares, como dados de métricas de longo prazo, despejos de núcleo de aplicativo e pacotes de diagnóstico. O recurso é configurado para usar a armazenamento com redundância de zona (ZRS) com a replicação de objeto entre regiões. Essa combinação foi escolhida porque permite controlar a região secundária e a camada de armazenamento, ou seja, a cópia primária premium e a cópia secundária frequente-esporádica. Para esse caso de uso, também é uma maneira econômica de replicar dados.
Consulte Cargas de trabalho de classe de operadora bem arquitetadas: modelo de dados.
Implantação em várias regiões: escalabilidade, disponibilidade e custo
A carga de trabalho é implantada em várias regiões e em várias Zonas de Disponibilidade dentro de cada região. Isso proporciona resiliência contra falhas no nível de zona e região.
A escala é alcançada por meio da combinação da capacidade de carimbo individual e do número total de instâncias. A solução geral é dimensionada de tal forma que até uma região inteira pode falhar, mas as regiões restantes ainda podem atender à carga máxima de tráfego esperada. Isso significa que uma implantação de duas regiões precisa de 100% de espaço livre (2x superprovisionado), enquanto uma implantação de quatro regiões precisa de apenas 33% de espaço livre.
As considerações de espaço livre favorecem uma implantação maior. No entanto, as despesas gerais constantes por instância e a taxa de disponibilidade constante por região favorecem uma implantação menor. A modelagem de disponibilidade e custo é necessária para determinar a melhor topologia para uma determinada carga de trabalho. Os requisitos de conectividade, localidade e residência de dados também podem afetar a seleção de região.
A capacidade de cada carimbo individual é ajustada com base nos resultados dos testes de carga que preveem variações de carga. O dimensionamento automático é habilitado para o serviço e o cluster usando o dimensionador automático do cluster AKS e o dimensionamento automático de pod horizontal do Kubernetes. Há componentes que são dimensionados manualmente. Para esses componentes, os limites de escala são definidos na configuração, e o dimensionamento é tratado como uma operação de atualização.
Observabilidade geral
Os logs e as métricas emitidos pela carga de trabalho e pelos recursos do Azure são coletados e armazenados nos Logs e no Armazenamento de Blobs do Azure Monitor. Eles são processados pelo serviço de gerenciamento em cada Zona de Disponibilidade e não são replicados fora de cada zona, pois o custo adicional não se justifica nesse caso. O monitoramento em todo o aplicativo é obtido por meio do uso de consultas federadas no serviço de gerenciamento em cada zona. Os dados de monitoramento são retidos de modo que o diagnóstico possa ser realizado após o fato, permitindo a resolução de falhas.
Os alertas são configurados pelas instâncias do aplicativo. Os eventos de limite de métrica são replicados em todas as zonas e regiões para que estejam sempre disponíveis.
Consulte Cargas de trabalho de classe de operadora bem arquitetadas: modelagem de integridade.
Considerações operacionais
O aspecto operacional da arquitetura é fundamental para alcançar uma alta disponibilidade. Isso abrange automação, implantação e decisões de gerenciamento secreto da arquitetura.
Implantação
O código-fonte e a configuração do aplicativo são armazenados em um repositório Git no Azure DevOps. Uma abordagem GitOps é usada para integração contínua/implantação contínua (CI/CD).
Flux é o operador GitOps que responde às alterações e aciona uma ferramenta de script para criar recursos do Azure para os carimbos. Isso inclui máquinas virtuais, cluster AKS, pods de convergência e atualizações de DNS para descoberta de serviço da nova instância. Os requisitos de dimensionamento também são atendidos pelo GitOps. Para o dimensionamento manual, os limites de escala são definidos na configuração de carimbo. O dimensionamento é obtido por meio do processo de atualização que cria novas instâncias do tamanho necessário e, em seguida, substitui a atual.
Por outro lado, o Flux também desativa recursos que não são necessários. Por exemplo, se uma instância específica não deve receber tráfego, o Flux reage à alteração de configuração. Ele aciona as atualizações de DNS para impedir que o novo tráfego chegue à instância. Além disso, quando os arquivos de definição são removidos, o GitOps aciona scripts para excluir normalmente o cluster, as máquinas virtuais e outros recursos do Azure. Os recursos são desativados como parte do dimensionamento das operações.
Atualização, aplicação de patches e atualizações de configuração
Quando uma nova instância é criada, os arquivos de configuração de implantação são alterados para indicar um aumento no tráfego para a nova instância e diminuir o tráfego para a instância antiga. O Flux detecta essa alteração e atualiza os registros DNS. O tráfego será revertido para a instância antiga se houver erros. Caso contrário, a instância antiga será desativada.
Automação
A automação é fundamental para a resiliência geral, dados os tempos de reação necessários. Diversas tecnologias de automação são utilizadas no fluxo operacional. No entanto, também é fundamental que haja portas manuais no processo de ponta a ponta para garantir que os erros não sejam introduzidos e propagados por meio da automação.
Consulte Cargas de trabalho de classe de operadora bem arquitetadas: tolerância a falhas.
Teste e validação
De uma perspectiva de disponibilidade, a análise do modo de falha é estendida para incluir todos os segmentos de rede entre os componentes do aplicativo. Além disso, entre o aplicativo e os clientes, pois as interrupções ainda afetarão a disponibilidade do aplicativo conforme percebido pelos usuários.
Consulte Cargas de trabalho de classe de operadora bem arquitetadas: teste e validação.
Alternativas
Em vez de Fila de Armazenamento, você pode escolher outro agente de mensagens que tenha garantias de confiabilidade. O Barramento de Serviço do Azure é uma boa opção porque tem confirmações de duas fases e recursos como fila de mensagens mortas interna e recursos de eliminação de duplicação.
Outra opção para roteamento global de tráfego HTTP (não outros protocolos) é o Azure Front Door. Ele tem recursos internos do Firewall de Aplicativo Web (WAF) aplicados para proteger o tráfego de entrada da Camada 7.
O Azure Functions pode ser usado para fornecer recursos adicionais, incluindo até mesmo funções dependentes do tempo, como mensagens atrasadas ou notificações atrasadas.
Recursos relacionados
Para obter a documentação do produto sobre os serviços do Azure usados nessa arquitetura, consulte estes artigos.