Aplicativos em nuvem escaláveis e engenharia de confiabilidade do local (SRE)

O sucesso da sua solução na nuvem depende da sua fiabilidade. A fiabilidade pode ser amplamente definida como a probabilidade de o sistema funcionar como esperado, sob as condições ambientais especificadas, dentro de um período de tempo especificado. A engenharia de confiabilidade do local (SRE) é um conjunto de princípios e práticas para a criação de sistemas de software escaláveis e altamente confiáveis. Cada vez mais, o SRE é usado durante o projeto de serviços digitais para garantir maior confiabilidade.

Para obter mais informações sobre estratégias SRE, consulte AZ-400: Develop a Site Reliability Engineering (SRE) strategy.

Potenciais casos de utilização

Os conceitos neste artigo aplicam-se a:

• Serviços na nuvem baseados em API.
• Aplicações Web orientadas para o público.
• Cargas de trabalho baseadas em IoT ou em eventos.

Arquitetura

Transfira um ficheiro PowerPoint desta arquitetura.

A arquitetura considerada aqui é a de uma plataforma de API escalável. A solução compreende vários microsserviços que usam uma variedade de bancos de dados e serviços de armazenamento, incluindo soluções de software como serviço (SaaS), como Dynamics 365 e Microsoft 365.

Este artigo considera uma solução que lida com casos de uso de mercado e comércio eletrônico de alto nível para demonstrar os blocos mostrados no diagrama. Os casos de uso são:

• Navegação no produto.
• Registo e login.
• Visualização de conteúdos, como notícias.
• Gestão de encomendas e subscrições.

Aplicativos cliente, como aplicativos Web, aplicativos móveis e até mesmo aplicativos de serviço, consomem os serviços da plataforma de API por meio de um caminho de acesso unificado, https://api.contoso.com.

Componentes

• O Azure Front Door fornece um ponto de entrada seguro e unificado para todas as solicitações à solução. Para obter mais informações, consulte Visão geral da arquitetura de roteamento.
• O Gerenciamento de API do Azure fornece uma camada de governança sobre todas as APIs publicadas. Você pode usar as políticas de Gerenciamento de API do Azure para aplicar recursos adicionais na camada de API, como restrições de acesso, cache e transformação de dados. O Gerenciamento de API oferece suporte ao dimensionamento automático em níveis padrão e premium.
• O Serviço Kubernetes do Azure (AKS) é a implementação do Azure de clusters Kubernetes de código aberto. Como um serviço Kubernetes hospedado, o Azure lida com tarefas críticas, como monitoramento e manutenção de integridade. Como os mestres do Kubernetes são gerenciados pelo Azure, você gerencia e mantém apenas os nós do agente. Nesta arquitetura, todos os microsserviços são implantados no AKS.
• O Gateway de Aplicativo do Azure é um serviço de controlador de entrega de aplicativos. Ele opera na camada 7, a camada de aplicação, e tem vários recursos de balanceamento de carga. O Application Gateway Ingress Controller (AGIC) é um aplicativo Kubernetes que possibilita que os clientes do Serviço Kubernetes do Azure (AKS) usem o balanceador de carga nativo do Application Gateway L7 do Azure para expor o software de nuvem à Internet. O dimensionamento automático e a redundância de zona são suportados no SKU v2.
• O Armazenamento do Azure, o Armazenamento do Azure Data Lake, o Azure Cosmos DB e o Azure SQL podem armazenar conteúdo estruturado e não estruturado. Os contêineres e bancos de dados do Azure Cosmos DB podem ser criados com taxa de transferência de dimensionamento automático.
• O Microsoft Dynamics 365 é uma oferta de software como serviço (SaaS) da Microsoft que fornece vários aplicativos de negócios para atendimento ao cliente, vendas, marketing e finanças. Nessa arquitetura, o Dynamics 365 é usado principalmente para gerenciar catálogos de produtos e para gerenciamento de atendimento ao cliente. As unidades de escala fornecem resiliência aos aplicativos do Dynamics 365.
• O Microsoft 365 (anteriormente Office 365) é usado como um sistema de gerenciamento de conteúdo corporativo baseado no Office 365 SharePoint Online. Ele é usado para criar, gerenciar e publicar conteúdo, como ativos de mídia e documentos.

