Cargas de trabalho de nível de operadora no Azure

Os sistemas críticos se concentram principalmente na maximização do tempo de atividade e eles existem em muitos setores. No setor de telecomunicações, eles são chamados de sistemas de nível de operadora. Esses sistemas são desenvolvidos devido a um ou mais dos seguintes drivers:

• Minimizando a perda de vidas ou lesões.
• Atender aos requisitos regulatórios de confiabilidade para evitar o pagamento de multas.
• Otimizando o serviço aos clientes para minimizar a rotatividade para os concorrentes.
• Atender a SLAs (Contratos de Nível de Serviço) contratuais com clientes corporativos ou governamentais.

Esta série de artigos aplica a metodologia de design para cargas de trabalho críticas para informar diretrizes prescritivas para criar e operar uma carga de trabalho de telecomunicações altamente confiável, resiliente e disponível no Azure.

Observação

Os artigos desta série se concentram em fornecer considerações críticas adicionais ao projetar níveis de confiabilidade de 99,999% ('5 9s') no setor de telecomunicações.

O que é uma carga de trabalho de nível de operadora?

O termo carga de trabalho refere-se a uma coleção de recursos de aplicativo que dão suporte a uma meta comercial comum ou à execução de um processo comercial comum, com vários serviços, como APIs e armazenamentos de dados, trabalhando juntos para fornecer funcionalidades específicas de ponta a ponta.

O termo missão crítica refere-se a uma classificação de criticalidade em que um custo financeiro significativo (comercialmente crítico) ou o custo humano (crítico à segurança) está associado à indisponibilidade ou ao baixo desempenho.

Uma carga de trabalho de nível de operadora é dinâmica tanto comercialmente crítica quanto crítica à segurança, em que há um requisito fundamental para estar operacional com apenas minutos ou até mesmo segundos de tempo de inatividade por ano civil. Não atingir esse requisito de tempo de atividade pode resultar em perda extensiva de vidas, incorrer em multas significativas ou penalidades contratuais.

O aspecto operacional da carga de trabalho inclui como a confiabilidade é medida e as metas que ela deve cumprir ou exceder. Sistemas altamente confiáveis normalmente têm como alvo 99,999% de tempo de atividade (normalmente chamado de '5 9s') ou 0,001% de tempo de inatividade em um ano (aproximadamente 5 minutos). Alguns sistemas têm como destino 99,9999% de tempo de atividade, ou 30 segundos de inatividade por ano, ou até mesmo níveis mais altos de confiabilidade. Isso abrange todas as formas e causas de interrupção – manutenção agendada, falha de infraestrutura, erro humano, problemas de software e até mesmo desastre natural.

Embora a plataforma usada tenha evoluído de hardware dedicado e proprietário por meio de hardware comercial, off-the-shelf para nuvens OpenStack ou VMware, as empresas de telecomunicações fornecem consistentemente serviços que alcançam ≤ 5 minutos de tempo de inatividade por ano e, em muitos casos, atingem ≤ 30 segundos de tempo de inatividade devido a interrupções não programadas.

Quais são os desafios comuns?

A criação de cargas de trabalho de nível de operadora é um desafio por esses motivos main:

Abordagem de elevação e deslocamento

As empresas de telecomunicações têm aplicativos bem arquitetos que fornecem o comportamento esperado em sua infraestrutura existente. No entanto, deve-se tomar cuidado antes de assumir que a portabilidade desses aplicativos como está para uma infraestrutura de nuvem pública não afetará sua resiliência.

Os aplicativos existentes fazem um conjunto de suposições sobre sua infraestrutura subjacente, que dificilmente permanecerão verdadeiras ao migrar do local para a nuvem pública. O arquiteto deve marcar que ainda mantém e ajusta a infraestrutura e o design do aplicativo para acomodar a nova realidade. O arquiteto também deve procurar oportunidades em que a nova infraestrutura remova as limitações existentes no local.