Alternativas

Como essa solução usa uma arquitetura baseada em microsserviços altamente escalável, considere estas alternativas para o plano de computação:

• Azure Functions para serviços de API sem servidor
• Azure Spring Apps para microsserviços baseados em Java

Fiabilidade adequada

O grau de confiabilidade necessário para uma solução depende do contexto de negócios. Uma loja de varejo que está aberta por 14 horas, e que tem o pico de uso do sistema dentro desse período, tem requisitos diferentes de uma empresa on-line que aceita pedidos a qualquer hora. As práticas SRE podem ser adaptadas para alcançar o nível adequado de confiabilidade.

A confiabilidade é definida e medida usando SLOs (Service Level Objetives , objetivos de nível de serviço) que definem o nível de confiabilidade desejado para um serviço. Atingir o nível-alvo garante a satisfação dos consumidores. Os objetivos do SLO podem evoluir ou mudar dependendo das demandas do negócio. No entanto, os proprietários de serviços devem medir constantemente a confiabilidade em relação aos SLOs para detetar problemas e tomar ações corretivas. Os SLOs são geralmente definidos como uma realização percentual ao longo de um período.

Outro termo importante a ser observado é o indicador de nível de serviço (SLI), que é a métrica usada para calcular o SLO. Os SLIs são baseados em informações derivadas de dados capturados à medida que o cliente consome o serviço. Os SLIs são sempre medidos do ponto de vista do cliente.

SLOs e SLIs sempre andam de mãos dadas, e geralmente são definidos de forma iterativa. Os SLOs são orientados pelos principais objetivos de negócios, enquanto os SLIs são impulsionados pelo que é possível ser medido durante a implementação do serviço.

A relação entre a métrica monitorada, o SLI e o SLO é descrita abaixo:

Isso é explicado com mais detalhes em Definir métricas de SLI para calcular SLOs.

Escala de modelagem e expectativas de desempenho

Para um sistema de software, o desempenho geralmente refere-se à capacidade de resposta geral de um sistema ao executar uma ação dentro de um tempo especificado, enquanto a escalabilidade é a capacidade do sistema de lidar com cargas de usuário aumentadas sem prejudicar o desempenho.

Um sistema é considerado escalável se os recursos subjacentes forem disponibilizados dinamicamente para suportar um aumento da carga. Os aplicativos em nuvem devem ser projetados para escala, e o volume de tráfego é difícil de prever às vezes. Os picos sazonais podem aumentar os requisitos de escala, especialmente quando um serviço lida com solicitações para vários locatários.

É uma boa prática projetar aplicativos para que os recursos de nuvem aumentem e diminuam automaticamente conforme necessário para atender à carga. Basicamente, o sistema deve se adaptar ao aumento da carga de trabalho, provisionando ou alocando recursos de forma incremental para atender à demanda. A escalabilidade diz respeito não apenas a instâncias de computação, mas também a outros elementos, como armazenamento de dados e infraestrutura de mensagens.

Este artigo mostra como você pode garantir a confiabilidade apropriada para um aplicativo em nuvem conduzindo modelagem de escala e desempenho dos cenários de carga de trabalho e usando os resultados para definir os monitores, os SLIs e os SLOs.

Considerações

Consulte os pilares Fiabilidade e Eficiência de Desempenho do Azure Well Architected Framework para obter orientações sobre a criação de aplicações escaláveis e fiáveis.

Este artigo explora como aplicar técnicas de modelagem de escalabilidade e desempenho para ajustar a arquitetura e o design da solução. Essas técnicas identificam alterações nos fluxos de transação para uma experiência de usuário ideal. Baseie suas decisões técnicas em requisitos não funcionais da solução. O processo é:

• Identifique os requisitos de escalabilidade.
• Modele a carga esperada.
• Defina os SLIs e SLOs para os cenários de usuário.

Capture os requisitos de escalabilidade

Suponha estas métricas de carga de pico:

• Número de consumidores que usam a plataforma API: 1,5 milhão
• Consumidores ativos por hora (30% de 1,5 milhão): 450.000
• Percentagem de carga para cada atividade:
  • Navegação no produto: 75 por cento
  • Registo, incluindo criação de perfil e login: 10 por cento
  • Gestão de encomendas e subscrições: 10 por cento
  • Visualização de conteúdo: 5%

A carga produz os seguintes requisitos de escala, sob carga de pico normal, para as APIs hospedadas pela plataforma:

• Microsserviço do produto: cerca de 500 solicitações por segundo (RPS)
• Microsserviço de perfil: cerca de 100 RPS
• Encomendas e microsserviço de pagamento: cerca de 100 RPS
• Microsserviço de conteúdo: cerca de 50 RPS

Esses requisitos de escala não levam em consideração picos sazonais e aleatórios, e picos durante eventos especiais, como promoções de marketing. Durante os picos, o requisito de escala para algumas atividades do usuário é de até 10 vezes a carga de pico normal. Tenha essas restrições e expectativas em mente ao fazer as escolhas de design para os microsserviços.

Definir métricas de SLI para calcular SLOs

As métricas de SLI indicam o grau em que um serviço fornece uma experiência satisfatória e podem ser expressas como a proporção de bons eventos para o total de eventos.

Para um serviço de API, os eventos referem-se às métricas específicas do aplicativo que são capturadas durante a execução como telemetria ou dados processados. Este exemplo tem as seguintes métricas SLI:

Aqui estão exemplos de SLIs:

• (Número de solicitações concluídas com êxito em menos de 1.000 ms) / (Número de solicitações)
• (Número de resultados de pesquisa que retornam, em três segundos, quaisquer produtos que foram publicados no catálogo) / (Número de pesquisas)

Depois de definir os SLIs, determine quais eventos ou telemetria capturar para medi-los. Por exemplo, para medir a disponibilidade, você captura eventos para indicar se o serviço de API processou uma solicitação com êxito. Para serviços baseados em HTTP, o sucesso ou falha é indicado com códigos de status HTTP. O design e a implementação da API devem fornecer os códigos adequados. Em geral, as métricas SLI são uma entrada importante para a implementação da API.

Para sistemas baseados em nuvem, você pode obter algumas das métricas usando o suporte de diagnóstico e monitoramento disponível para os recursos. O Azure Monitor é uma solução abrangente para coletar, analisar e agir em telemetria de seus serviços de nuvem. Dependendo dos seus requisitos de SLI, mais dados de monitoramento podem ser capturados para calcular as métricas.

Usar distribuições de percentis

Alguns SLIs são calculados usando uma técnica de distribuição de percentis. Isso dá melhores resultados se houver valores atípicos que possam distorcer outras técnicas, como distribuições médias ou medianas.

Por exemplo, considere que a métrica é a latência das solicitações de API e três segundos é o limite para o desempenho ideal. Os tempos de resposta classificados para uma hora de solicitações de API mostram que poucas solicitações levam mais de três segundos e a maioria recebe respostas dentro do limite limite. Este é o comportamento esperado do sistema.

A distribuição percentil destina-se a excluir valores atípicos causados por problemas intermitentes. Por exemplo, se as respostas adequadas do serviço estiverem no percentil 90 ou 95, o SLO é considerado cumprido.

Escolha períodos de medição adequados

O período de medição para definir um SLO é muito importante. Ele deve capturar a atividade, não a ociosidade, para que os resultados sejam significativos para a experiência do usuário. Essa janela pode ser de cinco minutos a 24 horas, dependendo de como você deseja monitorar e calcular a métrica SLI.