Por exemplo, a atualização de sistemas locais deve ocorrer porque não é viável manter hardware suficiente para criar uma nova implantação junto e fazer a transição lenta de maneira segura. Esse caminho de atualização gera uma série de requisitos de como as atualizações e reversões são gerenciadas. Esses requisitos levam à complexidade e significam que as atualizações são pouco frequentes e são permitidas apenas em janelas de manutenção cuidadosamente gerenciadas.

No entanto, na nuvem pública, é razoável criar uma nova implantação em paralelo com a implantação existente. Esse processo cria a oportunidade para grandes simplificações no design operacional do aplicativo e melhorias na experiência e nas expectativas do usuário.

Soluções monolíticas

A experiência em uma variedade de setores críticos mostra que não é realista tentar construir uma solução monolítica que alcançará os níveis de disponibilidade desejados. Há muitas fontes potenciais de falha em um sistema complexo. Em vez disso, as soluções bem-sucedidas são compostas por elementos individuais independentes e redundantes. Cada unidade tem disponibilidade relativamente básica (normalmente ~99,9%), mas quando combinada, a solução total atinge as metas de disponibilidade necessárias. A arte da engenharia de nível de operadora torna-se, então, garantir que as únicas dependências comuns aos elementos redundantes sejam aquelas que são absolutamente necessárias, uma vez que exercem a influência mais significativa na disponibilidade geral, muitas vezes ordens de magnitude maiores do que qualquer outra coisa no design.

Apenas compilar redundância zonal

Usar o Microsoft Azure Zonas de Disponibilidade é a escolha básica para reduzir o risco de interrupção devido a falhas de hardware ou problemas ambientais localizados. No entanto, não é suficiente alcançar a disponibilidade de nível de operadora, principalmente por estes motivos:

• Zonas de Disponibilidade (AZs) foram projetados para que a latência de rede entre duas zonas em uma única região seja ≤ 2 ms. As AZs não podem ser amplamente e geograficamente dispersas. Portanto, as AZs compartilham um risco correlacionado de falha devido a desastres naturais, como inundações ou quedas maciças de energia, que podem desabilitar várias AZs em uma região.

• Muitos serviços do Azure foram explicitamente projetados para serem com redundância de zona para que os aplicativos que os usam não precisem de lógica explícita para se beneficiarem do ganho de disponibilidade. Essa função de redundância dentro do serviço requer colaboração entre os elementos em cada zona. Geralmente, há um risco inevitável de falha de software em uma zona que causa falhas correlacionadas em outras zonas. Por exemplo, qualquer problema com um segredo ou certificado usado com o serviço com redundância de zona pode afetar todos os AZs simultaneamente.

Quais são as principais áreas de design?

Ao criar uma carga de trabalho de nível de operadora, considere as seguintes áreas:

Área de design	Descrição
Tolerância a falhas	O design do aplicativo deve permitir falhas inevitáveis para que o aplicativo como um todo possa continuar operando em algum nível. O design deve minimizar pontos de falha e adotar uma abordagem federada.
Modelo de dados	O design deve atender às necessidades de consistência, disponibilidade e tolerância à partição do banco de dados. A disponibilidade de Grau da Operadora requer que o aplicativo seja implantado em várias regiões. Essa implantação requer um pensamento cuidadoso sobre como os dados do aplicativo serão gerenciados nessas regiões.
Modelagem de integridade	Um modelo de integridade eficaz fornece observabilidade de todos os componentes, plataforma e aplicativo, para que os problemas possam ser detectados rapidamente e a resposta esteja pronta por meio da autorrecuperação ou de outras correções.
Teste e validação	O design e a implementação do aplicativo devem ser testados minuciosamente. Além disso, a integração e a implantação do aplicativo como uma solução inteira devem ser testadas.

Próxima etapa

Comece examinando os princípios de design para cenários de aplicativo de nível de operadora.

Princípios de design