Estabelecer um processo de governança de desempenho

O desempenho de uma API deve ser gerenciado desde o seu início até que seja preterido ou desativado. Um processo de governança robusto deve estar em vigor para garantir que os problemas de desempenho sejam detetados e corrigidos antecipadamente, antes que causem uma grande interrupção que afete os negócios.

Aqui estão os elementos da governança de desempenho:

• Objetivos de Desempenho: Definir os SLOs de desempenho aspiracionais para os cenários de negócios.
• Modelagem de desempenho: identifique fluxos de trabalho e transações críticas para os negócios e conduza a modelagem para entender as implicações relacionadas ao desempenho. Capture essas informações em um nível granular para previsões mais precisas.
• Diretrizes de design: Prepare diretrizes de design de desempenho e recomende modificações apropriadas no fluxo de trabalho de negócios. Certifique-se de que as equipes entendam essas diretrizes.
• Implementar diretrizes: implementar diretrizes de design de desempenho para os componentes da solução, incluindo instrumentação para capturar métricas. Realizar avaliações de design de desempenho. É fundamental rastrear tudo isso usando itens de backlog de arquitetura para as diferentes equipes.
• Testes de desempenho: Realize testes de carga e estresse de acordo com a distribuição do perfil de carga para capturar as métricas relacionadas à integridade da plataforma. Você também pode realizar esses testes para uma carga limitada para avaliar os requisitos de infraestrutura da solução.
• Análise de gargalos: use inspeção de código e revisões de código para identificar, analisar e remover gargalos de desempenho em vários componentes. Identifique os aprimoramentos de dimensionamento horizontal ou vertical necessários para suportar as cargas de pico.
• Monitoramento contínuo: estabeleça uma infraestrutura contínua de monitoramento e alerta como parte dos processos de DevOps. Assegurar que as equipas em causa são notificadas quando os tempos de resposta diminuem significativamente em comparação com os parâmetros de referência.
• Governança de desempenho: Estabelecer uma governança de desempenho composta por processos e equipes bem definidos para sustentar os SLOs de desempenho. Rastreie a conformidade após cada versão para evitar qualquer degradação devido a atualizações de compilação. Realize revisões periódicas para avaliar qualquer aumento de carga para identificar upgrades de solução.

Certifique-se de repetir as etapas ao longo do desenvolvimento da solução como parte do processo de elaboração progressiva.

Acompanhe os objetivos e expectativas de desempenho em sua lista de pendências

Acompanhe seus objetivos de desempenho para ajudar a garantir que eles sejam alcançados. Capture histórias de usuários granulares e detalhadas para rastrear. Isso ajudará a garantir que as equipes de desenvolvimento tornem as atividades de governança de desempenho uma alta prioridade.

Estabelecer SLOs aspiracionais para a solução de destino

Aqui estão exemplos de SLOs aspiracionais para a solução de plataforma de API em consideração:

• Responde a 95% de todas as solicitações READ durante um dia dentro de um segundo.
• Responde a 95% de todas as solicitações CREATE e UPDATE durante um dia em três segundos.
• Responde a 99% de todas as solicitações durante um dia em cinco segundos sem falhas.
• Responde a 99,9% de todas as solicitações durante um dia com sucesso em cinco minutos.
• Menos de um por cento das solicitações durante a janela de pico de uma hora de erro.

Os SLOs podem ser adaptados para atender aos requisitos específicos da aplicação. No entanto, é fundamental ser suficientemente granular para ter a clareza necessária para garantir a fiabilidade.

Meça SLOs iniciais baseados em dados dos logs

Os logs de monitoramento são criados automaticamente quando o serviço de API está em uso. Suponha que uma semana de dados mostra o seguinte:

• Pedidos: 123,456
• Solicitações bem-sucedidas: 123.204
• Latência do percentil 90: 497 ms
• Latência do percentil 95: 870 ms
• Latência do percentil 99: 1.024 ms

Esses dados produzem os seguintes SLIs iniciais:

• Disponibilidade = (123.204 / 123.456) = 99,8%
• Latência = pelo menos 90% das solicitações foram atendidas dentro de 500 ms
• Latência = cerca de 98 por cento dos pedidos foram atendidos dentro de 1000 ms

Suponha que, durante o planejamento, a meta de SLO de latência aspiracional é que 90% das solicitações sejam processadas dentro de 500 ms com uma taxa de sucesso de 99% durante um período de uma semana. Com os dados de log, você pode identificar facilmente se a meta do SLO foi atingida. Se você fizer esse tipo de análise por algumas semanas, poderá começar a ver as tendências em torno da conformidade com SLO.

Orientações para a redução dos riscos técnicos

Use a seguinte lista de verificação de práticas recomendadas para reduzir os riscos de escalabilidade e desempenho:

• Design para escala e desempenho.
  • Certifique-se de capturar os requisitos de escala para cada cenário de usuário e carga de trabalho, incluindo sazonalidade e picos.
  • Conduzir modelagem de desempenho para identificar restrições e gargalos do sistema
• Gerir a dívida técnica.
  • Faça um rastreamento extensivo das métricas de desempenho.
  • Considere o uso de scripts para executar ferramentas como K6.io, Karate e JMeter em seu ambiente de preparação de desenvolvimento com uma variedade de cargas de usuário — 50 a 100 RPS, por exemplo. Isso fornecerá informações nos logs para detetar problemas de design e implementação.
  • Integre os scripts de teste automatizados como parte de seus processos de implantação contínua (CD) para detetar quebras de compilação.
• Tenha uma mentalidade de produção.
  • Ajuste os limites de dimensionamento automático conforme indicado pelas estatísticas de integridade.
  • Prefira técnicas de dimensionamento horizontal em vez de vertical.
  • Seja proativo com dimensionamento para lidar com a sazonalidade.
  • Prefira a implantação baseada em anel.
  • Use orçamentos de erro para experimentar.

Preços

Confiabilidade, eficiência de desempenho e otimização de custos andam de mãos dadas. Os serviços do Azure que são usados na arquitetura ajudam a reduzir custos, porque eles são dimensionados automaticamente para acomodar cargas de usuário variáveis.

Para o AKS, você pode começar inicialmente com VMs de tamanho padrão para o pool de nós. Em seguida, você pode monitorar os requisitos de recursos durante o desenvolvimento ou o uso da produção e ajustar de acordo.

A otimização de custos é um pilar do Microsoft Azure Well-Architected Framework. Para obter mais informações, consulte Visão geral do pilar de otimização de custos. Para estimar o custo dos produtos e configurações do Azure, use a Calculadora de preços.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• Subhajit Chatterjee - Brasil | Engenheiro de Software Principal

Próximos passos

• Documentação de Azure
• Estrutura bem arquitetada do Microsoft Azure
• Estilo de arquitetura de microsserviços
• Design para expansão
• Escolha um serviço de computação do Azure para seu aplicativo
• Padrões de design e implementação
• Arquitetura de microsserviços no Serviço Kubernetes do Azure
• O que é o Azure Front Door?
• Sobre a Gestão de API
• O que é o Application Gateway Ingress Controller?
• Azure Kubernetes Service
• Gateway de Aplicação com dimensionamento automático e redundância entre zonas v2
• Dimensionar automaticamente um cluster para satisfazer as exigências das aplicações no Azure Kubernetes Service (AKS)
• Criar contêineres e bancos de dados do Azure Cosmos DB com taxa de transferência de dimensionamento automático
• Documentação do Microsoft Dynamics 365
• Documentação do Microsoft 365
• Documentação de engenharia de confiabilidade do local
• AZ-400: Desenvolver uma estratégia de Engenharia de Confiabilidade de Site (SRE)

Recursos relacionados

• Aplicação Web de linha de base com redundância de zona
• Monitoramento de aplicativos Web no Azure